IT工程師數位筆記本

不滿意，重寫了：項目管理（一）任務分配

+++++++++++++

“凡事預則立不預則廢”，所以還是決定花兩天時間，專門完成這個系列博客。關注我博客的同學都知道我開發了一個任務管理系統，這本來只是我隨手做的一個項目管理小工具，但后來用得順手，在上面花的時間也越來越多，所以隱隱有點覺得，還真可以把這事當成一個小事業來做。所以也借這個博客系列，整理一下我的思路，和大家一起分享我關于項目管理的一些經驗和想法。都是我自己揣摩的，不一定靠譜，所以希望園子里的童鞋們大膽質疑，使勁拍磚！

鞭子

還是很多年前，記得有一次，我和黎叔一起去他的工地。他的一個侄兒在工地上幫他看現場，見黎叔來了，就要賣力一些，戴著安全帽夾著一個小包，在工地上走來走去，還不是吆喝兩聲：“用心點！”，“你這里搞快點！”，“這里這里，來個人……”黎叔看了一會兒，走到他跟前，對他說，“你還差個東西啊！”他很迷茫，就去摸他的安全帽。黎叔笑瞇瞇的接著說，“你還差根鞭子在手里！誰做得慢就給他一鞭子，是吧？”我在旁邊想笑不敢笑，差點憋成內傷。

但這些年來，我自己開過公司，也待過很多家公司，這個場景卻讓我記得越來越深刻。我經常不由得想，管理者手里究竟有沒有拿著“鞭子”？該不該拿著“鞭子”呢？

拿著鞭子，兇神惡煞，“誰做得慢就給誰一鞭子”的監工形象，來源于各種影視作品，講的肯定是古代的事了。但時至今日，有形的鞭子早就沒了，但無形的呢？各種KPI考核、扣獎金、裁員……沒有這根鞭子，員工還能好好干活么？估計很難，我們國家改革以前的“大鍋飯”，甚至我待過的一些赫赫有名的外企，“大公司病”里最重要的一點，被管理者偷奸耍滑混日子（或許都包括我自己，呵呵）的越來越多，一個重要的原因就是管理者手里沒權，沒有“鞭子”。

胡蘿卜

但“鞭子”慢慢的退出歷史舞臺，除了文明進步、日益嚴格的勞動法律法規以外，我覺得最重要的原因，還是管理者發現：“胡蘿卜”比“鞭子”更管用。

歷史的發展似乎也印證這一點。按主流的說法，最初，我們實行的是殘酷的奴隸制，監工手里拿著鞭子使勁抽；后來，封建社會，地主們就聰明了，多少地收多少租子，農民多勞多得，這就把農民的積極性給刺激起來了。其實，仔細想想，還真是這個道理。第一、“威逼”是有成本的，而且這個成本不低，至少監工要吃飯吧？第二、發自內心的驅動力是無比強大的，被人推著走和自己撒開腳丫子往前跑，完全是兩個概念。這個，對比一下改革開放前后“包產到戶”的效果就一目了然了。

還想到了一個例子，以前我們都說金字塔是奴隸們修的，后來西方有考古學家就說了，“不對，奴隸做不了這么精致的活。應該是自由工匠做的”。還有很多考古證據，我是外行，但想想這個推論，其實是很有道理的。

誤區

綜上，很多管理者就把“威逼利誘”當成了法寶，奉行“賞罰分明”；俗一點，“打個巴掌，給個棗吃”。但這樣有用么？我覺得，有時候有用，有時候沒用。

先說說沒用的時候。首先，如果我是被管理者，就會很抵觸這種做法。憑什么打我一巴掌？稀罕你這顆棗子呢？把爺當傻子耍？去你媽的！不要把別人都當傻子似的，利益面前誰都不傻。其次，這種行為會造成管理者和被管理者之間的復雜博弈。簡單點說，就是勾心斗角陽奉陰違。你以為你在玩他，他其實悄悄在玩你，搞成了宮斗權謀，一片烏煙瘴氣。

很多公司試圖從“企業文化”這個角度來解決這個問題。試圖把這些問題柔化掉，大家一起吃吃飯，溝通一下，喊兩句口號，樹立一致目標之類的，但以我的觀察，都是緣木求魚而已。上下級矛盾、部門扯皮，矛盾的根源沒有解決，只是讓大家謙恭忍讓，忍得了一時忍得了一世？相反的，矛盾只會越積越深，直到崩盤。

