項目管理（一）計時計件

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

 

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

 

「凡事預則立不預則廢」，因此仍是決定花兩天時間，專門完成這個系列博客。關注我博客的同窗都知道我開發了一個任務管理系統，這原本只是我隨手作的一個項目管理小工具，但後來用得順手，在上面花的時間也愈來愈多，因此隱隱有點以爲，還真能夠把這事當成一個小事業來作。因此也借這個博客系列，整理一下個人思路，和你們一塊兒分享我關於項目管理的一些經驗和想法。都是我本身揣摩的，不必定靠譜，因此但願園子裏的童鞋們大膽質疑，使勁拍磚！

 

鞭子

 

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

 

但這些年來，我本身開過公司，也待過不少家公司，這個場景卻讓我記得愈來愈深入。我常常不禁得想，管理者手裏究竟有沒有拿着「鞭子」？該不應拿着「鞭子」呢？

 

拿着鞭子，凶神惡煞，「誰作得慢就給誰一鞭子」的監工形象，來源於各類影視做品，講的確定是古代的事了。但時至今日，有形的鞭子早就沒了，但無形的呢？各類KPI考覈、扣獎金、裁人……沒有這根鞭子，員工還能好好幹活麼？估計很難，咱們國家改革之前的「大鍋飯」，甚至我待過的一些赫赫有名的外企，「大公司病」裏最重要的一點，被管理者偷奸耍滑混日子（或許都包括我本身，呵呵）的愈來愈多，一個重要的緣由就是管理者手裏沒權，沒有「鞭子」。

 

胡蘿蔔

 

但「鞭子」慢慢的退出歷史舞臺，除了文明進步、日益嚴格的勞動法律法規之外，我以爲最重要的緣由，仍是管理者發現：「胡蘿蔔」比「鞭子」更管用。

 

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

 

還想到了一個例子，之前咱們都說金字塔是奴隸們修的，後來西方有考古學家就說了，「不對，奴隸作不了這麼精緻的活。應該是自由工匠作的」。還有不少考古證據，我是外行，但想一想這個推論，實際上是頗有道理的。

 

誤區

 

綜上，不少管理者就把「威逼利誘」當成了法寶，奉行「賞罰分明」；俗一點，「打個巴掌，給個棗吃」。但這樣有用麼？我以爲，有時候有用，有時候沒用。

 

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

 

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

 

公平

 

獎懲可以真正產生正面效力的基礎是公平。這一巴掌該打多重，這顆棗該有多甜，標準是什麼？這個標準是否是公平，纔是問題的關鍵。

 

這一點，我以爲都沒什麼必要論述，但不少管理者每每遺忘甚至有意識的忽略它。受某D的影響，不少人還把勞動關係當作剝削關係，他們認爲，「向管理要效益」就是多剝削一些員工的血汗錢。給你3000讓你幹5000的活就是我賺的，再搞個績效考覈，扣你200，晚上睡覺都樂醒。這種思路，不屬於本文探討範疇，我以爲這其實不是主流。更常見的狀況是，管理者以爲本身被坑了，我發了這麼多工資，你究竟有沒有幹這麼多活？

 

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

 

因此，在計時工資的框架內，管理就轉變成了「如何在單位時間內提升員工工做效率」的問題。出於人性的貪得無厭（資方）和好逸惡勞（工方）考慮，這注定將是一場鬥智鬥勇難解難分的大混戰。

 

計件

 

這裏的計件，還包括內部承包、銷售提成等一系列非「計時」支付方式。這幾乎是解決上述問題的靈丹妙藥。對於管理者來講，減小了一系列的管理成本；對於被管理者來講，擺脫了被監視督促的困境，能夠自由的安排工做。更重要的是：公平！一旦達成協議，雙方按約履行，多幹多得少幹少得你們心服口服。因此，其實看看周圍，差很少能計件的，都計件了！

 

剩下的，就是一些確實很差計件的。軟件開發，在不少人看來，剛好就是這種很差計件的工做。

 

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

 

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

切分

 

說任何複雜的事物，過於絕對，但大部分的軟件開發工做，其中大部分的內容，實際上是能夠切分紅一個一個簡單任務的——簡單到能夠比較準確的計算其工做量。

 

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

 

假設兩個功能點，覈算都是14我的天的工做量，直接分給張三和李四，張三和李四會不會以爲公平，服不服？我估計最可能的狀況是他們本身都不知道！裏面可能出狀況的地方太多了，因此他們實際上是硬着頭皮接下這個任務，由於他也不知道這任務的工做量是多少！你們都只有拼人品了。但老是這樣作也不是個事兒，尤爲是在任務重工期緊的時候（前期你們可能都悠哉樂哉的玩兒），矛盾很容易就爆發出來：

