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