“誰也無法改變現狀，唯有無數程式設計師血灑大地，才能使專案重建天日。”這一點也不誇張，軟體專案做爛了就是個坑，參與者也不過是填坑的。就像是在魔獸世界戰場遇到國家隊一樣，你贏也贏不了，出也出不去。

一、坑有多深？

當我們進入一個專案時，通過不斷觀察我們可以發現我們的專案到底是不是一個坑。造坑的專案，往往具有某些“臭味”，以下是我的一些認識，這些“臭味”即是專案健康狀態不佳的明顯標誌：

編碼規範形同廢紙，程式碼質量低下

每個專案都有編碼規範，但真正嚴格實施卻是另一回事。太多的專案把編碼規範作為形式的存在，沒人在乎讓開發人員寫出“人能讀懂的程式”，註釋和命名也成了開發人員的隨心所欲。project上永遠只有開發任務，而幾乎找不到單元測試的時間和程式碼審查的時間。在高壓進度之下的專案，顯得如此山寨。當我們還在抱怨自己工資低的時候，就先看看我們的程式還能稱作OOP嗎。

缺乏文件或文件質量低下

前期文件很重要，不論是框架的API使用手冊，還是需求或設計文件，以及各種既定流程的規範，不同種類的模板及核對表，等等這些文件，對於專案來說都是非常重要的資源。而往往有些專案，這類文件就是交由非軟體行業的人員來編寫，或者前期根本不打算在文件上浪費時間。這就導致了，缺少相關文件或文件質量低下，在軟體構建過程中，開發者和團隊，不得不為這種“表面工程”的產物而糾結。甚至會退回到前期準備工作，完成所需的文件。有些文件可以在後期補，但有些必須在前期進行準備，以保住團隊降低風險，減少缺陷引人的機率並提高編碼質量，如果前期這類文件沒有做好，那麼就會像考前不復習一樣，自食惡果。

無盡的需求變更，永遠追不上的進度

這是最常見也是最可怕的，因為無論怎樣，我們都無法完成它。客戶可能認為改個程式，就像改個Excel一樣簡單省事，甚至會使用可動用的一切權利和資源來推行變更。好吧，我承認這樣的客戶我遇到過很多。當我向客戶解釋過變更的代價並提供備選方案後，也就只能等待客戶的選擇了，這多少有些運數的成分，但也是無奈之舉。

僅僅靠加班應對進度落後

進度落後並不可怕，可怕的是僅靠加班來追趕進度。這是問題的關鍵，長時間的趕工仍然無法趕上進度，這隻意味著專案有某種更深層次的問題，已經不是單開趕工可以解決的了。留意那些長時間加班的專案，他們往往在管理上存在很大問題，發現這些問題，在你成為PM時，不要犯類似錯誤。

溝通無門

如果你在一個“叫天天不應，叫地地不靈”的專案裡，那你最好省心吧。專案中溝通很重要，但總有些專案，領導的工作太忙，人就是找不到，發出去的郵件就是沒人回，遇到問題就是自己扛。在這樣的專案裡也有一些好處，比如鍛鍊自己的自學能力，以及磨練意志與根性。不過這些，也都是我的自嘲。低效的溝通將導致不必要的返工，這才是我所痛恨之處。我最為惱火的一段經歷是，甲方要進行變更，開了一週的會沒人通知我，我的小組在這一週裡完成了原計劃的數個需求並進入到測試階段， 但這些需求均被砍掉 。本來只有甲方告知是可以調整進度開發其它模組的，但最終演變為資源的浪費。可見，溝通是多麼的重要。

沒人關心質量

因為軟體構建屬於專業領域，客戶並不具備相應領域的知識，由於這種資訊不對稱，助長了軟體的質量低下。我們開發的軟體可以是“低等級高質量”的，但不能夠是“高等級低質量”的。但是，太多的專案不在注重編碼質量，這與軟體構建的複雜度有關，也與整個行業的風氣有關。但不管何種原因，提高程式碼質量仍然應該作為團隊的努力方向。團隊應該獎勵那些，編寫高質量程式碼的程式設計師。如果你的團隊獎勵的是那些，“BUG殺手”（每天修改上百個BUG），而冷落那些缺陷檢出數量很低的程式設計師，那麼，你的PM是個不懂技術的，至少我本人認為，任何有技術背景的PM都應該獎勵那些正在保持職業操守，認真對待需求，保證程式碼質量的程式設計師。他們為專案付出了更多，更多的異常處理， 更多的測試除錯，更多的檢查，更多的重構，雖然他們的進度並不快，但他們引人的缺陷數量很少。每個做過開發的人都會在質量和進度上做出取捨，而我敬佩那些選擇質量程式設計師，因為他們才是真正拿開發當事業的人。在此，向所有努力提高程式碼質量的程式設計師致敬！

