我們都是軟件行業(yè)是世界所有的行業(yè)中，失敗率高的。進度沒有辦法度量的，通常會拖，一拖再拖，而且人員都撲上去了，可是還是慢。
為什么？
多少年，多少人，更有很多的專業(yè)公司都在分析這里面的原因。為什么我們的人員都在加班了，沒有人偷懶，都很努力，效率卻上不去？
據(jù)我分析和思考，認為可以從下面兩個角度看這個問題：業(yè)務和技術。究其原因的話，有下面幾個常見的原因：
業(yè)務混亂。業(yè)務是軟件的基礎，軟件是為業(yè)務服務的，這尤其在應用軟件開發(fā)中是常見的。可是很多時候我們太急于出界面了，忽略了業(yè)務的分析和梳理。往往有個需求，要求盡快開始開發(fā)工作，盡快的完成功能，盡快的見到界面，可以操作，可以進行測試。其實，這時候的業(yè)務流程往往由于沒有梳理清楚，存在很多的漏洞，看起來整體是沒有問題的，是流暢的�？墒牵锩娴募毠�(jié)，摳一下的話，會發(fā)現(xiàn)僅是絆子，到處都是陷阱。這樣的業(yè)務作出的設計，寫出來的代碼，后面很有可能會需要推倒重來。這時候開發(fā)人員的開發(fā)體驗很不好，情緒受到很大的影響，效率自然也搞不到哪里去？反而，由于屢次的推到，很有可能會降下來。
技術基本功不足。算是業(yè)務分析清楚了，也梳理好了，也畫了很多的圖，表述也達到了統(tǒng)一的程度。還是有點慢呢？還是沒有達到預期的速率呢？那是業(yè)務分析人員完成了他們工作，架構師設計了軟件架構，該到程序員開始編碼了。可是，每個程序員的水平是不一致的，有的時候會在一些技術點遇到問題，導致了開發(fā)時間超出預期范圍�；竟Πǎ盒〉椒椒ǖ脑O計，參數(shù)的設計，算法的應用，大到類的設計，設計模式的應用，對架構師給出的軟件架構的理解，都存在各方面的問題。
對于第一個原因，業(yè)務的原因。我認為需要從業(yè)務的角度解決，需要在分析業(yè)務的時候，深入的思考，深入到業(yè)務的細節(jié)部分。對整個流程中的細節(jié)好有梳理，每一步分析梳理都要有結果，文字和圖例。不要草率的開工，不要只是分析一點點可以了�？梢詤⒖汲绦虻臉I(yè)務流程，分析適合自己的業(yè)務流程。
還有是需要領導在這個問題上有正確的認識，不要基于要求開工，技術人員這時候可以做一些技術的積累和基礎工作。例如公共類庫的整理和編寫，架構師可以進行系統(tǒng)的架構，是否要分布式，是否需要物理分層，是否有可以用的類庫。還有一些cross-cutting的關注點，這時候都可以進行開發(fā)和設計，進行技術的探討也是不錯的。對于后期的開發(fā)也是很有幫助的。
對于第二個原因，需要企業(yè)和開發(fā)人員兩者都要有深入的認識。
首先，企業(yè)方面要有公司的類庫，有自己的積累。對于一些公共的類庫，一些非功能的模塊，例如：日志、異常處理、數(shù)據(jù)合法性驗證、用戶驗證、數(shù)據(jù)訪問、緩存等等。
其次，公司要有統(tǒng)一的開發(fā)標準，開發(fā)規(guī)范，這樣的話，大家可以互相幫忙，例如在一個人較慢的情況下，有人可以幫助他編寫一部分的功能，加快整體的速度。因為大家的標準的一樣的，所以接手起來也不會太困難，否則接手很困難的話，對整體進度沒有幫助了。
再次，對于開發(fā)人員需要有培訓，培訓每個人的基本功。尤其是關注那些新人，提升大家的基本功。使得大家在進行模塊設計和開發(fā)的時候不至于牽絆太多，可以順利進行。而且做出來的東西，從質(zhì)量角度來講也可以更高，減少返工的幾率。這方面園子里面也有人提出了很多不錯的建議面向?qū)ο笏枷氲念^腦風暴（一） 面向?qū)ο笏枷氲念^腦風暴（二）—— 詳解繼承與組合的優(yōu)缺點 面向?qū)ο笏枷氲念^腦風暴(三)-使用接口進行解耦 等。其實是提高我們的面向?qū)ο竽芰Γ驗槲覀兇蠖嗍褂玫氖敲嫦驅(qū)ο蟮木幊陶Z言，但是開發(fā)的時候我們除了寫了類，什么都沒有了。這方面可以用頭腦風暴的方式，花一個下午或者是，大家一起針對一個問題進行分析、設計、編寫，讓新人參與進來，可以學習成熟的代碼編寫方式和技術，可以統(tǒng)一大家的認識高度。雖然不可能通過幾次的培訓和做幾個小題有實質(zhì)性的提高，但是可以鍛煉思考能力，終的提高還是要靠個人在實戰(zhàn)的開發(fā)中總結和應用，還有是多花工夫思考和聯(lián)系。師傅領進門，修行靠個人。<!--end: searchItemTitle -->
后，技術上面要有人來把控。至少有一個人是具有豐富經(jīng)驗的，可以把握整體的方向，整體的風格，可以對新人進行培訓。而且公司也可以充分授權這個人，充分這個人，也可以較為放心的進行開發(fā)管理。
個人觀點，難免偏頗。歡迎大家一起討論。
