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

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

6月16日消息，據(jù)外電報(bào)道，微軟程序經(jīng)理PhilipSu本周四一篇博客中稱，新一代操作系統(tǒng)WindowsVista之所以一再延遲，主要是因?yàn)閮煞矫嬖颍阂皇窍到y(tǒng)代碼過于復(fù)雜，二是微軟的企業(yè)文化所致。

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

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

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

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

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

Let"sseeif,quantitatively,there"sanytruthtotheperceptionthatthecodevelocity(netlinesshippedperdeveloper-year)ofWindowshasslowed,orisslowrelativetotheindustry.Vistaissaidtohaveover50millionlinesofcode,whereasXPwassaidtohavearound40million.ThereareabouttwothousandsoftwaredevelopersinWindowstoday.Assumingthereare5yearsbetweenwhenXPshippedandwhenVistaships,thosequickonthedrawwithcalculatorswilldiscoverthat,onaverage,thetypicalWindowsdeveloperhasproducedonethousandnewlinesofshippedcodeperyearduringVista.Onlyathousandlinesayear.(Yes,developersdon"tjustwritenewcode,theyalsofixoldcode.Yes,someofthoseWindowsdeveloperswerepartlybusyshipping64-bitXP.Yes,manyofthemalsoworkedonhotfixes.Workwithmehere.)

Lestthoseofyouwhowrote5,000linesofcodelastweekendpassakidneystoneatthethoughtofWindowsdeveloperswritingonlyathousandlinesofcodeayear,realizethattheaveragesoftwaredeveloperintheUSonlyproducesaround(braceyourself)6200linesayear.SoWindowsisinbadshape--butonlybyaconstant,notbyanorderofmagnitude.Andifitmakesyoufeelanybetter,realizethattheaverageUSdeveloperhasfalleninKLOCproductivitysince1999,whentheyproducedabout9000linesayear.SoWindowsisn"taloneinthis.

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

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

1.軟件人員的

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

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

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

這位看官還真讓你說對(duì)了：

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

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

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

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

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

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

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

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

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

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

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

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