沒人為缺陷買單

沒人為自己的成果負責。需求產出了低質量的文件，設計沒有進行充分的迭代，開發可以怎麼簡單怎麼寫，測試可以隨意測測，沒人為自己的成果中的缺陷買單，除了專案經理，他為專案承擔唯一責任。當專案組所有人員都在混時，就是在給自己挖坑。這種缺陷的堆積，會像放射性元素在食物鏈中的堆積一樣，早晚專案會因此而崩潰。

過高的離職率

這個是最明顯的“臭味”，這說明我們的同行已經在這裡無法忍受了。它所帶來的惡略影響不光體現在可用資源的減少，還體現在對成員士氣的極大影響。如果不及時改善，這將是一個非常惡性的迴圈，當往一個進度落後的專案中新增資源只會使進度進一步落後，而非正離職導致必須補充新的資源，資源從入職到培訓都會對對團隊產生震盪，並降低現行團隊的生產力。一個頻繁處於形成階段的團隊，很難要求其有什麼凝聚力，團隊問題將會凸顯，尤其是在溝通上，在專案忙的時候很少能照顧到新人。花費在對新人進行培訓，和與其溝通上的時間，很可能得不償失。

團隊中的不良情緒

不同團隊開始扎堆並相互敵視，例如開發組認為設計組是一幫搞業務的白痴，根本不懂程式設計；測試組認為開發組的人就是垃圾，BUG提交了多少便還是無法關閉；PM開始抱怨，自己的成員不配合；成員開始抱怨，PM是個純管理沒資格指揮內行做事。等等，諸如此類的怨念會在團隊中積累，並以某個導火索為契機爆發。面對現實吧，至少，我遠沒有自己想象的那樣高尚。我承認我曾經會和別的程式設計師說：“你看XX他們寫的程式碼…什麼呀…”，這樣的話。在過去我也吐槽過別人程式碼，這種做法是錯誤的，我為此表示歉意。現在，如果有必要，我會說程式碼有缺陷，但絕不會說他的程式碼不好。我希望，我們能彼此尊重。對於技術人來說，不尊重他的成果就是不尊重他的人，所以我還是建議PM在管理工作中，多用“缺陷”，少用“不行”、“不對”。但是，專案中也總是有些人，靠鄙視別人的成果來彰顯自己的實力。這些人，有，但很少。至少我遇到的很少，遇到過幾個，讓他們的話語成為你學習的動力吧。我曾經被人諷刺UI做的太醜，之後我學會了SL和FLEX；被人鄙視基礎太差，之後開始閱讀《CLR Via C#》；我朋友被人嘲笑過資料庫設計，現在人家也開始買書深造。團隊中就是這樣，我們無法管住別人的嘴，但我們可以管住自己的。少說多聽，一鳴驚人，乃上上之策。不要受情緒的影響，保持一個平靜的心。

沒有專案或階段的後評價

不對專案的階段進行後評價，也意味著沒人在乎你到底幹了些什麼，所有人都只是進度是否完成，而沒有對完成的好壞進行評價。這也意味了，僅靠做好你的工作，你是無法得到領導的重視的。最終只有那些加班時間最長的程式設計師被領導認可。而能力強，口碑好的成員也只能在團隊和客戶中間留下傳說。

二、誰在造坑？

軟體專案涉眾眾多，造坑的多為專案實施團隊內部，而究其原因也是多方面的，但是始終離不了專案的四個維度——時間、範圍、成本、質量。很多時候客戶並不具備軟體專案的實施經驗，而實施團隊為了迎合客戶意願，也會多多少少的在這四了維度上做文章。資源、時間不足，輕質量重功能，往往成為造坑的契機。所以，不用懷疑，造坑的往往是我們自己。很難理解，真正挖出大坑的人，最後也是填坑的人。一個人很容易被外部事務所左右，就如“同假的多了，真的到成假的了一樣”，多數人不願意在一個新環境中表現得特立獨行。但也有老的程式設計師對我說過：“當別人做錯了，你就不要跟著去做！”所以，我認為工作就是工作，不需要我們在其中融合多少興趣，也不要求我們有過多的付出，但對於工作的成果則要求我們認真的對待。俗話說：“拿多少錢，辦多少事！”如果多少有些團隊意識，能夠對自己的工作負責，那至少在意識上，我們能給自己少造些坑。

