[转载&探讨]軟體專案團隊設計及管理
團隊的3個條件：
1. 自主性
自主性就是團隊中的每個成員都自覺，自願，自發的去做事情。
案例：東方航空公司在VIP班機上招聘日本及韓國空姐，因為她們從飛機起飛到降落一直在不停的小跑。她們總是不停的在為乘客服務：到水，遞報紙等。而中國的空姐只有你呼喚的時候才會出現，缺少自主性。
2. 思考性
團隊中的每個成員都能在考慮團隊整體利益的條件下有自己的獨立思考問題的能力
上級會給團隊每個成員一定的職責，在此範圍內希望下屬能獨立思考。在做一個項目的時候，主管希望聽到的是下屬拿出的大於2的方案，並且希望聽到下屬對不同方案的自己的分析。「方案一和二最可行，但是一公司的立場我覺得3更好，而我個人覺得2好」。通過時刻考慮「什麼是敵人做不到，而我能做到的？」來找到問題或者方案的突破口。
一個好的主管是個通才，可以駕馭手下的專才來完成任何任務。往往他們只需要思考，計劃，調配，決策，以及簽名。為什麼他們能做主管，因為他們更會思考。
案例：DELL的崛起
DELL的創始人常常在思考什麼是IBM做不到，而我能做到的？想出組裝滿足客戶不同價格需要的機型，並且保證：直接組裝，直接送貨，直接維修
3. 合作性
水平溝通的過程，人與人，部門與部門，銜接斷層。
在一個項目組中，什麼樣的人才能擔任項目經理呢？
1). 年齡大於30歲（成熟，能夠駕馭和控制自己的情緒）
2). 在一個公司裡至少做過3個部門以上
3). 良好的人際關係
4). 對工作的熱情和投入
團隊精神的培養
團隊是生活中的一種教育，一種規範。
從小培養，從小承擔力所能及的責任。
家庭作為一種特殊的團隊，其中的每個成員都有各自的責任和義務，同時要滿足上述的3個條件。
團隊精神的特點：一致性
團隊的成員來自不同的文化背景，但是卻又相同的特質：遵守同樣的規章制度和紀律。
有了這三個條件，能自動自發的工作，對自己的業務肯思考，又肯與別人協作，才是一個真的團隊，否則，就是一群人。
二,軟體專案團隊建設的「三個中心」
要以客戶需求，以客戶操作使用的方便性作為指導產品開發、專案實施的原則。一切工作都要貫徹此原則。
以客戶為中心，不是被動消極的接受客戶的意見，盲從客戶。而是積極主動地引導客戶，和客戶達成共識。這需要處處想在客戶的前面，真正的替客戶著想，從客戶的角度出發考慮問題。
有三個方法可以和客戶達成共識：
1、通過多種途徑深刻理解客戶的業務，抽像成清晰、簡單、客戶易於接受的思路。
2、在細處多替客戶著想，爭取在某些方面超出客戶的預期。通過這種方法，才能使客戶容忍那些達不到的需求。這有些和顧客買東西類似，客戶可能會認同他比較關心的幾個產品功能，忽略他不怎麼關心、他認為不重要的幾個產品功能，而決定購買此產品。
3、如果條件允許，不要局限於一個專案的用戶需求，要延伸到普遍的此類用戶的業務需求，抽像出其共性。
什麼樣的產品對公司而言才是好的產品？這個問題仁者見仁，智者見智。我認為能使公司蠃利的產品才是好的產品，能使公司蠃利的產品有如下特點：
1、花費最少的成本取得最大的收益，能讓客戶比較順利的付款。
2、能帶來公司短期蠃利，又可減少長期成本（對小型公司而言）。蠃利可分為短期蠃利和長期蠃利。對大型的軟體公司，如Mircosoft、IBM可能追求公司穩定長期的蠃利；對新組建的公司，可能在前期會以短期收益為主。當然在產品研發、專案實施過程中，要逐步抽像出一些可以復用的功能模組和產品，比如底層開發平台、底層開發構件、專案實施經驗等，以減少公司的長期成本，這種認識能促成公司專案和產品研發的良性發展。
這是最主要的一點。軟體專案中最主要的是人才、是團隊合作精神。如果專案團隊成員相信他們是世界上最好的，在某種程度上，他們的確會成為最好的。這並沒有想像中那麼困難。
在專案團隊中，如果有一位成員悲觀、自卑，這會具有極強的感染力，甚至會影響到整個部門直不起腰。要使團隊的每一個成員都挺直腰桿，就必須讓他們自尊、自信。只有自尊、自信，才能自強！
孫子兵法云：「欲得其中，必求其上；欲得其上，必求上上」，否則不可能順利達到目的。
要相信我們的團隊是最好的團隊！
三,建立與維繫專案團隊
專案對策的產生，應該包含下列四個基本步驟。
- 完全掌握問題的性質
- 找出最適合的解決方案
- 發展出完整的執行計畫
- 按步驟進行
釐清真正需求後，須有條理地明列出專案需求要項，以求完全瞭解問題。
- 對問題或機會的描述
- 該問題可能造成的影響或效應
- 釐清與該問題有關之利害關係人與事
- 若不處理該問題或機會，可能造成的影響
- 期望的理想結果
- 達成預期成果將能帶來的效益與價值
- 該專案與組織整體策略配合的狀況
- 該專案與組織內部之介面整合與相容性問題
- 不確定性與未知數
- 重要假設
- 限制條件
- 環境評估
- 背景與其他支援性資料
在確認需求與問題後，找出最佳方案，提出建議
- 列出所有可能的潛在方案
- 邀請相關專家與利害關係人參加討論
- 運用腦力激盪技巧
- 針對合理可行的方案進一步深入地探討
將可能的潛在方案篩選至剩下2~5個選擇方案，選擇的方式如下。
1.運用財務評量指標來進行方案篩選
- 淨現職 (Net present value / NPV)
- 內部報酬率 (Internal rate of return / IRR)
- 還本期間 (Payback period)
- 現金最大需求 (Cash hole)
2. 財務分析流程
- 確認現金流量來源
- 預估現金流量的大小
- 將現金流量做成圖表
- 利用當時的貼現率來計算現金流量
3. 運用非財務標準來進行專案選擇時，可以先找出選擇該方案的關鍵因素，並設計出各因素的權重，小組成員(或專家)依不同方案給予不同的評分，評分經過加權平均後，選擇分數最高的方案。
規劃研發專案時須考量的項目：
- 目的
- 目標產業及目標（產品規格、工程能力、技術能力）
- 工作內容（製程選擇、製程設計、實驗方法、測試方法、驗收準則、成功因素、須解決的困難）
- 時程規畫（里程碑，查核點與具體成果）
- 資源運用（經費、人力、外包）
- 效益（產出結果、效益評估、未來的影響潛力）
- 其他注意事項，如核心能力的培養
評估科技類專案時所需考量之輸入資訊：
- 專利的分析與檢討（專利地圖）
- 市場調查與優劣勢分析（SWOT）
- 技術趨勢預測（預測方法）
- 廠商或客戶的需求（客戶問卷、QFD）
- 目前市場上的產業資訊
- 政府法規與國際標準
評估科技類專案時所需考量之輸出資訊：
- 技術可行性分析
- 產品的製程規畫
- 實驗性的SOP( Standard Operations Procedures )的規畫
- 測試計畫
- 理論推導的結果與估計
- 製程設計與產品規格
四,成功開發團隊的八項特質
根據調查，遠超過一半軟體開發專案會嚴重超時，幾乎形成軟體專案的慣例，其中更有許多專案面臨半途取消或無疾而終的命運。微軟可以算是全世界最大的軟體公司，自然也為軟體專案的高度不確定性所苦，雖然不乏極為成功的產品，也有產品在尚未面世即中止開發。
微軟從過去數十年來的軟體開發經驗，挑選出成功的開發專案，歸納出八項成功團隊的工作特質：
- 促進開放的溝通
- 為共同的願景工作
- 授權給團隊成員
- 建立明確責任並共同負責
- 專注於提供商業價值
- 為了變動, 隨時保持最佳的彈性
- 投資於品質
- 從經驗中獲得學習
促進開放的溝通
專案是由許多人才，依據自己的專長，貢獻心力共同完成，這需要藉供充分的溝通。多數的專案成員並不善於溝通，特別是技術專長的專家(例如：架構規劃師、程式設計師)認為溝通工作是專案經理的責任，在例行性進度報告中已經完成必要的溝通，沒有更進一步溝通的需要，有些專案經理只讓少數參與討論的成員知道專案資訊，多數專案成員只知道自己眼前的工作。
很多專案失敗的原因在於：『左手不知道右手正在做什麼』，大家彼此不關心其他成員的工作內容，成員們專注於眼前的工作內容，不清楚正在的進行的工作對專案的幫助，形成資源的浪費。例如：某位成員選擇了一個演算法，以預先載入的方式加速執行，但是他卻不知道自己的程式如何被使用，事實上這支程式雖然被大量呼叫，但都是一次性資料，不僅未能發揮預期的效能，還大量地佔用系統資源，使得程式越跑越慢。
為共同的願景工作
偉大的團隊一定都會有明確的願景，這個願景不僅僅是一句口號，或者是主管片面的要求，必需是大家都能同意的方向與目標，並要與專案的成果相結合。缺乏共同願景的團隊，到處是無法協調的意見，以及彼此誤會的目標，即使專案最後得以交付，還會為了如何評估成效或驗收，花更多時間在討論並互相妥協，畢竟，大家是基於不同的願景來看待專案。
共同的願景不僅是專案成功的必要特質，也是其他成功特質的基礎，如：溝通、授權、負責、專注商業價值 …等。專案團隊中，各個成員依自己的專業責任工作，難免在決策上產生不同的意見，若沒有共同的願景，不僅無法化解衝突，還會因為某些小小的意見相左進而擴大成意氣之爭，對專案目標造成負面的影響。
授權給團隊成員
最好的團隊都是由各種領域的專家組成的，團隊中沒有人是永遠的領導者，而是依不同的領域由最適當的成員來負責推動。缺乏授權的團隊，雖然一樣可以經由熟練的工作技巧，讓專案順利進行，但是這樣子並不能發揮團隊的潛力，也因此降低創造力而導致工作士氣低落。
高效能的團隊裡，每一位成員都被授權，並相信自己對專案的承諾的付出，專案經理與客戶都相信這個團隊可以帶來專案的成功。建立這樣的團隊文化，除了有助於團隊面對更高的挑戰，並能主動結合組織的策略目標。團隊內部的結構應該是網路型式的而非階層式，特別是在專案團隊之中，『官大不見得學問大』。
建立明確責任並共同負責
專案成員對專案團隊的責任，必須依角色有明確的定義，能夠以文字方式描述，所有的成員也都能理解並同意責任的分派。若不能作好明確的責任定義，專案將會投入重覆的工作，卻仍不能保證每一件工作都有人去做，常常專案裡每個人都忙不過來，仍然還有很多重要的工作沒有人去做。
微軟的團隊都會在成立初期，建立一張稱為 R&R 的『角色與責任』(Roles and Responsibilities) 的表格，以確保每一項工作都有人負責推動，更重要的是：負責人只是負責推動，而不是獨立去做並獨自承擔成敗，專案成敗是所有成員的責任，沒有人可以坐視專案只是某個人負責的一件工作沒做好，而導致整個專案的失敗。
以角色去定義責任的好處，是可以避免『因人設事』，讓每一個人的工作在合理的條件下共同分擔，不致於造成能力強的人被工作壓得喘不過氣來，而能力弱的沒事可做，只好去想整個專案的未來。經由角色與責任的預先定義，才能夠定期檢視每一個成員的工作表現，以判斷那些人可以勝任更多的工作，那些人則需離開專案。
專注於提供商業價值
雖然如期完成的專案才能算是成功的專案，但切不可因此誤以為專案存在的目的，只是為了如期完成專案，一切工作皆以如期完成來妥協專案產出，而忽略原本專案成立的商業目標。在大型專案裡，偶而聽到這樣的說法：『因為沒辦法如期完成，建議刪除部份功能，或停止品質的改善。』
假若刪除的工作，是與專案目標無直接相關的附屬功能，自然無可厚非，但如是只站在如期完成的立場，遭刪掉的可能會是專案核心的功能，常常核心最複雜且完成風險最大的。結果整個專案只是為了驗收而完成，大家變成白忙一場，而更多的專案則是因為失去存在的價值，而半途取消。專案的所有活動，應該專注於讓專案能夠提供商業價值，避免只是流於專案成員的個人興趣。
為了變動, 隨時保持最佳的彈性
『規格不是早就談好了嗎？為什麼還要變？』相信這是專案成員普遍的抱怨，許多專案的衝突也都是源自這樣的抱怨。經常變動的規格，可能造成專案工作重覆的投入，增加專案執行成本，並一再延後專案的完成時程，大多數的專案成員傾向專案不作變更。但專案變動常不全然是基於個人的喜好，也許是設計時的疏失，也許是大環境的改變，使得若不作專案變更，會讓專案失去商業價值，也就是沒有繼續做下去的必要。
不論是由誰來承擔變更的後果，直覺上專案變更會造成時程延後，其實並不盡然如此，這個『直覺』其實是過時的。傳統的軟體工程模型 (尤其是『瀑布式』模型)，假定專案的過程與成果是可預先規劃的，因此不會設計入變更的可能，一旦專案變更，自然是大費周章。現在的軟體開發工具與方法，已經提供非常具有的彈性的設計方式，只要設計得當，在開發的過程中隨時可以重組軟體的結構。難的只是人的頭腦，一時還不能適應與時俱進的工具與方法，帶來軟體生命週期管理的變革。
投資於品質
品質可以有許多不同的定義，可能是穩定執行的程式，可能是安全的系統，也可能是價格效能比划算的產品。就算我們採取其中某種品質定義，品質仍然不會自動發生，還要靠專案團隊不斷努力改善才有品質，而且品質改善是沒有止境的。整個軟體工業在品質的提昇上，不斷發展出更好的理論、工具、程序與評量，使得軟體品質的提昇可以更具體、更有效。
重要的是，對於品質提昇的投入，間接鼓勵團隊和個人發展一種追求品質卓越的文化，有助於更好的想法的產生，並提高高品質產品的生產效率。因此，對品質的投資，會轉化成對人的投質，好的品質管理更能將品質融入組織文化，讓品質提昇進入一個正向的循環。
從經驗中獲得學習
如果整天只專注於提昇專案成功率的數字上，或是考慮怎樣讓某個失敗的主要因素不至於影響到整個時程，表示我們還未能從經驗中學會成長，特別是從失敗的經驗中學到教訓。就算專案的時程和資源是如此的緊，我們還是要花相當的時間從經驗中學習成長，否則同樣的錯誤必然一犯再犯。
從經驗中獲得學習，是持續改善的重要基礎，整個團隊都可從其他成員成功與失敗的經驗中，學會怎樣複製成功，也學會怎樣避免犯錯。不能從經驗中學習的團隊，一定是到處救火，類似的錯誤不斷地由內部發生。
