曾經有個笑話，說三個軟體高階人材等待上帝安排工作，一個說自己擅長抽象思維，上帝說那就做系統分析師吧；一個說自己工作非常細心，上帝說那就做QA；最後一個說，我實在沒有更多的才能，那就做專案經理吧。有句專案管理名言則是這個笑話的最好解釋：對專案經理的知識要求是要有1英里寬，7英寸深。也就是說，各方面的綜合能力是專案經理的首要技能。

專案管理引入中國好多年了，除了國外的PMP、IPMP認證體系，現在更是將之引入高等學位教育。除了最先應用專案管理的建築行業，現在各行各業都非常重視行業內的專案管理，這些足以可以看到專案管理的蓬勃發展。但是軟體專案失敗案例還是比比皆是的今天，如何將專案管理與新理論和技術層出不窮的軟體產業雙劍合璧？專案管理理論是歐美國家伴隨著生產管理起步的，雖然方法論是通用的，但是如何在軟體開發中產生更大效益，需要更多的業界專案經理以及高層思索和總結。

一個成功的建築行業專案經理也會是一個合格的IT專案經理嗎？專案管理有之一個名言：一個成功的建築行業專案經理也會是一個合格的IT專案經理。在歐美國家是適用的，這樣跨行業的例子也非常多。但據我瞭解在大陸這樣的例子還非常鮮見。尤其軟體開發行業，就更沒這種先例了，為什麼在歐美或者印度模式中，都是行得通，在中國不行呢？歐美或者印度模式的專案經理負責制定開發計劃、協調、以及填寫各種專案輸出表格或模版就夠了。在這種模式中專案經理不一定要求必須是技術專家，但更強調專案經理的工作經驗，一般會要求專案經理有8年以上工作經驗。而在中國，尤其是現在一個有三年工作經驗的team leader也會稱專案經理，當然他也並不需要對成本、人員、採購等眾多專案管理領域的關注，這樣的team裡也根本不會有技術經理或顧問專有角色的配備，專案經理要更多的關注技術因素，所以專案經理一般是與行業和產品同步成長起來的。如何做好質量、成本、溝通、時間、以及更資源參與的全面專案管理是我們的專案經理的課題。

範圍管理是專案經理具備的首要能力。範圍說明是未來專案決策的基線，也是衡量專案是否成功的標準。在我們軟體開發專案中，需求規格就是我們專案的範圍的體現。我的經驗是專案經理應極端重視需求，成功的需求管理才能保證範圍在基線內，需求調查、討論、分析、歸檔、review、變更、回溯等一系列活動是我們需求管理的有效活動。

計劃能力是專案經理的應具備的另一個技能，其中軟體開發任務的估算是一個難點，即使有歷史資料達到CMM4的軟體企業也會有20%-50%的誤差，我的一些做法用三層到四層的WBS模版從底向上進行時間資源的估計，會從自己經驗和相似專案的歷史資料中進行加權平均，時間資源的平衡，在WBS分解模版中採用自底向上估計，估計時我們採用了三人以上匿名delphi法，設定差值閾值為30%，如果與平均值的差值比小於此閾值，將不在重新估計，如果大於將進行重新估計，重新估計後如果還是超過設定閾值，估計人要寫明為什麼如此估計的原因。對於閾值內估計值我們採用歷史經驗資料進行修正即可作為我們WBS工作包的估計值。

合適的軟體開發生命週期模式，對軟體開發專案尤為關鍵。根據專案的需求、資源、風險、時間、質量等實際情況，選擇合適的軟體開發生命週期模式，對軟體開發專案尤為關鍵。印度軟體模式中更是提出了流程模式重於專案。在需求不確定、變化較頻繁的專案我們可以選用迭代和原型法。在產品按版本遞增開發的專案，由於每期需求比較穩定，宜選擇瀑布變種的V模型進行測試提前的生命週期。開發模式的選擇將影響專案計劃，例如V字形，每個過程都有嚴格的輸入輸出，上一個過程的輸出作為此過程的輸入，實際情況中我們會選用改良的V模型，一些過程可以並行，例如需求規格完成後，可以系統測試計劃和概要設計並行。在實際專案管理中開發模型生命週期中各過程的輸出宜作為milestone(里程碑)設定計劃控制點。

時間、質量和成本是衡量專案成功的三要素，時間和成本因為有形比較容易監控，質量控制在軟體開發專案中非常重要了，所以我們很多過程和活動（文件review、程式碼走讀、單元測試、整合測試、系統測試、以及各過程的需求反饋追蹤等）都是保障質量的活動。現在好多專案都特別重視了系統測試（包括功能測試、效能測試等），但是忽略了單元測試。單元測試是所有測試中最底層的一類測試，是第一個環節，也是最重要的一個環節；是唯一一次有保證能夠程式碼覆蓋率達到100%的測試，是整個軟體測試過程的基礎和前提；單元測試防止了開發的後期因BUG過多而失控；單元測試的價效比是最好的。在專案中我們引入了TDD單元測試實踐，並關注了編譯檢查、程式碼走讀，以及在等價類、邊界值、因果圖等方法下的黑盒功能測試和達到覆蓋率指標下自動單元測試程式碼的白盒測試。並將XP方法中的Nightly Test實踐達到程式碼和測試程式碼的每日building。

Review活動在我們的專案中重視度很高，我們的一些評審制度，評審首先進行小組內部預評審，內部評審模版記錄提交專案經理和評審組織者；正式評審可以先走email評審，評審物件完成人將評審文件或其他可交付物提前一天email給所有評審人，請評審人各自將意見email給評審組織者，評審組織者按評審人員彙總整理意見，提交第二天討論。討論後，評審結果記錄和每人評審意見列入文件考核績效。

