軟體公司的績效管理和內部消耗

同步自：http://www.blogjava.net/AndersLin/archive/2006/06/18/53660.html

引子：今天上csdn看一則新聞是關於微軟Vista的，地址：http://news.csdn.net/n/20060616/91704.html。原文載如下：

微軟經理曝Vista延遲內幕 原定日期不實際
　　6月16日訊息，據外電報道，微軟程式經理Philip Su本周四一篇部落格中稱，新一代作業系統Windows Vista之所以一再延遲，主要是因為兩方面原因：一是系統代碼過於複雜，二是微軟的企業文化所致。
　　據Techweb報道，Philip Su已經在Windows部門任職五年，他在部落格中寫道，Vista系統代碼本來就很複雜，而因為企業文化的原因，公司所制定的Vista上市日期根本不切合實際，因此Vista的再三延遲是不可避免的。
　　Su稱，Vista至少有50個獨立的“層”，而他在這五年期間，只弄懂了其中的2層。據悉，Vista有5000萬行代碼。一般情況下，一名Windows開發人員每年可以寫1000行。而微軟目前雖然有9000名開發人員在圍著Vista轉。但可以計算出，要完成5000萬行代碼還是有難度的。
　　按照原計劃，Windows Vista本應於今年11月上市。但微軟今年3月宣布，Vista企業版將於今年11月上市，而個人版要到明年1月才能推出。6月7日，Windows Vista Beta 2已進入公測階段。

以上這則新聞最讓我關心的是：“一般情況下，一名Windows開發人員每年可以寫1000行”
咋一看嚇了一跳，咋微軟的員工工作就這麼悠閑呢。一年寫1000行。覺的有疑問，趕快上google的blogsearch，找到原文一看，發現不是那麼回事，原文blog地址：http://blogs.msdn.com/philipsu/archive/2006/06/14/631438.aspx

Let's see if, quantitatively, there's any truth to the perception that the code velocity (net lines shipped per developer-year) of Windows has slowed, or is slow relative to the industry.  Vista is said to have over 50 million lines of code, whereas XP was said to have around 40 million.  There are about two thousand software developers in Windows today.  Assuming there are 5 years between when XP shipped and when Vista ships, those quick on the draw with calculators will discover that, on average, the typical Windows developer has produced one thousand new lines of shipped code per year during Vista.  Only a thousand lines a year.  (Yes, developers don't just write new code, they also fix old code.  Yes, some of those Windows developers were partly busy shipping 64-bit XP.  Yes, many of them also worked on hotfixes.  Work with me here.)

Lest those of you who wrote 5,000 lines of code last weekend pass a kidney stone at the thought of Windows developers writing only a thousand lines of code a year, realize that the average software developer in the US only produces around (brace yourself) 6200 lines a year.  So Windows is in bad shape -- but only by a constant, not by an order of magnitude.  And if it makes you feel any better, realize that the average US developer has fallen in KLOC productivity since 1999, when they produced about 9000 lines a year.  So Windows isn't alone in this.

才知道人家的blog說的清清楚楚，只是新聞的編輯為了吸引眼球改的。

不過讓我想起軟體公司的內部管理的東東。
1. 軟體人員的績效管理。
      我不知道現在還有多少公司還用程式碼數來算生產力的，我以為採用如此辦法考評的只能說明一點：公司沒有辦法組織起有效績效管理。績效考核應該以：所實現的技術複雜度＋所花費的時間（OT時間一定要算）＋加權調整，3個來評定。
      業務的複雜性往往導致技術實現上複雜，A和B兩個工程師在相同時間內完成不同的項目，A的複雜性高於B的複雜性，那麼A的績效應該高於B。不過，實際的情況往往不是這樣，複雜性越高的項目需要的時間也會越多（當然如果有人能很快完成，說明之前他積累的相當的經驗能快速分析或者是對這個業務本身很熟悉），無論如何完成工作所需的時間是需要做合理的評估的：10天，1個月或者更多，一個需要1個月可以完成的項目用了1.5個月，那麼考核績效就需要降低。
      有看客說了：你這是坐著說話不腰疼。技術複雜度和時間的評估是那麼容易做的，這裡面的人為因素就可以讓整個績效管理全部跨掉。
      這位看官還真讓你說對了：
      技術複雜度確實不好估計，一名優秀的架構師可能覺的是B的複雜度的項目，在一名普通工程師眼裡可能是A。
      時間評估也不好做，老員工憑著對業務和系統的熟悉，以及對公司內部資源的瞭解，可以很快的理解需求（自學或者找有做過類似的同事學習）認為只需要2周的任務，對於一名新員工來說可能需要1個月。
      這樣的情況將使實際的績效管理一團糟。
      我們需要儘可能的減少兩者評估在不同團隊成員間的差異性，而這個手段是用統計方法＋案例法：把所有的做過的任務翻出來重新評估統計。參與統計的成員儘可能覆蓋廣，這樣就可以得到一個相對合理的評估值，對與新的任務，就類似英國的案例法，參照舊的以做過的項目給出的評估值。（當然這個值合理與否在於統計的任務數）此外還有個統計覆蓋時間取捨，軟體技術更新很快，通常採用新的技術架構往往會改進工作（舉例：在使用webwork+spring+hibernate和前webwork+spring+hibernate年代做同樣的時間，花的時間是不一樣的）。對於複雜度來說，用新的技術架構＋公司不斷改進私人的平台是可以在一定程度上降低複雜度的。這是我不用“業務複雜度”而用“技術複雜度”的原因。
      在這個基礎上加上一個加權調整，理論上可以比較好的做績效管理了（實際情況很難講，具體大家都知道怎麼回事）。
      實際工作，由於這樣的成本比較高，對於小企業和項目導向型的企業來說不太實際，或者沒有，或者草草完成。

2. 軟體公司的內部消耗
      因為是團隊合作，每個開發人員的工作需要其它同事協助。這裡的內部消耗就是這個，包括了知識傳遞，工作傳遞和工作委派。對於公司來講，希望努力控制內部消耗就來提高競爭力。不過這種事往往吃力不討好！
      知識傳遞。最傳統的是靠文檔，同樣最靠不住的也是文檔。寫文檔的人費力，看的人也費力。寫文檔人往往假定讀的人對文檔的需求背景有一定瞭解，有意無意的省略一些東西（例如：寫的文檔人由於對需求背景很熟，覺的有些東西司空見慣，就不寫），但對於讀的人來說卻未必。
      工作傳遞。最常見的新來的覺的老代碼都有問題，來一批人就重新寫一次代碼。還有比較常見的是一些任務大處了講沒什麼，細節卻很多很瑣碎（意味著陷阱很多），傳遞的人不知道從何處講，接手的人不知道有陷阱，往往做到後來還是給不停的問。
      工作委派。這個就更容易耗時間了。一件不大的事，請人幫忙，那人手裡不忙還好，如果忙事情的優先順序又不高就不知道什麼時候能做好了，尤其是跨部門的時候。
      XP的開發方法試圖解決這樣的問題，似乎蠻有效！可惜還沒有機會嘗試，如路過的看官有心得體會還請賜教。

      BTW，在對任務做時間評估的時候，一定要考慮這樣的內部消耗，不然。。。。。嘿嘿！