項目管理（）績效考核 - freeflying－IT工程師數位筆記本

文章出處

其實我是有點慚愧，又浪費時間寫水文，所以扯上項目管理的大旗，稍稍心安了一點。不知道能不能上首頁，候選吧，老規矩，5贊上首頁。

《創業泡沫的“軍功章”，高薪低能的程序員分一半》里提到兩個觀點，我都是很贊成的：1、編程日益簡化；2、程序員可以更多的把時間花在編碼和思考架構上。我覺得這是個好事情，而且也是社會發展的必然。任何一個行業的蓬勃發展，都需要高度的專業化分工，以及隨之而來的大量的熟練產業工人。我感覺過去的幾百年工業史可以簡化為下面這個模型：

少數天才發明了機器，賺了大錢；
更多的天才涌入機器制造行業，也開始賺錢，
機器越來越多，帶動了機器的使用、維護、再制造等一系列行業，整個產業開始繁榮；
產業的繁榮需要更多的人手，不斷的吸引人才的加入，直到人才不夠了。
這時候，聰明的天才們開始了兩條道路的探索：

- 用機器制造機器，減少的人工的使用（現在很多行業都已經是大量的使用機器人了，你看諾大的車間就沒幾個人，全部是自動化）
- 將機器的制造、使用、維護……變得更加簡單，哪怕是個蠢才培訓一下都能干活（流水線作業，想想卓別林的《摩登時代》吧）

大家對比一下吧，軟件行業今天發展到哪一個階段了？人類社會的發展，是一個永遠加速的過程。我很好奇，在我有生之年，能不能看到“程序員就像狗，滿街都在走”的奇幻世界。

程序員這個行業，是有門檻，但門檻不是那么高不可攀的。而且隨著技術的發展，這個門檻會越來越低。

就像很久很久以前，拜師傅做徒弟學門手藝，入門都得三年；你看現在，把一個農民培訓成一個流水線上的產業工人需要多久？我大嫂勉強初中文化，一直帶孩子賣票之類的直到40歲，進廠做工人，培訓了兩個星期，現在還是個小頭目。當然，她的工作沒什么技術含量。但就算是開車床學挖機，技校培訓，連實習上崗，也就最多兩年而已。軟件行業有什么不一樣的？別扯什么算法編譯二進制啦，開車床的還需要研究電磁場原理？

所以，這對準備自學成才的同學來說，是個好消息；當然，對已經身處其中的同學來說，那就相當的不妙了！

我這種言論遭到了圍攻群毆，其中一個同學留言，“你這樣就只能招到流水線工人！”

“咦？！”我拍案叫絕，說得太貼切了！對于絕大多數程序員，你不就是一個流水線上的工人？軟件工程師？產品經理還是經理呢！很傷自尊，但我覺得這就是真相，雖然很殘酷。

Sorry，跑題了。我是個奸商，所以我著重談一下，作為用人單位，或者項目管理者，如何利用這種形勢吧。

首先，不管泡沫破不破滅，程序員的工資升上去了就降不下了（經濟學理論，比較復雜，找不到鏈接了。不信的話你可以試一下）。

所以，要想降低成本的話，裁員招新人吧！

那么，問題來了：

1、裁員之后，更少的人手，如何提高效率。

2、如何盡快的讓新人上崗完成工作任務。

第2點，靠架構靠入職培訓，本文暫不討論，我們著重討論第1點。我認為，最核心的方法就是對程序員的工作進行有效考核！

在工業時代，工資支付方式的革命就是“計件”——按工作成果而不是工作時間來支付工資，這無疑是最公平最符合人性最具有激勵作用，所以也就是最好的制度。這已經被無數的人類實踐所證明，90后沒經歷過改革開放之初農村家庭聯產承包責任制，后來的國企內部承包改革等一系列重大事件，我們親身經歷，那種改變，真的只能用一個詞來形容，“天翻地覆”！地還是那塊地，人還是那些人，以前一個個餓得皮包骨頭，現在家家戶戶吃不完的糧食，為什么？就一個簡單的制度改變而已。

但問題在于，程序員的工作很難計量（其實所有行業都一樣，好計量計件的，早就按計件支付了，剩下按工作時間支付的，都是難以計件的）。靠代碼量來計算？懂行的就知道這明顯不科學。有些單位靠功能來劃分，這稍微科學點，但還是失之于粗糙。某加班的程序員不滿了，“艸，他憑什么就下班了？他的功能明顯要簡單得多，就看見他在玩游戲！”下班的程序員不爽了，“是我有本事，好吧？你自己磨磨蹭蹭的搞不出來……”

所以問題的關鍵就轉變成如何公平的衡量工作量。我覺得，越精細化，越有可能實現公平。

兩個任務，核算都是30個人天的工作量，直接分給甲和乙，甲和乙會不會覺得公平，服不服？里面可能出情況的地方太多了，他硬著頭皮接下這個任務，也是因為他也不知道這任務的工作量是多少！大家都只有拼人品了。但總是這樣做也不是個事，尤其是在任務重工期緊的時候，矛盾很容易就爆發出來，“草，我忍你好久了……”然后陳谷子爛芝麻的事，就扯出來說，一堆爛帳誰他媽說得清楚？當然，說出來的還算好的，按程序員的常規做法，“say Goodbye，這個坑你自己找人填吧！大爺我不伺候了。”