公平

獎懲能夠真正產生正面效力的基礎是公平。這一巴掌該打多重，這顆棗該有多甜，標準是什么？這個標準是不是公平，才是問題的關鍵。

這一點，我覺得都沒什么必要論述，但很多管理者往往遺忘甚至有意識的忽略它。受某D的影響，很多人還把勞動關系看成剝削關系，他們認為，“向管理要效益”就是多剝削一些員工的血汗錢。給你3000讓你干5000的活就是我賺的，再搞個績效考核，扣你200，晚上睡覺都樂醒。這種思路，不屬于本文探討范疇，我覺得這其實不是主流。更常見的情況是，管理者覺得自己被坑了，我發了這么多工資，你究竟有沒有干這么多活？

這種顧慮的根源在于“計時”工資。這就和奴隸制時代很相似，你干一天的活，我給你一天的吃的。但問題在于，你是不是認真“干活”了呢？這就太難以衡量了。所以什么指紋打卡、裝攝像頭之類亂七八糟的管理方式就出臺了。而且，從管理者的角度，還有一種潛意識，我給你8小時的工資，你就得干8小時的活，水都不喝一口這個要求過分了，但你躲在廁所抽煙我就接受不了。所以我看到新聞，某工廠每天上廁所次數不多于三次，每次不超過15分鐘的奇葩規定就出來了。作為員工，尤其是現在的年輕一代，哪里還受得了？據我觀察，一天8小時，能認認真真干4個小時的活就不錯了；能干6小時的活，那絕對是優秀員工楷模了；干滿8小時，那是絕對不可能的（加班除外）。

所以，在計時工資的框架內，管理就轉變成了“如何在單位時間內提高員工工作效率”的問題。出于人性的貪得無厭（資方）和好逸惡勞（工方）考慮，這注定將是一場斗智斗勇難解難分的大混戰。

計件

這里的計件，還包括內部承包、銷售提成等一系列非“計時”支付方式。這幾乎是解決上述問題的靈丹妙藥。對于管理者來說，減少了一系列的管理成本；對于被管理者來說，擺脫了被監視督促的困境，可以自由的安排工作。更重要的是：公平！一旦達成協議，雙方按約履行，多干多得少干少得大家心服口服。所以，其實看看周圍，差不多能計件的，都計件了！

剩下的，就是一些確實不好計件的。軟件開發，在很多人看來，恰好就是這種不好計件的工作。

難以計件，不是因為工作本身很復雜，需要特殊的難以掌握的知識技能等，而是工作本身能否簡單的被計量。一般來說，工作越簡單越容易計量，比如建筑工地上砌磚墻，工作簡單，計量也簡單，直接用面積/用磚數量計算就可以了。但一些看上去很復雜很高科技的工作，一樣可以計量，比如醫生動手術，夠專業吧？一樣可以用手術類型和時間計算，切膽結石手術一次用時3小時，就OK了，可以計件算報酬了。據我所知，掛多少號做多少床手術，這些都是和工資獎金直接掛鉤的。但一些簡單的工作，卻沒辦法計件只能計時，比如餐館迎賓服務員，怎么計件？鞠了多少個躬收了多少盤子？

那么回過頭看程序員的工作呢？只能是“做一天和尚撞一天鐘”？只能“吃大鍋飯”，沒辦法多勞多得少勞少得？

切分

說任何復雜的事物，過于絕對，但大部分的軟件開發工作，其中大部分的內容，其實是可以切分成一個一個簡單任務的——簡單到可以比較準確的計算其工作量。

切分的工作，其實我們都有意無意的在做著。一個項目，只要是多人合作，必然要進行切分，你做什么他做什么，都有個分工，不可能一擁而上吧？但有的切分是依據程序員的崗位或技能進行的，比如張三做前臺、李四做后臺；有的切分是按任務量來切分的，比如張三做甲功能，李四做乙功能。因為本文主要談任務切分是否公平，所以我們著重討論“按功能切分”，這種切分主要的問題是不夠細，粒度太大。

