新管理思維6月活動-寓意科技大規模外包管理與分散式組織

在談論Paul分享的內容前，我先摘要一下為何當初我聽完寓意科技公司的經營方式就決定有一天一定要找他來跟大家分享。

我自己從事軟體專案管理工作多年，我非常清楚外包工作的困難，我還記得在3.4月的某一天Geng約了我，說要介紹Paul給我認識，我還記得我們是約在北車附近的漢堡王，碰了面我才知道Paul是我中央資管的學弟...XD

簡單閒聊後，開始聊Paul的公司在做些什麼，他告訴我他們是一間接案的公司，一開始我以為就是一般的工作室，直到他跟我說：

「我們不養工程師，我們只養PM。」

這句話引起我的好奇，因為就我過去的經驗，一般的接案公司或SI廠商，PM跟工程師都自己養，結案率就已經低的可憐了，寓意科技這種經營方式，要怎麼做才能營利？

Paul自己在演說過程中就有提到接案公司的狀況，以下是美國的數據，接案公司所乘接的案子中，只有32%左右是如期如質如預算完成的，而44%則是超過預算、超時或刪減功能下完成，也就是說能順利結案的，大約就是7-8成。

而寓意科技能做到5-6成的如期如質如預算，這個數字又引起我第二層興趣。

他告訴我，他們合作的工程師團隊有超過一百人，到目前為止做過專案也做過產品，而營收來源很大一部分都來自與海外，原因無他，就是利潤高。

我進一步了解PM與外包工程團隊間的分工，他說基本上接案、談需求與客戶溝通的主要都是PM，而工程師團隊則專注於把系統開發好，把品質顧好，在這樣的分工下，獨立工作者或工作室的工程人員們可以更專注地去做擅長的事，而其他事，則由寓意科技來搞定。

而為了同時兼顧品質與彼此的合作愉快，在每個案子結束後，PM會對每個工程師進行評價，而工程師也一樣會評價PM，這個做法的好處我認為有三：

1. 能找出工程師技能與態度面的問題，且工程師會希望把案子做好，否則多次評價不佳後下次可能沒案子做，反過來，PM也會有一樣的動力
2. 工程師與PM間即使在評價上給了彼此低分，但有時只是溝通上出狀況，不意味著哪一方有明顯問題，只是不適合，那下一次在安排專案時或許就能把彼此錯開
3. 評價的內容涉及專業能力的評價，這是很有用的資料，往後一個案子準備要開始前，只要設定一下這個案子所需要的技術以及專案時間，就能直接找出最適合的工程團隊，這是規模化管理能帶來的直接好處之一

寓意科技的分散式組織管理之道

Paul在分享的開頭用這張投影片，點出了他當初切入接案公司的關鍵原因，他認為在網際網路時代，技術不斷的推陳出新，變遷速度極快，企業要面對這樣多變的環境，如果總想著凡事自己來，或許不是最恰當的解決方法。

我也補充一下我在數據力課程中談到的一個觀念，「創業初期，你應該盡可能的降低固定成本，而把成本轉到變動成本上」，對企業來說，你聘請一個正職員工，你承擔的是固定成本，不管他有沒有創造效益，你每個月就是要固定支付這樣的費用，此時你應該優先思考外包的可能性。

分散式組織-Decentralization

Paul在緊接著的分享中提到，過去企業習慣自己建立團隊，自己成立各種功能型部門，自己掌握所有的控制權，但隨著時代變遷，他認為以後企業應該要更習慣於分散式團隊，組織架構不再是科層式，而是網狀式；也不再是一家公司全包，而是個別function都由不同的外包團隊負責。

而這個想法，也是我先前談過的趨勢，企業組織架構會從內部往外部延伸。

In-house or Outsourcing

技術多且雜，而且愈來愈多人成為自僱者(或者反過來說不想受僱於人)，在這樣的氛圍之下，企業也必須要思考你到底要繼續用In-house的正職人員，或者要乾脆考慮Outsource出去，而下面這張投影片則是Paul認為這兩個選擇之間的差異或難處。

我個人的觀點一直都是「要嘛解決問題，要嘛被問題解決」，如果你希望降低固定成本，但又希望外包品質能顧的好，那可行的做法之一就是好好的思考如何做好外包管理，我認為這是接下來所有企業都需要好好思考的一項任務。

以寓意科技來說，Paul思考的是「共存」，也就是PM in-house，工程師 outsourcing，讓彼此可以專注於擅長的工作上，這是一種新的功能型組織，也是我認為未來組織的會出現的新樣貌-讓多家公司運作的像一家公司一般。

