|
文／Tathagat Varma 譯／顧全
自古以來，那些地位尊崇的理念、宗旨和經驗，和長盛不衰的經濟、社會和情感的價值，都是由共同工作于團隊中的人們創造的。就算某些藝術、哲學和科學領 域的非凡成就，看上去是由那些單打獨斗的卓越個人所作，我仍懷疑他們也一樣有其他人助一臂之力，這些人無私奉獻而寂寂無名（也許在幕后），都是作為團隊而 共同工作在一起。從大國混戰、社會動蕩、政治反抗、建立帝國、為自由抗爭和建立國家并保衛邊疆，到金字塔、泰姬陵、艾菲爾鐵塔、自由女神像、悉尼港大橋以 至倫敦眼摩天輪等諸多雄偉奇跡的創造，每一樣都仰賴于團隊協作才得以誕生與存在。當然，團隊協作的范疇并不排除簡單、俗世而日常的事務，它們雖然上不了報 紙頭條，卻極為重要：平淡者如下田耕作，安排野餐以至家庭活動，都離不開團隊。 團隊協作既然對我們的日常生活有如此深刻的作用，我們很自然就期望團隊的產出直接受其協作質量的影響。不幸的是，單憑良好愿望或是聽天由命，團隊協作是不會產生的，而很多時候根本就無法產生！團隊協作的質量受很多因素的 影響，比如團隊成員個體的積極性，團隊成員間的信任度，團隊使命的清晰度，對目標的統一理解，資源的缺乏，團隊成員間糟糕的溝通，等等。因此可以毫不奇怪 地說，要讓團隊一拍即合，適當的投資是必需的。可是，盡管有最先進的流程和工具，團隊的機能障礙還是頻繁地嚴重影響團隊的表現，危及它有效執行的能力。大 多數軟件經理缺乏相關能力去感知這些深層社會學問題的信號，也就無法處理其影響。對這些問題任何敷衍潦草的反應，都只會使其更難應付。 在本文中我分析了團隊機能障礙的模式，這一模式由Patrick Lencioni在其基于業務情景的精彩寓言體著作《團隊的五種機能障礙——領導力之寓言》中提出。在書中所稱的模式中，他識別了五種影響團隊績效的機能 障礙。這些機能障礙并非是全然獨立的，而是互相關聯，如后圖所示般上下層疊。 
也就是說，信任缺失導致懼怕沖突，而懼怕沖突又導致承諾不足，如此以往。雖然Patrick在探討該模式時，借助于一個沒有充分發揮潛能的業務團 隊，我倒發現這些理念放之四海而皆準，也適用于一個軟件開發團隊的情境。可能哪里也找不到像軟件開發這樣能凸顯團隊協作的效用和重要性的了。 軟件開發是一項團體運動，有自己的 公平競爭政策（“職業道德”），整套游戲規則（“流程”）和對團隊協作的高度重視。軟件開發流程，或者管理開銷（以流程或組織認為合適的任何類型和份額而 存在），或者更簡單點的，比如統一的集成開發環境（IDE）、通用編碼規范、配置管理工具……實際上任何東西的存在都為了同一個理由：讓團隊作為整體，大 于其組成部分的集合。但是，我們也知道軟件項目的失敗率驚人地高，即便業內對于“失敗”的構成及其真實統計數據沒有共識，大家都心知肚明，失敗率總歸要比 該有的高！就算偶有例外，可考慮到軟件業雇傭的員工大都聰慧過人，如果在項目失敗理由清單中名列前茅的是技術低能、粗心愚蠢或者有意破壞這樣的原因，我也 還是會非常奇怪。那么，為什么還有如此多的軟件團隊沒能達成其預設目標呢？我相信在其他因素相同的情況下，軟件項目失敗中一個重大卻尚未被足夠重視的原 因，就是團隊的機能障礙。 團隊流程決定了“工作的方式”，對團隊的效力有很大影響。過去十年間，敏捷方法廣泛流行，已經成了主流。維基百科對其定義為： “……敏捷方法普遍推崇：一種項目管理流程，它鼓勵頻繁的檢查和調適；一種領導哲學，它鼓勵團隊協作、自我組織和責任擔當；一套工程最佳實踐，它允許快速交付高質量的軟件；一個業務方法，它把開發工作與客戶需求和公司目標相匹配。” 上述這些帶來的對團隊和個人的賦權，達到了迄今我們在軟件業所見過的最高程度。我將其看成流程改進中的又一重要進步，它將決策權從經理下放到被賦權的自指揮團隊，因而使團隊協作在其中扮演比以往更重要的角色。但是，敏捷不是一個社會學流程，它是軟件開發中一種面向團隊的哲學，雖然有團隊社會學的痕跡，但若是武斷地來看，就很容易忽略這一點。 考慮到敏捷原則正逐漸成為業內開發流程的事實標準，我分析了敏捷實踐如何應對軟件團隊的五種機能障礙。讓我們從金字塔底部開始一一展開。 信任缺失 “第一重機能障礙是團隊成員間的信任缺失。這實質上源于他們不愿在團體中輕易受到攻擊的心態。團隊成員如果不對其失誤和弱點真正地開誠布公，就不可能打下信任的基礎。” 一個團隊遠不只是一群烏合之眾，不管其中的個體如何能干。每個團隊成員擺上臺面的，都是獨特且經常互補的技能，而這些技能的全體集合，幫助團隊達 成其目標。在一個由各種“勞動分工”方式創立的傳統團隊中，其成員間存在強大的攀比壓力，沒有機會發展“基于弱點的信任”。團隊成員在過往績效表現可持續 的基礎上受到“信任”。但是，在現代行業中，不可能假設或期望任何人具備所有所需技能，在任何狀況下都能成功。據Patrick所說，互信團隊中的成員 們，能夠承認他們的弱點和失誤，請求他人的幫助，接受對他們職責領域的質詢和評價，做出負面結論前先假定他人無辜，承擔提供反饋意見和幫助的風險，欣賞和 發掘他人的技能和經驗，集中時間和精力于重要問題而非勾心斗角，提出和接受道歉時毫不猶豫，對會議和其他集體工作的機會滿懷期待。 敏捷鼓勵適應性的軟件開發，它大量依賴于對過去績效的反饋來改善未來的表現。敏捷鼓勵所有利益相關者——開發者，業務人員，贊助人和客戶——之間 面對面的溝通和互動。它還鼓勵頻繁（通常每天進行一次）的進展更新，以及迭代結束時對過去進展狀況和未來改善之處的反思。這種定期的開放溝通和反饋可以成 為非常有效的信任建設活動。 敏捷團隊通常都較小，團隊成員具備互補的技能和任務，而非多人同時擁有互相競爭的技能和任務。他們也高度自治，允許以民主方式做出決策，而不是被 客戶和管理層強加沒有合理論據和邏輯思考的指示。團隊自己負責承諾，同時小型團隊都位于單一地點，這中氣氛可以讓團隊成員互相依靠，從而達成承諾。特定的 實踐，如結對開發，其根本理念是盡早查出軟件缺陷，而不是以缺陷數據判定個體成員的績效，這有助于更深入地發展信任關系。為此，團隊的生產率指標“速率 ”，不是歸功于個人，而是歸功于團隊。所有這些做法，都極有可能在團隊成員間建立信任。 懼怕沖突 “無法建立信任是有破環性的，因為第二重機能障礙——懼怕沖突——就是由此而定調。缺乏信任的團隊無法展開無需多慮而充滿熱烈激情的想法辯論，他們退而求諸云遮霧罩的探討和小心謹慎的說辭。” 進行富有成效的沖突，這是一種能力，而該能力會因缺乏互信而受損。大家唯恐提出不同意見被視為反團隊行為。這最終變成了一個自我挫敗的問題，因為 對沖突的懼怕不僅損害了團隊的決策力和進展，也加深了業已存在的信任缺失。團隊需要進行富有成效的沖突。在Patrick看來，進行有成效沖突的團隊，能 夠開展生動有趣的會議，提煉和開發全員的想法，迅速解決實際問題，盡量減少勾心斗角，挑明關鍵主題進行討論。 敏捷要求團隊全員都參與到估計與計劃、情況更新和回顧會議中去。Scrum中每日站立會議的發言，是針對團隊而非任何經理。團隊的進展公開透明， 非常容易識別進度落后（這可能危及團隊兌現承諾）的團隊成員，而下一步并非申斥其進展緩慢，而是要施以援手，必要時進行建設性的爭論來找出解決問題的辦 法。因為“基于弱點的信任”這時已經建立，所以團隊成員珍視健康的沖突，而無需懼怕斥責。 承諾不足 “健康沖突的缺乏是個問題。第三重機能障礙保證會因此出現，那就是承諾不足。如果團隊成員沒有在熱烈而開放的辯論過程中廣而告之他們的觀點，就算他們在會議中掩飾爭拗，也罕能接受最后決策并承諾于中。” 不難想象，互不信任的團隊成員是不愿共同工作或分擔同一承諾的。Patrick認為：能做出承諾的團隊，能夠明晰方向和優先級，圍繞共同目標匹配整個團隊，發展從失誤中學習的能力，搶在競爭者前利用機會，毫不猶豫地前進，也對改變方向毫無躊躇或負罪感。 敏捷最強的一點在于，它是一個面向團隊的方法，其中每件事務都由團隊主導和負責——從同意沖刺工作清單、工作量估計、衡量和追蹤進展，直到最終交 付。敏捷團隊中沒有個人的承諾——一個敏捷團隊的進展和成功完全由其兌現的團隊承諾來衡量。敏捷也非常重視從過去的經驗、尤其是錯誤中學習，并采取特定步 驟來加以完善。回顧會議流程的確立，就是要確保在每輪沖刺和最后項目結束時，從團隊得到這些反饋。敏捷還注意鼓動團隊成員擁抱不確定性。傳統的軟件流程對 如何處理高度不確定或者快速改變／進化的問題有著嚴格的限制，而絕大部分人可能都把參與這樣高風險的項目當作是職業墳墓。然而同樣真實的是，就算最后項目 失敗，這種項目本身多數都是能夠發展事業的工作，具備大量的學習機會。通過敏捷實踐，進行短期計劃、逐個解決問題，從而降低了失敗或重大返工的風險，這有 助于一個團隊從如此不確定的情況中獲得最佳結果。因此，團隊當然感到更有信心去承擔這么有風險的事業，而且就算中途無可避免地需要改弦更張，敏捷也能毫不 困難地擁抱這些改變。 逃避擔責 “由于缺乏真正的承諾和認同，團隊成員發展出了第四重機能障礙：逃避擔責。沒有對于清晰行動計劃的承諾，即便是最專注和最有驅動力者，也經常在同伴的行動做派與團隊效益背道而馳之時，躊躇于是否出言提醒。” 不擔承諾的團隊可能在責任擔當上表現欠佳。信任缺失時，團隊成員經常向個人目標努力，而與團隊目標南轅北轍。他們經常傾向于只對自己那部分工作承 擔責任。可以預料，會有很多相互指責，或是將錯誤歸咎于外因的情形。但是，責任和擔責相伴相生，就像我們要求團隊自我指導和對其賦權那樣，我們也同樣程度 地要求他們擔起應有的責任來。根據Patrick所言，互相問責的團隊保證了績效低下者感受到改善的壓力，團隊成員毫不猶豫地質疑他人的工作方法以圖迅速 發現潛在問題，在統一的高標準上建立互相尊重，并避免圍繞績效管理和懲治行動而產生過度的官僚主義。 敏捷關注團隊全員參與計劃和追蹤等項目的方方面面。另外，敏捷團隊較小，于是整個團隊都了解其各個成員幾乎每天的績效情況。雖說其理念不是要對個 人施加負面壓力，但績效較差者在此情形下還是會受到大量的攀比壓力，去提高其表現。當然，敏捷團隊的其他成員會提供各種幫助，但不是要懲戒（或容忍）表現 較差者，而是要保證團隊努力工作并傾盡所能兌現承諾。另外，雖然敏捷是一種團隊方法，它并未削弱關鍵成員的重要性。與任何團隊環境一樣，關鍵成員很容易獲 得尊重和同事的仰視，這種尊重有助于團隊樹立模范典型（在小型敏捷團隊中很容易發現他們）。 漠視結果 “無法互相問責給第五重機能障礙創造了生長條件。在團隊成員將其個人需求（如自負心理，職業發展，或者表彰獎賞）甚至于其小團體的需求置于團隊總體目標之上時，漠視結果就產生了。” 團隊中沒有互信，或者大家只顧埋頭自己的進展，團隊就經常會在兌現承諾時出問題。可是，不能一貫專注于“整體結果”，就不可能交付好的軟件。 Patrick描繪了一個專注于整體結果的團隊，它留得住有成就感的雇員，減少了個人主義的行為，急切地同甘共苦，從個人利益服從于團體利益中獲益，并避 免人心渙散。 敏捷倡導具備跨職能知識的個人與業務人員密切合作，“通過盡早和持續交付有價值的軟件來使客戶滿意”。敏捷原則尋求圍繞自組織團隊中受激勵的成員 來建立項目。其意圖是最終交付團隊之承諾，而它側重團隊成員間對他人技能的相互依賴，所要求的代價只是對個人傲慢與偏見的壓制。進一步說，短期頻繁地交付 可工作的軟件，有助于減低重大失敗的可能性，而每個讓團隊向目標進一步邁進的迭代都是愉悅之源。最后，團隊回顧的實踐能夠幫助它“反思如何才能更有效，隨 之調整優化其行為方式”。當團隊的低層次機能障礙消除了，就有了互信的堅實基礎，和對團隊承諾的負責擔當，這讓團隊始終關注于整體結果，而無個人追求其私 心雜念。 結語 敏捷方法正在幫助軟件組織改善其績效。敏捷2008大會上發布的一份近期調查指出，敏捷團隊的上市時間加快37%，生產率提高16%。敏捷實踐在 明確追求“發現軟件開發的更優辦法”之余，也微妙地應對了團隊機能障礙的方方面面。敏捷實踐雖不直接要求人們改變其行為方式，卻有助于克服一些最普遍的團 隊機能障礙，從而為團隊績效打下了堅實基礎。 |
|
|