加班的先嘀咕了，「艹，他憑什麼就下班了，我就要加班？」

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

這時候不服了，「他的功能明顯要簡單得多，就看見他在玩遊戲！個人功能多麻煩多複雜……」

而後擺事實講道理，這裏原覺得怎麼怎麼，結果怎麼怎麼，要是裏面還有點需求變動，就純粹一堆爛賬了，誰說得清楚？

項目經理通常就只有投降了，「那張三，幫一下李四吧，特殊狀況！」

一次兩次就算了，但可能只是一次兩次麼？誰人品那麼好？最終下去，兩種狀況：一、此次你幫我下次我幫你，幫來幫去幫成「大鍋飯」；二、有人能力不行或偷奸耍滑，長期要人幫，老實人吃虧，怨氣積累直到爆發。不管哪一種狀況，項目經理都是大眼瞪小眼迫不得已。

 

精細化

 

因此切分必定要切分到可控的粒度爲止。任務太大，30我的天確實很差估計；但30分鐘之內能完成的任務，應該內心有數沒什麼爭議吧？根據個人實踐經驗，我通常會把任務切分到20分鐘左右的粒度，最多不超過60分鐘。在這個粒度範圍內，任務已經至關的具體，能夠說是成竹在胸十拿九穩。

 

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

 

成本

 

有同窗感到疑惑，若是任務要切分到這麼細，是否是項目經理一天到晚就劃分任務去了，不用幹別的？這個問題咱們從兩方面考慮：

 

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

1. 可以真正的釐清功能和任務實現。在切這個任務的過程當中，之前朦朦朧朧的概念，才一點點的清晰起來。
2. 可以「糾錯」。清晰事後，一些疏漏錯誤也就天然而然的暴露出來了。可能之前覺得是2小時就能完成的工做，進行切分以後，才發現漏了一些功能點，把實現想得簡單了一些之類的，本身就要適當的調整開發進度。
3. 對開發人員有指導做用。我用的都不是高手大牛，但他們新人也能夠順着這個路子一步一步的作下去，至少其中一些簡單的部分能夠分給他，複雜的留給我本身作。
4. 開發人員偷不了懶，但比較服氣。不是每個任務時間都估得那麼準，若是你估多了，開發人員偷着樂就是了；估少了，他徹底能夠提出來。由於任務已經被切得很細很小了，他一提出來什麼什麼狀況，你立刻就能反應過來，任務量就相應的調整就是了。

總之，切分完任務，對這個項目，基本上就心中有數成竹在胸啦。做爲管理人員，做爲領導，威信就創建起來了。而不是稀裏糊塗的把任務佈置下去以後，下面一問三不知，錯漏百出。一次兩次問題不大，次數多了，下面的人不服，「聰明」點的就開始動心思糊弄了……

 

第二，能夠採用「從下往上」壘的方式。若是開發人員值得信賴，你也可讓開發人員本身進行任務切分，你在任務驗收時同時覈查任務的工做量。由於代碼都已經提交review了，這時候的工做量已是挺好衡量的了。開發人員通常也不會亂來。但這裏有一個小問題，就是開發人員開始可能會抵觸這種作法。他們會認爲切分任務和寫文檔、寫註釋、寫日報週報同樣，是無用的工做。

說說我是怎麼處理的吧！我拗不過他，就隨他的便，但只有一個要求， 你先把你要花多少時間告訴我。他說行，好比一個功能點，他信心滿滿的說，「120分鐘夠了」。結果夠個屁！哈哈，他兩天都搞不出來，想加時間，我不幹了呀，你加時間的依據在哪裏？我知道是由於任務在作的過程當中變複雜了，但東一榔頭西一棒，他怎麼說得清楚？搞得他焦頭爛額以後，他本身去體會。多嘗試幾回以後，同時隨着他技術的逐步提升，最後他也養成了作以前，先切任務的習慣。其實切任務就是一個理思路的過程，作以前思路清晰了，事半功倍，「磨刀不誤砍柴工」說的就是這個道理。

 

其餘做用

 

咱們是由着「計件」這個話題談到任務切分的，但實際上，即便任務切分，讓程序員拿計件工資，我以爲現階段仍是不現實（鼓勵你們多嘗試，我有機會也試試）。當初咱們公司開發人員入職，我給他們講的都是計件，但實際上仍是按月發大體固定的工資。可是，經過任務切分，咱們能夠作到如下幾點：

 

