項目從無到有，中間解決了一個個技術難題，有時為了趕進度，不知加了多少次班，終于到了收尾階段，看到勝利的署光了，是不是該松口氣了，不要忘了黎明前是最黑暗的，這時候對外的交流將更加明顯和重要，項目將全部移交給測試人員進行測試，銷售、實施人員將拿著產品去給客戶演示、實施，中間一但出了問題，處理不當，責任將會像皮球一樣踢來踢去，并極有可能上演“狗咬狗”大會。

　　項目是否真的到了收尾階段？對照開始寫的需求，是不是所有的功能都搞定，只要有一個沒弄好，即使這個功能再小，也是還沒做完！當然你可以對外說都弄好了，但到底是怎么回事，自己心里要有數；中國不是有句古話叫寧可欺人，不可欺已，在沒有達到收尾的要求時，便要進行相應的延時了，一般的延時有：

　　1、正規延時。到了規定時間做不完。對照需求、任務文檔統計每個人未完成的任務，并將未完成的任務重新進行分配（注意要形成任務文檔），上報上級，待批準后，按照正常的開發任務一樣進行。（最好能把小組的人招集到一起，談談為什么出現了延時，找找原因，打打氣，延時時間內抓抓緊，因為延時之后再完成不了就說不過去了）

　　2、蒙著延時之占用測試的時間。到了規定時間還有一部分功能未做完，但是測試那里一下子不可能測到所有的功能，把未完成的項目打包交給測試，一般情況下測試的流程跟開發的流程順序差不多（不是的話，可以跟測試說下），這樣的話測試就先測做好的功能，一般會每天上交BUG表，開發的進行更正（同時完成未完成功能），更新程序時一并更新過去即可，神不知鬼不覺？？組內的人都知道，潛規則？

　　3、蒙著延時之與客戶相互忽悠。功能未能全部完成（中間很可能沒有測試環節），但要急著見婆家，只好說做完了，然后去做客戶做演示，或先裝一個試用，未完成部分能忽悠盡量忽悠（避而不談、扯東扯西、問東說西等伎倆），客戶難免會提修改意見，自然要加時間，這就達到目的了，未完成的功能就可以插到這段時間里面去完成了。

　　對于這幾種項目延時的方法，盡量使用第一種，規范化操作，是最好的；少用第二種，因為由于各種原因不能進行正規延時（如已經延時了多次），用下這招也是可以的；能不用則不用第三種，個人最痛恨這種方法，延時得很痛苦，拖得越久客戶想法越多（新的需求，對開發方有意見），往往不斷反復下去，變成無盡的需求。（我在大學里做的項目延時幾乎都是第三種延時，苦不堪言；跟朋友交流時，發現不少的公司延時也常常用第三種方法，難道又是潛規則？！）

　　對照著需求文檔，客戶要求的所有功能都實現了，恭喜，項目可以進入到收尾階段了。剩下的工作分為組內和組外分別進行處理。

　　小組內部，不過份放松，打起精神，做好后續工作，等待驗收完畢。

　　不過份放松，打起精神。任務都做完了，辛苦了那么久，當然要放松一下羅，但放松不能過了度，一但超過了度，再做起事來效率好低好幾倍（任務是做完了，但隨時要做事呀，測試發現了大問題、銷售的說客戶要加功能等），在這點上我是吃過大虧的：剛開始領一個項目時，做完了，交到相關人員，全體開發人員休息兩天，休息回來突然有要求要對一些流程進行修改，發現大家都沒勁（包括我），本來按平時的效率做一天就OK了，結果弄了3天，后來回想起來其實也正常呀，試想一下：一群人在跑5000米，跑完了之后一個個都累得躺在地上了，然后突然來個人叫大家再跑50米，誰還跑得動呀！不要過份放松，僅僅向組員說說是不起作用的，本人做法是給他們分配一些其它的工作，來保持一個基本的狀態。

　　（1）對自己的任務進行測試，發現錯誤自行進行修改。對測試發現BUG進行更正。

　　（2）不足的地方進行改進，哪些地方的代碼是體力勞動、重復勞動，能否用技術進行替代。（平時不是說沒時間研究技術嗎，現在不正是時候么？）

　　（3）好的地方繼續發揚，哪些模塊可以抽象成通用模塊，形成通用模塊并編寫文檔，下次開發就省時省力了。

　　（4）把一些小問題、小技巧形成文檔，下次有疑問一查不就知道了嗎？

　　上面的工作尤其要注意形成文檔，公司的知識庫不就是這樣豐富起來的嗎，個人認為上面的工作（2-3）是比較有意義的，又沒有正式任務的壓力，即保持了一種開發的狀態又適度地放松了自己。

　　小組外部，明確責任，是自己的不推卸，多交流，不斗氣，以解決問題為目的。

　　以前聽老師說開發與測試是對立，之間矛盾尖銳，當時覺得有點夸張；在實際的操作中發現確實是這樣的（特別是有嚴格的績效考核、相關利益分配的時候），測試人員以為找出程序中的錯誤為主要目的，而在程序員這邊素有把程序看做自己的孩子這一說，試想一下別人為了找你孩子的錯誤為樂，你能不著急嗎？再加上假如再有銷售人員摻和進來，那真的是熱鬧了，出了問題，三方協調的時候，測試的罵開發：拖延時間造成測試時間不夠；銷售的反映：程序沒及時完成，或質量有問題，或功能不全，使他丟了客戶；開發的反罵：測試的對錯誤的分級不正確，還有銷售人員對軟件不熟悉，演示時自己造成了失誤。。。我一同學戲稱這為“狗咬狗”大會（汗，好像他也是其中的一員呀），我想造成這種現象這主要原因是責任不清，交流不夠。

對責任劃分的一點個人看法

　　當前的責任劃分模式比較模糊、不明確，出了一個問題，即可以說是銷售的，也可以是開發的，還可以說是測試的；更有甚者，發現問題，居然說“只要是與程序有關的就是你們開發的”，我當時就想反問一句“你能找出完全與程序沒關的問題來嗎？”，可能是這種想法在作怪，出了問題開發的人員都有份，極容易造成開發人員身心疲憊。

?

個人認為責任要劃分要有明確的界線，總結為一句話：誰發現了什么類型的問題責任歸屬于誰，如圖

?

?

如圖中所標1，2，3部分同時對號入座，即可唯一地確定問題責任者。當1，2，3不能對入到相關責任規定時，疑罪從無，本輪不追究責任人；討論后再形成責任規定，以后按規定執行。

　　例如：同為一個程序中的嚴重錯誤

　　假如是客戶發現，則是測試人員的責任（因為經過了測試人員的測試，測試人員有責任保證程序中不存在嚴重的錯誤）

　　假如是測試人員發現，則是開發人員的責任。（這條應該不用說明了吧）

　　這樣的話，責任劃分得一清二楚，對號入座，又怎么總會出現責任推來推去的情況？但我只是開發小組的組長而已，不能將自己的想法實行到小組之外，所以只能夠通過多交流來解決問題，雖然治標不治，都總比沒的強！

　　（寫到這里發現文章已經很長了，還有與組外人員交流的一些心得想法沒寫，作為組長剛開始處理時覺得與組外人員交流很麻煩，因為大家的利益經常是對立，很容易把關系弄僵，但是后來細心觀察、思考、實踐后，發現一些小技巧，可以巧妙地解決很多問題，又何必大家爭得臉紅耳赤呢，現在回想起來還是別有一番樂趣的）

?

轉載于:https://blog.51cto.com/2537085/1174494

總結

以上是生活随笔為你收集整理的项目收尾阶段管理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。