最後，專案延期是客觀存在的事實，你會選擇紅藥丸，還是藍藥丸？
摘要：當我們要考慮如何讓專案不延期時，我們是否做到讓每個員工都滿負荷了？我們追求的是不延期，還是追求更卓越的產品？
這一兩個星期和同事討論如何使用看板進行專案管理時，總的來說，我遇到最頻繁的問題有：
- 如何能看出專案是否延期？
- 如何拆任務？
其實，我遇到的問題是：如何能看出專案是否延期？然後經我將問題深挖，才發現他們更本質的問題是：拿到需求，如何拆任務，拆到什麼粒度。
討論這類問題，最好舉個例子，否則整個討論過程會很虛。
比如我們的專案經理從產品經理那裡拿到一個需求：改版APP。這款APP有12個介面，所有的介面都需要改。而你手下有6個人。
這時，可以以兩種粒度來拆分：
- 以介面為粒度
- 拆分成更可以量化的粒度。
關於什麼是可以量化的粒度，下文會闡述。
按介面粒度來拆分
可以看出，以介面粒度來拆分，簡單粗暴：24人天的任務，我們有6個人，所以，理論上我們只需要4天完成“改版APP”。我們可以很容易看出這個專案是否延期，只要每個介面都沒有延期。
放到看板上，理所當然，每個介面一張卡。
現實中，我們的專案經理可能還會這樣分到人頭上：
為什麼一定要分到人頭上？除了方便KPI（表面上），背後還有一定的文化因素：因為當專案延期時，我們就可以找出那個相應的人進行問責。這種問責的機制導致的後果：人們更願意推卸責任，而不是共同協作。
放大一些這個問題，公司內部多個技術部門也會因為這種問責的文化，導致部門之間更趨向責怪對方不按期，而不是共同協作完成一件事情。
再再放大一些這個問題：在人們的意識裡往往認為，問責後，壞的事情就可以避免問題再發生。放到我們本篇文章討論的上下文裡，也就是問責可以避免延期。但是，可能嗎？因為延期已經發生，我們應該在延期發生前進行協調資源來解決延期。
我們舉個例子：在專案進行的過程中，人員B在做介面3，4時，在第3天時被一個問題卡住了。而人員C其實在第3天時就已經完成了，第4天開始優化。其他人準時完成了自己的任務。最後人員B的延期導致專案延期了2天。這時，如果你問責人員B，那麼，這次的延期能倒退嗎？也許你會說，問責後，這個人下次就不會延期了。
我想說：
- 延期不延期和你問責沒有任何關係。如果有關係，你在專案開始時，就每個人問責一下，這樣專案就不會延期了？
- 我們應該追求的是每個專案都不延期，而不是下一個專案不延期
- 我們追求的是不延期，還是追求更卓越的產品？
回頭看這次延期，也許我們是可以避免的，比如在第3天的站會上，人員C說出自己被某個問題卡住了。這時，可能其他人員一句話就點通人員C的問題了。還有可能是人員C遇到的問題是需要其它部門來協助才能根本解決，這時專案經理就需要與其它部門溝通了。
回到問題“按介面粒度來拆分任務”這個問題本身。
將介面再拆分成可量化的粒度
這種方式要我們的專案經理拿到需求後，讓最熟悉這個APP的人或團隊對需求再進行拆分成一系列工作單元，然後再分別估算這些工作單元在現有的人員基礎上需要多少天。最後估算出一個總的交付時間點。我們假設完成這個需求，我們同樣需要4天完成。
至於拆分到什麼程度，就是我們上文提到的可量化的程度。
什麼叫可量化？
上面我們看到將需求拆分成一系列工作單元后，我們可以更靈活的安排優先順序。同時，這樣也幫助我們發現介面1和介面2有一個工作單元3是有交集的。有交集的工作單元，我們應該讓同一個人來完成以避免其中的溝通成本。總的來說，拆分成一系列可量化的工作單元后，我們可以：
- 更靈活的優先順序調控
- 發現有交集的工作單元，也就能發現可減少溝通成本的空間。
但是，什麼樣的工作單元叫可量化？
程式碼行數是最簡單的，估計完成APP改版需要寫10萬行程式碼。一個工作單元，我們定1萬行？這種工作單元是可以量化，但是寫完那麼多行程式碼，你就是完成APP改版這個任務了？
我們舉個例子來說明什麼樣的工作單元叫可量化，比如對於介面1，我們需要：
- 把“完成”按鈕的顏色從綠色改成藍色
- 當完成值為100時，不顯示100，顯示成“恭喜，已完成”
- 快取從伺服器獲得的任務完成值，對於多次操作，只向伺服器請求一次，以提升使用者操作的流暢感
從這個例子，我們可以看出，每個工作單元都應該是：
- 準確的：將綠色改成藍色，而不是紅色
- 不可分割的：不顯示100，顯示成“恭喜，已完成”，這個工作單元，你不能再分割了
- 體現了業務含義：程式碼行數並不能體現業務含義，但是提升使用者操作的流暢感有業務含義的。
可量化的工作單元、站會與看板
有了可量化的工作單元后，再結合站會和看板，這樣，我們每天都可以知道（視覺化）團隊的工作狀態了。延不延期，大家都可以看得到，大家都是成年人了：
- 誰做得快，誰撿更多的卡來做的。而且可以撿優先更高的卡先做，也降低延期的風險。我們可以從這個過程中識別人才。
- 站會的第3天，人員B還在做_#3_卡，我們其他成員可以加快速度做其它卡以彌補人員B的慢速度，同時專案經理也可以更早的介入這個可能延期的卡中幫助人員B
- 當出現質量問題時，人員D的卡會被打回Todo多次，因為有站會，我們所有人都很感覺到_#5_這張卡可能存在一定難度或者人員D在協作方式存在問題，這時，我們其他人就會主動幫助人員D解決問題，而不是責怪他。
慢慢地，團隊的協作方式變得以解決問題為導向，而不是以問責為導向。
拆分成可量化的工作單元，一樣會延期
但是，我個人的經驗看來即使我們將需求拆分成可量化的工作單元，專案一樣可能會延期。
看板只能幫助我們更視覺化，更容易地瞭解到專案當前的狀態，對於這個狀態，我們的專案經理要如何反應，完成是個人問題了。
同時，看板也能幫助我們找到延期的根本原因，比如是某個人的卡在In Progress上拖了很長時間、某個人請假了、其它部門中間改需求了、專案人員在某項技術的能力問題……
所以，要延期的專案一定會延期，我們應該正確面對，找到原因並根本解決。我們要做的只是保證每個人每個工作日都是滿負荷的。
這裡，留給大家一個思考題：如果其它外部條件不變，每個人每個工作日都是滿負荷了？如何不延期？
拆成可量化的工作單元會增加專案經理的工作量？
然而，又會有人說了，這麼多專案，我每個專案都要拆分成可量化的，我們專案經理會增加很多工作量。
其實，如果真的有作用了，這些工作量是值得的，只要你真的理解可量化工作單元的作用。同時，當出現多個專案時，你忙不過來時，說明現在是你培養另一個專案經理的時機了。你可以嘗試將一些專案管理的工作交給團隊成員來完成。但前提是專案經理本身也是超負荷工作，影響正常工作了。
小結
想讓專案不延期，我們首先關注的是如何將需求拆分成可量化的工作單元，然後想辦法保證這些工作單元真正被有效的執行。辦法通常可以有：
- 使用看板視覺化所有的工作單元
- 通過站會了解工作單元執行過程可能的風險
- 通過協作來取長補短
- 通過優先順序來降低延期時的風險
- 通過打包有交集的工作單元減少溝通成本
通過以上方法可以將團隊“調”到可能的最優狀態。但是如果還是延期，原因可能就不在團隊了。