寫專案計畫是乙個非常考驗專案經理工作能力的工作，既包括了專案的客觀規律，也是在拼專案經理的工作經驗。這個行業門檻低，大家都可以學習了pmp或者prince2以後，嘗試一把去管專案，但是管的好不好，成功不成功，這個真的就是仁者見仁智者見智的事情。
寫專案計畫是個技術活，可能真的沒有你想的那麼容易。因為專案可能會有多目標你沒有辦法平衡，可能進度要求不明確或者不合理，人力資源緊張或者沒有合適的人力，採購的裝置不清楚型號和數量，專案簽訂的合同不知道是否能夠包的住專案成本，客戶的甲方人員說不清楚需求，配合專案的程度也不高，更像是嗷嗷待哺的嬰兒一樣要你手把手帶。
很多資深的經理人都告訴你做計畫多麼重要，然後告訴你什麼叫做pdca。這些道理我就不要贅述了，我們直接進入正題。 如果你公司或者組織的管理能力沒有很高的成熟度，也就是管理專案有章法，有方**支援的，ok，接下來我跟你講的事情就很關鍵了。
一、不要去羨慕那些高階大氣上檔次的工作計畫，實用就好
我看見過很多專案經理做出華麗炫目的甘特圖，用project做出結構化的wbs，也有excel隨手做的任務清單，也看見過在redmine和禪道裡面管理的敏捷工作任務。也經歷過和一位善用word文件寫工作規劃的領導，有人跟我說這樣做真的好土，一點都不專業。這些都是形式，只是看懂計畫的人是不是直觀或者吃力，跟你寫出乙份好的計畫並沒有很強的關聯關係。
寫計畫一般按照緊急程度和你所掌握資訊的詳細程度，你可以把它們分成短期計畫、中間計畫、長期計畫。管專案其實是乙個專案資訊明晰化的過程，是場資訊戰，你能夠掌握的資訊越多，你獲得勝利的可能性就越大，有人說這是漸進明細，確實，我只對我最近要做的事情清楚。
如果你沒有參與售前和需求的調研工作，你可能在專案的早期因為獲得的專案資訊非常少，你只知道有乙個專案的結束時間，是乙個什麼性質的專案，比如說產品實施專案、合同開發專案，運維專案，研發專案。然後你要準備乙個通訊錄把你知道的干係人的****記錄到你的筆記本或者**簿，跟需求方簡單地寒暄了幾次，你可能就要開始動工啟動專案。
這個時候，你最需要的是做乙份比較符合現狀的短期工作計畫，包括了什麼時間、地點、誰誰誰拜訪哪些專案的相關人員，詢問他們什麼問題，如果有疑問下次需要緊急聯絡的方式，需不需要做文字記錄等。我以前有個同事覺得這個工作真的很傻帽，為什麼這種看似是需求調研的工作要去做乙份計畫出來。但是實際的情況是，我通過這份計畫，可以看到我是否訪問過了所有的干係人，我使用的調查方法是否合適，並且對他們展開的問題是有針對性的，那麼我獲得的資訊才是有效的。
在我沒有掌握到足夠的資訊能夠撰寫出乙份支撐專案的工作計畫之前，那麼乙份臨時的短期的調研工作計畫是必須的。這份工作計畫可能只能支撐我的工作一周或者甚至更短的時間，但是我獲益更多的是我已經在專案早期對我的干係人所做的工作都有了記錄，我可以在後期的工作中補充我前期沒有做到，遺漏或者忽略的一些細節，有助於我的工作完善起來。ok，這個計畫對我是夠用的，沒有必要在乎別人的看法。
二、認真分析你所知道的各個細節，盡量考慮你能承受的意外損失
1.招標書和投標書上面的技術指標要求，工作建設範圍。
2.合同書上專案的里程碑進度要求、付款要求、質量要求。
3.被調研的人員的範圍陳述是否超過了你所知道的專案邊界。一些很容易被忽略的問題，比如：資料錄入工作是否甲方人員完成，系統管理員是否需要甲方的專人負責。
4.專案的驗收要求和是否培訓、運維等後期工作。
5.需要採購的裝置和**商要求，到貨日期和安裝日期等。工作場地的要求。
6.專案結束時需要提交的文件、**、裝置等要求。
7.法律法規的特殊要求，或者甲方提出的特別要求，比如:技術平台的要求，伺服器作業系統的要求，保密性和安全性的要求等。當然了如果你能把一些非功能需求調查清楚你可以申請效能測試的工程師，或者設計高效能結構的設計工程師。但是前提是你要把這些資訊調查清楚。
8.變更的方式和確認的方式。這也是小白們經常踩踏的乙個坑，客戶提什麼就接納什麼，對於那些信奉客戶就是上帝的人來說，服從了上帝的命令，上帝就會讓你去天堂跟他相會。記住，要把變更的資訊搞清楚，有可能在合同中提及，有可能沒有這種變更的規定，客戶對此一無所知。good，那麼後面你要做的計畫就要把這個問題補充上去。
9.最後再就是預算和資金的要求。如果你的專案已經簽訂了合同，你無力改變專案的收入，但是你一定要把專案的預算做清楚，這也許是今後追加費用的乙個依據，不要覺得這是個可有可無的工作。虧本賺吆喝，你要把吆喝喊出去，不然誰知道你吃虧了，對吧。
有了分析後，你會發現，好吧，其實招標檔案也有矛盾的地方，投標書也有講的不清楚的地方或者根本做不到的環節，甚至是哪個傻叉商務籤的合同，這完全是客戶的霸王條款。所以為什麼乙份好的專案計畫非常重要，你要把這乙個乙個的坑全部都填上，直到專案結項，專案經理真的不容易，你不再是個從技術人員提拔上來的coder，你現在是乙個manager。
如果你是個很樂觀的人，或者你是個沒心沒肺的人，這個時候請你悲觀一些，寧可考慮最惡劣的情況，也要把所有不利的因素拿著紙和筆都記錄下來，如果你會用思維導圖工具，能夠邀請到相關的人員做頭腦風暴，那麼請召開一場風險識別的會議，把你們能夠想到的風險都想一遍，如果做過cmmi的公司，或許會有一張風險庫的**（很多情況下這個**並無卵用），還是仔細對照看一遍自己的專案是否存在風險。因為接下來，你在做計畫的時候，有意識的會安排人員處理風險，會延長工作任務的時間，增加工作量的投入，增加交付物的產出。你這個時候越是謹慎，後面你踩到的坑就越少。
好了，下面你就要開始做專案的估算了，這樣才能做出乙份長期和中期計畫。你會用到軟體的生命週期模型或者敏捷方法。
如何運用專案管理思維制定工作計畫
我們都知道，專案管理的過程包括了啟動 計畫 執行 監控 收尾五個階段 那麼同樣的，我們也可以把工作計畫當做乙個專案來進行管理。我們都知道，專案管理的過程包括了啟動 計畫 執行 監控 收尾五個階段 那麼同樣的，我們也可以把工作計畫當做乙個專案來進行管理。工作計畫的啟動階段，要想清楚想做什麼 怎麼做等這...
如何做好軟體專案的驗收工作
專案驗收是公司乃至每個專案成員都想要的結果，一旦驗收對公司來說就是，可以收驗收階段的款了，不需要再投入那麼多人力到專案當中，專案終於可以告一段落，大家都可以輕鬆一下了。專案驗收是一系列細緻工作完成到位的結果，而不是某一點的成功或某個人能力就可以促成的事情。乙個專案的驗收，一般是由一系列驗收準備工作組...
軟體測試 測試用例 如何寫好乙個用例
測試用例 test case 是為某個測試目標而編制的一組測試輸入 執行步驟以及預期結果的集合，以便測試某 個程式的路徑或驗證軟體是否滿足某個特定需求，那麼怎麼寫好乙個用例呢？測試用例 test case 是為某個測試目標而編制的一組測試輸入 執行步驟以及預期結果的集合，以便測試某 個程式的路徑或驗...