論軟體過程中的效率問題

軟體開發過程中，主要參與者包括開發人員與各個領導，開發人員負責執行流程，而領導負責制定流程。

在實際項目過程中，領導需要項目開發過程中的很多資料，它可以選擇自己去從各地方去收集，費時費力。所以領導就制定流程，要求執行人員自己到某一個地方去填寫它所需要的資料，這樣領導就不必各個地方去收集，提高了自身的效率。在他的心目中，每個程式員只是開啟一個頁面，填寫一個資料，用不了5分鐘，如果自己來做，也許要幾個小時。

當公司越來越大的時候，程式員上面的領導也越來越多，而這些領導對開發過程中關注點也不同，這些領導為了自身的效率，都會要求修改開發流程，從而減輕自身的工作量。

就這樣，開發人員所面對的流程越來越多，其效率也越來越低。舉個例子，在CMM中，為了達到對項目的按時完成，其要求精確到人天，這時要求程式員準確記錄工作時間，來計算程式碼/時間。這對於領導來講很好，我能精確控制項目進度，對於開發人員來講，簡直就是噩夢，你讓領導也試試每天記錄自己的工作時間。這種方法也許是能夠準確控制項目時間，但開發效率是否提高了呢？如果本來2天幹完的活，我說4天做完，我是能確保在第4天做完。

個人認為，CMM已經走偏了，它太強調了開發過程的可控，而忽視了開發過程的效率，所以對於小公司來講，你上CMM就得死。

提高軟體開發過程的效率

在做流程最佳化之前，我們先要分析軟體開發效率的瓶頸在什麼地方，是在管理者還是執行人員？

在分析瓶頸時，要深入到流程當中，看其具體運行情況，不要為一兩個人的效率所影響。比如說開發人員每解決一個bug，其要走一套相關的流程。如果領導需要每個月對這些資料統計，每個月可能要花費2個小時來收集資料，為此他想改變一下流程，讓程式員每解決1個bug，多花費1分鐘填寫一下，這樣他就可以節省2個小時。

如果在每個bug上多花費1分鐘，那麼按照100個程式員，每天解決2個bug計算，一個月所多花費的時間就是1*2*100*20（天）=4000分鐘。

2個小時VS4000分鐘，哪個效率更高一點呢？很多時候，效率就是這樣一點一點浪費的。

從提高軟體開發整體效率來講，以社會分工的理論來講，每個人分工儘可能的細，這樣他才能專註，他才能在這個領域不斷的提高效率。也就是說與其讓每個人花費1分鐘時間，不如一個人花費2個小時。

之所以出現因為一兩個的人利益，而損失了大多數人的利益在於，大多數人每人損失了一點不太在意，而且一兩個人又位高權重，負責制定流程。

提高軟體開發效率的方法：

1、
減少開發人員在流程上所花費的時間，使其精力真正花費在有價值的東西上，去掉一些沒用的東西。在實際項目流程中，開發人員填寫了很多無用的項目，這些項目可能是一開始就沒有用，也可能是開始有用後來沒用。管理員認為，反正你也是填表，多填一項也就是1分鐘的事，可這一分鐘是一個迴圈。

2、
改進開發流程的管理軟體，使各個軟體盡量相通，有些流程該合并的合并，這樣程式員只需要填寫少量的資料，就可以滿足各個領導的要求。實際中，開發人員可能幹這個事情，去一個地方。幹那個事情，去另外一個地方，同樣的資料，在多套系統中流轉。

3、
將程式員一些經常的工作提取出來，由專門人來完成，利用社會分工理論來最佳化效率。如果覺得這麼一點事由一個專門人來做太少的話，還可以讓他去兼職其他的項目。

現在的軟體開發流程，很多都是從管理層面由上至下制定出來的，管理者有其自身的目標：按時、保質、高效的完成。而這3個目標當中，以"按時"最為重要，管理者希望他管理的項目可控，至於效率，它完全可以推到開發人員這裡，畢竟IT業界對於開發效率沒有一個具體的評估方法。他們是以一個管理者的角度，去看待軟體開發流程，自覺不自覺的考慮到自身的利益，很少考慮開發人員自身的效率問題。而由開發人員改作專案管理的人來講，其又會受到CMM和PMP等思想的影響，認為當初影響自身工作效率的那些條條框框是理所應當的，就這樣程式員的利益再一次被忽視，每天重複做一些無價值的東西。

對公司來講，開發效率是最重要的，但有趣的是卻很少有人關注開發人員的效率問題，大多數人把開發看成一個黑盒，認為是一個不可控的東西，效率低下是很正常的東西。技術本身的複雜程度也許是我們所無法改變的，但為開發人員減負，使其專註於開發本身，從而提高效率，是我們可以做到的。

以程式員的眼光，重新審視開發流程，傾聽程式員的聲音。