軟件公司的績效管理與內(nèi)部消耗

申請免費試用、咨詢電話：400-8352-114

引子：今天上csdn看一則新聞是關(guān)于微軟Vista的。原文載如下：

微軟經(jīng)理曝Vista延遲內(nèi)幕 原定日期不實際

6月16日消息，據(jù)外電報道，微軟程序經(jīng)理Philip Su本周四一篇博客中稱，新一代操作系統(tǒng)Windows Vista之所以一再延遲，主要是因為兩方面原因：一是系統(tǒng)代碼過于復(fù)雜，二是微軟的企業(yè)文化所致。

據(jù)Techweb報道，Philip Su已經(jīng)在Windows部門任職五年，他在博客中寫道，Vista系統(tǒng)代碼本來就很復(fù)雜，而因為企業(yè)文化的原因，公司所制定的Vista上市日期根本不切合實際，因此Vista的再三延遲是不可避免的。

Su稱，Vista至少有50個獨立的“層”，而他在這五年期間，只弄懂了其中的2層。據(jù)悉，Vista有5000萬行代碼。一般情況下，一名Windows開發(fā)人員每年可以寫1000行。而微軟目前雖然有9000名開發(fā)人員在圍著Vista轉(zhuǎn)。但可以計算出，要完成5000萬行代碼還是有難度的。

按照原計劃，Windows Vista本應(yīng)于今年11月上市。但微軟今年3月宣布，Vista企業(yè)版將于今年11月上市，而個人版要到明年1月才能推出。6月7日，Windows Vista Beta 2已進(jìn)入公測階段。

以上這則新聞最讓我關(guān)心的是：“一般情況下，一名Windows開發(fā)人員每年可以寫1000行”

咋一看嚇了一跳，咋微軟的員工工作就這么悠閑呢。一年寫1000行。覺的有疑問，趕快上google的blogsearch，找到原文一看，發(fā)現(xiàn)不是那么回事

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說的清清楚楚，只是新聞的編輯為了吸引眼球改的。

不過讓我想起軟件公司的內(nèi)部管理的東東。

1. 軟件人員的績效管理

我不知道現(xiàn)在還有多少公司還用代碼行數(shù)來算生產(chǎn)力的，我以為采用如此辦法考評的只能說明一點：公司沒有辦法組織起有效的績效管理?？冃Э己藨?yīng)該以：所實現(xiàn)的技術(shù)復(fù)雜度＋所花費的時間（OT時間一定要算）＋加權(quán)調(diào)整，3個來評定。

業(yè)務(wù)的復(fù)雜性往往導(dǎo)致技術(shù)實現(xiàn)上復(fù)雜，A和B兩個工程師在相同時間內(nèi)完成不同的項目，A的復(fù)雜性高于B的復(fù)雜性，那么A的績效應(yīng)該高于B。不過，實際的情況往往不是這樣，復(fù)雜性越高的項目需要的時間也會越多（當(dāng)然如果有人能很快完成，說明之前他積累的相當(dāng)?shù)慕?jīng)驗?zāi)芸焖俜治龌蛘呤菍@個業(yè)務(wù)本身很熟悉），無論如何完成工作所需的時間是需要做合理的評估的：10天，1個月或者更多，一個需要1個月可以完成的項目用了1.5個月，那么考核績效就需要降低。

有看客說了：你這是坐著說話不腰疼。技術(shù)復(fù)雜度和時間的評估是那么容易做的，這里面的人為因素就可以讓整個績效管理全部跨掉。

這位看官還真讓你說對了：

技術(shù)復(fù)雜度確實不好估計，一名優(yōu)秀的架構(gòu)師可能覺的是B的復(fù)雜度的項目，在一名普通工程師眼里可能是A。

時間評估也不好做，老員工憑著對業(yè)務(wù)和系統(tǒng)的熟悉，以及對公司內(nèi)部資源的了解，可以很快的理解需求（自學(xué)或者找有做過類似的同事學(xué)習(xí)）認(rèn)為只需要2周的任務(wù)，對于一名新員工來說可能需要1個月。

這樣的情況將使實際的績效管理一團(tuán)糟。

我們需要盡可能的減少兩者評估在不同團(tuán)隊成員間的差異性，而這個手段是用統(tǒng)計方法＋案例法：把所有的做過的任務(wù)翻出來重新評估統(tǒng)計。參與統(tǒng)計的成員盡可能覆蓋廣，這樣就可以得到一個相對合理的評估值，對與新的任務(wù)，就類似英國的案例法，參照舊的以做過的項目給出的評估值。（當(dāng)然這個值合理與否在于統(tǒng)計的任務(wù)數(shù)）此外還有個統(tǒng)計覆蓋時間取舍，軟件技術(shù)更新很快，通常采用新的技術(shù)框架往往會改進(jìn)工作（舉例：在使用webwork+spring+hibernate和前webwork+spring+hibernate年代做同樣的時間，花的時間是不一樣的）。對于復(fù)雜度來說，用新的技術(shù)框架＋公司不斷改進(jìn)私有的平臺是可以在一定程度上降低復(fù)雜度的。這是我不用“業(yè)務(wù)復(fù)雜度”而用“技術(shù)復(fù)雜度”的原因。

在這個基礎(chǔ)上加上一個加權(quán)調(diào)整，理論上可以比較好的做績效管理了（實際情況很難講，具體大家都知道怎么回事）。

實際工作，由于這樣的成本比較高，對于小企業(yè)和項目導(dǎo)向型的企業(yè)來說不太實際，或者沒有，或者草草完成。

2. 軟件公司的內(nèi)部消耗

因為是團(tuán)隊合作，每個開發(fā)人員的工作需要其它同事協(xié)助。這里的內(nèi)部消耗就是這個，包括了知識傳遞，工作傳遞和工作委派。對于公司來講，希望努力控制內(nèi)部消耗就來提高競爭力。不過這種事往往吃力不討好！

知識傳遞。最傳統(tǒng)的是靠文檔，同樣最靠不住的也是文檔。寫文檔的人費力，看的人也費力。寫文檔人往往假定讀的人對文檔的需求背景有一定了解，有意無意的省略一些東西（例如：寫的文檔人由于對需求背景很熟，覺的有些東西司空見慣，就不寫），但對于讀的人來說卻未必。

工作傳遞。最常見的新來的覺的老代碼都有問題，來一批人就重新寫一次代碼。還有比較常見的是一些任務(wù)大處了講沒什么，細(xì)節(jié)卻很多很瑣碎（意味著陷阱很多），傳遞的人不知道從何處講，接手的人不知道有陷阱，往往做到后來還是給不停的問。

工作委派。這個就更容易耗時間了。一件不大的事，請人幫忙，那人手里不忙還好，如果忙事情的優(yōu)先級又不高就不知道什么時候能做好了，尤其是跨部門的時候。

XP的開發(fā)方法試圖解決這樣的問題，似乎蠻有效！可惜還沒有機(jī)會嘗試，如路過的看官有心得體會還請賜教。（ITpub）