項目管理不僅適用于客戶的項目,同樣也適合于生活中的項目. 有了它生活變得非富多彩,有了它管理客戶的項目更加輕松愉快.項目管理沒有一成不變的方法, 唯一的辦法就是根據(jù)項目的實際情況去靈活的處理, 不論你采用敏捷模式(Agile), 還是使用瀑布模式(waterfall) , 最終的結(jié)果就是按時,保質(zhì)保量的完成客戶確定的目標. 正如兵書所云,只有天時,地利,人和,才能取得戰(zhàn)爭的勝利, 項目管理尤是.
一個項目成敗,有幾個關(guān)鍵的因素影響著,諸如項目范圍,時間,費用和質(zhì)量.實際上在項目管理中,我認為對需求變更的管理以及對質(zhì)量的控制顯得尤為關(guān)鍵.由于工作在外企,所以有機會和國外的客戶(項目經(jīng)理)一起合作項目. 這里舉個實際項目的例子,一起分享我是如何管理需求的變化以及控制項目的質(zhì)量.
簡單介紹一下項目的背景,項目的名字(dZine)既是公司名字也是項目名字, 是為國外的一家機場開發(fā)的信息實時發(fā)布系統(tǒng), 軟件整體的功能由服務端, 中轉(zhuǎn)端, 以及客戶端三部分功能組成. 軟件是基于客戶原有的一套系統(tǒng)上開發(fā)的, 需求及業(yè)務邏輯都很復雜.項目整體采用敏捷模式.
需求變更的控制
項目啟動后, 作為項目經(jīng)理的我,開始進行項目的監(jiān)控活動,每周的項目進度周報都及時地發(fā)給客戶,以便客戶了解項目的狀況.有一天, 收到客戶的一封郵件, 大致意思是,希望增加一個新功能,并且很急.我立即召集項目組骨干成員,對新需求進行了分析,并且考慮了它可能的一些潛在的風險,諸如,它對整體架構(gòu)的影響, 技術(shù)實現(xiàn)的可行性,開發(fā)費用以及所需的工時等等. 討論的結(jié)果是,我們項目組可以接受這個變更,在CCB(控制變更委員會)同意之后, 我隨即給客戶寫了反饋郵件, 并且附帶了RFC(需求變更單),在變更單中包括一些需要確認的信息:完成新功能所需的人/日,開發(fā)費用,完成開發(fā)的截止日期等等,同時完成了對Blueprint(需求文檔)的更新.結(jié)果當天就得到了客戶的確認反饋, 他同意這次變更以及由此產(chǎn)生的費用.
以后的事情,變得清晰而明了,我們開發(fā)了新功能,并且按計劃提交了測試版本.客戶看似很滿意, 沒過多久,客戶有了第二次變更, 功能與第一個變更有關(guān),只是業(yè)務邏輯更復雜,有了之前的處理辦法,變更這件事看似很簡單,評估需求的影響,分析潛在風險,費用估算,CCB的審批,最后到客戶確認. 一切都還順利,按時提交了版本后, 我們滿心歡喜的等待著客戶的反饋.
幾天之后,得到了客戶的反饋,只不過不是表揚,而是質(zhì)疑我們?yōu)槭裁床唤?jīng)過他的同意就擅自修改需求,并且給我指出了問題所在,這還不算,這封郵件還抄送給公司的總經(jīng)理. 我馬上意識到問題的嚴重性,在客戶是上帝的今天,我絲毫不敢怠慢,馬上召集項目組成員,一起查找以往的變更歷史,通過需求跟蹤矩陣進行反推,最后終于找到了此次變更, 并且找到了客戶的確認郵件,看到這份客戶確認的需求變更單,我如獲至寶,當我把客戶以前的確認郵件轉(zhuǎn)發(fā)給他,并且抄送了總經(jīng)理后,此時的心理充滿了勝利的喜悅.果然第二天收到了客戶的道歉郵件, 承認是自己的問題,并且又增加了新的需求,當然在郵件中也沒有忘記表揚我一下.客戶的反饋對我們這些項目經(jīng)理至關(guān)重要.半小時后,又收到了總經(jīng)理的回復郵件,僅僅兩個單詞, Well done!足矣,這兩個字既包含對我工作的認可,又包含了對我的信任. 這一案例,后來被總經(jīng)理多次提及,并且被收集到公司的資產(chǎn)庫中,作為其他項目的參考案例.以至于在后來的項目總結(jié)會上, 我無不感慨地說,項目成也需求變更,敗也需求變更.如果處理不好,的確對項目造成很大的影響.
質(zhì)量保證管理
在國外開始推廣Q