 |
相關閱讀 |
大道至簡——軟件工程實踐者的思想 第3章 團隊缺乏的不只是管理
|
>>> 讀書—連接古今充實信仰 >>> | 簡體 傳統 |
第3章 團隊缺乏的不只是管理
“言人三為眾，雖難盡繼，取其功尤高者一人繼之，於名為眾矣。”
——《漢書高惠高后文功臣表序》顏師古注
1. 三個人的團隊
《漢書》中說“言人三為眾①”，是指三個人就算得上是“眾”了。這里的“眾”應該理解成一個群體，亦或者說是一個團隊。
團隊是至少以三個人為規模的。這有其合理性。為什么呢？首先一個人算不得團隊，那是個體。兩個人則互相支撐，古文中“從”字是二人互立，就是這個意思。然而二人互立并不算團隊，因為沒有監督。三個人便可以構成團隊，這樣便有了團隊的一些基本特性：主從、監督和責任。
一個人的開發行為可以成功，這取決于個人努力。大家熟知的 KV100、KV200 反病毒軟件，最早就是王江民先生一個人做出來的。二人小組如果能相互支撐，那也是可以獲得成功的，同樣作為反病毒軟件的 AV95 在 95 到97 年成功占據反病毒軟件市場之一隅，就是周輝和劉杰先生兩個人的作品。
① 片面地理解成“三人為眾”是不對的。“三”在這里是虛詞，指的是很多人的意思。然而，古人以“三”來泛指很多人或者群體，則是很值得玩味的事。
然而到了三個人的時候呢，就得選個領導了。顏師古為《漢書高惠高后文功臣表序》作注時，引用了孟康的話，說“取其功尤高者一人繼之，於名為眾”，簡意就是功高者代替群體受功。古人的受功當然包括封侯晉爵，因此這便仿然成了慣例而推廣開來，功勞大的、能力強的便成了團隊中的領導角色。
殊不知彼時彼事，目的并非要選領導，而是要表彰功
績。項目結束會議上，總經理說：“M 項目完成得很好，
小 S 的進步尤其之大，他獨立完成了全部核心代碼的編
寫，因此月獎加三倍”。獎不可謂不豐，然而這并不代表
在下一個項目該讓小 S 來做項目經理。
同樣，三板斧定了瓦崗寨的程咬金，功不可謂不高，
技不可謂不強。但程咬金不是將帥之才。
做管理起碼需要能承担責任，這是最基本的素質。
《史記循吏列傳》記載了李離伏劍的故事。春秋時
晉國最高司法長官李離，因為“過聽殺人”，斷獄失誤，
把一個不該處死的人錯判了死刑。隨后“自拘于廷，請死
于君”，晉文公欲以其下屬有過為由免他的罪，而李離說：
“臣居官為長，不與吏讓位；受祿為多，不與下分利。
今過聽殺人，傅其罪下吏，非所聞也。”
隨后拔劍自殺了。
同樣的道理，你的項目經理職位又沒有讓給別人做，
你拿的經理級工資又沒有分給別人，那項目失敗了，你為
什么要把責任推到別人頭上呢？
三人團隊中的那個領導，不是要程咬金一樣的牛人，
而是要李離一樣的死士。項目完成不了，切腦袋的事倒不
必做，遞交辭呈的那點勇氣總是要有的。
2. 做項目 = 死亡游戲 ?
如果項目做不成就要掉腦袋，那就象好比是枕著鍘刀
在做程序；如果項目失敗就要交辭呈，那可能就從來不會
有項目經理。
為什么這么說呢？
從管理角度來看，項目失敗與否與項目經理的經驗直
接相關。我曾經聽過一個來自澳大利亞的講師說軟件工
程。她說到項目的成功是兩個方面的評估：
項目完成質量
項目完成時間
由于項目的時間是在項目前期對項目工期的設定，因
此我問這個講師：什么方法能保證預期的工期是正確的，
或者說是可以完成的。
講師的回答很有意思：經驗豐富的工程師能盡可能接
-28-
『大道至簡』
近地預估工期，但沒有辦法保障(預估的)工期是絕對合理
的①。
那么進一步的推論是，由于沒有絕對合理的工期，所
以項目的完成時間可能總是被進度變更所修正，所以項目
也就總是不能“成功”。
——看來外來的和尚(包括尼姑)也未必能比本地的
更會念經。在這一點上，來自澳大利亞的講師，與來自北
極的愛斯基摩人(如果他們也念經的話)如出一轍。
項目工期的問題不能解決，就不能保證項目成功。只
有經驗更加豐富，才能更盡可能地逼近“合理的工期”。
因此在此之前，項目經理面臨的就是失敗。這個失敗可能
不是項目經理本身能力所決定，或者也不是團隊成員的工
作所決定，而是在一開始，那份給客戶的項目協議就簽錯
了。
項目經理是需要時間來成熟的。他需要有機會來承受
錯誤，而不是一開始就享受成功。
3. 做 ISO 質量體系的教訓
Y 公司終于在 2001 年發現管理跟不上了，于是開始
① 軟件工程中有專門的學科來研究項目的工期問題。學者們試圖
尋找公式來計算項目的復雜度，從而計算出所需的工時和人月。
然而在實踐中，這被認為是不可行的。
引進 ISO 質量認證體系，希望通過這個體系來規范管理行
為，提高產品質量和對外的競爭力。
他們做得非常認真，把全公司的人員都調動起來了，
質量手冊的論證做到了每一個員工；他們按照標準的軟件
工程模型進行了開發流程的重組；每一份流程相關的材料
都約定了格式，并進行了歸檔說明；每一個環節都設定了
質量監督員來考核和回顧；……
接下來，他們開始實施。
三個月后，他們發現了一個問題：所有環節的質量監
督員是同一個人，他沒有工程經驗，于是他提出的問題總
是得不到工程負責人的確認。——很顯然，沒有工程負責
人愿意說自己這里存在問題：有問題就要改，就有可能中
斷或者重新來過。再則這質量監督員也沒有管理權限，于
是他即使確認了問題，也沒有權利要求立即整改，工程負
責人隨時可以以進度為由擱置這份監督報告。
再兩三個月后，他們發現一切如舊，好象工作并沒有
因為《質量手冊》的存在而發生什么變化，在手冊上被改
造的流程因為人力資源不充分而沒有辦法運作起來；絕大
多數應該書寫的材料因為時間不夠而被“候補”。
改變最大的是綜合部，這里多了一個虛設的機構用于
分管 ISO 質量，綜合部的經理也變成了分管質量的副總，
但又沒有因此而多拿一分錢。改變最少的是開發部，其表
現為每個人的顯示器頂上放了一本質量手冊，用來擋住窗
口射進來的陽光，以及落向顯示器的灰塵。
兩年之后，我們一群人來回顧這一次失敗時，很多人
都說是“體制的問題”，說是原有的公司轉型到新的公司，
不適合新的公司的管理體制以及對管理的要求。
其實這并不十分正確。體制的內涵是分兩個方面的，
其一是“體”，即“體系”；其二是“制”，即“制度”。“ISO
質量體系”所產生的那份手冊只是“制度”，在它的背后，
所要求的是對舊有“體系”的改變。——舊的公司轉型到
新的公司，不是搬來一本“管理制度”給每個員工讀一遍
就要可以的了。
在這一個轉型期，第一要務是解決“體”的問題，也
就是“組織機構建設”的問題。如果把這個問題縮小到開
發部門的工程環節，
那么就是“如何組織
開發團隊”的問題。
有 了 確 定 的 團 隊 模
式，才能尋求相應的
管理制度，并且才能
把這樣的制度實施在
團隊之上。
漢 朝 的 劉 向 在
《新序·雜事二》中
記錄了一個故事，說
是魏文侯出游，見路
人把羊皮統子毛向內
皮朝外地反穿著，還背著一簍喂牲口的草。文侯奇怪地問
他為什么。這個人答道：我愛惜這件皮衣，怕毛被磨掉了。
文侯嘆道：你難道不知道，如果皮被磨盡了，毛不也就掉
光了嗎？
皮之不存，毛將焉附。沒有確定的組織機構，又如何
能指望做出來的管理制度“合用”呢？
Y 公司在 1999 年至 2001 年一直保持著從 K 公司移
植過來的組織機構模式和管理模式，兩年的組織機構建設
的時候被白白浪費了。本來，做 ISO 體系是最后一次彌補
組織機構建設的機會，然而在管理者還沒有意識到“皮之
不存”的時候，Y 公司就連“毛”也都掉光了。
4. 誰動搖了你的制度？
組織模式確定的同時，相應的制度也有隨之建立。很
少是有幾年之后才來補制度的。
然而制度究竟決定了什么呢？我們先來看看，如果員
工在工作中出了紕漏：
沒有制度，你沒有辦法和依據來懲戒員工，因此
是管理者的過失；
有了制度而沒有懲戒他，是執行者和監督者的過
失；
一而再、再而三地犯錯，又一而再、再而三地被
懲戒，那就是教而不改，就真正是員工的品性和
素質的問題了。
因此，先做制度總是好的。至少在你選擇做伏劍自刎
的李離之前，你還有機會把黑鍋扔到出問題的員工的頭
上。
對于一個已經規范管理、體制健全的公司，不容許員
工犯錯是對的。即使是一次犯錯，立即開除也說得過去。
但還是有前提的，這至少包括：
員工已經接受過相關的培訓，這至少包括員工規
范和技術技能的學習
在該員工之前，相同的或者相關的錯誤沒有被枉
縱
第一條是人性化的體現。中國人常說不知者不為過：
員工不知道，管理者也沒有給他知道的條件，那怎么能說
是他的過錯呢？如果因為不知道而出了問題，那管理者首
先應該自省才是。
第二條則是公平性的體現。不管是針對誰，制度都是
一樣的，沒有情面可講的，常說的“特殊情況特殊處理”
在制度面前行不通。規矩一旦被破壞就形同虛設，反而被
員工作為笑柄，用來類比其它的制度。如此一來，整個的
制度也就離崩潰不遠了。反過來，在已經被破壞了制度面
前，若再做殺雞儆猴狀，那猴子是被嚇著了，不平聲、怨
憤聲也就跟著出來了。
因此最好的方法是趕緊修訂制度，而不是修理人。
所以，經常的情況下，動搖了制度的人不是犯錯的員
工，而是管理者自己。如果在制度面前，既做得到“人性
化”，又做得到“公平性”，那么當管理者的便可以多做幾
次黑臉的包龍圖，而脖子上的腦袋便可以比李離頂得長久
一些。
5. “那我們就開始開發吧”
現在，公司的組織機構和制度建設已經完成①了，在
這個組織機構里，我們已經有了一個或者多個團隊。接下
來，我們要真正的開始團隊建設了。
這是任務。因為正在讀書的你，和我一樣，是要拉齊
七八桿槍，開始做工程的了。而在這一切開始之前，再之
前的時間里，我還想知道一件事：你知道如何做工程嗎？
我們先來回顧一下。
前一章說的是編程，EN，那實在簡單，愚公式的工
作。我們先不管愚公們的水平如何，以及夠不夠勤快，反
正，他們會編程就是了。
上一章呢，說的是一部分懶人“創造”或“尋找”到
一些編程的方法。這些懶人們可能來源于做得太老的、或
者太累的愚公，或者是……一些看著愚公們著急，又被閑
出毛病了人。反正他們找了一些方法出來，而我們的愚公
們也已經學會了這些方法。
現在，有了會(比較快速地)編程的愚公，而且有了公
司，我們完成了組織機構建設，我們還找到了一名(或好
① 這里的“完成”是指告一段落，或者說是階段性的結束了。完
成，并不等于完善。而完美，則更是無可企及。
多名)項目經理，他們一不怕死，二不怕苦……對了，更
為可喜的是我們還有了開發部：對內，我們訂了一套規章
制度；對外，我們還拿到了項目單子。
“那我們就開始開發吧”——你就這樣給我說。
很久以前，很久很久以前，人們都是這樣做的。拿到
項目單子，然后“那我們就開始開發吧”。這樣的事出現
得很自然，因為積極的愚公們總是有挖山不止的欲望。所
以他們一看到項目單子，第一個反應就是：那我們就開始
開發吧。
做了這么多年項目，我現在一聽到這句話，就哆嗦。
6. 組織的學問：角色
現在先考察一下你的公司，在整個系統里面，有沒有
這樣的人：他既不歸任何人管理，也不管理任何的他人。
如果有，那么就早早地把他開掉好了。
這樣的人在組織機構中是一個盲點，或者空洞。按照
我的觀點來看，他在組織中不担任任何的角色，既然“不
是角色”，那么當然要開掉。
在任何錯誤被歸咎于員工之前，管理者應該先想想是
不是自己的問題。
是的。你可能很快發現問題出在了管理者。因為管理
者沒有確定組織機構模式，或者沒有為組織中的成員進行
-35-
第 3 章 團隊缺乏的不只是管理
角色定位和分工。如果這樣，出現“既不能令，又不受命”
的人就是必然的事了。
同樣的道理，在工程開始“做”之前就得先把“角色”
確定好。——可能部分角色是組織機構相關的，例如“部
門經理”和“開發人員”；而有些就需要臨時授命。
對于一個項目來說，第一個授命的人的當然是“項目
經理”。接下來的事件就復雜得多了。按照微軟的慣例，
授命項目經理的同時，會有“產品經理”、“開發經理”、
“市場經理”以及“文檔化和培訓負責人”。這當然不表
明至少需要 5 個人才能構成團隊，在大量角色從項目團隊
中抽取與剝離后，我們可以得到一個精減的團隊模型①（在
后面我會把它叫“R模型②”）：
① 我非常不情愿給出一個模型來讓讀者跟隨，但如果沒有這樣的
一個模型，我想接下來的講述可能會令很多人如墜霧里。明確的
組織機構，既是團隊的關鍵，也是我們思考問題的基礎。
② 我試圖找一個單詞來表現這個模型的簡單和粗糙。我得到的一
個建議是Rough(粗糙的)。然而我更愿意溯源到這個單詞在古英語
中的形態(Ruh)，希望我這樣一再強調，能讓你真正地注意到：“R
模型”是一個原始而且粗糙的東西。
更上層管理
品質部門 文檔和培訓 客服部門 市場部門
開發團隊
開發經理
項目經理
開發人員
在保障這樣一個組織機構模式的過程中，有幾點是需
要注意的：
如果項目針對直接客戶，而且沒有產品化的可能
性(或必要性)，那么可以將與市場(以及市場部門)
相關的問題和角色先暫時放在一邊。
已經存在于開發團隊中的成員，不適合在品質部
門中兼任角色。
項目經理應致力于減少團隊中開發角色與其它
部門的溝通，必要時開發經理應該站在開發人員
之前進行部門間的交互。
品質部門、文檔和培訓部門和客服部門應該主要
由有專門培訓的人員構成，盡管開發人員可以
(或者經常會)參與文檔、培訓和客服工作，但這
也通常是他們最不能勝任的角色。
這是中小型規模的公司和團隊的參考組織機構模型，
對大型團隊并不適用。
在這個模型中，我們仍然看到了一個至少由三個人構
成團隊。其中，在開發經理和開發人員之間，既存在主從
關系，也存在協作關系。而項目經理，則在團隊中處于領
導者、組織者和團隊保障者的地位。
如果非得要精簡到兩個角色的團隊模式，那么這種情
況下，通常是開發經理兼任項目經理，因此這位開發經理
一定要能清楚地區分這種雙層角色的身份：在任何時候，
明確自己是在進行“團隊內協作”、還是“團隊管理(和組
織)”、還是在與“團隊外交流”。
如果這個開發經理總是混淆自己的角色，那么，我建
議，換人吧。
7. 跟隨螞蟻。但不要栽進螞蟻洞里。
團隊真的需要管理嗎？
這經常是“經營”開發團隊的管理者最容易給錯答案
的問題。這些管理者兢兢業業，試圖細化每一個管理環節，
將自己的意愿貫徹到……EN，CPU 里去。
實際上，開發團隊并不需管理。或者說，在你還沒有
弄清楚狀況之前，不要去管它。
溫伯格(Gerald M. Weinberg)在“給軟件開發經理的建
議”中提到了這樣一個問題：開發經理如何面對一個并非
由他親自雇傭成員的團隊。溫伯格的回答是：
與成員面談，讓他們簽約受雇于你；
或者，解聘他們；
再或者，放棄這個職位。
溫伯格的意思是“沒辦法管就不管”。溫伯格當然可
以有更多的選擇，他總可以找到適合自己管的公司。然而
目前，你可能是唯一的人選。或者你原本就期待這個角色
很久了，當然不能象溫伯格一樣放棄。
你得找辦法來解決團隊問題。
“簽約”這樣的事，在大多數環境下是行不通的。要
知道，既然他們與公司的簽約保證不了他們工作的質量，
同樣與你的這份簽約也不會。協議并不能建立管理者與被
管理者的信任，而只是確保了這種關系。
但是你應該相信我，在你接手這個團隊之前，上一任
經理也確保了這種關系。然而團隊失敗了，否則不會換作
是你。
所以告訴團隊成員“現在輪到我管理你們了”，根本
就是一句廢話。或者在你來之前，他們就已經知道你要來
了。
小的時候，我就喜歡觀察螞蟻。我喜歡看它們成群結
隊地搬著東西穿過小路，或者水溝。我嘗試用木棍導引它
們改變行動的路線，然而不久之后，它們就會翻過那根木
棍，按照既定的路線行進。
稟性難移，要改變一個人都難，何況是改變一個團隊
的既定習慣。
如果有一群開發人員象螞蟻一樣辛勒地工作著，那
么，先不要打擾他們。你應該跟隨他們，看看他們是如何
做的。發現規律，分析這個規律的價值，最后再嘗試改變
它們(的一些負面價值的規律)。
所以你要緊緊地跟隨他們。——除了一個地方。那地
方是你去不得的，那就是螞蟻洞。
顯然，你不是開發者，你是管理人員。所以盡管你是
團隊中的角色，但千萬記得離螞蟻洞遠點。你在洞外張望，
可以發現問題；你在洞內，就只有做“循規蹈矩”的螞蟻。
管理者是那個可以在洞外放木棍的人。
8. “什么是增值稅發票？”
現在你已經足夠地觀察了你的團隊，你知道這個團隊
存在問題，你也知道你需要改變。當然，你也知道這種改
變并不是放一根木棍那么簡單。
你已經確定了組織結構，確定了組織中的角色，還有
了一個團隊(5 個？或者 10 個？)的人。所以作為項目經理，
你需要先分工。
在分工之前，那個團隊只能算是一個沒有組織與合作
的群體(所以英文中群是 Group，而開發團隊是 Team)。
被優先考慮的是彈性分工。每一個人都被要求做一顆
革命的螺絲釘，哪里需要哪里擰。所以彈性分工總是被放
在企業節省人力資本的第一要務上。然而我們真的會做彈
性分工嗎？
螞蟻的分工模式之一就是彈性分工。一只螞蟻搬食物
往回走時，碰到下一只螞蟻，會把食物交給它，自己再回
頭；碰到上游的螞蟻時，將食物接過來，再交給下一只螞
蟻。螞蟻要在哪個位置換手不一定，唯一固定的是起始點
和目的地。
確定被“彈性分工”的員工需要可以快速地轉換到新
的角色，但首要考察的并不是他是否“有能力”勝任這個
角色。能力可以通過學習來增強，而角色的轉換，則首先
是思想的轉換。
1997 年，P&J 的公司打算全面拓展市場，我隨他一
起到了成都。當時我是開發部的三個主力開發人員之一，
因此在原定計劃里，我是到成都組建西南區開發部(或技
術中心)。然而在兩周之后，P&J 發現總公司的運作存在
問題，因此他必須回鄭州。P&J 決定將成都市場的問題全
權交給我，換而言之，我必須出任成都辦事處經理。
我對市場一竅不通，也不懂得公司的經營與管理。但
很明顯，做辦事處經理不是做技術，這與我(當時的)個人
意愿是相背的。于是我拒而不受。理由也很充分：我不會
做市場。
P&J 用了兩天的時間來說服我，直到在臨回鄭州的前
一晚我仍未能接受這個任命。這時他告訴我：即使是做開
發，也是需要了解市場的，你必須知道用戶想要什么，你
必須理解你的客戶。因此你如果想要做一個好的開發人
-41-
第 3 章 團隊缺乏的不只是管理
員，你應該正視這次機會。
我沉默了許久。我想明白了兩件事：從公司的角度上，
我必須接受這個職務；從個人的角度上，我需要接受這個
職務。于是，我問了我的第一個問題：“什么是增值稅發
票？”
P&J 笑了。接下來我們開始討論經營問題。第二天
P&J 飛回鄭州。五個月后我升任西南區總經理，一年后，
西南區做到六個分區市場中業績第二。此后我辭職回到鄭
州，再一次從開發人員做起。
“什么是增值稅發票？”意味著從技術到經營的角色轉變。這個問題本身帶來的并不是能力的提升，但如果我提不出這個問題，我將沒有可能理解經營與市場。
盡管彈性分工非常有效，然而真正做彈性分工卻并非易事。螞蟻的角色轉換是本能的，而 P&J 卻不得不花兩天時間來說服我。因而更應當留意團隊成員“自激”式的角色轉換，知道他是不是真的想(而不是需要)轉變一下角色，這樣起碼可以省去你兩天的功夫。
然而能提問“什么是增值稅發票”的愚公畢竟不是太多，大多數時候他們在“箕畚運于渤海之尾”，如果實在閑得厲害，他們可能會去發明翅膀，而不是思考“什么是增值稅發票？”
更好的選擇是明確分工，而不是彈性分工。你應該明白，重要角色的更替通常是極具風險的，例如項目經理或者開發經理；頻繁的開發人員的調度也會直接影響到工程的質量和進度。
如果所有人都在思考“什么是增值稅發票”，那么你的組織機構將立即潰散。
因此，明確分工是你的管理職責。做管理≠做伯樂。
周愛民(Aimingoo) 2013-08-24 22:16:32
評論集
暫無評論。
稱謂：
内容：
驗證：
返回列表