軟件開發(fā)的項目周期大體分為3個階段：獲取需求和定義產(chǎn)品,、開發(fā)和測試、部署和運(yùn)維,。

     在獲取需求和定義產(chǎn)品階段,，需要防止的不是進(jìn)度太慢而是過快,、過草率。特別是對于創(chuàng)業(yè)公司的產(chǎn)品經(jīng)理來說,，很可能因為看到開發(fā)人員無事可做而感到壓力,，所以盡快完成產(chǎn)品定義，而沒有充分了解市場和競爭對手信息,，沒有與合作伙伴充分溝通,，沒有做深入的思考。這些因倉促而隱藏的問題,，發(fā)現(xiàn)得早則導(dǎo)致開發(fā)階段大量返工,，發(fā)現(xiàn)得晚則導(dǎo)致產(chǎn)品上線后不受歡迎。常聽一些人說現(xiàn)在互聯(lián)網(wǎng)開發(fā),，講究快速迭代和敏捷,，邊做邊想，返工也正常,。這是一個誤解,。快速迭代指的是將不同版本之間的周期縮短，小步快跑,，而不是在一個版本的周期內(nèi)來回折騰,。

     在開發(fā)和測試階段，項目管理重在跟蹤進(jìn)度和保持溝通—用集成和演示跟蹤進(jìn)度,，基于Bug溝通問題,。要做到各個模塊外部接口相對清晰穩(wěn)定，并盡早完成各個模塊間的集成,，最晚不超過開發(fā)周期的1/4時間,。第一次集成之后，就應(yīng)該開始每日集成和每周演示。每日集成使得測試團(tuán)隊每天能同步測試最新的代碼,，幫助開發(fā)團(tuán)隊盡早發(fā)現(xiàn)問題并及時了解技術(shù)細(xì)節(jié)上的進(jìn)度,；每周演示使產(chǎn)品經(jīng)理、項目經(jīng)理和管理層能從用戶的角度感受產(chǎn)品,，使他們對產(chǎn)品有信心,。集成和演示是項目管理的心跳，合理利用它們,，有助于及時把握項目的健康程度,。無論開發(fā)流程多敏捷，工程師能力多強(qiáng),，記錄和跟蹤Bug都是必不可少的,。開發(fā)團(tuán)隊和測試團(tuán)隊的溝通都應(yīng)該基于Bug，才能言之有物,。開發(fā)工程師每次提交代碼都應(yīng)該記錄是針對哪個Bug的,，每日工作簡報都應(yīng)該寫今天關(guān)/開了哪些Bug。要在每日晨會（站著開,，一般15分鐘內(nèi)）時說好,，今天打算解決哪些Bug，其中有哪些點(diǎn)不清楚,，需要和誰溝通,。

       在后期部署和維護(hù)階段，要快速響應(yīng),?？简灥氖菆F(tuán)隊成員的責(zé)任心和抗壓能力。系統(tǒng)運(yùn)維工程師要深夜工作,，因為部署可能要在流量低的時候進(jìn)行,；項目經(jīng)理要保持能隨時溝通，做出快速而準(zhǔn)確的決定,，鼓勵團(tuán)隊并做出表率,；一旦出現(xiàn)高危害Bug，開發(fā)團(tuán)隊要在24小時內(nèi)準(zhǔn)備好補(bǔ)丁,。Amazon的做法比較有趣：在產(chǎn)品剛上線一段時間內(nèi),，開發(fā)工程師要保持24小時開機(jī)。如果自己負(fù)責(zé)的模塊中出現(xiàn)高危害Bug,，那么很可能會在深夜被系統(tǒng)運(yùn)維工程師叫醒,。這樣不僅能保證快速響應(yīng)，還能讓工程師意識到：前期代碼不好好寫,，后期就別指望能好好睡覺了,。

每個項目經(jīng)理都希望能有效地控制項目進(jìn)度,。但這件看似簡單的事情，實(shí)際操作起來卻常常不盡如人意,。即使在成熟的大公司里,，有著完善的項目管理流程，配備著一流的團(tuán)隊,，項目延期事件還是頻頻發(fā)生,。這里分析主要的三個原因。

