挨踢項目求生法則（8）——計劃篇

摘要：

計劃趕不上變化，計劃還要不要寫呢？項目工期限死，估算有什麼價值呢？只有項目經理緊張項目，其餘人是打工心態，怎樣辦呢？PMP的知識能搭救項目嗎？如何才能作出一個定期交付的完美計劃呢？全部問題，將在這一篇中大爆發！

說明：

這是「挨踢項目求生法則」系列文章，以前已經爲你們分享了戰略篇、團隊建設篇、需求篇、設計篇、編碼篇、測試篇、實施篇，這篇是計劃篇。

什麼叫挨踢項目？

IT項目，特別是軟件開發項目，都屬於「挨踢」項目的範疇。挨踢項目的幾大特色：
1.需求不肯定。
2.技術不肯定。
3.工期限死。
4.預算限死
兩大不肯定和兩大限死，你想不「挨踢」都難！

什麼是項目計劃？

實際工做中計劃應該在前面就寫了，爲何本系列文章直到第8篇才寫計劃這個主題呢？

計劃其實就是爲了實現項目的目標，對項目各項工做的統籌安排。

那什麼是項目的「各項工做」呢？

各項工做包括團隊建設、項目分析、需求分析與管理、軟件設計、編碼、測試、實施等，本系列前面的文章逐一分享了」各項工做「（固然項目的」各項工做「不止這些，後文會補充說明）。各項工做的最佳實踐，將會直接決定計劃的質量。爲何在第8篇才分享「計劃」這個主題，緣由也是如此。

計劃對加速工期有多大幫助？

有朋友問了一個計劃應該如何寫的問題。這位朋友已經有幾年的軟件研發一線工做經驗，項目經理的工做也不是第一天干的，問出這樣的問題我以爲有點怪。但我仍然說了一通項目計劃的「大道理」供他參考。而後他說：項目成員技能不足，計劃怎樣寫？

後來我才發現，他的真正問題是：如何寫好計劃以保證工期！

我給出的回答居然是：計劃自己對加速工期並無幫助！

要加速項目工期，主要在於兩方面：

1）提高需求分析與管理能力，能爲客戶帶來價值的前提下，儘可能將需求控制在必定範圍內並儘可能簡單。
2）提高軟件的設計能力，讓項目的總體工做量降低。

若是項目小組能力不足，而且不重視上述兩個方面，那麼這個計劃怎樣寫都是寫很差的，寫計劃不是紙上談兵啊。

而一般狀況咱們的工期是限死的，因此咱們的計劃是「倒推法」寫出來的，計劃中的關鍵節點基本上經過倒推法已經卡死，咱們能作的事情就是想辦法讓事情變得更簡單、工做量更少和提高咱們的能力，以便在工期內完成項目！

因此計劃及計劃跟蹤的問題，並非僅僅本篇就能解決的，你還須要再認真看看前面的幾篇文章，理解項目的」各項工做「是作好計劃的根本。

法則1：項目管理首先是一門技術活

做爲新上任的項目經理，如何寫計劃指導你們工做呢？

首先請作這兩條自測題：

1）你熟悉這個項目需求嗎？
2）你熟悉這個項目須要用到的開發語言、數據庫和相關技術嗎？

若是上述兩條題目的回答都是NO，你是沒法開展工做的。

軟件項目管理首先是一門技術活，若是你不懂需求、不懂技術，你將會：

1）沒法拆解工做；
2）沒法和項目組成員溝通；
3）沒法與客戶溝通。

固然大部分項目經理是技術出身的，這方面的問題就不太嚴重；但有些項目經理是「外行」出身的，若是又不肯意去學習需求和技術，那麼只能說祝你好運了……

法則2：項目經理須要周身刀而且每把刀都要鋒利

中國的項目經理，一般要幹如下事情：

1）項目管理（這個不用說了，廢話）；
2）需求分析與管理；
3）軟件設計，包括數據庫設計；
4）寫代碼；
5）測試軟件；
6）和客戶溝通；
……

或者這樣說會更合適一點，項目經理不幹的事情有哪些？結果你發現：沒有！

項目經理必須是全才，並且各方面能力都須要首屈一指！

固然你會說：你當我是齊天大聖啊，能夠三頭六臂地幹活！

如下一些實用建議供你參考：

1）有機會要儘可能每方面都學習一下鍛鍊一下，項目經理確實是須要全才；
2）若是項目規模不大，那麼你一我的兼任」管理+需求+設計」是能夠的；
3）若是項目規模比較大，你能夠兼任「管理+需求」或「管理+設計」；
4）哪怕項目規劃超級大，不建議你幹「純管理」的事情，你至少要兼任「管理+需求」。「純管理」實際上是幹不了事情的，還須要其餘人「服侍」你，你才能「純管理」。

法則3：積極提高項目成員水平

我作過這麼多項目，沒有試過項目小組從一開始具有了完成這個項目所須要的所有能力，這種狀況估計之後也不會發生。提高項目成員的能力和水平，是定期交付的重要因素，甚至是決定性因素。

員工離職的兩個重要因素，一個是薪金，另一個就是學不到東西。項目經理可能還沒法直接提高項目成員的薪金，但你能夠創造學習機會和環境，甚至是親自傳授知識給項目成員，讓他能夠學到提高薪金的技能。若是你的下屬離職了，緣由是一直學不到東西，那麼大家兩個能夠抱頭痛哭了！

法則4：應對變化的最好辦法就是計劃

計劃趕不上變化，因此計劃寫了也沒有用！果真如此嗎？

你可能以爲軟件項目「兩大限死兩不肯定」很恐怖，其實有更恐怖的項目呢，那就是戰爭指揮！

