某論壇上關于如何建設管理軟件團隊的一些問答，其中一些對話頗有意義，記錄之，分享之。

Q: 啥子是Programmer manager
A：program manager的program不是程序啦。。。一般管一個business domain的end to end solution. 在甲方的話，一般還會分成幾個team，下面的service manager管operation和client management，還有initiative manager管一堆project manager來deliver project。

Q: 請教一下，從帶10-20人到帶更多的人，最需要注意的是什么？

A：
請教不敢，我就是完全失敗的一個典型，呵呵，經驗教訓可以簡單說說。

我自己的經驗，其實技術團隊的管理， 真正質變的大概是從超過25-30人起， 道理很簡單。 一個人可以直接充分管理的人大概就是4-5個為佳， 25個以內，分組就可以，超過25/30個以后就必須分3層，管理成本就開始劇烈增加，啥問題都出來了。
二層結構的時候，下面人有問題容易及時修補，對小組leader的協調能力要求不高，只要負責即可，這種情況下基本沒有多少管理成本。但是到了三層結構以后對第二層的人要求比較高，如果沒有合適的第二層人員，就基本是個亂攤子。老大這時候主要的工作，其實就是應該在人數超過50之前，盡可能快的培養出適合第二層次的負責人，而不是急著做大導致整天忙著救火。另外分層架構的一個必然問題就是容易產生幫派和分離勢力，不注意這方面出現的內耗殺傷力極大。所以對下屬馬仔頭目的監控會耗費你比較多的精力，而且同時還要充分考慮到如何讓這些小流氓敏感脆弱的心理感覺到尊重。


我自己感覺50個人左右時是個大坎，如果可以突破就可以順利向三層的黑社會組織結構發展，可以過度到100人以上，我們那時候的問題就是老板其實并沒有意思到管理成本這個問題，錯誤的以為可以通過規模追求效益。在基本能突破50個人這個坎的時候，老板被上年的產值弄混了頭，盲目發起了一場新戰役，又空降了一個一心想做大事的牛人，兩人一合作，就一起over了。我們當時的架構，老板熱衷于搞大合并，把幾個事業部合并了弄個大部門，把一些馬仔頭目拆分的亂七八糟的，說是充分利用資源，打破部門間的壁壘（扁平化管理？)，然后又亂七八糟塞了一大堆人進來，原來的三層結構徹底打破，結果變成無人負責制。

軟件項目的團隊規模，個人還是覺得越小越好，可能的情況下盡可能走小而精的道路，在培養了團隊成員的默契和一些共同的文化認同以后，再逐步拆分擴充，要比一開始就上大攤子有效的多。 我們之前成功的一個項目，最初的預算是60人，我采取的做法現在看起來非常明智，首先只找了1，2個核心的程序員和少數的普通程序員，通過結對開發的方式讓他們彼此熟悉和磨合，在這個過程中完成基本的核心開發，在2個月以后再補充第二批程序員，把原來人分拆重新結對。通過這種方式逐步過度到20-30的團隊。 再往后考慮到個人能力和管理成本的問題，就拒絕再加入了，最后以項目規劃的1半左右的資源就完成了開發工作。而且這期間培養了不少人，大部分人后來又補充到其他項目，逐步建立了整個部門技術團隊。這種逐步圈地的做法比較穩妥，也容易培養團隊之間的信任文化，那時候整個工作氣氛還是蠻好的，我們是公司最少加班的團隊，但是是公司開發效率最高的團隊。而其他幾個規模只有一半，一開始就砸進幾十個人的項目，都是問題多多那種。

100個人以上的團隊，我只見過，沒管過，，基本上我覺得戰斗力要比50人甚至30人低，吵架pk聊天時間多過做事時間，別相信啥1+1>2 。最近聽朋友說XXX為了保證銷售額，把銷售人員增加了1倍，銷售人員任務降低一半，這種規模游戲也就是騙領導有用吧，地球人都知道，橫豎能干活的就是那么幾個人。

對一個leader來說，我自己的感覺就是4，5個人的時候啥都可以不管，自己把活干大頭就好了，要有nb的小弟就扔給她做。 10來個人的時候，就要注意大家吃喝玩樂心情愉快，因為到了這個規模，基本上靠個別牛人發飆已經不可能搞定工作了，需要你去努力拍下屬的馬匹投其所好，讓他們賞臉做事，而且一定要有風險控制機制，關鍵工作崗位一定要有backup。規模再往上走，自覺往后面站，基本上你工作的中心就是要培養一批打手讓他們自己折騰自己。


P：
Q： 受教了，多謝分享！
一個問題就是：在2個月以后，團隊開始擴充時，如果仍然采用結對的方式，而不是傳統的分組（幾個人一個小組，然后選拔組長），如何保證隊伍具有非常一致的目標和想法，如何保證團結？

A：
軟件工程里面有個著名的brook定理，大意就是向一個進度落后的項目加人，只會讓這個項目更加落后，引申開來就是應該避免在項目的中后期大幅度加人。 這里面的主要的原因有幾點。

1. 新人加入團隊以后需要獲取團隊成員的信任和尊重，這需要比較多的溝通和交流成本，軟件開發說到底是一種群體活動。
2. 新人要理解，認同團隊的文化，也需要很大的成本
3. 新人需要對項目進行學習和了解，過程會拖累其他開發人員
4. 新人太多，有可能會徹底摧毀原來團隊已經建立的平衡結構，比如團隊文化， 團隊間的角色定位。
5. 管理者會因此大幅度的增加管理成本，另外，管理者很可能并未做好管理這樣團隊的準備，有可能會因為不合適的行為和決定導致團隊崩潰
6. 人員增加以后，彼此之間的交流溝通成本會大幅度增加，超出一般人的想象。

