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

申請(qǐng)免費(fèi)試用、咨詢(xún)電話(huà)：400-8352-114

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

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

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

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

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

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

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

咋一看嚇了一跳，咋微軟的員工工作就這么悠閑呢。一年寫(xiě)1000行。覺(jué)的有疑問(wèn)，趕快上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說(shuō)的清清楚楚，只是新聞的編輯為了吸引眼球改的。

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

1. 軟件人員的績(jī)效管理

我不知道現(xiàn)在還有多少公司還用代碼行數(shù)來(lái)算生產(chǎn)力的，我以為采用如此辦法考評(píng)的只能說(shuō)明一點(diǎn)：公司沒(méi)有辦法組織起有效的績(jī)效管理。績(jī)效考核應(yīng)該以：所實(shí)現(xiàn)的技術(shù)復(fù)雜度＋所花費(fèi)的時(shí)間（OT時(shí)間一定要算）＋加權(quán)調(diào)整，3個(gè)來(lái)評(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的績(jī)效應(yīng)該高于B。不過(guò)，實(shí)際的情況往往不是這樣，復(fù)雜性越高的項(xiàng)目需要的時(shí)間也會(huì)越多（當(dāng)然如果有人能很快完成，說(shuō)明之前他積累的相當(dāng)?shù)慕?jīng)驗(yàn)?zāi)芸焖俜治龌蛘呤菍?duì)這個(gè)業(yè)務(wù)本身很熟悉），無(wú)論如何完成工作所需的時(shí)間是需要做合理的評(píng)估的：10天，1個(gè)月或者更多，一個(gè)需要1個(gè)月可以完成的項(xiàng)目用了1.5個(gè)月，那么考核績(jī)效就需要降低。

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

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

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

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

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

我們需要盡可能的減少兩者評(píng)估在不同團(tuán)隊(duì)成員間的差異性，而這個(gè)手段是用統(tǒng)計(jì)方法＋案例法：把所有的做過(guò)的任務(wù)翻出來(lái)重新評(píng)估統(tǒng)計(jì)。參與統(tǒng)計(jì)的成員盡可能覆蓋廣，這樣就可以得到一個(gè)相對(duì)合理的評(píng)估值，對(duì)與新的任務(wù)，就類(lèi)似英國(guó)的案例法，參照舊的以做過(guò)的項(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ù)雜度來(lái)說(shuō)，用新的技術(shù)框架＋公司不斷改進(jìn)私有的平臺(tái)是可以在一定程度上降低復(fù)雜度的。這是我不用“業(yè)務(wù)復(fù)雜度”而用“技術(shù)復(fù)雜度”的原因。

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

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

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

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

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

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

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

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