打仗要不要寫做戰計劃？戰爭中信息變幻無窮，你會由於這樣而不許備做戰計劃嗎？狀況越複雜，不肯定因素越多，其實越須要計劃！

法則5：估不許總比不估算要好！

估算很恐怖，不少人不肯意估算，主要緣由有：

1）「兩大限死「，估了等於沒估；
2）「兩不肯定」直接致使沒法估算；
3）估算就是一種承諾，我可不肯意本身限死本身啊。

其實在咱們軟件開發屆，估算誤差達到100%是很常見的事情，甚至是200-300%都很正常，但若是不估算，你的偏差就是無窮大！

勇敢的跨出第一步，估不許總比不估算要好，估算和實際工做量之間總會有個譜，只要跨出第一步，咱們就有改進基礎了！

法則6：計劃須要近期細，中長期粗，並持續細化和優化

曾經負責某項目，項目工期3個月，領導要求我寫出3個月的詳細計劃。我很鬱悶，死活寫不出來，我不想紙上談兵、不想浪費時間寫這些沒有用的計劃，因此我還去和領導理論這樣的作法是不合理的。軟件項目存在這麼多不肯定因素，通常來講幾周後的具體工做是很難計劃出來的，因此法則6很重要。計劃並非僵化的東西，須要持續細化和優化。

其實比較怕遇到外行的領導，外行領導監督工做的辦法就是讓你寫計劃，而後根據你的計劃來檢查你，而這個計劃的工期是卡死的。若是有人用這個你無奈而寫的計劃來卡死你，你確定不肯意寫這樣的計劃。

開明的領導是這樣作的：

1）計劃寫出來了，我會全力支持你完成計劃，包括：提供各類資源、協調各部門、協調客戶等等；
2）計劃能夠變，能夠推遲，但你要儘早告訴我；
3）我不會用計劃做爲你工做成績的檢查標準，也不會以此來績效考覈。

法則7：人人都是項目管理者

不少項目經理都有這樣的感觸：好像整個項目小組當中，就只有本身最緊張項目的成敗，其餘人的心態就是完成工做的打工心態。其餘人彷佛曆來不會主動彙報工做，主動思考項目的風險與問題等。

項目管理是每個人的事情，而不只僅是項目經理的事情，每個人至少須要作到：

1）全力完成工做，要保證工做質量；
2）要主動報告進度，遇到風險和問題要主動提出來；
3）要主動管理好本身的工做產品；（作好本身工做產品的配置管理）
4）要主動協助同事完成工做；
5）要主動溝通。

每個人至少要作到能管理好本身的工做，若是本身的工做還須要別人來管理，這樣的工做水平是不及格的！

法則8：計劃的執行在於每一天！

咱們都知道如下大道理：

1）項目的問題都是經過一每天積累的；
2）問題越早發現，解決成本越低。

但咱們每每在計劃跟蹤上節省時間，結果得不償失，在臨近項目死期（發佈日），進入正式測試階段時問題大爆發：

1）某些需求沒有實現；
2）某些缺陷沒法改，須要改動數據庫底層或軟件架構才能搞定；
3）軟件總體的用戶體驗不好，但這些問題已經遍地都是了，沒有時間去改；
4）一大堆不符合編碼規範的代碼；
……

天天的計劃跟蹤能解決上述問題，而且能加速項目成員的能力提高。

跟蹤計劃的最有效方法是眼見爲實，就是直接編譯程序看看運行效果，同時檢查代碼與數據庫實現。

法則9：通用項目管理知識的對項目的幫助不大

我在大學時曾經學過「施工進度管理」的課程（我大學學的專業是城鎮建設），當時學了不少項目管理的知識，例如：前置任務後置任務、關鍵路徑、單代號網絡圖、雙代號網絡圖、甘特圖、流水施工等等概念，開闊了很大的眼界，發現項目管理確實是一門高深的學問。後來個人課程設計就是要寫一個施工進度計劃，我紙上談兵地完成了這個課程設計，結果我感受良好，覺得本身就是項目管理大牛了！

幸虧我舅父給我潑了冷水，讓我浮躁的心安靜下來。當時舅父帶我到某建築工地見識一下，我見到工地的辦公室中有一張很大的甘提圖（進度計劃），我問這個圖有用嗎？我舅父說：這個圖只是擺出來應付檢查的！

從事軟件研發工做後，儘管我學過一些項目管理知識，但確實發現這些知識對項目管理基本上沒有實質性的幫助。剛學習時，你確實會有「哇呀」這樣的感受，項目管理竟然能夠這樣！實際上若是你沒有豐厚的一線研發工做經驗，軟件項目管理是作很差的。

關於通用項目管理知識的學習建議：

1）公司報銷或者你是土豪，而且你有不少空餘時間，建議去考一考PMP，這個過程仍是學到一些知識的；
2）沒有銀兩，但你有不少時間，能夠去自學一下，考證就不是必須的了；
3）這些通用的項目管理知識不要硬套到軟件項目上。

還有會有SQA篇、SCM篇和維護篇

以前剛寫完「實施篇」的時候，有朋友問何時寫「SQA篇」？

確實我原來沒有計劃寫「SQA篇」，「計劃篇」就是最後一篇。

但計劃趕不上變化，計劃是能夠調整的！我打算未來再爲你們分享SQA篇、SCM篇和維護篇。

你有任何想法和建議，歡迎提出來！

做者：張傳波

創新工場創業課堂（敏捷課程）講師

軟件研發管理資深顧問

CMMI首席專家

《火球——UML大戰需求分析》做者

www.umlonline.org創辦人