敏捷外包工程系列之二：人員結構（敏捷外包工程，敏捷開發，產品負責人，客戶價值）
敏捷開發整體上適合小團隊、產品研發（所以才有product owner一稱）的環境，而外包軟體開發中常常存在的則相反，因此在建立團隊的時候要充分認識到這一點。
下文提到“企業”時指軟體開發公司即乙方，而“客戶”指政府、銀行等採購軟體的甲方。這裡將其稱為企業的目的是與傳統意義上的“開發團隊與客戶”提升到“軟體開發企業與客戶”的高度，從而更好地理解一些非技術問題問題。
Product Owner產品負責人的人選
聽到無數次有人說“我們的Product Owner就是客戶，因為所有需求都是客戶提的”，其實這樣做極度危險。
Scrum開發理念提出前的環境大致如此：一小群開發人員（3～9人），內有專案經理髮號施令，外有銷售人員指手畫腳，團隊加班加點苦不堪言。因此Scrum提出了要自組織的概念，接下來發生的故事大致如此：自組織需要代價；結果導致分權；開發組獲得的權力是計劃與技術；開發組放棄了需求管理權。剩下的是，誰應該得到需求管理權？
在產品研發環境中，這一職責自然地落到產品經理（或其他類似職責）手中，他們將與市場、客戶、高層溝通，完成需求管理工作。
在專案開發環境中，由於沒有為需求負責的產品經理，所以大家自然而然地想到了客戶或銷售人員。
其實，Product Owner負責的不只是把需求說出來，還應該為需求背後的商業目標負責，而這一點客戶或銷售人員做不到。
完整地解析Product Owner的職責，將包括：
1. 描述需求
2. 為需求排序
3. 為客戶價值負責
4. 為客戶群價值負責，即長期、廣泛的客戶價值
5. 為由滿足客戶價值而帶來的乙方企業商業利益負責
客戶或銷售人員可以實現123，但對45則不會當作首要驅動力，極易出現問題。單個客戶會因為過於突出自身利益而傷害企業的的其他客戶，銷售人員則會因為過於關注自己負責的客戶而傷害企業的其他客戶，並進而影響其企業的整體利益。
鑑於這個是軟體外包中存在的主要人員問題，下面將以主要篇幅加以描述。
為了滿足對45的管理，以下人員適合擔當PO：
1. 乙方的專案經理
其工作方式是與客戶溝通需求，確保正確實現客戶價值。但其績效應由企業判斷，也就是說“通過實現客戶價值，帶回來多少企業收益”是其主要考核點。
其工作心法受到兩方面制約：一方面要滿足客戶保證收款，一方面要保證利潤率。
以往一般的做法是銷售/開發割裂開，前者從合同總額提成，後者沒有提成只對進度質量成本負責。結局是如果本來100萬能做的單子被籤成50萬，銷售人員仍然有提成（個人認為把兩個100萬的單子都當50萬賠本賣掉，比把其中任何一個100萬賣掉的難度都小，再加上“100萬”這個數字誰也無法檢驗，這導致銷售人員的心法越來越傾向於前者），而專案經理則幾乎只能面對失敗。
合理的做法，是以各種方式將兩者的責權交織一下，交織的方案試情況定，下舉兩個實際例子。
A. 某電信研發企業
其銷售績效機制不明（當時筆者沒有問）；專案組擁有X%的合同總額作為獎金。
其運作方式是以季度為結帳週期，每月商討需求，配合功能點報價作為內部工作量計算的參考依據。由於採用短週期交付，專案組比較容易逐漸建立“生產率”的概念，即使這種生產率不是準確量化的，所能提供的參考價值也能保證不會出現太大的偏差。這裡提到的“太大”的偏差包括準確性上的百分比偏差，也包括合同總額的巨大偏差。
為了保證短週期交付，他們採用敏捷開發方法。
點評：未來軟體開發將更多地向服務而非技術專案轉型。前者將更多地使用連續式的交付方法，需求將更多地逐步被發現而非一次發現，在此類專案中實施敏捷將是一個趨勢。在一些業務變化很快的領域如電信行業，這已經成為現實；銀行業在邁進（儘管他們從來不提“敏捷”二字）；政府專案處於落後狀態，有其政策變化不會太快的因素。
B. 某產品+實施企業
其銷售與專案經理合二為一。績效機制是從淨利中提成X%，需要扣除各種實際費用和實施費用（包括實施和售後的人工費用）。若提成已經全額提取，而又發生了費用，則記賬在下一單中。
其運作方式是銷售全程乃至在實施完成後仍關注客戶和專案，一則需要客觀地推測實施所需成本（可比照為研發所需成本），二則“下一單記賬制度”促使他們不斷促進客戶二次採購產品或服務以平掉費用。
點評：在專案合同洽談的早期如何估算專案是個難題，這家企業也不例外（實際上國外已經解決並且應用地很好，國內也正在制定國標，在以後的早期估算篇中詳述）。但即使沒有量化的方法，當制度設定合理，其導致的心法也將起到很大作用。因此切勿因為沒有方法而一“嘆”了之。或者反過來說，無論你用什麼精度的神奇方法，如果銷售的心裡一心想的就是把100萬弄成50萬賣掉，這個神奇方法就一定會失敗。
2. 乙方的部門經理、區域經理、行業經理
這些人不適合擔任一線PO就是負責需求收集與傳達的人，而是適合組建PO團隊（在139團隊系列中有描述，本博文完成時尚未編寫），並擔任其團隊領導。
常見的情景是銷售人員或專案經理都希望將自己的專案重點對待，多投人多投力，或者為自己的客戶多製作一些免費的“開拓性功能”由公司承擔成本等等。這時候需要更高一個級別的人來把控。
此人必須站在更高更廣更長期的位置來把控走向，因此為其設定的績效也往往更長期，乃至將其職位的升遷作為主要績效回報方式，由於外包企業組織龐大，這種方式往往可行。
Scrum Master人選
1. PPQA過程與產品質量保證人員
如果是產品研發，我會推薦專案經理，但在外包企業中，往往有上百乃至上千的專案經理，讓他們能以統一的方式運作專案是非常困難的，甚至連培訓的費用都很驚人。
很多專案經理還會拿敏捷方法對抗原來的CMMI方法，造成矛盾。
PPQA是原來CMMI體系下的角色，人員配比一般為1～2%左右比專案經理少很多，如果讓他們同時瞭解CMMI和敏捷，會對公司制度貫徹帶來極大便利。
如果公司沒有過CMMI，但也有過程改進人員，則一樣適用。
風險在於做CMMI的時候一般心法都比較“死”，常常喜歡條文化、制度化，而忽略了實用化。因此PPQA的組長（或其他更高負責人）的要求很高。
“找不到這麼好的人怎麼辦？”這是個公共困難也沒有太好的答案，唯一提示是內部培養永遠比空降更好。這並不是培養世界級的科學家的過程，2～3年足以。
2. 專案經理
小公司或重點專案可以考慮。
團隊
這個和產品研發基本一樣，唯一的問題是有時規模較大，人員流動率高，還有一人多專案問題。
1. 大規模團隊
請參考139系列文章（本文編寫時尚不存在）。
解決思路是靠師徒制度來維繫較大團隊的溝通問題，並依靠其學習機制促進團隊的擴張。
2. 人員流動率高
解決思路是儘量保持組長/小組長（師傅）的穩定性，他們人數較少，給以較高工資比較可行。另外“成為技術主管”的需求被滿足，也可換取更長的留任期。
3. 一人多專案
很多企業都有的問題，但實際上是一個很差的實踐，尤其在沒有建立專案群管理的時候。
簡單的數學計算是：倘若10個人參與10個專案（每人都參與每個專案）需要10個月讓所有專案同時完成，則如果讓他們10個人同時負責1個專案，待完成後再進行下一個專案，則不用10個月所有專案都可以完成，因為減少了“思路的奔波成本”。當然這是理想情況，因為如果換成100個人100個專案，總不能讓100個人同時負責1個專案吧。
解決之道之一是儘量保持正在啟動專案的數量不要太多。在故事板的應用中就有一個最佳實踐：同時開工的故事數不能太多，做完一個再做一個，因為會分散精力。專案的尺度比故事大得多，問題也會更嚴重。很多時候會被所謂迫於壓力而提前啟動專案，則合理的順序是先讓139團隊的組長進入，其次安排小組長進入，最後安排組員進入。這樣組長/小組長就可以被認為“長期呆在此專案中”，而不會面臨太多切換問題。組員的工作相對深度較小，受到切換的影響小。
解決之道之二是儘量保持高手的穩定性，比如每個高手可能只串1～2個專案，在他們忙的時候可以申請新手幫忙，這些新手則可能串更多的專案。高手的注意力集中了，專案的質量、進度都有保證。早期微軟曾經做過測量，發現穩定的團隊比臨時團隊的效率高50%，換言之即使穩定團隊每工作一年閒著半年，也比讓他們解散分散到其他團隊強。在外包公司閒半年是不現實的，但是保持核心骨幹的穩定還是可行的。
外包工程人員結構的核心是Product Owner的人選，必須認識到PO是企業和團隊的一員，他從技術上到需求上到商業目標上，都應該是首先服務於企業和企業利益，其次服務於客戶和客戶價值，並通過後者來成就前者。
由於人數眾多而且多數在CMMI體系下已經建立了管理方法，推薦外包企業將原有CMMI過程改進人員培養為Scrum Master，以便於將CMMI與敏捷完美結合。
“一人多專案”的問題可通過團隊的層級結構來解決，應儘量保持組長/小組長不要太過頻繁切換。
其實在選定人員之前就早應該解決的問題是：敏捷鼓勵變化鼓勵創新，但倘若我在做一個定額定期定需求的專案，敏捷開發到底有用沒有？這是下篇要討論的話題。
點選下載免費的敏捷開發教材：《火星人敏捷開發手冊》
