綜合管理：關(guān)于項目管理的一點體會

申請免費試用、咨詢電話：400-8352-114

這段時間，一直在負責一個項目的管理與開發(fā)。在時間短、任務(wù)緊，而團隊人員又大部分是沒有經(jīng)驗的菜鳥的惡劣情況下，我?guī)ьI(lǐng)接近40人的團隊，終于在客戶規(guī)定的時間范圍內(nèi)如期交付產(chǎn)品。這其中，經(jīng)歷了需求變更、人員變動（因為其它任務(wù)，先后有近10人離開團隊）等諸多問題，項目仍然取得成功了，不能不說有幾分僥幸，但此外也有一些經(jīng)驗與教訓(xùn)可以與大家分享。
　　項目開發(fā)方面
　　需求
　　項目應(yīng)以需求為核心。一個項目是否能夠成功，對需求的準確把握在成功因素中要占上60%的比例。不管系統(tǒng)的架構(gòu)設(shè)計、團隊管理有多么的成功，如果需求出現(xiàn)偏差，仍然是南轅北轍。由于EAS項目的特殊性，項目開發(fā)過程中能夠與客戶建立有效快速的溝通渠道，是項目成功的關(guān)鍵。
　　需求必須獲得客戶的確認。通過需求調(diào)研與分析后獲得的用戶需求說明書，以及軟件需求規(guī)格說明書都必須得到客戶的簽字確認。確認的內(nèi)容包括項目的目標、范圍以及項目需求功能點（用例）。EAS項目在前期對需求不夠重視，導(dǎo)致在需求理解上出現(xiàn)了一些偏差，從而影響了項目的進度。幸而得到了及時的糾正，在項目管理部的協(xié)助下，所有需求都得了客戶或客戶代表的簽字確認。從而使得項目在客戶驗收時，有了充分的保證。
　　項目應(yīng)確立專門的需求分析師。公司沒有專門的需求分析師，不能不說是人員配備上的一大弊端。從EAS項目的開發(fā)過程中，我們就充分地認識到這一問題的嚴重性。需求的不斷更改，客戶遲遲未簽字確認，原因正是在于我們沒有專門的具有豐富經(jīng)驗的需求分析師。普通開發(fā)人員在調(diào)研需求以及撰寫需求規(guī)格說明書時，總是會出現(xiàn)偏差或理解錯誤的地方。軟件需求分析是一項重要且負責的技術(shù)，沒有經(jīng)過專門訓(xùn)練的需求分析師，通常會給項目帶來隱患。
　　項目應(yīng)指定各個模塊的需求接口人。只有這樣，才能有效地保證項目組與客戶的及時溝通，快速響應(yīng)客戶的請求與反饋。EAS項目在開發(fā)早期及時地確立了需求接口人，在一定程度上規(guī)避了需求變更給項目帶來的風險。但是，確立的需求接口人未經(jīng)過系統(tǒng)培訓(xùn)，在需求調(diào)研以及與客戶溝通的過程中，工作表現(xiàn)只能說是差強人意。
　　注意維護需求調(diào)研記錄以及需求跟蹤表。這一工作做得不夠好。由于需求調(diào)研人不夠?qū)I(yè)，而項目經(jīng)理以及需求分析負責人對這一過程還欠缺足夠的重視，同時沒有好的工具或流程來監(jiān)控這一過程，使得需求調(diào)研記錄沒有發(fā)揮更大的作用。此外，需求跟蹤也非常重要，畢竟，任何項目的需求都不是固定不變的，需求隨時會發(fā)生變更，而開發(fā)人員實現(xiàn)的需求也可能會與客戶的要求偏差。
　　注意維護需求矩陣。項目經(jīng)理對這一內(nèi)容缺乏足夠的重視與理解，項目開發(fā)過程體系中也缺乏好的需求矩陣文檔模板。但是在項目中后期，項目及時撰寫了EAS項目需求功能列表，并結(jié)合交付版本與客戶進行了溝通和協(xié)商，從而規(guī)避了需求偏差的風險。
　　控制需求變更。重視CCB的作用，同時應(yīng)建立需求變更的響應(yīng)機制。EAS項目組對于需求變更的響應(yīng)還不夠及時，這一點項目經(jīng)理與項目管理小組要擔負一定的責任。
　　設(shè)計
　　重視架構(gòu)設(shè)計。EAS項目的成功，一定程度是源于我們有個優(yōu)秀的框架開發(fā)小組，我們在項目立項之初就基本確定了整個系統(tǒng)的架構(gòu)。其中雖然發(fā)生了一些變化，但核心架構(gòu)仍然沒有發(fā)生大的變化。由于，我們建立了穩(wěn)定、簡單的系統(tǒng)框架，可以極大地提高開發(fā)效率，規(guī)避了對框架的重復(fù)編碼。
　　善于對設(shè)計作出取舍。項目開發(fā)的三要素是成本、質(zhì)量與進度。在保證質(zhì)量的前提下，為了項目進度不出現(xiàn)大的偏差，EAS項目組并沒有過分強調(diào)技術(shù)，特別是在考慮進度的情況下，犧牲了系統(tǒng)的部分可擴展性。雖然這為系統(tǒng)的后期維護帶來一定隱患，但卻能夠有效地保證項目的進度。從EAS最初的架構(gòu)設(shè)計來看，我們引入了Castle與AOP，試圖簡化ORM以及橫切關(guān)注點例如日志、異常、權(quán)限、事務(wù)等功能的實現(xiàn)。同時，希望采用WCF，利用SOA思想建立松散耦合的面向服務(wù)應(yīng)用程序。但隨著客戶需求的變化，我們果斷地放棄了采用WCF的構(gòu)想，同時又克服了技術(shù)困難，堅持了對Castle與AOP的使用，并為此成立了框架開發(fā)小組。事實證明，在技術(shù)的抉擇上我們作出了正確的決定。
　　重視UI原型設(shè)計。系統(tǒng)的原型設(shè)計與需求分析相輔相成。如果有好的原型版本交付給客戶，則客戶更能夠理解系統(tǒng)的實現(xiàn)，促進溝通的有效性與準確性。在EAS項目中，我們從一開始就確立了原型設(shè)計小組，并在分析需求階段，就開始了原型設(shè)計。這一做法無疑在客戶溝通、需求確認、UI設(shè)計等方面都發(fā)揮了很大的作用。但是，我們在這一點上，由于缺乏專門的UI設(shè)計人員，因此，這一工作還存在很大的缺陷，甚至于UI的設(shè)計為迭代版本的交付帶來了很大的障礙。在項目后期，關(guān)于UI的bug是最多。因此，我們認為在開發(fā)類似的WEB應(yīng)用程序時，應(yīng)盡早確立UI設(shè)計規(guī)范，以約束所有的UI設(shè)計。同時，必須培養(yǎng)專門的UI設(shè)計師，在開始原型設(shè)計時，就盡快完成UI交互的設(shè)計。并且，必須成立專門的UI設(shè)計小組，在需求階段與需求分析師合作，在編碼階段與開發(fā)人員合作。
　　測試
　　測試成員應(yīng)了解需求。如果不了解需求，測試人員無法編寫正確的測試用例，同時在測試過程中，也可能因為錯誤地理解需求，從而導(dǎo)致報告錯誤的bug，影響開發(fā)人員效率。
　　加強開發(fā)人員與測試人員的合作。開發(fā)人員必須及時響應(yīng)測試人員提交的bug。而測試人員也應(yīng)跟蹤開發(fā)人員對bug的修復(fù)情況。
　　測試之初必須確定測試原則，對bug的嚴重程度進行分級。同時，必須確定修復(fù)bug的優(yōu)先級別。