二、誰在造坑？

軟件項目涉眾眾多，造坑的多為項目實施團隊內(nèi)部，而究其原因也是多方面的，但是始終離不了項目的四個維度——時間、范圍、成本、質(zhì)量。很多時候客戶并不具備軟件項目的實施經(jīng)驗，而實施團隊為了迎合客戶意愿，也會多多少少的在這四了維度上做文章。資源、時間不足，輕質(zhì)量重功能，往往成為造坑的契機。所以，不用懷疑，造坑的往往是我們自己。很難理解，真正挖出大坑的人，后也是填坑的人。一個人很容易被外部事務所左右，如“同假的多了，真的到成假的了一樣”，多數(shù)人不愿意在一個新環(huán)境中表現(xiàn)得特立獨行。但也有老的程序員對我說過：“當別人做錯了，你不要跟著去做！”所以，我認為工作是工作，不需要我們在其中融合多少興趣，也不要求我們有過多的付出，但對于工作的成果則要求我們認真的對待。俗話說：“拿多少錢，辦多少事！”如果多少有些團隊意識，能夠?qū)ψ约旱墓ぷ髫撠�，那至少在意識上，我們能給自己少造些坑。

三、如何免坑？

一）清除盲區(qū)

以下觀點，僅是我對軟件項目中一些錯誤認識的歸納：

寫出能用的程序行啦！我們應該首先清楚我們做的是什么，一個成熟的團隊產(chǎn)出的可交付成果應該包括軟件編程產(chǎn)品，相關文檔，項目實施過程中的經(jīng)驗教訓已經(jīng)其它一些非形式的成果（培訓）。這里，我們必須清楚的認識到，我們所開發(fā)是是編程產(chǎn)品，而不是我們個人的技術實踐或大學的畢設。對于編程產(chǎn)品，我們必須認識到，其是產(chǎn)品級別的，必須保證質(zhì)量，必須提高用戶體驗，必須考慮系統(tǒng)的諸多特性或維度。這一過程遠比我們自己寫個程序要復雜的多。設計需要不斷地進行迭代；開發(fā)人員需要遵守嚴苛的規(guī)范，編寫大量的注釋和大量的異常處理；測試人員需要不斷地進行各種重復測試，但是正是這種全局的規(guī)范，全體團隊的不懈努力，才保證了我們的編程產(chǎn)物可以稱之為產(chǎn)品。所以，一定要明確，我們要完成的是一個產(chǎn)品，而不是一個畢業(yè)設計，它不是一個人的技術實踐，而是整個團隊傾注精力去完成的佳成果。我們可以輕松的實現(xiàn)客戶的某些需求，但需求背后的某些東西，需要我們認真對待，比如安全性和性能等。實現(xiàn)功能的程序誰都會寫，而寫出高質(zhì)量的程序的才是真正的藝術。

盡快開始編碼吧！軟件構件是一個精心設計的過程，其前期準備十分重要。在后期修復缺陷的成本要遠遠高于前期。因此，在項目執(zhí)行前，前期的規(guī)化十分必要。在前期每發(fā)現(xiàn)一個缺陷，都會為后期節(jié)省大量的成本。

需求怎么變了！沒有不變的需求。

進度落后了招人唄！這是種典型的錯誤認識，《人月神話》中已經(jīng)說明的很清楚了——往一個進度落后的項目中注入資源，只會使進度進一步落后。雖然，這本著作成為PM必讀之作，其思想也被業(yè)界所廣泛認可，但是，還是會有很多管理者單純的認為，通過注入資源能解決問題。對于這些人，只能讓實踐來檢驗真理了。

軟件質(zhì)量保證是測試的工作！這是一種逃避責任的說辭。如果把代碼質(zhì)量比喻為減肥，那么測試無疑是一個磅秤，減肥工作還是要有開發(fā)人員來完成。所以，不要將代碼質(zhì)量都寄希望于測試工作上。即使是大規(guī)模的用戶測試，其錯誤檢出率也不足五成。而真正挑起代碼質(zhì)量重擔的是代碼審查。