然而，不管怎麼說，在未有完善機制前，外包的問題始終還在，如果你在公司內負責過外包，你就會知道外包管理的困難不僅僅在工作本身，更難搞的還有幾件事：

1. 兩家公司間的合約關係，凡事都要按著合約走
2. 兩條不同report line的問題，你甲方希望這樣做，乙方卻有其他考量
3. 外包團隊不在公司內on-site，不知道人會被叫去做什麼
4. 其實最嚴重的就是彼此之間是靠合約約束，缺乏信任感的問題

而這樣的問題Paul分享了他如何處理，針對in-house的PM，他認為能認同公司的文化是最核心的議題，這一點甚至勝過能力，因為能力好培養，但性格與價值觀卻很難改變，因此他花了更多的時間在招聘上。

而這件事，也跟我一開始聽到這個寓意科技的經營模式時想到的問題一致，我認為PM的培養非常難，因為要能找到願意背負商業到開發責任的PM本來就很難，意願、能力、特質都要能匹配上，難度真的很高。

而在PM養成上，他很強調讓PM將工作重點放在處理專業且困難的事情上，簡單的說就是著重於高價值的工作上，讓PM的工作更加focus，這樣才能有效縮短養成時間，也更能聚焦於產生價值。

最後提到一點，就是文件，他提到Google工程師花在寫文件的時間跟Coding的時間幾乎是1:1，同樣的，這樣的要求也同時出現在外部的工程團隊身上。

那他對Outsourcing的團隊又怎麼看呢？

他認為PM是核心樞紐，他必須要能好好與工程團隊溝通，並盡可能的不讓團隊浪費時間，這一點是關鍵中的關鍵，因為這通常意味著，你必須要有明確的需求、較完善的文件，好的時間分配與正確的決策能力，否則這些優秀的工程師將會選擇不再與你合作，你可用的資源也會愈來愈少。

這種把外包工程團隊當客戶對待的心態，讓我想到平台經濟的供需兩端，寓意科技是平台，媒合了供應方(工程團隊)與需求方(企業)，而PM則居中扮演著為兩方創造價值的角色，從這個角度來看，兩方其實都是寓意的客戶。

這有別於過往將外包團隊當乙方對待的心態，也是我認為未來企業與外包商之間產生的另一種夥伴與依存關係，我建議企業領導者們都應該好好的思考這件事。

PM的關鍵與價值何在？

PM在分享的最後一段談到了這個議題，PM培育、運作的關鍵是什麼？他認為要讓PM能真正解決"管理"的問題，並提出了以下幾件關鍵舉措：

1. 建立PM的標準化程序，Statement of Work，這對於工作相對明確的崗位來說是很常見的東西，但對PM來說，我很少看過有人會寫Statement of Work，主因是PM的工作既多且雜。不過當初我聽他說寓意要把這些都標準化下來時，我心裡是有點興奮的...XD，終於有人要來搞這件事了
2. 重視PM的教育與成長，要同時培訓他們IT與產品的知識，這觀點與我一致
3. 要持續評量與累積工程師數據，你只要想想，以後有個案子來了，有個演算法能迅速的幫你按技能、時間、工程師品質，從最高分到最低分，馬上給你三組工程師團隊建議，你不會覺得酷斃了嗎？
4. 讓工程師得到有效的文件，這通常意味著PM必須要具備撰寫這些文件的能力，那天Paul提到，他團隊中12個PM，技術出身與非技術出身的比例很接近，但不管你會不會技術，你都要能做wireframe，要能寫User Story，要能寫API文件....

然而，當PM身上擔了這麼多責任，若不能給PM一些對等的權力也說不過去，所以他認為PM手上應該要有三個武器，分別是：

1. 能換掉客戶(營運團隊)的權力，極端一點當然是不做案子，稍微和緩一點的作法是請客戶端換窗口，否則放著無法與PM溝通的窗口也不好
2. 能換掉工程師並且永遠有備案的權力，如果工程師在專案進行過程中有任何主被動而導致配合度不佳的狀況，PM應該有權力去替換掉
3. 開發的技術那麼多，就算是技術背景出身的PM都不見得總是能搞定每個問題，若開發過程卡住了，他必須要有人能call help，而這些人就是長年下來寓意所累積的技術人脈，可能是外部朋友、工程團隊或內部成員

連著兩位講者的分享都很精彩，最後的提問我覺得也很棒，下次應該現場錄影才對。