淺析哪些軟件開發項目不能做
最近半年撲在一個項目上難以自拔，簡直就是一個泥潭，無數同行來到這里、陷在這里，誰也不知道到底完成項目還需要多少人來填坑。項目管理混亂，高層領導離職，已無進度管理可言（自打來了項目組，就沒見“里程碑”為何物）。干到現在，我所感覺到的僅僅剩下失望、苦悶與挫敗感。寫到這里有點發牢騷的味道，其實我想說的是項目的成敗與管理有莫大的關系，作為一個管理學出身（我現在是開發），我也想通過我的經歷說說我對項目管理的認識。
首先，說說我們項目組自身的不足。
1 沒有“規范”。進入項目我沒有拿到任何“規范”性文檔，所以開發中數據表、變量、工作流等命名極其混亂。
2 沒有數據字典。開發對數據庫的認識僅能通過查詢來了解，對于一個企業級項目來說，表實在是太多了，我們不了解某些數據，現有的表是否保存。
3 沒有核心人物。對于一個使用獨立框架開發的系統，沒有一個對其十分了解的技術總監，所有人都是在按照之前的版本改造，嘗試性地引入新功能，經常是一錯錯一片，需要不斷地進行整體的返工，非常耗時。
4 沒有責任到人。項目一貫的拆東墻補西墻的做法，導致某個功能點被分配了N手，所有人都要看前人的代碼并熟悉業務，但項目組有不給你足夠的時間交接，這樣的結果就是大量代碼重復，BUG數量飆升，以及出問題沒人認領，互相推諉，最后接手的人要為前人買單。
5 缺乏溝通。在如此一個需求不明確的情況下，開發就應該坐在需求部門邊上不斷掌握需求，但是多數人沒有，導致了我們都變更單都快追上《C#高級編程》了，而且內部人員溝通不足，缺乏協作。
6 不做代碼審查。項目組沒有質管，破壞現有代碼分層，插入不寫驗證的情況很多，誰來為他們的BUG買單？
7 資源分配不合理，獎懲不均。甲方人員閑的打游戲，乙方人員加班到半夜。這其實也沒啥，但是我要說的是為啥表揚的總是甲方，乙方加班就是應該的對嗎。開發兼職運維，每天都要浪費大量時間來解答用戶的各種問題，這也沒啥，但為啥不讓用戶去找培訓人員而來找我們，為啥解決問題消耗的人日不列入計劃。
其次，說說我們的合作廠商的問題。
1 顧問能力不足。多數顧問不懂技術，其設計的系統完全違背大型分布式系統的開發原則。一個接口對應N個功能點，為了復用代碼他們絞盡腦汁呀，可你可知道你提高了系統的耦合度，你對維護提高的多少成本。自己接口從不寫驗證，你為啥那么相信你的外圍系統，你自己的庫你都不看好門嗎。完全不知道需求文檔該怎么寫，你是顧問，你要將用戶的需求轉換為需求文檔，而不是指導用戶如果寫個EXCEL來應付差事，你的用戶不知道開發人員需要什么，也不知道該如何表示自己的需求，再說哪有讓用戶寫需求文檔的。完全不能估算工作量，單方地認為改改字段就像改EXCEL文檔那樣簡單，壓外圍進度壓的好死。此外，顧問的業務水平也不高（經常遭投訴），定個需求要開幾天會，等真正做的時候發現業務又走不通了，明顯在設計時，沒有根據實際業務對設計進行反復迭代。
2 糟糕的文檔。先不說文檔的質量，首先數量就不全，經常是先開發后補文檔。再說質量，完全是外行人寫的東西，不過也可以理解，畢竟大部分文檔是用戶寫的，我就想問，讓用戶出設計那還要你顧問干啥，難到就是發發郵件當監工。我覺得這已經不是能力問題了而是職業道德和責任心的問題。
3 推卸責任。業務上本該自己系統實現的功能，因為不好做就下發給外圍系統，你個幾千萬的系統做不了，你要個幾百萬的實現，這理由充分嗎。每個系統都應該承擔起自己的責任，占有自己的位置，不要因為客戶不懂技術，就偷懶。雖然作為顧問，維護己方開發人員的利益是合理的，但也你不能夠以犧牲系統的可用性為代價。
4 換人不做交接。很難相信會發生這樣的事情。不過我確實遇到了，換了人了，之前的設計全報廢，然后做新的。
5 環境混亂。完全不理解為啥開發需要搭建如此多個環境。用戶不停地從1個環境上測完去另外一個。你同類環境1個就夠了，為啥整一堆沒有針對性的測試環境，最要命的是還不能保證發布的版本同步。而且環境數據臟了就整新的，那得啥時是個頭。
6 不接受意見。外部廠商顧問不愛接受外圍系統給出的意見，比如接口復用問題。完全是把接口做成一個并集，來最大限度進行復用。
7 頻繁變更。變更過于頻繁，這也是項目組遇到最大的問題。不管是否收到甲方的確認函，變更都會到來，我報廢掉的代碼比現在可用的高出數倍。你完全不知道你的任務啥時候完了，到開發完成，測試結束，用戶確認并試點上線之后，本該認為是沒事了，但是到來的不是BUG而是變更。看過《C#高級編程》都知道那書有多厚，如果把我們的辦更文檔都打印出來，頁數也差不多了。
說了這么多，很多都是自己的牢騷與不滿，不過我真正想說的是軟件工程的重要性。是什么造就了軟件泥潭？原因的多方面的，但是好的項目管理能夠幫助我們規避風險降低開發成本，并提高代碼質量。比如，與用和其他參與者（包括合作廠商）密切溝通，對需求反復迭代，規范技術文檔，好的版本控制，統一編碼風格，進行代碼走查，問題責任到人，采用合適的開發模型，正確評估工作量，制定合理的進度管理和激勵機制，這些都有助于對一個項目的跟進。
感謝讀者能夠耐心地讀完我的這篇”牢騷“，作為一名普通的開發人員，我不想指責誰的過失，因為畢竟我沒有坐到那個崗位上，沒有資格指責別人的工作。我覺得，一個項目的成敗，雖然不是某個人能左右的，但是只有各個崗位的人各司其職，全力配合才能夠保證系統的順利上線。我想對剛入行的程序員們說的是，請對你們的代碼負責，用戶不提的不代表你就不用做了，沒測出BUG不代表就沒BUG，請在提交前做好代碼走查，并不要推卸你的責任，是人就會犯錯，你要做的就是承認錯誤并及時解決；對顧問說的是請對你們的客戶和你的設計負責，你要知道你出具的文檔是我們開發系統的重要依據，我們是如此的信任著你，請不要讓我們失望。
最后送上我比較喜歡的一句話：軟件開發如同在水面行走一樣簡單，只需需求已確認，水面已結冰。
原文鏈接：http://www.cnblogs.com/MeteorSeed/archive/2011/07/12/2104069.html
【編輯推薦】