常見的原因之計劃不清

很多項目經(jīng)理,，項目完成得很好,，計劃也做得很漂亮，卻總是計劃趕不上變化,。原因在于,，有些時候，按工作量預(yù)估的發(fā)布日期卻得不到領(lǐng)導(dǎo)的同意,，領(lǐng)導(dǎo)有時會說我們現(xiàn)在就是和時間賽跑,，這個項目必須在某某時間發(fā)布。這將致使計劃推倒重來,，一切都要趕進(jìn)度。而對于其他團(tuán)隊成員來說,，這份計劃沒有同他們商量,，無異于強(qiáng)壓任務(wù)。項目還沒開始,，抱怨聲就不絕于耳,。因此，項目工具選得好,、任務(wù)劃分細(xì)致清楚只是做好技術(shù)的基礎(chǔ),，更重要的是項目計劃要得領(lǐng)導(dǎo)和團(tuán)隊成員的認(rèn)同，并愿意為之全力以赴,?？傊胱龊庙椖坑媱?，要做好以下三點(diǎn),。項目計劃前，先和產(chǎn)品經(jīng)理,、上級領(lǐng)導(dǎo)溝通好,，確定這個項目的輕重緩急。團(tuán)隊成員要達(dá)成一致意見,，項目經(jīng)理不可獨(dú)斷專行,。項目計劃要細(xì)化到天,、功能點(diǎn)要責(zé)任到人、確定里程碑點(diǎn),。

常見的原因之需求問題

需求中的功能點(diǎn)要在PRD（產(chǎn)品需求文檔）中羅列清楚,，業(yè)務(wù)流程要寫得完整清晰，交互細(xì)節(jié)要體現(xiàn)在視覺稿中,。要組織項目組所有成員參加PRD評審,，評審時要針對具體的問題，給出明確的處理意見,。暫時不能確認(rèn)的問題,，問題跟進(jìn)人要在限定時間內(nèi)給出反饋，項目經(jīng)理可以制定問題跟進(jìn)表格,。項目進(jìn)行中的需求變更,，盡量在前期提出。在項目管理的過程中,，當(dāng)前期的需求和計劃都確
定后,，項目經(jīng)理不能只顧著跟進(jìn)開發(fā)和測試的進(jìn)度，也要階段性地和需求方多溝通,，讓他們及時反饋意見,。不要等到臨發(fā)布時，產(chǎn)品經(jīng)理跑過來說“我要的不是這樣的,，這里要改一下”,。永遠(yuǎn)不要把問題留到最后一分鐘，要超前一步,，留有余地,。下面是一個真實(shí)的案例。案例情景：該項目的整個周期為2個月,，有3輪功能測試,。當(dāng)?shù)?輪功能測試結(jié)束時，也就是即將進(jìn)入預(yù)發(fā)布階段時,，產(chǎn)品經(jīng)理才給出用戶反饋并要求按用戶的反饋修改,。改動的地方涉及到頁面的樣式、文案,、SQL語句和校驗邏輯等,，總共可能有20多個文件要被改動。項目經(jīng)理建議只改頁面的樣式和文案,，其他部
分先不要改,，等下次升級維護(hù)時再改，否則可能會影響發(fā)布,。而在多次交涉無果的情況下,，開發(fā)人員只能硬著頭皮修改,，測試人員只能再重新測一輪。雖然大家努力地按需求方的要求做了,，但項目延期已不可避免了,。

常見的原因之溝通不暢

為某項目臨時組建的團(tuán)隊往往來自不同部門，團(tuán)隊成員之間不熟悉,，此時,，要為團(tuán)隊建立一個溝通通道，確保溝通順暢,。常用方式為：建立一個內(nèi)部網(wǎng)絡(luò)空間,，所有文檔資源統(tǒng)一存放，供團(tuán)隊成員共享,；利用即時聊天工具,，建立一個項目群，每天通報項目進(jìn)度,；建立項目郵件組,，所有變更達(dá)成一致后，發(fā)送郵件確認(rèn),；每天要開15分鐘晨會,，每周一次周會，每周發(fā)送項目周報,；跨團(tuán)隊項目,，最好申請獨(dú)立的項目室，所有項目組成員坐在一起工作,，降低溝通成本。

