軟件項目管理實踐之日計劃
袁光東 原創
如何提高項目的生產率，保證項目按期交付是每個軟件開發項目經理都需要面對的難題。關于這方面的研究，在《人月神話》、《人件》等書籍都有很詳細的論述。研究表明，不同程序員之間的生產率最高差別在40倍以上。雖然筆者沒有親睹這種樣例，但是筆者的開發和管理生涯中所發現的相同技術水平程序員之間的生產率最大差距可達4倍。這個數據就發生在筆者的一個項目中，這讓筆者感到非常的震驚。如果說40倍的生產率差距可能會有技術能力、工作經驗、熟悉程度諸多因素的影響。那么，筆者所發現的4倍生產率差距卻更讓筆者感到不可思議。
案例
程序員J：四年開發經驗
程序員L：三年開發經驗
程序員Y：五年開發經驗
技術能力：Y > J > L
J，L，Y同時進入一個項目組，開發時間為30個工作日，即6周，包括需求分析、設計、編碼和集成。其中編碼和單元測試時間為10個工作日(2周)。產生的工作績效為：
| 程序員 |
規模(代碼行) |
| J |
1500 |
| L |
3600 |
| Y |
6000 |
可見，當程序員的技能達到一定水平后，技能與生產率并不成正比，并不是技術水平越高的程序的生產率越高。
一、最后期限
很多程序員都會有類似的經歷：
1月1日，項目經理說：“小張，在1月5日之前把這項工作做完，詳細的需求文檔我已經發到你的郵箱中。”
1月1日，小張對需求文檔瞥了幾眼，估計2天就可以完成，嘀咕：“現在才是1月1日嘛。這項任務要1月5日才提交。我還有時間，不用管它，還是先看我的小說吧。”
1月2日，小張繼續看他那心愛的小說......
1月3日，小張繼續看他那心愛的小說......
1月4日 9:00，小張開始看需求文檔，2小時后中斷，因為他需要修復系統的一個Bug。
1月4日 18:00，小張正在埋頭苦干，因為明天就要提交工作，可是一個代碼還沒有寫呢。
1月4日 23:00，小張完成大部分工作，下班走人。
1月5日 9:00，項目經理問：“小張，那個功能做完了吧？”小張答道：“就快了，今天提交沒有問題。”
1月5日 14:00，小張發現有一部份代碼需要重寫。用戶的要求是需要一個可配置的功能，而小張卻寫成了硬代碼。
1月5日 17:00，項目經理來到小張面前：“小張，你中午不是說今天提交沒有問題嗎？怎么現在還沒有看你提交代碼？”小張委屈地答道：“經理，遇到一點小麻煩。不過相信我，下班之前一定完成。”
1月5日 18:00，項目經理急匆匆趕到小張的座位旁：“小張，請馬上提交代碼，不然就來不及了。”小張這時也急了：“你不要催我。這個功能麻煩大了，沒有想象得那么簡單。我今天晚上得加班。”項目經理無可奈何地走了。小張加班到凌晨1點。但程序還是有一些問題。
1月6日，小張仍然在修改程序......
1月7日，小張仍然在修改程序......
1月8日，總算是修改完成。已經拖了三天，來不及測試，只能匆匆把代碼提交。
后來，又經過5次修改，直到1月20日，這個功能總算是徹底完成。
小張向項目經理請了一周假。因為這兩周來幾乎每天晚上都是加班解決問題。
許多的程序員還會有這樣的經歷：
4月1日，項目經理：“小王，這個功能交給你，需求你看了嗎？你看需要多長時間完成？”
小王：“哦，經理，這個功能我剛看過，大約需要1周時間。”
項目經理：“那就是4月5日可以提交啦？”
小王：“是的，經理。這個功能內容很多，還要實現一個郵件功能，4月5日能提交已經是我的極限了。”
項目經理：“那就4月5日吧。”
4月2日，小王發現：系統中已經有一個類似的郵件功能，直接使用就可以。
4月2日 18:00，小王已經把功能都完成了。
4月3日 9:00，小王把功能都測試通過，并且還私下請用戶幫他進行測試通過。
4月3日 11:30，項目經理：“小王，那個功能做完了嗎？”
小王：“經理，正在做呢。你看，昨天你又叫我修改另外一個Bug。不過，經理你放心吧，4月5日一定可以提交。”(小王已經做完工作，但聲稱沒有做完。)
4月4日，小王專注的看著一本電子書，名字叫《The Deadline》。
4月5日 15:00，小王把代碼提交，并向經理發郵件，主題是：XXX功能已經完成。
4月6日 9:00，項目組開會，項目經理表揚了小王，要求大家向小王學習。因為這次發布只有小王按時完成了工作。
簡直不可思議，我們的程序員就是這樣工作的。是的，我也認為不可思議！可是哪個程序員敢保證自己沒有這么干過呢？這就是所謂的最后期限：人們總是在最后期限才開始工作
二、熱衷于加班
在所有的軟件項目組中，加班已經成了天經地義的事。甚至有些管理層認為，如果一個項目組不加班，說明項目組沒有盡全力的去做事。我至今不明白這是什么道理，工作是否盡力與加班到底有何關系？工作的績效又與加班有何種關系?
在筆者的項目組中，筆者的客戶方也曾對筆者要求項目組必須加班，遭到了筆者的拒絕。在保證每個階段在不加班的情況下按期完成，客戶方才勉強同意。事實證明，不加班也是可以把項目做完的，而且可以做得更好。
在我的程序員生涯中，曾經兩次長達4個月的封閉開發期，被要求每天從19:00－22:00集體加班。但實際情況是，每天都可能要在23:00之后才可以下班。因為項目經理沒有走，所以其它開發人員也只能留下。痛苦的是，我在那段加班時間里除了看技術電子書外，找不到任何可做的事情。我相信，當時項目組有太多的人跟我一樣。當我每天23:00回到賓館時，已經完全麻木了。我無時不想那該死的項目早一天結束。在那段時間里，我最大的收獲時進行了大量技術積累。項目結束時，我的加班記錄累計長達30人天。
甚至有些程序員在正常的工作時間里也是不做事的，下班前開始忙碌，加班干活。想想這樣的加班又有什么效果呢？
三、工作成熟度與團隊成熟度
因此，我一直致力于研究提高個人工作績效的方法和提高項目組工作績效的方法。
在長期的學習、摸索、實踐中，我發現全心的投入工作，干好4個小時就足以把工作做好。這種全心投入產生的績效要比以前一周所干的還要多。如果每天努力干好8個小時，你會比周圍的人產生2倍以上的績效，當然也會非常疲憊。
在管理一個40人規模的團隊時，我每天投入僅僅4個小時就足夠。為什么會有這么高的工作效率？主要是長期堅持下面的方法:
1.日計劃，列出工作清單(列出當天需要做的事情)
2.為任務劃優先級(標出當天必須完成的事情)
3.只做最重要的事情，而不是最緊急的事情
4.絕不拖延，計劃當天必須完成的事情就一定要做完才走。
筆者長期以來在思考，這個方法能否幫助團隊提高工作績效？能否讓項目組提高生產率？能否使項目按期交付和提前交付？能否幫助程序員在不加班的情況下把項目做好？
在筆者帶項目和監控項目的過程中發現，程序員工作效率不高的原因除了技能因素外，還有幾個重要的因素在影響著程序員的工作績效：
1.工作無計劃：很多程序員根本不知道每天要做哪些事情，每天必須做完哪些事情。很少有程序員對當天的工作進行計劃，
2.工作無重點：很多程序員通常按事情發生的先后順序來做事。有時，有些程序員忙碌了一天下來卻發現當天其實沒有做什么有用的事情。
3.工作無目的：程序員不知道當天要把事情做到什么程度，完全是憑心情做事，憑良心做事。事情沒有做完，別人下班自己也跟著下班，認為反正明天還有時間，還沒有到最后期限。
4.工作不到位：工作起來總是覺得差不多就行。把代碼寫完和功能能夠運行當作兩回事情。工作到位就是一次就把工作做好，達到可交付。
5.工作無積極性：被動式工作，就算工作做完也不提交，一定要等到最后期限才提交。如果比承諾時間提前提交工作，馬上就會帶來新的工作，多干和少干一個樣，誰愿意多干呢？
我們可以提出一個概念叫做“工作成熟度”。工作成熟度高的程序員通常會有計劃性、工作有重點、有目的性、工作做到位。而成熟度低的程序員通常是無計劃的，工作不分輕重，很容易被突發事件打斷當前工作，工作要通過多次修改才能夠完成。所以，我發現，工作成熟度對程序員生產率造成最直接的影響。
筆者在監控項目的過程中也發現造成項目組效率低下、進度落后的一些因素：
1.項目經理不了解項目當日狀態。是的，有些項目經理根本不知道今天每個程序員會干些什么？該干些什么？
2.項目經理不了解項目實情。沒錯，項目經理根本就不知道每個程序員當天干了多少活，干到什么程度，還要干多久？也就不知道項目到了什么程序，還有多少工作量要做？
3.項目經理不知道每個人是否能夠按期交貨。項目經理只能是望天收成，期望程序員憑良心、憑職業道德做事。但是，至于程序是否能夠按期交貨，只有鬼才知道。
4.項目經理不知道工作的重點是什么？哪些工作是本階段必須要完成的？哪些是可以拖后的？
5.不良溝通。項目組的溝通不良，產生大量重復代碼。甚至會有兩個程序同時開發一個功能，但是彼此間卻不知道。
6.信息不能共享。程序員彼此之間不知道別人干得怎么樣？也不知道項目整體情況到底怎么樣？這也難為程序員了，因為項目經理也不知道。
糟糕的項目都存在著一個黑洞。通常會是在編碼階段，整個項目組就像在黑洞中穿行一樣，誰也看不清對方，不知道黑洞的盡頭在哪里，誰也不知道走過多少地方，還要多久才能走出黑洞。總之，項目經理只能拼命的喊：“快點，快點，兄弟們，我們的時間不多了。”所以，項目經理只能讓所有的人每天加班，星期六不能休息，到最后，星期天也不能休息。
這就是我們可以提出的另一個概念——“團隊成熟度”。
“噢，伙計，我已經聽煩了。好像是有那么回事！可是又能怎么樣呢？所有的項目不都是這樣過來的嗎？”
四、日計劃做什么？
程序員的工作成熟度直接影響了程序員的生產率；項目的團隊成熟度直接影響了項目的生產率。如果我們能夠提高程序員工作成熟度和團隊成熟度，就一定可以提高項目的生產率。
而程序員工作成熟度和項目團隊成熟度的共同核心點就是計劃。在筆者的研究和實踐過程中，可以通過在項目中實施日計劃來提高程序員的工作成熟度和項目的團隊成熟度，從而提高程序員的生產率和項目的生產率。
實施日計劃的流程：
1.每天8:30-8:35，項目組召開晨會。由項目經理列出每個開發人員的工作清單，并對每個工作任務標注優先級別，設定任務完成的標準，指明當日必須要完成的任務，并得到責任人的承諾。
2.每天下班前20分鐘，由項目經理依次檢查開發人員的工作。評定工作是否完成。如果有開發人員未能完成任務，一起分析任務未能完成的原因。然后召開一個簡單的會議，介紹當天工作的完成情況及當前階段的項目狀態，未完成任務的開發人員需要加班完成。
每天早晨的會議我們稱之為晨會，下午的會議稱之為夕會。
日計劃的實施環節：設定目標，制定計劃，檢查，反饋。
日計劃的特點：
1．開發人員每天在晨會承諾完成的任務必須當天完成，提倡日清日結。
2．提交可交付的成果。（事先制定任務完成的標準，并由項目經理進行檢查，評定任務是否完成。）
3．做最重要的事情
4．保證把工作做完
五、我們是怎么實施日計劃的？
日計劃看起來非常簡單，下面我們將對日計劃的實踐進行討論。
1.實施日計劃對項目有什么作用？
· 實施日計劃，使項目有良好的溝通機制。每個開發人員都非常清楚項目的當前情況：項目已經完成了多少？還有多少工作沒有完成？
· 日計劃提倡可交付的成果，也就是每天完成的工作都一定是可交付的。
· 日計劃提倡只做最重要的事情，使項目抓住了重點。
· 項目經理通過實施日計劃，非常清楚每個開發人員每天需要完成哪些任務，每天必須完成哪些任務，以及每個人的完成情況怎么樣？項目經理充分地掌握了項目的情況，可以及時調整計劃，應對各種變化。
· 日計劃實現了項目的良好溝通，每項任務都由開發人員和項目經理達成一致。
· 日計劃通過晨會和夕會實現了項目組的信息共享。
2.實施日計劃對程序員的作用
· 日計劃列出了程序員每天要做的任務清單，并且對任務確定優先級。
· 對程序員的工作指明方向，并且要求程序員優先做最重要的任務，使程序員抓住了工作重點。
· 日計劃要求提交可交付的成果，要求程序員把工作一步要做到位，養成良好的習慣。
· 日計劃提高了程序員的工作績效，程序員可以回到正常的工作時間，減少無謂的加班。
· 程序員比以前完成更多的工作而獲得獎勵。
3.在實施日計劃時，與傳統項目管理的工作分配有什么不同？如何進行工作分配？
傳統項目管理的工作分配中，工作項的粒度比較粗。每一個工作項通常指一個功能。通常是把一個功能分給某程序員，甚至把一個模塊分派給某個程序員。工作項的工時以周為單位，通常是一周或者兩周。
傳統項目管理任務分配表
| 模塊 |
功能 |
當前狀態 |
計劃開始 |
計劃結束 |
實際開始 |
實際結束 |
責任人 |
| 訂單管理 |
訂單信息查詢 |
已開始 |
2009-3-1 |
2009-3-7 |
2009-3-1 |
|
L |
| 新增訂單 |
已開始 |
2009-3-1 |
2009-3-7 |
2009-3-1 |
|
L |
| 訂單管理 |
修改訂單 |
未開始 |
2009-3-1 |
2009-3-7 |
|
|
L |
| 刪除訂單 |
未開始 |
2009-3-1 |
2009-3-7 |
|
|
L |
實施日計劃的工作分配中，“工作項”的粒度更小。如果按照XP和Scrum的說法，功能就是指一個“故事”，完成“功能”的步驟或事件叫“任務”。
傳統項目管理的任務分配是以“故事”為最小粒度。日計劃的任務分配是以“任務”為最小粒度。“任務”是指完成某一個“功能”的步驟或事件。每個人當天的任務工時總合為1人天。
故事和任務的區別：
|
故事
|
任務
|
|
訂單信息查詢
|
DAO編碼
|
|
DAO單元測試
|
|
業務層編碼
|
|
JSP表示層編碼
|
|
集成測試
|
要實現訂單信息查詢就由右邊的那些任務組成。
開始，我不知道怎樣來描述一個“功能”和實現一個功能細化的“任務”。后來，當我看到Scrum的書籍后，看到Sprint和任務板時，才知道自己的實踐與Scrum的某些實踐竟有如此相似之處。我困惑很久，想不到用什么詞來表示一個“功能”和實現一個功能所需要的“步驟”。Scrum使用“故事”和“任務”來定義它們，我認為非常的準確到位。
但是日計劃的工作分配與Scrum的工作分配是不同的。實施日計劃是由項目經理主導的；而Scrum強調由程序員主導。至于這兩種方式，哪一種更好。我覺得可以結合具體的情況進行不同的實踐。
如果是程序員成熟度比較高的項目，可以由程序員來主導。程序員成熟度較低和工期很緊的項目，可以由項目經理來主導。總之，這都需要程序員和項目經理達成一致。程序員需要向項目經理承諾。
Scrum會對每個任務進行事先估算，而日計劃分配工作任務前才會進行估算，并且只為每個人分配工作量為1人天的任務總和。
日計劃樣例：2009-3-22程序員L工作計劃
| 開發人員 |
今日計劃工作及完成情況 |
| 序號 |
工作任務 |
優先級 |
完成標準 |
是否完成 |
完成百分比 |
完成情況 |
未完成原因 |
檢查人 |
| L |
1 |
訂單管理模塊DAO實現 |
50 |
單元測試通過 |
|
|
|
|
|
| 2 |
與用戶確認頁面原型 |
10 |
用戶確認郵件 |
|
|
|
|
|
程序員L任務1的優先級為50，任務2的優先級為10。這并不表示兩個任務的重要程度相差40，而是表示L當天應該先做任務1，再做任務2。
筆者認為這種日計劃更加靈活。因為項目經理可以靈活的設置任務。Scrum的任務都是依據故事。日計劃甚至可以把與開發根本不相干的事情包括進來。
當天要完成哪些任務是由項目經理先計劃的，但是程序員可以提出不同的意見。雙方達成一致。并且任務是可以量化和檢查的。因此，事先還要設置完成標準。一旦程序員與項目經理達成一致，就相當于程序員向項目經理承諾，今天可以完成這些任務。
對于成熟度比較高的程序員，完全可以由程序員先提出計劃。然后，由項目經理進行評估和檢查。雙方達成一致后，就把任務放入日計劃的工作任務表中。
4.為什么要檢查？怎么進行檢查？
如果沒有檢查，計劃就是無效的。
日計劃強調提交可交付的成果。雖然事先制定了標準，但是程序員和項目經理可能會對可交付成果的理解不同。項目經理如果要清楚地了解到項目狀況就必須要親自進行檢查。
如何進行檢查？項目經理一定要在現場工作，最好的辦法就是讓他演示給你看。對于不能演示的任務就進行抽查。因為事先已經制定完成標準，大家只需要按規矩辦事即可。
并且一定要填寫完成情況，以便后期的跟蹤。
5.如果程序員不能完成日計劃怎么辦？如何才能夠使程序員能夠完成日計劃？
程序員不能完成日計劃時，也就是進度出現了偏差。項目經理一定要與程序員一起分析偏差的原因，并記錄下來。進度發生偏差最有可能的兩個原因：計劃不合理和計劃執行不力。
計劃不合理包括：對任務的難度和工作量估算失誤，對程序員能力的估算失誤，或者程序員的工作方法存在問題，需要支持和協助等。
如果是對任務估算發生失誤，就需要重新進行估算。這正是日計劃和檢查帶來的好處。項目經理需要重新調整計劃。
如果是對程序員能力估計失誤，項目經理也需要重新進行調整，如換人，或延長時間。
如果是程序員工作方法存在問題，就一定要進行指導，或者安排其它人員進行協助。
如果是計劃執行不力，也要找到最核心的原因是什么？是意愿不高？中間去做其它事情？工作習慣如此？都需要找到核心原因，方可對癥下藥。
在我的團隊中，績效考核的幾個核心指標：工作效率*工作效果*工作量
不能完成日計劃，會直接影響到月底的績效和獎金。
如何才能夠使程序員完成日計劃？首先是計劃一定要合理，要考慮到個體差異,分配任務在其能力范圍之內。日計劃一定要獲得當事人的承諾。檢查和跟蹤一定要到位。要與考核掛勾，做到會得到什么？做不到會有什么后果？
六、沒有銀彈
是的，沒有銀彈。沒有任何一種方法可以保證項目一定能夠成功。日計劃也一樣。目標、計劃、執行、控制構成管理的核心。所謂工作成熟度和團隊成熟度其實都可以歸納為“執行力”。日計劃只是一種管理實踐，在不同的環境可能會有不同的實踐方法，并不是一層不變的。