假設兩個功能點，核算都是14個人天的工作量，直接分給張三和李四，張三和李四會不會覺得公平，服不服？我估計最可能的情況是他們自己都不知道！里面可能出情況的地方太多了，所以他們其實是硬著頭皮接下這個任務，因為他也不知道這任務的工作量是多少！大家都只有拼人品了。但總是這樣做也不是個事兒，尤其是在任務重工期緊的時候（前期大家可能都悠哉樂哉的玩兒），矛盾很容易就爆發出來：

加班的先嘀咕了，“艸，他憑什么就下班了，我就要加班？”

項目經理解釋了，“他的功能已經完成了呀！”

這時候不服了，“他的功能明顯要簡單得多，就看見他在玩游戲！我的功能多麻煩多復雜……”

然后擺事實講道理，這里原以為怎么怎么，結果怎么怎么，要是里面還有點需求變更，就純粹一堆爛帳了，誰說得清楚？

項目經理一般就只有投降了，“那張三，幫一下李四吧，特殊情況！”

一次兩次就算了，但可能只是一次兩次么？誰人品那么好？最終下去，兩種情況：1、這次你幫我下次我幫你，幫來幫去幫成“大鍋飯”；2、有人能力不行或偷奸耍滑，長期要人幫，老實人吃虧，怨氣積累直到爆發。無論哪種情況，項目經理都是大眼瞪小眼無可奈何。

精細化

所以切分一定要切分到可控的粒度為止。任務太大，30個人天確實不好估計；但30分鐘以內能完成的任務，應該心里有數沒什么爭議吧？根據我的實踐經驗，我一般會把任務切分到20分鐘左右的粒度，最多不超過60分鐘。在這個粒度范圍內，任務已經相當的具體，可以說是胸有成竹十拿九穩。

按照這種模式，我們就有可能形成精細化的管理實踐。而越精細化，就越有可能實現公平。就像買賣交割，一只羊43.78千克，每千克46元，合計2013.88元；其公平性肯定遠高于以物易物式的谷子一堆。當然，你可能會說，只要雙方你情我愿有何不可？但事實是，如前文說分析，基于人性的貪婪和計較，雙方很難你情我愿，所以大而化之的以物易物現在幾乎已經絕跡了。

成本

有同學感到疑惑，如果任務要切分到這么細，是不是項目經理一天到晚就劃分任務去了，不用干別的？這個問題我們從兩方面考慮：

第一，任務切分這個成本是必須的。比起切分任務，寫設計文檔才是“浪費”時間呢！我在實踐中，至少發現了切分任務的以下這些好處：

1. 能夠真正的厘清功能和任務實現。在切這個任務的過程中，以前朦朦朧朧的概念，才一點點的清晰起來。
2. 能夠“糾錯”。清晰過后，一些疏漏錯誤也就自然而然的暴露出來了。可能以前以為是2小時就能完成的工作，進行切分之后，才發現漏了一些功能點，把實現想得簡單了一些之類的，自己就要適當的調整開發進度。
3. 對開發人員有指導作用。我用的都不是高手大牛，但他們新人也可以順著這個路子一步一步的做下去，至少其中一些簡單的部分可以分給他，復雜的留給我自己做。
4. 開發人員偷不了懶，但比較服氣。不是每一個任務時間都估得那么準，如果你估多了，開發人員偷著樂就是了；估少了，他完全可以提出來。因為任務已經被切得很細很小了，他一提出來什么什么情況，你馬上就能反應過來，任務量就相應的調整就是了。

總之，切分完任務，對這個項目，基本上就心中有數胸有成竹啦。作為管理人員，作為領導，威信就建立起來了。而不是稀里糊涂的把任務布置下去之后，下面一問三不知，錯漏百出。一次兩次問題不大，次數多了，下面的人不服，“聰明”點的就開始動心思糊弄了……

第二，可以采用“從下往上”壘的方式。如果開發人員值得信賴，你也可以讓開發人員自己進行任務切分，你在任務驗收時同時核查任務的工作量。因為代碼都已經提交review了，這時候的工作量已經是挺好衡量的了。開發人員一般也不會亂來。但這里有一個小問題，就是開發人員開始可能會抵觸這種做法。他們會認為切分任務和寫文檔、寫注釋、寫日報周報一樣，是無用的工作。

之前發布了一篇，沒上首頁根本就沒人看，所以就沒臉沒皮的上個首頁吧！希望大家多拍磚。