發(fā)總監(jiān)為核心的研發(fā)團隊管理體系，其作用會隨著企業(yè)規(guī)模的不斷增大而發(fā)揮日益重要的作用。這一點上，共產(chǎn)黨指導的軍隊，除了編制上的首長之外，還有主抓管理的政委，其作用正在這里。
人員配備量力而行
然而，所謂“稍大”規(guī)模到底是什么規(guī)模?這個問題，我曾經(jīng)問過不少企業(yè)的技術主管，他們當中有CTO也有中層的技術主管和項目經(jīng)理等，通常情況下，7~8 個人是一個主管認為比較合適的規(guī)模。其中有一位精力旺盛的主管告訴我，他最多可以管理多達11 個人，也就是說在這樣的情況下，他可以了解向他匯報的每一個人的具體工作，然而一旦突破這個極限，就根本無法控制了。
這一點上，軍隊的建制很值得我們參考。通常在高一級的管理當中，3 這個數(shù)字被認為是最有效的管理數(shù)字，一個軍通常有三個師，一個師通常有三個團，一個團通常有三個營……基層人員的管理數(shù)量通常稍大，但不會超過10 個單元。在軍隊當中，這種建制所體現(xiàn)出來的效率經(jīng)歷了人類上千年的經(jīng)驗積累。
事實上，當你的開發(fā)團隊人數(shù)超過10 個時，你可能已經(jīng)開始需要建立多層的組織結構了。例如微軟在研發(fā)管理上的模式，通常一個產(chǎn)品組會被分成項目經(jīng)理組、程序開發(fā)組和測試組。同樣是最能夠發(fā)揮效率的組織結構，讓微軟在大規(guī)模用戶的客戶端產(chǎn)品開發(fā)上，比其他軟件公司遙遙領先。
一層又一層的匯報機制， 帶來的不僅是人數(shù)上的暴增，而且還帶來了很多管理上的成本，對于這些成本，不少國外企業(yè)的高級技術主管都認為是應該支付的，只有在極少數(shù)時候，才可以突破這種層級設置的法則。例如Google，其研發(fā)的扁平在業(yè)內(nèi)很有名氣，其項目總監(jiān)直接負責數(shù)千個項目，盡管這讓人難以想象，但是這種模式竟然得到了很好的運行。這是因為Google 和一般軟件公司有很大的不同，讓一般企業(yè)難以置信的利潤率可以確保這家公司能從業(yè)界招聘到最好的程序員，眾多能力超強的人在一起，往往會主動比拼實力，從而形成了一個良好的向上發(fā)展的氛圍。
然而，這種模式在一般企業(yè)根本行不通，所以我們會看到“半年以后可以啟動你的項目”這種情況屢見不鮮，因為相互的推諉和拖延已經(jīng)成了在這些企業(yè)中的毒瘤。作為CTO的技術主管，根本無法關注除了技術、管理等之外的諸多問題。研發(fā)體制，則成為一針強有力的反病毒注射劑。當然，如果你的研發(fā)團隊規(guī)模并不大，那么作為CTO的你，只好承擔所有工作了，一旦你覺得自己無法承受壓力，也許就應該在組織結構上想辦法了。
大棒胡蘿卜都不能解決的問題
作為老板，最關注的問題仍然是這個：招來的人不用心干活怎么辦?于是，各種各樣的考核機制出現(xiàn)了。為了讓程序員拼命干活，老板們想出來的招數(shù)確實不少，這當中有用鞭子抽的，有用胡蘿卜引誘的，有放羊的，有達爾文式的，總之手段層出不窮，但收效卻不多。
最簡單的考核辦法莫過于考勤+工作量的考核法。反正程序員必須每天都來上班，并且干夠至少8 小時，規(guī)定的代碼量也必須要完成。這種方式程序員自有應對的招數(shù)：每天準時上班，準時下班，寫代碼不用過腦子，能用就行，湊足了行數(shù)或者功能就完事。由于知識工作者的特殊性，導致工作量很難進行具體的衡量，這不像原來的軍隊，以斬首來計算那么客觀。如果較真地進行工作量考核，無疑會支付太高的管理成本。因此這種考核方式，往往在堅持了一年左右以后，常常會被很多老板放棄，或者最后淪為形式主義。但如果老板們愿意投入資源來做這個工作，并通過良好的研發(fā)體系來幫助完成考核，這種方式也能取得較好的效果。
拍腦袋的方式是國內(nèi)很多軟件公司都在使用的一種方法，這種方法通常行之有效。畢竟誰在干活，誰在偷懶，對于主管來說很容易區(qū)別。當然，其弱