成功開發團隊的八項特質

孤影 — Wed, 30 Mar 2005 17:21:00 GMT

我想有很多的軟體公司都是靠接案子維生,
當然工作室就更不用說了,
而接案通常不太可以一個人就可以解決,
除非案子很小或是那個人真的很強,
所以,一個團隊是否能成功就關係著公司的存亡,
尤其是在網路泡沫化之後,
看一下下面所說成功團隊所有具備的特質,
反觀一下你現在的團隊,是不是也是具有這些特質呢?
一說到這,我不免要擔心我的工作了...

轉在自台灣微軟MSDN
http://www.microsoft.com/taiwan/msdn/columns/PMP/PMP_20050318.htm

程式開發專案管理專欄：

成功開發團隊的八項特質

作者：周旺暾，PMP (台灣微軟應用開發技術經理)

2005 年 3 月

根據調查，遠超過一半軟體開發專案會嚴重超時，幾乎形成軟體專案的慣例，其中更有許多專案面臨半途取消或無疾而終的命運。微軟可以算是全世界最大的軟體公司，自然也為軟體專案的高度不確定性所苦，雖然不乏極為成功的產品，也有產品在尚未面世即中止開發。

微軟從過去數十年來的軟體開發經驗，挑選出成功的開發專案，歸納出八項成功團隊的工作特質：

促進開放的溝通
為共同的願景工作
授權給團隊成員
建立明確責任並共同負責
專注於提供商業價值
為了變動, 隨時保持最佳的彈性
投資於品質
從經驗中獲得學習

促進開放的溝通

專案是由許多人才，依據自己的專長，貢獻心力共同完成，這需要藉供充分的溝通。多數的專案成員並不善於溝通，特別是技術專長的專家(例如：架構規劃師、程式設計師)認為溝通工作是專案經理的責任，在例行性進度報告中已經完成必要的溝通，沒有更進一步溝通的需要，有些專案經理只讓少數參與討論的成員知道專案資訊，多數專案成員只知道自己眼前的工作。

很多專案失敗的原因在於：『左手不知道右手正在做什麼』，大家彼此不關心其他成員的工作內容，成員們專注於眼前的工作內容，不清楚正在的進行的工作對專案的幫助，形成資源的浪費。例如：某位成員選擇了一個演算法，以預先載入的方式加速執行，但是他卻不知道自己的程式如何被使用，事實上這支程式雖然被大量呼叫，但都是一次性資料，不僅未能發揮預期的效能，還大量地佔用系統資源，使得程式越跑越慢。

為共同的願景工作

偉大的團隊一定都會有明確的願景，這個願景不僅僅是一句口號，或者是主管片面的要求，必需是大家都能同意的方向與目標，並要與專案的成果相結合。缺乏共同願景的團隊，到處是無法協調的意見，以及彼此誤會的目標，即使專案最後得以交付，還會為了如何評估成效或驗收，花更多時間在討論並互相妥協，畢竟，大家是基於不同的願景來看待專案。

共同的願景不僅是專案成功的必要特質，也是其他成功特質的基礎，如：溝通、授權、負責、專注商業價值 …等。專案團隊中，各個成員依自己的專業責任工作，難免在決策上產生不同的意見，若沒有共同的願景，不僅無法化解衝突，還會因為某些小小的意見相左進而擴大成意氣之爭，對專案目標造成負面的影響。

授權給團隊成員

最好的團隊都是由各種領域的專家組成的，團隊中沒有人是永遠的領導者，而是依不同的領域由最適當的成員來負責推動。缺乏授權的團隊，雖然一樣可以經由熟練的工作技巧，讓專案順利進行，但是這樣子並不能發揮團隊的潛力，也因此降低創造力而導致工作士氣低落。

高效能的團隊裡，每一位成員都被授權，並相信自己對專案的承諾的付出，專案經理與客戶都相信這個團隊可以帶來專案的成功。建立這樣的團隊文化，除了有助於團隊面對更高的挑戰，並能主動結合組織的策略目標。團隊內部的結構應該是網路型式的而非階層式，特別是在專案團隊之中，『官大不見得學問大』。

建立明確責任並共同負責

專案成員對專案團隊的責任，必須依角色有明確的定義，能夠以文字方式描述，所有的成員也都能理解並同意責任的分派。若不能作好明確的責任定義，專案將會投入重覆的工作，卻仍不能保證每一件工作都有人去做，常常專案裡每個人都忙不過來，仍然還有很多重要的工作沒有人去做。

