這段時(shí)間，一直在負責一個(gè)項目的管理與開(kāi)發(fā)。在時(shí)間短、任務(wù)緊，而團隊人員又大部分是沒(méi)有經(jīng)驗的菜鳥(niǎo)的惡劣情況下，我帶領(lǐng)接近40人的團隊，終于在客戶(hù)規定的時(shí)間范圍內如期交付產(chǎn)品。這其中，經(jīng)歷了需求變更、人員變動(dòng)（因為其它任務(wù)，先后有近10人離開(kāi)團隊）等諸多問(wèn)題，項目仍然取得成功了，不能不說(shuō)有幾分僥幸，但此外也有一些經(jīng)驗與教訓可以與大家分享。

　　項目開(kāi)發(fā)方面

　　需求

　　項目應以需求為核心。一個(gè)項目是否能夠成功，對需求的準確把握在成功因素中要占上60%的比例。不管系統的架構設計、團隊管理有多么的成功，如果需求出現偏差，仍然是南轅北轍。由于EAS項目的特殊性，項目開(kāi)發(fā)過(guò)程中能夠與客戶(hù)建立有效快速的溝通渠道，是項目成功的關(guān)鍵。

　　需求必須獲得客戶(hù)的確認。通過(guò)需求調研與分析后獲得的用戶(hù)需求說(shuō)明書(shū)，以及軟件需求規格說(shuō)明書(shū)都必須得到客戶(hù)的簽字確認。確認的內容包括項目的目標、范圍以及項目需求功能點(diǎn)（用例）。EAS項目在前期對需求不夠重視，導致在需求理解上出現了一些偏差，從而影響了項目的進(jìn)度。幸而得到了及時(shí)的糾正，在項目管理部的協(xié)助下，所有需求都得了客戶(hù)或客戶(hù)代表的簽字確認。從而使得項目在客戶(hù)驗收時(shí)，有了充分的保證。

　　項目應確立專(zhuān)門(mén)的需求分析師。公司沒(méi)有專(zhuān)門(mén)的需求分析師，不能不說(shuō)是人員配備上的一大弊端。從EAS項目的開(kāi)發(fā)過(guò)程中，我們就充分地認識到這一問(wèn)題的嚴重性。需求的不斷更改，客戶(hù)遲遲未簽字確認，原因正是在于我們沒(méi)有專(zhuān)門(mén)的具有豐富經(jīng)驗的需求分析師。普通開(kāi)發(fā)人員在調研需求以及撰寫(xiě)需求規格說(shuō)明書(shū)時(shí)，總是會(huì )出現偏差或理解錯誤的地方。軟件需求分析是一項重要且負責的技術(shù)，沒(méi)有經(jīng)過(guò)專(zhuān)門(mén)訓練的需求分析師，通常會(huì )給項目帶來(lái)隱患。

　　項目應指定各個(gè)模塊的需求接口人。只有這樣，才能有效地保證項目組與客戶(hù)的及時(shí)溝通，快速響應客戶(hù)的請求與反饋。EAS項目在開(kāi)發(fā)早期及時(shí)地確立了需求接口人，在一定程度上規避了需求變更給項目帶來(lái)的風(fēng)險。但是，確立的需求接口人未經(jīng)過(guò)系統培訓，在需求調研以及與客戶(hù)溝通的過(guò)程中，工作表現只能說(shuō)是差強人意。

　　注意維護需求調研記錄以及需求跟蹤表。這一工作做得不夠好。由于需求調研人不夠專(zhuān)業(yè)，而項目經(jīng)理以及需求分析負責人對這一過(guò)程還欠缺足夠的重視，同時(shí)沒(méi)有好的工具或流程來(lái)監控這一過(guò)程，使得需求調研記錄沒(méi)有發(fā)揮更大的作用。此外，需求跟蹤也非常重要，畢竟，任何項目的需求都不是固定不變的，需求隨時(shí)會(huì )發(fā)生變更，而開(kāi)發(fā)人員實(shí)現的需求也可能會(huì )與客戶(hù)的要求偏差。

　　注意維護需求矩陣。項目經(jīng)理對這一內容缺乏足夠的重視與理解，項目開(kāi)發(fā)過(guò)程體系中也缺乏好的需求矩陣文檔模板。但是在項目中后期，項目及時(shí)撰寫(xiě)了EAS項目需求功能列表，并結合交付版本與客戶(hù)進(jìn)行了溝通和協(xié)商，從而規避了需求偏差的風(fēng)險。

　　控制需求變更。重視CCB的作用，同時(shí)應建立需求變更的響應機制。EAS項目組對于需求變更的響應還不夠及時(shí)，這一點(diǎn)項目經(jīng)理與項目管理小組要擔負一定的責任。

　　設計

