某論壇上關(guān)于如何建設(shè)管理軟件團隊的一些問答，其中一些對話頗有意義，記錄之，分享之。
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。
A：
請教不敢，我就是完全失敗的一個典型，呵呵，經(jīng)驗教訓(xùn)可以簡單說說。
我自己的經(jīng)驗，其實技術(shù)團隊的管理， 真正質(zhì)變的大概是從超過25-30人起， 道理很簡單。 一個人可以直接充分管理的人大概就是4-5個為佳， 25個以內(nèi)，分組就可以，超過25/30個以后就必須分3層，管理成本就開始劇烈增加，啥問題都出來了。
二層結(jié)構(gòu)的時候，下面人有問題容易及時修補，對小組leader的協(xié)調(diào)能力要求不高，只要負責(zé)即可，這種情況下基本沒有多少管理成本。但是到了三層結(jié)構(gòu)以后對第二層的人要求比較高，如果沒有合適的第二層人員，就基本是個亂攤子。老大這時候主要的工作，其實就是應(yīng)該在人數(shù)超過50之前，盡可能快的培養(yǎng)出適合第二層次的負責(zé)人，而不是急著做大導(dǎo)致整天忙著救火。另外分層架構(gòu)的一個必然問題就是容易產(chǎn)生幫派和分離勢力，不注意這方面出現(xiàn)的內(nèi)耗殺傷力極大。所以對下屬馬仔頭目的監(jiān)控會耗費你比較多的精力，而且同時還要充分考慮到如何讓這些小流氓敏感脆弱的心理感覺到尊重。
我自己感覺50個人左右時是個大坎，如果可以突破就可以順利向三層的黑社會組織結(jié)構(gòu)發(fā)展，可以過度到100人以上，我們那時候的問題就是老板其實并沒有意思到管理成本這個問題，錯誤的以為可以通過規(guī)模追求效益。在基本能突破50個人這個坎的時候，老板被上年的產(chǎn)值弄混了頭，盲目發(fā)起了一場新戰(zhàn)役，又空降了一個一心想做大事的牛人，兩人一合作，就一起over了。我們當(dāng)時的架構(gòu)，老板熱衷于搞大合并，把幾個事業(yè)部合并了弄個大部門，把一些馬仔頭目拆分的亂七八糟的，說是充分利用資源，打破部門間的壁壘（扁平化管理？)，然后又亂七八糟塞了一大堆人進來，原來的三層結(jié)構(gòu)徹底打破，結(jié)果變成無人負責(zé)制。
軟件項目的團隊規(guī)模，個人還是覺得越小越好，可能的情況下盡可能走小而精的道路，在培養(yǎng)了團隊成員的默契和一些共同的文化認同以后，再逐步拆分擴充，要比一開始就上大攤子有效的多。 我們之前成功的一個項目，最初的預(yù)算是60人，我采取的做法現(xiàn)在看起來非常明智，首先只找了1，2個核心的程序員和少數(shù)的普通程序員，通過結(jié)對開發(fā)的方式讓他們彼此熟悉和磨合，在這個過程中完成基本的核心開發(fā)，在2個月以后再補充第二批程序員，把原來人分拆重新結(jié)對。通過這種方式逐步過度到20-30的團隊。 再往后考慮到個人能力和管理成本的問題，就拒絕再加入了，最后以項目規(guī)劃的1半左右的資源就完成了開發(fā)工作。而且這期間培養(yǎng)了不少人，大部分人后來又補充到其他項目，逐步建立了整個部門技術(shù)團隊。這種逐步圈地的做法比較穩(wěn)妥，也容易培養(yǎng)團隊之間的信任文化，那時候整個工作氣氛還是蠻好的，我們是公司最少加班的團隊，但是是公司開發(fā)效率最高的團隊。而其他幾個規(guī)模只有一半，一開始就砸進幾十個人的項目，都是問題多多那種。
100個人以上的團隊，我只見過，沒管過，
對一個leader來說，我自己的感覺就是4，5個人的時候啥都可以不管，自己把活干大頭就好了，要有nb的小弟就扔給她做。 10來個人的時候，就要注意大家吃喝玩樂心情愉快，因為到了這個規(guī)模，基本上靠個別牛人發(fā)飆已經(jīng)不可能搞定工作了，需要你去努力拍下屬的馬匹投其所好，讓他們賞臉做事，而且一定要有風(fēng)險控制機制，關(guān)鍵工作崗位一定要有backup。規(guī)模再往上走，自覺往后面站，基本上你工作的中心就是要培養(yǎng)一批打手讓他們自己折騰自己。
P：
Q： 受教了，多謝分享！
一個問題就是：在2個月以后，團隊開始擴充時，如果仍然采用結(jié)對的方式，而不是傳統(tǒng)的分組（幾個人一個小組，然后選拔組長），如何保證隊伍具有非常一致的目標(biāo)和想法，如何保證團結(jié)？
A：
軟件工程里面有個著名的brook定理，大意就是向一個進度落后的項目加人，只會讓這個項目更加落后，引申開來就是應(yīng)該避免在項目的中后期大幅度加人。 這里面的主要的原因有幾點。
1. 新人加入團隊以后需要獲取團隊成員的信任和尊重，這需要比較多的溝通和交流成本，軟件開發(fā)說到底是一種群體活動。
2. 新人要理解，認同團隊的文化，也需要很大的成本
3. 新人需要對項目進行學(xué)習(xí)和了解，過程會拖累其他開發(fā)人員
4. 新人太多，有可能會徹底摧毀原來團隊已經(jīng)建立的平衡結(jié)構(gòu)，比如團隊文化， 團隊間的角色定位。
5. 管理者會因此大幅度的增加管理成本，另外，管理者很可能并未做好管理這樣團隊的準(zhǔn)備，有可能會因為不合適的行為和決定導(dǎo)致團隊崩潰
6. 人員增加以后，彼此之間的交流溝通成本會大幅度增加，超出一般人的想象。
因此一般正確的做法是避免在項目中后期加人，雖然這么顯然簡單的道理大部分老板都不相信。
所以表面上看，逐步圈地的做法是違反brook定理的。但實際情況，恰恰因為結(jié)對工作在很大程度上克服了上述的問題，所以你要是理解了結(jié)對的收益，就可以明白為什么結(jié)對可以保證“隊伍具有非常一致的目標(biāo)和想法，保證團結(jié)”
1. 結(jié)對可以讓新人之間加快了解過程，盡快的融入團隊， 不使用結(jié)對的方式，一個新人可能需要1，2周才能和團隊相處融洽， 使用結(jié)對的方式以后，1，2天就可以很熟悉。
2.結(jié)對降低了新人的學(xué)習(xí)成本，在結(jié)對過程中，原團隊的成員采取人盯人的方式盡快的將技能和團隊文化傳遞給新人，而新人一開始就可以上手工作（即便是菜鳥，在結(jié)對過程中也可以通過質(zhì)疑和提問對老人提供幫助和監(jiān)督，而出于維護個人的自尊，團隊成員一般都會急于向新人推銷，證明自己
3. 結(jié)對是分而治之的，有助于避免新人因為陌生環(huán)境產(chǎn)生分離感，建立自己的幫派。 有助于強制性的向新人灌輸團隊的目標(biāo)，保證團隊的團結(jié)。習(xí)慣了結(jié)對的工作模式以后，程序員之間必須強制性的進行溝通和交流，也可以避免產(chǎn)生幫派和內(nèi)耗。
4.作為boss更關(guān)心的一點就是，通過結(jié)對這種方式，可以獲得足夠的backup，可以避免因為人員流動給項目帶來毀滅性的風(fēng)險。因此可以大幅度的降低管理成本。我們項目中期流失了近三分之一的人，進度沒有受到任何影響，所以前期boss極力反對做pp，后期大力支持。我們自己有過一個大致統(tǒng)計，正常情況下離職一個人，要損失至少半年的人工。
通過結(jié)對這種方式，互相之間建立了溝通和信任機制，再劃分如果有目的的小團隊，就比較自然，另外在不同的小團隊之間交換結(jié)對伙伴也可以做激勵和監(jiān)督作用。而一次性投入的建設(shè)新團隊，碰到的問題會更多。
這個項目其實失敗的一個地方就是中期迫于人員流動而放棄了結(jié)對，最后導(dǎo)致幫派和內(nèi)耗，糾正過來化了血本，否則還能做的更好。人員流失有一部分是因為個人當(dāng)時管理經(jīng)驗不足，對問題的解決欠妥，還有一個原因是原材料不合適，老板在團隊組建之初盲目的招來了一些并不適合的人（后來碰到一個老板，居然跟我提招10留1的理論，Orz），也為后來的內(nèi)耗埋下了隱患。這也算是一個經(jīng)驗，團隊成員的選擇leader一定要過問，對于那些性格比較偏激，難以控制的人應(yīng)該盡量回避，絕不可以因為資源緊迫就充數(shù)。
按：pp的工作方式，對團隊成員性格有一定要求。
Q：
任何團隊的組織劃分，一定不是用技術(shù)最好的人來做leader。對技術(shù)好的人要進行壓制。不管有多出色，都要盡力扶持聽話的人。
找技術(shù)好的人是對的，但是他技術(shù)好，你技術(shù)不好，就面臨挑戰(zhàn)了。何況技術(shù)好，不聽話的，到哪里都是干活的命，沒有人會重視他們的。
A：
你老外說話也不真見外，按你這樣管， 幾天大家就造反了。
軟件團隊和一般的團隊區(qū)別非常大， 對軟件團隊來說，最好的管理模式就是不管理， 讓大家自己發(fā)揮，做好足夠的引導(dǎo)工作就好。小團隊leader身先士卒起個帶頭示范左右，大團隊， leader要躲在后面做好后援當(dāng)保姆。 技術(shù)好的人的做leader是非常自然的，不懂技術(shù)的人做負責(zé)人倒是比較容易引起問題，技術(shù)人員都比較驕傲，除非是個美女mm帶頭，那還可以忍忍。 不是說不懂技術(shù)的人做不好pm，但是沒有技術(shù)背景的人天然就和技術(shù)人員有鴻溝，技術(shù)人員背后搞的小九九，花樣那個多，所以沒有技術(shù)背景，管理成本會比較高。
有個老外專門寫了本書論證為啥技術(shù)好的人就該做leader， 你可以找找看。
說起來， 管理無所謂，只要肯聽話的，這個是永遠的原則。
聽話的，能力也強的--這當(dāng)然最好的，但是一般聽話的能力都比較一般。要是能力強，不聽話，最好不要，這樣的人， 很容易出問題。
A：
軟件開發(fā)和普通的項目是有根本的差別的，軟件本質(zhì)還是個體的腦力勞動， 所以軟件的生產(chǎn)力完全取決于個人的能力和工作態(tài)度。 2個程序員之間工作效率的差別可以輕易超過10倍， 所以你找找再多聽話的人又有什么用？
能力的問題可以舉個真實例子： 某500強企業(yè)開發(fā)的一個業(yè)務(wù)系統(tǒng)， 投入近20個人， 歷時2年至今還不能上線。而同樣的東西，在另外一個團隊只是2個人一個月的工作量而已。第二個團隊的平均人工是要低于第一個團隊的。
態(tài)度的問題也可以舉個真實例子： 某公司開發(fā)的一個應(yīng)用系統(tǒng)，4個人組成的驗收團隊測試了5個月只找到40個的缺陷， 系統(tǒng)提交客戶以后，客戶方自己組織測試，3天內(nèi)就發(fā)現(xiàn)了40個以上的重要缺陷。
任何一個公司，都必須有聽話（執(zhí)行者）和不聽話的人（創(chuàng)造者和破壞者）的存在，否則這個公司就離死不遠了。 管理要的不是簡單的聽話與否，管理者關(guān)心的應(yīng)該是可控和有效性。
Q：
為了達到目標(biāo)，有效性就是聽話，完成任務(wù)達到目標(biāo)可控性，也就是要聽話。
A：
算了，讓我去死吧。
按：管理人員和技術(shù)人員的溝通真是雞同鴨講，呵呵。