程序員你8小時寫了這么點代碼？讓開發(fā)人員將全部時間都花在編碼上是不可能的。開發(fā)人員需要時間預讀文檔，需要與相關干系人進行溝通，需要花時間來搜索資源。此外，可能還需要編寫文檔，參加會議，培訓以及處理個人事務等等。這些時間都會無情的奪走編碼的時間。程序員大約有近似20%的時間甚至更多會用在與編碼無關的事情上（不算上班或聊QQ），所以不要錯誤的以為每個程序員每天能寫8小時的程序。

你寫了這么多行代碼真有效率！編碼不是在掃地，比誰掃的面積大。不能單純用行數(shù)來評價開發(fā)人員的工作量。評判的標準應該結(jié)合模塊的復雜度，編碼的缺陷檢出量以及終交付時可用代碼的比例（實踐表明，我們報廢了大量的無用代碼）。

他把自己100多個BUG都改了，我們得在組里表揚下他！在我看來這樣的領導不跟也罷，這是讓人相當無語的行為。好的開發(fā)者在提交測試前，覺得會對自己的代碼進行走查和調(diào)試，甚至使用單元測試工具，因此其代碼的缺陷檢出量很小。這樣的程序員，才值得被表揚。而那個改了自己100多個BUG的人，作為管理者應該想想，流程哪里錯了，需要進行改進。

設計我來定，開發(fā)你閉嘴！這樣的例子也不少，這種做法有一種聽起來非常合理的理由——保證項目架構的概念完整性。其解釋為，如果將設計人員從開發(fā)人員剝離，那么可以將架構的概念完整性統(tǒng)一，因為設計人員的數(shù)量比開發(fā)人員是數(shù)量要少的多，更容易統(tǒng)一認識。而這樣做的項目組，也默認地認為設計組的技術實力要明顯高于開發(fā)組。他們往往從開發(fā)組中選擇的設計人員到設計組，但也會有走眼的時候。其一，硬手沒有被提拔。這時候多半是硬手對設計不滿，并對團隊管理層產(chǎn)生質(zhì)疑，并想法設法進行溝通。如果處理的好，可能硬手會被重視，如果溝通無門，那之后，可能會充斥著抱怨和不滿，以及人際關系的惡化。有些強硬些的可能會選擇拒絕不合理的設計或更為極端的是離職。走眼的另一種情況是，挑的人干不了設計。這樣往往是讓他鍛煉，而不是撤換（彼得原理——每個人都會被晉升到他不適合的崗位）。這郁悶到極點了，設計者將會與相應的數(shù)名開發(fā)人員進行一場曠日持久的暗戰(zhàn)。其中，已經(jīng)不只是個人的抱怨，甚至會演變成成員集體的士氣低落，并終促成小組的重組。我認為，有必要將開發(fā)人員納入設計活動。應該參考開發(fā)人員的意見，其原因有三：其一，開發(fā)人員對實現(xiàn)相當熟悉，往往發(fā)現(xiàn)設計中的不足；其二，通過授權開發(fā)者參與設計，能讓其感受到認同感，提升其參與項目的欲望，和責任心；其三，讓開發(fā)參與設計，可以對設計人員進行儲備，在需要時作為備選資源使用。

客戶（領導）說必須完成，我也沒辦法！這是“領導一句話，勞動人民跑斷腿！”這是非常典型的加班借口。軟件構建過程如同耕種，你每次只處理它的一小部分，一點一點的加到整個系統(tǒng)，使系統(tǒng)一點一點的“生長”。這也暗示了，工作應該按部班，正如春種秋收一樣，各個環(huán)節(jié)有強硬的邏輯存在。所以，我們必須學會對不合理的要求說“不”。這里并不是說要拒絕客戶的需求，而是指應該向客戶說明情況并提出相應的備選方案以供參考。例如通過通過削減范圍來達到按時完工的目的。PM需要向客戶說明情況，并向其提供幾套可行的解決方案，以促成項目向良性發(fā)展。

我是領導我來排進度！工作進度的安排不能是領導的單方?jīng)Q策，而應該參考做了解這項工作的人的意見。

系統(tǒng)上線了，項目算結(jié)束了！只有當可交付成果成功移交，項目進行的相應的收尾工作，項目的經(jīng)驗教訓文檔被總結(jié)和歸納，一個項目才算真正意義上的完成。