三、如何免坑？

（一） 清除盲區

以下觀點，僅是我對軟體專案中一些錯誤認識的歸納：

寫出能用的程式就行啦！

我們應該首先清楚我們做的是什麼，一個成熟的團隊產出的可交付成果應該包括軟體程式設計產品，相關文件，專案實施過程中的經驗教訓已經其它一些非形式的成果（培訓）。這裡，我們必須清楚的認識到，我們所開發是是程式設計產品，而不是我們個人的技術實踐或大學的畢設。對於程式設計產品，我們必須認識到，其是產品級別的，必須保證質量，必須提高使用者體驗，必須考慮系統的諸多特性或維度。這一過程遠比我們自己寫個程式要複雜的多。設計需要不斷地進行迭代；開發人員需要遵守嚴苛的規範，編寫大量的註釋和大量的異常處理；測試人員需要不斷地進行各種重複測試，但是正是這種全域性的規範，全體團隊的不懈努力，才保證了我們的程式設計產物可以稱之為產品。所以，一定要明確，我們要完成的是一個產品，而不是一個畢業設計，它不是一個人的技術實踐，而是整個團隊傾注精力去完成的最佳成果。我們可以輕鬆的實現客戶的某些需求，但需求背後的某些東西，需要我們認真對待，比如安全性和效能等。實現功能的程式誰都會寫，而寫出高質量的程式的才是真正的藝術。

儘快開始編碼吧 ！

軟體構件是一個精心設計的過程，其前期準備十分重要。在後期修復缺陷的成本要遠遠高於前期。因此，在專案執行前，前期的規化十分必要。在前期每發現一個缺陷，都會為後期節省大量的成本。
需求怎麼變了！ 沒有不變的需求。

進度落後了就招人唄！

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

軟體質量保證是測試的工作！

這是一種逃避責任的說辭。如果把程式碼質量比喻為減肥，那麼測試無疑是一個磅秤，減肥工作還是要有開發人員來完成。所以，不要將程式碼質量都寄希望於測試工作上。即使是大規模的使用者測試，其錯誤檢出率也不足五成。而真正挑起程式碼質量重擔的是程式碼審查。
程式設計師你8小時就寫了這麼點程式碼？ 讓開發人員將全部時間都花在編碼上是不可能的。開發人員需要時間預讀文件，需要與相關干係人進行溝通，需要花時間來搜尋資源。此外，可能還需要編寫文件，參加會議，培訓以及處理個人事務等等。這些時間都會無情的奪走編碼的時間。程式設計師大約有近似20%的時間甚至更多會用在與編碼無關的事情上（不算上班或聊QQ），所以不要錯誤的以為每個程式設計師每天能寫8小時的程式。

你今天寫了這麼多行程式碼真有效率！

編碼不是在掃地，比誰掃的面積大。不能單純用行數來評價開發人員的工作量。評判的標準應該結合模組的複雜度，編碼的缺陷檢出量以及最終交付時可用程式碼的比例（實踐表明，我們報廢了大量的無用程式碼）。

他今天把自己100多個BUG都改了，我們得在組裡表揚下他！

在我看來這樣的領導不跟也罷，這就是讓人相當無語的行為。好的開發者在提交測試前，覺得會對自己的程式碼進行走查和除錯，甚至使用單元測試工具，因此其程式碼的缺陷檢出量很小。這樣的程式設計師，才值得被表揚。而那個一天改了自己100多個BUG的人，作為管理者應該想想，流程哪裡錯了，需要進行改進。

設計我來定，開發你閉嘴！

這樣的例子也不少，這種做法有一種聽起來非常合理的理由——保證專案架構的概念完整性。其解釋為，如果將設計人員從開發人員剝離，那麼就可以將架構的概念完整性統一，因為設計人員的數量比開發人員是數量要少的多，更容易統一認識。而這樣做的專案組，也預設地認為設計組的技術實力要明顯高於開發組。他們往往從開發組中選擇優秀的設計人員到設計組，但也會有走眼的時候。其一，硬手沒有被提拔。這時候多半是硬手對設計不滿，並對團隊管理層產生質疑，並想法設法進行溝通。如果處理的好，可能硬手會被重視，如果溝通無門，那之後，可能會充斥著抱怨和不滿，以及人際關係的惡化。