所以我自己的項目，我就開始嘗試一種“任務切分”管理的模式，30個人天確實不好估計，但30分鐘的任務應該都沒什么爭議吧？我事先就把任務一個一個的切出來，我一般要切到一個任務，30分鐘以內完成為止。這樣做的好處有兩個：

1、我自己心里有數。在切這個任務的過程中，我的思路基本上就出來了。可能以前以為是半天就能完成的工作，進行切分之后，就發現漏了一些，自己就要適當的調整開發進度。

2、對開發人員有指導作用。我用的都不是高手大牛，但他們新人也可以順著這個路子一步一步的做下去，至少其中一些簡單的部分可以分給他，復雜的留給我自己做。

3、開發人員偷不了懶，但比較服氣。不是每一個任務時間都估得那么準，如果估多了，開發人員偷著樂就是了；估少了，他完全可以提出來。因為任務已經被切得很細很小了，他一提出來什么什么情況，你馬上就能反應過來，任務量就相應的調整就是了。

最開始我用excel，后來感覺這個法子還管用，就順手開發了任務管理系統，越用越覺得不錯。所以我現在集中精力在完善這個系統，希望能推廣開來，產生一定的社會價值。

當然，工具不是萬能的，還是得落實到使用他的人身上。

這個工具不懂代碼的項目經理估計是完全沒法用了。

另外，用的人還是要有基本的“包容”精神。比如20分鐘的任務，開發人員18分鐘做完了，項目經理心里就像吃了顆蒼蠅一樣難受；后者開發人員花了22分鐘做完，就要跳起來打人……那這個也沒辦法了。

這里就不再給任務管理打廣告了，我們需要著重強調的，是“將任務進行切分，實現精細化管理”的理念。這是方向性的問題，只要方向對了，碰到的一些枝節問題，都可以再想辦法克服；方向錯了，那怎么努力都是藥丸。其實回過頭來看，我的這個理念是建立在一個假設/前提上的：程序員的工作是同質可量化的。這似乎是政治不正確的，現在最熱血的說法是，“員工是我們最寶貴的資源”，，保護員工的“積極性”，大力提倡激發員工的“創造性”……

但作為一個在500強大企業打過工，在5個員工的小作坊當過土老板的程序員，只能呵呵，最有創造性的產品怎么都不是出自這些大公司？怎么經常都聽到他們要把“最寶貴的資源”都給裁掉呢？

確定績效

評論里的同學說得很對，忘了說績效了。

首先，“績效”不如“計件”。我覺得現在所有的績效，基本上都是扯淡。在無法可量化的情況下，其唯一的作用就是無事生非，破壞安定團結的大好局面。你說他這個月績效打80分，憑什么？他加了班？加班應該給加班費啊代碼出了bug？誰的代碼沒bug？都沒bug要測試干什么？可能最大的原因是他和你頂了嘴？你看他不順眼吧？計件就沒這些問題，就像業務員拿提成，那是清清楚楚，你敢少給一分錢？他敢找你多要一份錢？

當然，目前的情況下，讓程序員做“計件”也太不現實了。當初我們公司開發人員入職，我給他們講的都是計件，但實際上還是按月發工資。但我有了任務管理系統的記錄和統計，每一周每一個月我把數據拉出來，明明白白的告訴他，為什么這個月多給，上個月少給，他基本上也認同。這里必須要說一下，工作量（時間）不是他實際完成工作的時間，而是我認為一個普通程序員（其實就是我啦）完成該工作的時間。比如我給這個任務20分鐘，是指我能在20分鐘完成，你哪怕花一天才搞出來，那是你的事！不然，你每天的工作量都是8小時，有什么意思？然后根據工作量，就可以統計出來你的績效了。當然，任務是有難度劃分的，還可以包括很多其他因素，比如：驗收不合格的比率、按時完成任務的比率等等。

劃分任務的工作量

還有同學提到了“劃分任務的工作量”問題，是不是項目經理一天到晚就劃分任務去了，不用干別的？

我把我的經驗貼出來吧！開始的時候，新人入門，沒辦法，那就是我一個任務一個任務的分，確實有點耗時間，但一個任務要做20分鐘，分配一下不過3-5分鐘吧？況且新人20分鐘根本做不完，所以我還是有大量時間做其他事的。

后來新人成長了，變成老人了，這時候，逐步逐步的讓他自己切分任務，比如一個功能點，我把文檔給他，讓他自己做，做之前，先把任務切分好！他肯定抵觸，“我做完就行了，切任務好煩的！”他切不出來——因為他還不能像我一樣胸有成竹。我拗不過他，就隨他的便，但只有一個要求，你先把你要花多少時間告訴我。他說行，比如一個功能點，他信心滿滿的說，“120分鐘夠了”。結果夠個屁！哈哈，他兩天都搞不出來，想加時間，我不干了呀，你加時間的依據在哪里？任務在做的過程中變復雜了呀，東一榔頭西一棒，他怎么說得清楚？還有其他一些原因（比如代碼review、commit等），以后再細講，并且隨著他技術的逐步提高，最后他也養成了做之前，先切任務的習慣。其實切任務就是一個理思路的過程，哪怕最開始你的思路有問題，因為任務已經進行了足夠細致的切分，出問題的部分也很好標示很好說明，我們再進行調整也很容易。

最后，我想知道的是，“