微軟的團隊都會在成立初期，建立一張稱為 R&R 的『角色與責任』(Roles and Responsibilities) 的表格，以確保每一項工作都有人負責推動，更重要的是：負責人只是負責推動，而不是獨立去做並獨自承擔成敗，專案成敗是所有成員的責任，沒有人可以坐視專案只是某個人負責的一件工作沒做好，而導致整個專案的失敗。

以角色去定義責任的好處，是可以避免『因人設事』，讓每一個人的工作在合理的條件下共同分擔，不致於造成能力強的人被工作壓得喘不過氣來，而能力弱的沒事可做，只好去想整個專案的未來。經由角色與責任的預先定義，才能夠定期檢視每一個成員的工作表現，以判斷那些人可以勝任更多的工作，那些人則需離開專案。

專注於提供商業價值

雖然如期完成的專案才能算是成功的專案，但切不可因此誤以為專案存在的目的，只是為了如期完成專案，一切工作皆以如期完成來妥協專案產出，而忽略原本專案成立的商業目標。在大型專案裡，偶而聽到這樣的說法：『因為沒辦法如期完成，建議刪除部份功能，或停止品質的改善。』

假若刪除的工作，是與專案目標無直接相關的附屬功能，自然無可厚非，但如是只站在如期完成的立場，遭刪掉的可能會是專案核心的功能，常常核心最複雜且完成風險最大的。結果整個專案只是為了驗收而完成，大家變成白忙一場，而更多的專案則是因為失去存在的價值，而半途取消。專案的所有活動，應該專注於讓專案能夠提供商業價值，避免只是流於專案成員的個人興趣。

為了變動, 隨時保持最佳的彈性

『規格不是早就談好了嗎？為什麼還要變？』相信這是專案成員普遍的抱怨，許多專案的衝突也都是源自這樣的抱怨。經常變動的規格，可能造成專案工作重覆的投入，增加專案執行成本，並一再延後專案的完成時程，大多數的專案成員傾向專案不作變更。但專案變動常不全然是基於個人的喜好，也許是設計時的疏失，也許是大環境的改變，使得若不作專案變更，會讓專案失去商業價值，也就是沒有繼續做下去的必要。

不論是由誰來承擔變更的後果，直覺上專案變更會造成時程延後，其實並不盡然如此，這個『直覺』其實是過時的。傳統的軟體工程模型 (尤其是『瀑布式』模型)，假定專案的過程與成果是可預先規劃的，因此不會設計入變更的可能，一旦專案變更，自然是大費周章。現在的軟體開發工具與方法，已經提供非常具有的彈性的設計方式，只要設計得當，在開發的過程中隨時可以重組軟體的結構。難的只是人的頭腦，一時還不能適應與時俱進的工具與方法，帶來軟體生命週期管理的變革。

投資於品質

品質可以有許多不同的定義，可能是穩定執行的程式，可能是安全的系統，也可能是價格效能比划算的產品。就算我們採取其中某種品質定義，品質仍然不會自動發生，還要靠專案團隊不斷努力改善才有品質，而且品質改善是沒有止境的。整個軟體工業在品質的提昇上，不斷發展出更好的理論、工具、程序與評量，使得軟體品質的提昇可以更具體、更有效。

重要的是，對於品質提昇的投入，間接鼓勵團隊和個人發展一種追求品質卓越的文化，有助於更好的想法的產生，並提高高品質產品的生產效率。因此，對品質的投資，會轉化成對人的投質，好的品質管理更能將品質融入組織文化，讓品質提昇進入一個正向的循環。

從經驗中獲得學習

如果整天只專注於提昇專案成功率的數字上，或是考慮怎樣讓某個失敗的主要因素不至於影響到整個時程，表示我們還未能從經驗中學會成長，特別是從失敗的經驗中學到教訓。就算專案的時程和資源是如此的緊，我們還是要花相當的時間從經驗中學習成長，否則同樣的錯誤必然一犯再犯。

從經驗中獲得學習，是持續改善的重要基礎，整個團隊都可從其他成員成功與失敗的經驗中，學會怎樣複製成功，也學會怎樣避免犯錯。不能從經驗中學習的團隊，一定是到處救火，類似的錯誤不斷地由內部發生。

收集的文章

成功開發團隊的八項特質

程式開發專案管理專欄：

成功開發團隊的八項特質

促進開放的溝通

為共同的願景工作

授權給團隊成員

建立明確責任並共同負責

專注於提供商業價值

為了變動, 隨時保持最佳的彈性

投資於品質

從經驗中獲得學習