因此一般正確的做法是避免在項目中后期加人，雖然這么顯然簡單的道理大部分老板都不相信。

所以表面上看，逐步圈地的做法是違反brook定理的。但實際情況，恰恰因為結對工作在很大程度上克服了上述的問題，所以你要是理解了結對的收益，就可以明白為什么結對可以保證“隊伍具有非常一致的目標和想法，保證團結”


1. 結對可以讓新人之間加快了解過程，盡快的融入團隊， 不使用結對的方式，一個新人可能需要1，2周才能和團隊相處融洽， 使用結對的方式以后，1，2天就可以很熟悉。

2.結對降低了新人的學習成本，在結對過程中，原團隊的成員采取人盯人的方式盡快的將技能和團隊文化傳遞給新人，而新人一開始就可以上手工作（即便是菜鳥，在結對過程中也可以通過質疑和提問對老人提供幫助和監督，而出于維護個人的自尊，團隊成員一般都會急于向新人推銷，證明自己），更有成就感和歸宿感。對團隊也就更容易認同。

3. 結對是分而治之的，有助于避免新人因為陌生環境產生分離感，建立自己的幫派。 有助于強制性的向新人灌輸團隊的目標，保證團隊的團結。習慣了結對的工作模式以后，程序員之間必須強制性的進行溝通和交流，也可以避免產生幫派和內耗。

4.作為boss更關心的一點就是，通過結對這種方式，可以獲得足夠的backup，可以避免因為人員流動給項目帶來毀滅性的風險。因此可以大幅度的降低管理成本。我們項目中期流失了近三分之一的人，進度沒有受到任何影響，所以前期boss極力反對做pp，后期大力支持。我們自己有過一個大致統計，正常情況下離職一個人，要損失至少半年的人工。

通過結對這種方式，互相之間建立了溝通和信任機制，再劃分如果有目的的小團隊，就比較自然，另外在不同的小團隊之間交換結對伙伴也可以做激勵和監督作用。而一次性投入的建設新團隊，碰到的問題會更多。

這個項目其實失敗的一個地方就是中期迫于人員流動而放棄了結對，最后導致幫派和內耗，糾正過來化了血本，否則還能做的更好。人員流失有一部分是因為個人當時管理經驗不足，對問題的解決欠妥，還有一個原因是原材料不合適，老板在團隊組建之初盲目的招來了一些并不適合的人（后來碰到一個老板，居然跟我提招10留1的理論，Orz），也為后來的內耗埋下了隱患。這也算是一個經驗，團隊成員的選擇leader一定要過問，對于那些性格比較偏激，難以控制的人應該盡量回避，絕不可以因為資源緊迫就充數。

按：pp的工作方式，對團隊成員性格有一定要求。
Q：
任何團隊的組織劃分，一定不是用技術最好的人來做leader。對技術好的人要進行壓制。不管有多出色，都要盡力扶持聽話的人。
找技術好的人是對的，但是他技術好，你技術不好，就面臨挑戰了。何況技術好，不聽話的，到哪里都是干活的命，沒有人會重視他們的。

A：
你老外說話也不真見外，按你這樣管， 幾天大家就造反了。

軟件團隊和一般的團隊區別非常大， 對軟件團隊來說，最好的管理模式就是不管理， 讓大家自己發揮，做好足夠的引導工作就好。小團隊leader身先士卒起個帶頭示范左右，大團隊， leader要躲在后面做好后援當保姆。 技術好的人的做leader是非常自然的，不懂技術的人做負責人倒是比較容易引起問題，技術人員都比較驕傲，除非是個美女mm帶頭，那還可以忍忍。 不是說不懂技術的人做不好pm，但是沒有技術背景的人天然就和技術人員有鴻溝，技術人員背后搞的小九九，花樣那個多，所以沒有技術背景，管理成本會比較高。

有個老外專門寫了本書論證為啥技術好的人就該做leader， 你可以找找看。

按：管理層對技術人員的不尊重和粗暴壓制， 才是技術人員不聽話的一個重要原因。

Q：
說起來， 管理無所謂，只要肯聽話的，這個是永遠的原則。
聽話的，能力也強的--這當然最好的，但是一般聽話的能力都比較一般。要是能力強，不聽話，最好不要，這樣的人， 很容易出問題。

A：
軟件開發和普通的項目是有根本的差別的，軟件本質還是個體的腦力勞動， 所以軟件的生產力完全取決于個人的能力和工作態度。 2個程序員之間工作效率的差別可以輕易超過10倍， 所以你找找再多聽話的人又有什么用？

能力的問題可以舉個真實例子： 某500強企業開發的一個業務系統， 投入近20個人， 歷時2年至今還不能上線。而同樣的東西，在另外一個團隊只是2個人一個月的工作量而已。第二個團隊的平均人工是要低于第一個團隊的。

態度的問題也可以舉個真實例子： 某公司開發的一個應用系統，4個人組成的驗收團隊測試了5個月只找到40個的缺陷， 系統提交客戶以后，客戶方自己組織測試，3天內就發現了40個以上的重要缺陷。


任何一個公司，都必須有聽話（執行者）和不聽話的人（創造者和破壞者）的存在，否則這個公司就離死不遠了。 管理要的不是簡單的聽話與否，管理者關心的應該是可控和有效性。

Q：
為了達到目標，有效性就是聽話，完成任務達到目標可控性，也就是要聽話。

A：
算了，讓我去死吧。

按：管理人員和技術人員的溝通真是雞同鴨講，呵呵。