有些強硬些的可能會選擇拒絕不合理的設計或更為極端的是離職。走眼的另一種情況是，挑的人幹不了設計。這樣往往就是讓他鍛鍊，而不是撤換（彼得原理——每個人都會被晉升到他不適合的崗位）。這就鬱悶到極點了，設計者將會與相應的數名開發人員進行一場曠日持久的暗戰。其中，已經不只是個人的抱怨，甚至會演變成成員集體的士氣低落，並最終促成小組的重組。我認為，有必要將開發人員納入設計活動。應該參考開發人員的意見，其原因有三：其一，開發人員對實現相當熟悉，往往發現設計中的不足；其二，通過授權開發者參與設計，能讓其感受到認同感，提升其參與專案的慾望，和責任心；其三，讓開發參與設計，可以對設計人員進行儲備，在需要時作為備選資源使用。

客戶（領導）說必須完成，我也沒辦法！

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

我是領導，我來排進度！

工作進度的安排不能是領導的單方決策，而應該參考做了解這項工作的人的意見。

系統上線了，專案就算結束了！

只有當可交付成果成功移交，專案進行的相應的收尾工作，專案的經驗教訓文件被總結和歸納，一個專案才算真正意義上的完成。

（二） 參考建議

做好前期準備

前期準備很重要，如果在開始構建之前認真的地進行適當的準備活動，那麼專案會運作的良好。充足的準備防止我們製造一個錯誤的產品。前期工作的好壞，多少會為這個專案的成功和失敗打下基礎。即使進入構建階段，如果我們發現前期工作做的不好，也完全有理由退回去。前期準備工作和核心目標就是降低風險——一個好的專案規劃者能夠儘可能早地將主要的風險清除掉，以使專案的大部分工作能夠儘可平穩地進行。目前，對後期影響最嚴重的風險是糟糕的需求分析和專案規劃，因此準備工作就傾向於集中改進需求分析和專案規劃。

預先行其事，必先利其器 用軟體武裝團隊提高生產效率，例如：版本控制，錯誤跟蹤，資訊釋出，自動釋出，CASE工具，除錯工具，測試工具，文件管理，程式碼生成工具等等。

分析專案型別，在管理和構建之間找尋平衡

商業系統、使命攸關的系統、性命攸關的系統在整個專案階段具備不同的控制粒度。需要根據專案的具體型別來確定管理的嚴謹程度，避免“過度控制”或“控制不足”。

需求必須被凍結

需求必須被凍結，如果需求不能凍結，那麼誰來了都沒有用。再強的團隊也無法完成一個無盡的任務。

變更必須走流程

正確應對變更，變更並不可怕，可怕的是失控的變更。以下建議希望對讀者有所幫助：

在構建期間處理需求變更

核對需求，評估質量：如果需求不夠好，停下來，把它做好再開始。

確保每一個人都知道需求變更的代價：讓客戶知道需求辦更並不像在Excel上進行幾個修改那樣容易，“進度”和“成本”是你最有力的武器。

建立一套變更控制程式：固定的變更控制程式讓你知道在什麼時候處理變更，讓客戶知道你會處理他們的提議。

使用能適應變更的開發方法：迭代與增量。

放棄這個專案：如果以上提議沒有一條奏效，需求變更極其頻繁，那麼，評估你的專案，考慮放棄它吧，繼續下去你只會越陷越深。

注意專案的商業案例：價效比，沒必要滿足超出專案成本的需求。

關於加班

做IT的加班是很正常的，但加班要加的有意義，而且不應該長期加班。必須針對關鍵路徑上的工作進行趕工，而不是做些無法加快整體進度的工作。而且，應當安排調休，而不是支付加班費。其主要原因也是我不贊成加班的原因——疲勞更容易引人缺陷。加班無疑會使人疲勞，每個人都想盡快結束手上的工作後回家休息。在長期疲憊的情況下，人員的工作效率會下降，士氣會低落，非正常離職率增加，最重要的是疲憊的團隊很難保證軟體的質量，缺陷在不知不覺中引人，在後期無疑會為此付出代價。專案的總成本和週期，都會隨著引人缺陷的數量的增加而倍增，而且發現的越晚越嚴重。

做好版本控制和配置管理

版本控制和配置管理是必須有的，即便是再小的專案也不能忽視，必須加以重視，一旦版本混亂，多多少少會對構活動造成影響。所以，平時不要偷懶，管理好每個基線。

授權的好處

授權好處多多，包括：一，減少管理者工作量；二，對人員有意識地進行鍛鍊，培養儲備人才；三，提高人員對專案的參與度，從而提高士氣。

樂觀管理與悲觀管理