重視細(xì)節(jié)

項目管理的目的是能夠按照預(yù)定的成本,、進(jìn)度和質(zhì)量要求順利地對人員,、產(chǎn)品、過程和項目進(jìn)行分析和管理,。在項目管理中,，有些細(xì)節(jié)需要引起項目經(jīng)理的重視。

根據(jù)經(jīng)驗規(guī)劃

即先做少量的規(guī)劃,，再根據(jù)實(shí)踐過程中得到的信息來做進(jìn)一步的規(guī)劃,，這樣可提高項目的可行性。試圖預(yù)測未來的規(guī)劃很難奏效,，除非你是個預(yù)言家,，否則應(yīng)該盡量在項目中根據(jù)經(jīng)驗做規(guī)劃和日程安排。

安排項目日程

首先,，要按可交付物安排日程,，而不是按功能,；其次，要以迭代的方式安排日程,；再次,，要使用難度較低的工具安排項目日程。過度追求完美的項目時間表可能意味著在實(shí)際項目中浪費(fèi)更多的時間,。

足夠的時間規(guī)劃

日程安排是由整個項目團(tuán)隊共同制定的,，因此，每個人都要對日程有信心,。不過,，天有不測風(fēng)云，總會發(fā)生點(diǎn)兒意外,，所以我們要做足夠的時間規(guī)劃,，而且要使用波浪式規(guī)劃，這樣才可以隨著環(huán)境的變化靈活地更新日程安排,。

管理會議

在組織項目時,，項目經(jīng)理要盡量避免浪費(fèi)時間的會議。要讓團(tuán)隊將注意力集中在項目上,，這是最簡單,、最有效的方式。在幫助團(tuán)隊朝著合理的交付截止日期前進(jìn)時,，要保證團(tuán)隊不受外界干擾和影響,。如果會議對于任何人都毫無價值，那就取消掉,；同時準(zhǔn)許團(tuán)隊成員不參與無法貢獻(xiàn)和收獲價值的會議,。也許有些團(tuán)隊成員會不高興，認(rèn)為你覺得他們不夠重要從而不能參加會議,。要跟他們解釋清楚,，你不讓他們參會是因為他們太重要了。

速度圖

如果只能繪制一個圖表,，那就選擇速度圖,。速度圖集三種度量方式為一身：需求、已完成工作和時間,。雖然無法從中看到自己希望了解的缺陷率或成本,，卻能從該圖中對項目的整體進(jìn)度有所掌握。使用速度圖可以使你在一張圖中同時度量多個趨勢：整體需求數(shù)量和已完成工作,，其中包括所有的測試,、文檔以及項目需要等其他內(nèi)容。這是最有用的圖表,，是項目經(jīng)理的好朋友,。但要注意,，速度圖只是獲取數(shù)據(jù)的工具，不是目的,。

測試

從項目開始就要堅持“減少技術(shù)債務(wù)”的原則,，讓測試與開發(fā)同步進(jìn)行。測試會將項目的風(fēng)險展現(xiàn)在眾人面前,，大家越早看到這些風(fēng)險越好,。在采納順序式生命周期的項目中，要讓測試人員參與到需求分析階段,，詢問他們關(guān)于產(chǎn)品需求的反饋,；在采用迭代式生命周期的項目中，要請測試人員幫助評估原型,；使用增量式生命周期的項目,，只要有可供測試的部分，就可以讓測試人員盡早開始測試功能,；在實(shí)施敏捷的項目中,，要確保測試人員與開發(fā)人員一起工作，以開展技術(shù)層面的測試,。同時,，還要讓測試人員與產(chǎn)品負(fù)責(zé)人一起，編寫面向客戶層面的測試,。