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