軟體開發專案中風險管理，風險管理不只是專案經理估計風險，我們風險管理採用了全員的頭腦風暴法，並按權重進行TOP10列表管理。針對TOP10風險，制定相應風險應對計劃。在軟體開發中，主要的風險有技術風險，所以風險應對計劃是專案計劃前期的技術驗證和測試，需求不確定等風險的應對計劃是原型和迭代的開發方法。例如在介面越來越重要的今天，需求規格中會做出原型介面並提前得到客戶方的review是很好的風險應對計劃。

溝通是監督、控制的基礎，是推動專案執行的基礎，更是減少衝突的良方。有項調查專案經理90%時間在溝通。的確溝通佔用了專案經理的大部分時間，因為專案經理是面對專案干係人最多的角色。在專案溝通方面，作為專案經理應週期性向機構管理層和客戶報告專案的技術、進度、費用、質量方面的狀況；在客戶面前全面代表所在機構，與客戶建立和維持友好和開放的關係，直接面向客戶的專案經理是客戶與所在機構最關鍵的聯絡點；做一個專案溝通的推動者、避免專案中出現溝通的遏制者；為專案溝通積極創造環境，包括集中工作；保證所有會議的高效率。專案經理要根據不同人員和不同情況下的問題選擇最合適的溝通方式（電話、傳真、Email、口頭、即時通訊工具、報告、會議、私下交流等），來達到好的溝通效果。如果專案中出現與干係人等的問題，首先要檢查溝通計劃了。現在好多溝通事項是隻裝在專案經理的腦子中的，如何做好專案的溝通計劃，是專案經理要培養成習慣的一個重要技能。這在我們軟體專案中尤甚。例如員工流動始終是軟體行業的一個顯著特徵，所以專案經理在處理此類問題時溝通計劃就非常重要了。曾經我們一個專案開發中，一個team leader 想離職技術移民到加拿大，由於前期不知是否能辦好也不知道什麼時候能辦好，所以沒有聲張，等辦好後，離離職就只有很短的時間了，而專案到了非常重要的時期，他們team成立不久，其他成員均無太多經驗，他的角色暫時無法找到合適的替代者，我做了以下準備，一、透過朋友推薦和參加一些技術交流的機會招聘合適人員；二、透過老總，全公司內部挖潛，並建立推薦人獎勵制度；三、由於平時大家關係很好以私人餞行名義和他溝通。告訴他現在他在專案無人替代的重要性，是否他有推薦的合適的人選替代，因為移民過去要保證半年時間在移民地，而找工作可能會有困難，而且他也表示並不想離職，代他和公司人事溝通，以重新修改勞動合同而不離職方式解決了他的後顧之憂，該teamleader 也主動做好安排，延期出國，保障了專案的順利結項和驗收。我想，在獎懲、激勵和重要溝通中選擇合適的溝通方式會產生迥然不同的結局，尤其是我們好多軟體開發人員比較內秀而不善言辭，專案經理更應注意這點，較好的引導和傾聽能力是每個專案經理需要具備素質。

使專案成員目標一致，專案成員更好的進行配合和協調，有良好的溝通氣氛、適當的競爭，減少衝突，提高專案組的工作能力和效率，團隊建設是專案經理需要關注的一個課題，我的一些經驗是儘早開始專案團隊建設並持續進行；在專案計劃、風險等重大決策上鼓勵大家參與並取得大家的認同；經常評估團隊績效和效率；最好不要超過每週50小時的工作量；“利用好“老員工和上級領導。

經驗分享。一項對專案經理的調查顯示，專案經理平均每週參加6個會議，其中25%的時間浪費在無用的討論上。會議效率低最普遍的3個原因是：會議沒有很好的計劃、會議沒有被適當的領導、無紀律的與會者。我們軟體專案也會遇到相同的問題，專案啟動會、評估會、大大小小的評審會、技術會、周例會等等一系列會議會隨著專案進展而召開，如何保證高效的會議效果，我的一些會議技巧與大家共享：確實需要開會時才開會；訂立會議紀律；非常清楚的明確會議目標；提前準備一個會議議程；提倡各會議參與人的會前準備；鼓勵參與，但在會議過程中遵守會議議程；把團隊建設融入會議、作會議記錄、會後跟蹤所有安排任務的執行情況。

專案經理對專案成敗負責，是專案中承受壓力最大的一個，在風險較高的軟體開發專案尤甚，專案經理溝通層面和專案視覺化的工作繁複冗雜，計劃中一定將管理活動列入工作量統計中，以便能使自己有時間和精力處理專案更重要的事情。專案經理應能忠實的反映一些無法力所能及的事情，取得上司的支援，這對專案成敗非常重要。

軟體專案管理，需要我們不但關注專案管理技術等在軟體行業中的應用，還應該關注如何與軟體新思想和技術的整合，例如XP等思想，使我們得到更高效益的產出。欲想琢其玉，必先利其器，專案管理和我們軟體開發、質量管理等得一系列工具和模版，是我們事半功倍的利器。他山之石可以攻玉，關注一些管理界的發展，例如目前的中國式管理等，將其經驗用於軟體專案管理實踐並總結，將為我們帶來更大實效。

以上是軟體專案管理的一些思索和經驗，歡迎與大家交流共享。
[@more@]

軟體專案成功的要素（轉）

相關文章