第1、合理的安排人手。項目成員中水平有高有低，新人都有一個成長的過程。任務切分以後，像剔骨頭同樣，嫩肉給新人菜鳥，硬骨頭給老人高手。這樣，項目組才更具備效率和活力。你把簡單的重複性工做給高手作，純粹是讓千里馬犁地，浪費啊；把複雜的扔給菜鳥，他百度google，半天弄不出來也是浪費時間。但若是沒有切分，難的簡單的混在一塊兒，區分不出來啊！

 

第2、有理有據的績效考覈。距今爲止，我所見過的全部績效考覈，基本上都是扯淡。在沒法量化的狀況下，其惟一的做用就是無事生非，破壞安定團結的大好局面。你說他這個月績效打80分，憑什麼？他加了班？加班應該給加班費啊！代碼出了bug？誰的代碼沒bug？都沒bug要測試幹什麼？可能最大的緣由是他和你頂了嘴？你看他不順眼打擊報復吧？因此最後基本上兩種結局，要麼弄得雞飛狗跳，要麼稀裏糊塗一鍋粥。

但我有了任務管理系統的記錄和統計，每一週每個月我把數據拉出來，明明白白的告訴他，爲何這個月多給，上個月少給，他基本上也認同。這裏必需要說一下，工做量（時間）不是他實際完成工做的時間，而是我認爲一個普通程序員（其實就是我啦）完成該工做的時間。好比我給這個任務20分鐘，是指我能在20分鐘完成，你哪怕花一天才搞出來，那是你的事！否則，你天天的工做量都是8小時，有什麼意思？而後根據工做量，就能夠統計出來你的績效了。固然，任務是有難度劃分的，還可 以包括不少其餘因素，好比：驗收不合格的比率、按時完成任務的比率等等，這些咱們之後再談。

 

第3、清晰準確的項目預算。我作開發七八年了，我歷來沒看到過一份清清爽爽的軟件項目預算。都是作工程，好比建築工程裝飾工程，根據圖紙，材料人工，一項一項的清單報價，無論多大的工程，價格算出來都是精確到分的，好比1080732.76元。但軟件開發，合同能精確到百，都不錯了，通常都是20萬、3500，感受在價格就是隨口喊出來的同樣。工期也是同樣，建築工程，誤了工期，時間稍微長一點，違約金賠都賠不起。軟件開發，延期延期再延期，纔是常態，是吧？即便勉強交貨，那都是蒙人的，裏面bug一大堆，先交了貨，再慢慢「維護」吧！

這個問題的根源在於，項目負責人對項目的細節沒有切實的把控。只能憑着「經驗」或者「想象」來大體的「估算」項目的工做量，而事實證實，這種估算是至關不靠譜的，由此而產生大量的糾紛。據我觀察，通常只有小項目，纔會採用按項目總體計價的方式發包；規模稍大的項目，若是雙方都有必定的行業經驗，一般是用外包人天過後覈算的方式結算。按實際的人天結算，其實並無真正的解決預算的問題，發包方同樣須要預算啊！項目會花多少錢，該什麼完工，內心一直沒數。再說了，你外包過來的程序員究竟有沒有認真幹活，是否是在混日子，誰知道呢？

 

第4、應對需求變化。可能有這樣一種想法：我花了大量的時間精力，事先把任務切分得清清楚楚，並據此作好了全部預算，但需求會隨時改啊，最後還不是改得一塌糊塗？所謂「計劃永遠沒有變化快」。其實不是這樣的。若是你的計劃是一個不可分割的總體，犬牙交錯，牽一髮而動全身的那種，那麼固然，每一次改動都是一次傷筋動骨的大折騰。

但經過良好組織的任務切分，改動就能夠被有效的對應到相應的計劃部分。這時候，「有計劃的變化遠勝於無計劃的變化」，由於每一次的改動就是一個局部的改動，是很是容易被從新計量評估的。好比，某次改動，會影響原任務3098-4012，原任務3876-3879，任務量共計480分鐘；改動新增任務5678-5894，任務量共計300分鐘；因此任務總量減小180分鐘，很是清晰。

固然，咱們還有一系列的措施應對需求變更。但良好的任務切分，具備基石般的重要做用！

 

以前發佈了一篇，沒上首頁根本就沒人看，因此就沒臉沒皮的上個首頁吧！但願你們多拍磚。