一個網路服務做了一陣子，大概就會有人倡議說要做 Open API，開放公司的資料供外界使用，包括合作廠商、甚至更多開發者使用，創造出一個生態圈（Ecosystem）出來。
對公司裡頭的各功能、各部門而言，如果你是業務人員，Open API 有很明顯的好處，工程師呢，看狀況，整體來說對公司有好處；但如果你負責的是產品的發想與規劃，做了 Open API，無異是幫自己製造威脅與壓力。對此，《工程師幹話》一向保持堅定的立場，在大我與小我之間，一定是主張犧牲大我，成就小我。
— -
Open API 是業務人員的武器，在與其他廠商討論業務合作的時候，立刻可以從口袋中拿出來兜售，而且可以同時向許多不同的廠商兜售。雖然能不能談到生意，還是要看業務人員本身的本領，但是 Open API 可以提供火力支援，快速讓對方了解我們已經能夠提供什麼，決定商業上要不要合作，技術上要怎麼合作。
至於工程師方面，就看你的志願是什麼。如果你希望讓更多廠商使用你的作品，擔任業務拓展的後勤，而你的技術能力與貢獻可以被技術社群看到，那麼來做 Open API 或相關的 SDK，就相當不錯。但相對地，你就要拿出上得了檯面的作品，拿出可以被技術社群檢視、公審的設計與工程品質。
你不但要寫程式，還要寫經過設計，別人看得懂、加上測試的程式，你把一個 SDK 的程式碼丟出去沒寫測試，就會有人來指指點點。不但要寫文件，寫的還是英文文件，更是廠商與其他人看得懂得英文文件。你當然不能用 Word 寫，而是要用 Markdown；你要搞懂各種程式碼授權的不同，也要導入 CI，畢竟你把一些程式放在 github 上，如果沒有加上個 travis 的 build success 的貼紙，就整個感覺遜掉。這些事情你上手了、習慣了，回頭來做內部的產品或系統，同樣可以提昇品質。
對工程師本身有沒有好處？如果你立志提昇自己，有，但也不見得每個人都有這種志願。對你的績效有沒有幫助呢？這就要看在你的公司中，哪一方比較有力，以及到底是誰在考核你的績效，畢竟不是每個人都了解工程品質是怎麼一回事。
如果你主管產品規劃，那麼，把 API 這種資源放給外人，降低其他人的進入門檻 — 聽起來就很糟。在一個稍微有點規模的公司當中，用來評估一個 PM 的標準往往不是提案多久創意，規劃多有水準，可以幫公司省下多少成本，而是他怎樣透過話術佔用多少公司資源，讓他的專案可以做出來，其他人都做不出來。既然你做不出來，而是我做的，那麼，就只有我有績效。
Open API 讓大家都可以用來設計、製作新的應用，即使新的應用結合的是我們沒有、對方所有的強項，做出來可以補上自家產品的不足，對提昇公司服務的市佔有幫助，但無庸置疑，這種東西脫離了我們自家 PM 的控制。即使在老闆的層次上，公司與外部廠商是商業合作的關係，但是在 PM 的層次上，顯而易見的，這是拿同樣的資料、可以做出怎樣不同產品的競爭關係。
如果廠商或第三方開發者做不好就算了，如果做得好，那豈不是公司可能會考慮把對方的產品團隊買進來？還會有別人空降進來？有了新歡，是不是就會忘了舊愛？即使我們可能有強大的裙帶關係當做後盾，也不該有絲毫鬆懈，絕對應該要盡可能把持著產品。
說來這份工作真是辛苦，我們光是內鬥就沒時間了，還有人想做 Open API，讓我們跟更多人鬥？光是在魚缸裡頭就夠忙碌了，還要擴大生態圈，把我們放生到大海去？
我們討厭競爭。我們從小就在升學競爭的環境下長大，我們怎麼會害怕競爭、抗拒競爭？就是因為是在競爭的環境下長大，所以競爭是我們的創傷經驗，我們折騰了那麼久，好不容易握有了那麼點的權力，為什麼還要讓競爭傷害我們？為什麼不是由我們來單方向傷害別人？如果可以在小圈圈裡頭，就可以讓權力的邪惡最大化，我們為什麼需要競爭力這種東西？
—
可是，你不該公然反對 Open API，你應該冷處理。原因是：Open API 也是個 buzzword — 人家講這個 buzzword 講到不但要開放資料，還要開放政府呢 — 而我們喜歡 buzzword。
在大多數狀況下，buzzword 很有用，像是什麼大數據啦、機器學習啦、人工智慧啦，都有助於我們寫出超酷炫的提案奪取資源。有些 buzzword 不是那麼有用，但也不應該反對，不要為這些少數影響 buzzword 對我們的整體好處。
初期，你應該冷眼旁觀，不置可否，擺出一種「好吧，就看看你們可以搞出些什麼吧」的態度。然後，你要保持耐心，等待機會，好的獵人要有耐心，好的 PM 也是。
等到 Open API 做到差不多程度，那麼，通常就會找來公司各部門的工程師，舉辦些內部的黑客松，試著揣摹其他廠商的心理，試試看目前提供的 API 可以做出什麼應用，如果都沒有什麼有趣的，這個時候就應該落井下石，說服大家 Open API 花了資源卻沒成效，沒什麼好做的，不如把力氣放在我們所規劃的一堆產品功能上。
但如果某個應用突然讓老闆眼睛一亮，腦袋裡頭的生意經開始轉動，你知道該出手了 — 「這個功能很不錯，我覺得我們應該自己做。」你說。
你不用管現在開發團隊到底在做什麼，他們身上已經有哪些工作量，反正你不用負擔實際的開發成本，你只需要知道一件事情，這是時機，你應該出手。
沒錯，這個東西，我們應該自己做。 — 你太清楚如何接管這種老闆喜歡，但是是由工程師提出，甚至都已經有 POC、甚至是半成品可以 demo 的計畫了。
—
既然，這是一個這麼具有前瞻與策略意義的專案，我們應該要成立一個 Scrum Team。既然 Scrum Team 裡頭沒有 PM、只有 PO，所以我們 PM 進入這個團隊裡頭，即使創意都不是我們發想的、可行性也不是我們評估的，初衷我們也不了解，但理所當然是由我們出任 PO，而既然是 PO，是 Product Owner，我們就取得了所有權。
工程師呢，只要乖乖實作就好。有種關係，用來描述自然現象，叫做寄生；這種關係，在公司裡頭，叫做團隊。這種關係，如果再加上迷人的 buzzword，以及橘逾淮為枳的管理風格，叫做 Scrum Team。
這種 PO 職位很適合作為辦公室政治的犒賞。你當然要選擇底下最安份、最乖順、最聽話、最服從的小 PM 來出任這個 PO，藉以在部屬前彰顯：他們的績效都取決於你的好惡，生殺由你予取予奪。
既然是最乖巧的 PM 來當 PO，在這麼一個團隊裡頭跟工程師一起工作的時候，通常也最搞不清楚狀況，但也沒關係，不管這個職位到底是什麼稱呼，只要能夠做出績效就好。
所以，明明掛的是 Scrum 的 PO，還是要不斷逼問工程師時程，以及寫出密密麻麻的企劃書，圖表精美的投影片，找設計師做出極其複雜、讓實作的人第一眼就看到皺眉的複雜 UI 流程。 — 是的，UI 很重要，重要的不在於好的設計可以如何消除用戶的痛苦，而是因為，UI 是看得到的績效。
—
一個簡單的產品概念，如果想要發展出厚厚一疊企劃文件，有其技巧。就是：你應該預先假設這個產品無比成功，無數用戶口耳相傳、爭相使用、萬人空巷，所以我們也預先規劃成功之後第二版的功能，並且在工程師還在為目前的程式焦頭爛額的時候，就邀請進來參與第二版的討論。
既然我們的產品這麼成功，就應該設想所有用戶情境，免得有哪一種用戶不開心，但是我們不該上街突擊用戶了解需求，如果你不在辦公室，讓老闆看到你在工作，會嚴重影響績效。所以，你應該召開很多會議，在會議室裡頭討論出用戶有哪些需求。像是：如果我們的產品功能被銀河艦隊傳播到了外太空，克林貢人會怎樣使用我們的產品，我們應該怎樣為克林貢人設計 UI，就是個很值得討論的話題。
至於如果這個產品失敗，應該怎麼善後，或是有什麼替代策略，如果工程上殘留了什麼沒有上線的系統的遺跡，會造成什麼技術負債，這種事情，我們不管，因為根本沒有討論的必要：我們規劃的產品，怎麼可能會失敗？
克林貢人來使用我們的產品，這件事情可能會發生，但是產品失敗絕對不可能發生。產品成效如何是由我們自己評估的，數字是由我們詮釋的，怎麼可能會失敗？如果原本的用戶只有兩個人，變成有三個人在用，我們也可以說成是成長了百分之五十，是飛躍的成長，至於最後沒有克林貢人來用，你又怎麼能說，為克林貢人設想是錯的？
不用理會工程師。工程師是一種倔強、自負而又愚蠢的生物。明知道自己的成就已經被人整碗抱走，一樣不會馬上掉頭走人，想走，也會為了證明自己可以把東西做出來，為了一些不知所謂的工程能力，至少把東西做完才走。
我們非常歡迎這種「不是我做不出來，是我不想跟你們玩」的瀟灑態度，既然現在的東西做完了，以後你又不想做，我們又不用負擔工程師的養成成本，你本來就沒有什麼利用價值，走了又不會有人出來搶奪功勞、分走一份獎金，我們也樂得輕鬆。既然人不在了，接下來如果出了什麼問題，還可以繼續往你身上卸責，進行後續的人格謀殺。
由於我們實在太喜歡 buzzword 了，Scrum 還不夠，我們還應該加上 Lean Stratup 的概念，這樣的產品，嗯，我們還是要叫他 MVP。喔喔！我們又有新的產品上線了！雖然這個產品，由第三方來做可能會更好。
—
這篇文章講的是 Open API，在結尾前，還是來說一下 Open API。
呃，想想做這個產品的人力是從哪來的？誰還管你什麼 Open API？
