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

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

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

范圍管理是項目經(jīng)理具備的首要能力。范圍說明是未來項目決策的基線，也是衡量項目是否成功的標準。在我們軟件開發(fā)項目中，需求規(guī)格就是我們項目的范圍的體現(xiàn)。我的經(jīng)驗是項目經(jīng)理應(yīng)極端重視需求，成功的需求管理才能保證范圍在基線內(nèi)，需求調(diào)查、討論、分析、歸檔、review、變更、回溯等一系列活動是我們需求管理的有效活動。

計劃能力是項目經(jīng)理的應(yīng)具備的另一個技能，其中軟件開發(fā)任務(wù)的估算是一個難點，即使有歷史數(shù)據(jù)達到CMM4的軟件企業(yè)也會有20%-50%的誤差，我的一些做法用三層到四層的WBS模版從底向上進行時間資源的估計，會從自己經(jīng)驗和相似項目的歷史數(shù)據(jù)中進行加權(quán)平均，時間資源的平衡，在WBS分解模版中采用自底向上估計，估計時我們采用了三人以上匿名delphi法，設(shè)定差值閾值為30%，如果與平均值的差值比小于此閾值，將不在重新估計，如果大于將進行重新估計，重新估計后如果還是超過設(shè)定閾值，估計人要寫明為什么如此估計的原因。對于閾值內(nèi)估計值我們采用歷史經(jīng)驗數(shù)據(jù)進行修正即可作為我們WBS工作包的估計值。

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

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

Review活動在我們的項目中重視度很高，我們的一些評審制度，評審首先進行小組內(nèi)部預評審，內(nèi)部評審模版記錄提交項目經(jīng)理和評審組織者；正式評審可以先走email評審，評審對象完成人將評審文檔或其他可交付物提前一天email給所有評審人，請評審人各自將意見email給評審組織者，評審組織者按評審人員匯總整理意見，提交第二天討論。討論后，評審結(jié)果記錄和每人評審意見列入文檔考核績效。

軟件開發(fā)項目中風險管理，風險管理不只是項目經(jīng)理估計風險，我們風險管理采用了全員的頭腦風暴法，并按權(quán)重進行TOP10列表管理。針對TOP10風險，制定相應(yīng)風險應(yīng)對計劃。在軟件開發(fā)中，主要的風險有技術(shù)風險，所以風險應(yīng)對計劃是項目計劃前期的技術(shù)驗證和測試，需求不確定等風險的應(yīng)對計劃是原型和迭代的開發(fā)方法。例如在界面越來越重要的今天，需求規(guī)格中會做出原型界面并提前得到客戶方的review是很好的風險應(yīng)對計劃 。

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

使項目成員目標一致，項目成員更好的進行配合和協(xié)調(diào)，有良好的溝通氣氛、適當?shù)母偁帲瑴p少沖突，提高項目組的工作能力和效率，團隊建設(shè)是項目經(jīng)理需要關(guān)注的一個課題，我的一些經(jīng)驗是盡早開始項目團隊建設(shè)并持續(xù)進行；在項目計劃、風險等重大決策上鼓勵大家參與并取得大家的認同；經(jīng)常評估團隊績效和效率；最好不要超過每周50小時的工作量；“利用好“老員工和上級領(lǐng)導。

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

項目經(jīng)理對項目成敗負責，是項目中承受壓力最大的一個，在風險較高的軟件開發(fā)項目尤甚，項目經(jīng)理溝通層面和項目可視化的工作繁復冗雜，計劃中一定將管理活動列入工作量統(tǒng)計中，以便能使自己有時間和精力處理項目更重要的事情。項目經(jīng)理應(yīng)能忠實的反映一些無法力所能及的事情，取得上司的支持，這對項目成敗非常重要。

軟件項目管理，需要我們不但關(guān)注項目管理技術(shù)等在軟件行業(yè)中的應(yīng)用，還應(yīng)該關(guān)注如何與軟件新思想和技術(shù)的整合，例如XP等思想，使我們得到更高效益的產(chǎn)出。欲想琢其玉，必先利其器，項目管理和我們軟件開發(fā)、質(zhì)量管理等得一系列工具和模版，是我們事半功倍的利器。他山之石可以攻玉，關(guān)注一些管理界的發(fā)展，例如目前的中國式管理等，將其經(jīng)驗用于軟件項目管理實踐并總結(jié)，將為我們帶來更大實效。

以上是軟件項目管理的一些思索和經(jīng)驗，歡迎與大家交流共享。

【?發(fā)表評論?0條?】