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