　　重視架構設計。EAS項目的成功，一定程度是源于我們有個(gè)優(yōu)秀的框架開(kāi)發(fā)小組，我們在項目立項之初就基本確定了整個(gè)系統的架構。其中雖然發(fā)生了一些變化，但核心架構仍然沒(méi)有發(fā)生大的變化。由于，我們建立了穩定、簡(jiǎn)單的系統框架，可以極大地提高開(kāi)發(fā)效率，規避了對框架的重復編碼。

　　善于對設計作出取舍。項目開(kāi)發(fā)的三要素是成本、質(zhì)量與進(jìn)度。在保證質(zhì)量的前提下，為了項目進(jìn)度不出現大的偏差，EAS項目組并沒(méi)有過(guò)分強調技術(shù)，特別是在考慮進(jìn)度的情況下，犧牲了系統的部分可擴展性。雖然這為系統的后期維護帶來(lái)一定隱患，但卻能夠有效地保證項目的進(jìn)度。從EAS最初的架構設計來(lái)看，我們引入了Castle與AOP，試圖簡(jiǎn)化ORM以及橫切關(guān)注點(diǎn)例如日志、異常、權限、事務(wù)等功能的實(shí)現。同時(shí)，希望采用WCF，利用SOA思想建立松散耦合的面向服務(wù)應用程序。但隨著(zhù)客戶(hù)需求的變化，我們果斷地放棄了采用WCF的構想，同時(shí)又克服了技術(shù)困難，堅持了對Castle與AOP的使用，并為此成立了框架開(kāi)發(fā)小組。事實(shí)證明，在技術(shù)的抉擇上我們作出了正確的決定。

　　重視UI原型設計。系統的原型設計與需求分析相輔相成。如果有好的原型版本交付給客戶(hù)，則客戶(hù)更能夠理解系統的實(shí)現，促進(jìn)溝通的有效性與準確性。在EAS項目中，我們從一開(kāi)始就確立了原型設計小組，并在分析需求階段，就開(kāi)始了原型設計。這一做法無(wú)疑在客戶(hù)溝通、需求確認、UI設計等方面都發(fā)揮了很大的作用。但是，我們在這一點(diǎn)上，由于缺乏專(zhuān)門(mén)的UI設計人員，因此，這一工作還存在很大的缺陷，甚至于UI的設計為迭代版本的交付帶來(lái)了很大的障礙。在項目后期，關(guān)于UI的bug是最多。因此，我們認為在開(kāi)發(fā)類(lèi)似的WEB應用程序時(shí)，應盡早確立UI設計規范，以約束所有的UI設計。同時(shí)，必須培養專(zhuān)門(mén)的UI設計師，在開(kāi)始原型設計時(shí)，就盡快完成UI交互的設計。并且，必須成立專(zhuān)門(mén)的UI設計小組，在需求階段與需求分析師合作，在編碼階段與開(kāi)發(fā)人員合作。

　　測試測試成員應了解需求。如果不了解需求，測試人員無(wú)法編寫(xiě)正確的測試用例，同時(shí)在測試過(guò)程中，也可能因為錯誤地理解需求，從而導致報告錯誤的bug，影響開(kāi)發(fā)人員效率。

　　加強開(kāi)發(fā)人員與測試人員的合作。開(kāi)發(fā)人員必須及時(shí)響應測試人員提交的bug.而測試人員也應跟蹤開(kāi)發(fā)人員對bug的修復情況。

　　測試之初必須確定測試原則，對bug的嚴重程度進(jìn)行分級。同時(shí)，必須確定修復bug的優(yōu)先級別。

　　項目管理進(jìn)度管理保證項目進(jìn)度不出現大的偏差的前提是制定一個(gè)好的項目計劃。必須根據項目規模，成員情況，技術(shù)難度等多方面考慮整個(gè)項目計劃。如果項目的deadline已經(jīng)確定，則必須采用一些方法來(lái)保障項目計劃的完成。首先是選擇符合項目的軟件開(kāi)發(fā)生命周期。通常情況下，并不建議采用瀑布開(kāi)發(fā)方式。最佳的辦法，應該是RUP或者敏捷開(kāi)發(fā)，然后結合原型法制訂項目計劃。這樣可以規避因為需求變更產(chǎn)生的風(fēng)險。

　　其次，要每日跟蹤項目的進(jìn)展情況�？梢酝ㄟ^(guò)晨會(huì )、周會(huì )以及項目日報、項目周報了解項目進(jìn)展情況。同時(shí)，需要為各個(gè)小組指定進(jìn)度跟蹤人，根據各個(gè)小組長(cháng)的日報，判斷實(shí)際的進(jìn)度是否與計劃出現偏差。

　　要制定項目進(jìn)度偏差的應對方法。一旦項目進(jìn)度出現了偏差，必須采取相應錯誤解決問(wèn)題�；蛘咄ㄟ^(guò)加班、增加人手、申請項目進(jìn)度等方法及時(shí)作出響應。