樂觀與悲觀完全取決於人的性格，一般來講多數傾向於樂觀，應該清楚這兩種性格在專案中的優勢與劣勢。

我本人傾向於悲觀，可能是性格使然，但悲觀的管理至少不會誤事。樂觀管理的優勢在於，很容易營造氣氛，擅長給客戶或領導描繪一個美好的未來。這種作風，前期很舒服，但後期可能要吃苦了。樂觀管理容易出現的問題是對風險的預計不足，不能預留充足的緩衝時間，沒有準備足夠的預防措施。其表現就是，在進行進度計劃時，總是認為今天的問題今天可以解決，已經修復的BUG將不會再次出現，使用者需求是最後一次變更，等等諸如此類的樂觀想法會使管理者矇蔽雙眼，而沒有做足風險應對，其結果就是不管怎麼加班就是趕不上進度，因為進度計劃被設計為最順利的情形，而不是現實場景。

悲觀管理的好處是，為潛在風險做足了準備。但悲觀管理有一個非常大的缺陷，就是“過度控制”，可以比喻為“疑心病”（小心的都有些病態了）。其表現是為：按照之前的措施，發現遺漏了一個問題，那麼悲觀管理者會在之前措施基礎上增加新的保障措施，然後又發現遺漏了一個問題，之後會繼續追加保障措施。乍看之下沒啥問題，因為是在不斷地進行過程改進，但問題出在保障措施的增長速度過於驚人，稱其為“疑心病”一點也不為過，悲觀管理者容易在很小的地方施加過多的控制，造成人日的浪費，而忽略掉本應該關注的更為重要的問題。不管那種性格的管理，清楚自己的弱點總是好的。

有效的溝通，不要踢皮球

軟體專案因為其本身的複雜度和涉眾眾多，所以更加需要溝通。溝通問題是所有大型專案都共用的問題，在大多數團隊中往往也不認為溝通是個問題。但我還是想請讀者認真對待溝通，比如郵件。郵件可以回覆的慢，但請回復郵件。當我在一個連發出的郵件都沒人回覆的團隊中工作時，除了無法解決問題，讓我感受到的只有無奈以及冷漠。

客戶是我們的朋友

把你的客戶當成朋友，客戶是我們做重要的資源之一。在每個客戶背後往往隱藏著更多潛在的客戶。我們必須清楚，客戶作為非專業人士，其可能並不理解我們的工作，在專案執行階段產生摩擦是難免的。但是，這些都不能成為我們遷怒客戶或故意在工作中放水的藉口。即便是為了專案能成功收尾，我們也必須維護好與客戶的關係。

不要超前設計，不要專案鍍金

超前設計和專案鍍金都是不可取的，因為他是在浪費資源。滿足需求以外的東西，不會對你的專案有任何好處，但是卻可能引人缺陷。

總結經驗教訓

必須對階段進行經驗教訓總結，沒有什麼比這些收穫更有價值。這樣文件就是組織的資產，是以後類似專案的參考和依據，並在持續優化方面發揮更為重要的作用。

不要讓會議和文件拖了團隊的後腿

“當船快要沉的時候，我們需要的是一個發號施令的領袖，而不是開會。”軟體專案的核心問題是降低複雜度，越是複雜的專案就越需要溝通，但別讓開會拖了我們的後腿。沒有必要的會盡量少開或不開，要常開會，開小會，每次會議就幾個相關干係人碰頭溝通下就可以了，沒有必要擴大為全員參與。冗長的討論應該適時的終止，畢竟會議室上只能做出決策，而解決問題還得在會下。所以我認為應該精簡那些冗長的會議，別然開會成為我們的工作。此外，要時刻謹記客戶最終需要的是可以良好執行的軟體產品而不是華麗的文件。所以，文件要恰到好處，寫的再漂亮的文件沒有完備的系統也不過是廢紙一堆，別丟了西瓜撿芝麻，可以正常工作的軟體才是我們的工作重心。

核對表的你的好助手

就像飛機工程師在檢查飛機時使用核對表一樣，軟體專案也可以大量使用核對表。核對表可以幫助檢驗文件的質量，降低缺陷數量，以及改進專案管理。好的核對錶，是你工作中的好助手。

小範圍的受控好過大範圍的失控

要注意控制的粒度，事無鉅細。根據專案規模，人員構成，要採用不同的控制粒度。評估可控範圍，並不是控制越廣越好，控制不了就是失控。 對無暇顧及的地方授權別人管理是個可行的做法。 即便是小範圍是受控，也好過大範圍的失控。一個失控的專案，誰也不知道其會走向何方。