　　及時(shí)向項目成員匯報項目進(jìn)度情況。只有讓各個(gè)項目成員了解到項目現狀，才能夠給每個(gè)成員增加壓力，不至于松懈。同時(shí)，也能夠使得每個(gè)成員能有一個(gè)目標，而不至于茫然失措。

　　制定項目計劃時(shí)，必須考慮階段評審與同行評審的時(shí)間。這一點(diǎn)在EAS項目中做得不夠好。其中原因也是由于項目進(jìn)度本身較緊的緣故。

　　注意維護項目進(jìn)度跟蹤表與項目進(jìn)度偏差跟蹤表。讓項目管理部以及QA及時(shí)掌握項目進(jìn)度，有利于對項目進(jìn)度的管理。

　　變更管理變更包括需求變更、人員變更。如果不控制好，兩者對項目的進(jìn)展都會(huì )帶來(lái)災難性的后果。需求變更在前面已經(jīng)敘述，而EAS項目中發(fā)現人員變更的情況也非常嚴重，因此這里重點(diǎn)介紹關(guān)于人員變更的管理。

　　如果發(fā)生人員進(jìn)入的情況，那么對項目帶來(lái)的通常都會(huì )是好的影響。但我們也必須注意如何讓新成員更快地融入團隊。整體上講，如果需要新成員加入，發(fā)生變更的最佳時(shí)機是項目前期。如果在項目中后期加入新成員，無(wú)疑則意味著(zhù)項目出現了災難性的后果。而新增加的成員，由于不熟悉項目，所能帶來(lái)好的影響也是有限的。如果不處理好新成員與老成員之間的合作關(guān)系，反而會(huì )帶來(lái)負面影響。

　　人員的退出很多時(shí)候是不可控的，同時(shí)對項目帶來(lái)的影響也是不可估計的。為了將這些影響降到最低，就必須在項目開(kāi)始之初就要確立編碼規范。同時(shí)，還應該重視對文檔的維護與更新。而在人員退出時(shí)，必須做好交接工作。同時(shí)，還應對這種變更進(jìn)行合理的評估，并及時(shí)報告項目管理部，并與客戶(hù)及時(shí)溝通。如果對項目進(jìn)度有嚴重影響，應爭取最大的努力取得客戶(hù)的理解，提出項目延期的申請。

　　風(fēng)險管理要在項目開(kāi)始之初就考慮到項目過(guò)程中可能出現的所有風(fēng)險，是不現實(shí)的。但是，我們必須考慮對風(fēng)險的管理，尤其是在制訂項目計劃以及創(chuàng )建團隊的時(shí)候，考慮這一因素。風(fēng)險有很多，包括需求的風(fēng)險、進(jìn)度的風(fēng)險、質(zhì)量的風(fēng)險以及技術(shù)風(fēng)險等。必須制定一套完整的風(fēng)險管理計劃，而一旦發(fā)生了風(fēng)險，則必須及時(shí)響應，組織相關(guān)人員解決風(fēng)險。不能忽略任何一個(gè)小的風(fēng)險，否則一個(gè)小的風(fēng)險到最后會(huì )造成大的災難。風(fēng)險的把握必須要有項目經(jīng)理與系統架構師把關(guān)。

　　成員管理不團結的項目組是無(wú)法保證項目的成功地。項目經(jīng)理與項目組長(cháng)在管理團隊成員時(shí)，必須時(shí)刻注意成員狀況，即使處理工作出現的矛盾與摩擦，隨時(shí)保證團隊合作精神得到最大程度的執行。

　　持續地保證項目成員的士氣非常重要。項目每取得一個(gè)階段性的進(jìn)展，必須告知全體成員，如此才能收獲成功的信心。項目開(kāi)發(fā)過(guò)程需要注意勞逸結合。一味地強制性加班，只能降低項目成員的工作效率。項目過(guò)程中，如能適當地開(kāi)展一些活動(dòng)，無(wú)疑能夠讓團隊成員感受到項目組的集體氣氛。在階段實(shí)現的重要時(shí)刻，項目經(jīng)理必須注意通過(guò)文字、語(yǔ)言等激勵項目組成員。而項目經(jīng)理的自信也是保證成員士氣的一個(gè)關(guān)鍵。

　　必須注意了解團隊成員的心理狀態(tài)與工作狀態(tài)。項目成員的戰斗力除了是個(gè)人的能力發(fā)揮之外，一個(gè)好的領(lǐng)導也是至關(guān)重要的。因此，必須選擇合適的項目組長(cháng)，通過(guò)他們掌握整個(gè)項目團隊成員的工作進(jìn)展。同時(shí)，還要了解每個(gè)成員的能力，以安排合適的角色與崗位。

　　重視開(kāi)發(fā)組與測試組以及項目管理小組的合作。項目組是一個(gè)整體，每個(gè)成員的角色不同，但大家都是團隊的重要一員。