1.項目需求清楚嗎？

需求的部署環境：這個很重要，弄清楚客戶的部署環境，才能很好地開發。

需求的里程碑：一般分為幾個里程碑，比如一期，二期等，或者幾個關鍵流程的某個流程走通。

對需求進行分類：重要，一般，次要需求。這個在項目的不同周期可能發生轉換。

是否畫出了流程圖，用例圖等來表示項目的關鍵需求。

有沒有對需求進行細化，也就是需求點的分解。

對需求變更有沒有進行處理，這個如何與任務計劃和安排進行聯動，對計劃始終進行***的控制，完全體現在報表上，而不是口頭上，這個需要一個系統，記錄需求的變動歷史記錄。

需求占項目的的40%也不為過，這個過程很重要

有沒有出原型設計，有沒有需求說明文檔

需求要與計劃，安排結合起來。

是否有需求管理和需求變更管理系統，這個與任務安排，系統每日構建是連在一起的。

需求管理應該是分模塊的，分功能點的，細化到不能細化為止。

先做功能，優化次之，但是最基礎的功能做完，也要有最基本的用戶體驗，而不是錯誤的不可用的，或者體驗差的。

需求弄清楚，技術架構才好做，包括硬件和軟件部分。

需求清楚，才知道找合適的人來做合適的事。

哪些需求完成，哪些需求不確定，哪些需求有變化，哪些需求不做了，都清楚嗎

2.源代碼管理清楚嗎？

是否用源代碼管理

是否進行每日構建

是否是完整的源代碼管理，每個人看到的是全部，而不是部分，有的公司并沒有正確應用源代碼管理，各做各的。

從源代碼管理下載的一定是最完整最正確能順利運行的系統嗎？

源代碼進行了權限控制碼

源代碼管理有分支的備份嗎

從我們的源代碼到上線發布能一步完成嗎

有規范統一的開發，測試，檢測標準

數據庫是一個人主力負責維護嗎

統一部分的代碼，核心代碼是一個人在做嗎

3.項目的Bug清楚嗎？

對待Bug的處理原則：發現一個處理一個，絕不拖到第二天。

需求管理和Bug管理應該是連在一起的，對應到需求管理的模塊部分。

在開始新程序之前，舊有的Bug是否已經清除，應該盡量避免返工。

有清楚的Bug列表，有人進行跟蹤，監督，檢查嗎

對于暫無法修改的Bug，后期有進行研究和更新改進嗎。

4.項目跟蹤清楚嗎？　

項目需求內容，開發日程安排，開發進度，跟蹤監督能反映在一個明確的地方嗎，讓管理員，程序員，客戶等都能一目了然的看到，而不是讓項目管理計劃與進度形同虛設嗎？

項目的需求點，模塊，功能，具體的功能點，變更記錄，計劃時間，完成時間，負責人，整個項目的情況應該是一目了然的。

項目流程的制定和執行清楚嗎

代碼和功能的走查在做嗎，有在進行跟蹤和監督嗎

項目人員的績效就是來自于任務的完成情況，工作態度，以及跟蹤的報表中

項目質量，樣式規范，代碼和開發規范，測試要求和規范清楚嗎，沒有標準參考，怎么進行質量跟蹤呢？

5.每個成員的任務清楚嗎？

模塊，功能點責任具體到人，誰負責誰承擔責任

成員間交叉開發，以防成員變動帶來的煩惱

優先解決成員的問題

有對成員進行技術講解和知識培訓嗎

有進行項目成員每日工作日志的記錄嗎，這個工作日志記錄應該與工作計劃安排是差不多的，不過即使這樣，也是要項目組成員去填寫的，每天至少寫個兩條以上。

工作周報和月報有時候還是很需要的。

指標管理未必不適合我們，什么人什么時間，完成什么功能，記錄數量和時間，就可以得出單位時間開發的效率。同時也可以算出Bug率，這樣都是衡量工作的指標

項目成員之間溝通方便嗎？

工作計劃的安排和變動，有成員的參與嗎？

目前某個人在做什么，前面在做什么，后面要做什么，完成的怎么樣，清楚嗎？

6.溝通清楚嗎？

團隊的每日或每周溝通，應該定期溝通，隨時溝通用，讓小組成員放心，安心。

客戶用戶的溝通，客戶溝通人必須唯一，引導用戶，匯報進度，讓客戶放心，安心。

上級的主動匯報溝通，看進度，提問題***提出自己的解決方案，爭取資源，讓老板放心，安心。

項目組外的統一溝通，設定一個跟其他組的統一溝通人，提前溝通，同樣需要跟蹤和檢查，確保無誤，讓合作伙伴放心，安心。

列出所有需要溝通的問題點，溝通人，溝通時間，溝通結果

總  結

一般大家都用MS Project，個人感覺并不是很好用，很多時候形同虛設，也可能是我自己不會用。

我的想法是：

最最重要的是出一張圖表，做到胸有成竹，這張圖標的內容就是：

需求【模塊，功能點，變更記錄】-->責任人【變更記錄】-->執行時間【計劃，完成，變更記錄】-->完成進度-->是否審核-->Bug列表-->是否解決，做到這個，項目管理全盤子都清楚了，那就可以輕松一些了。

當然補充一下：還可以根據人出對應的圖表：

查看這個人的工作情況和時間進度。

還可以根據時間出人和事情的報表。

這樣人，事，時間，三者進行一個組合，應該有六種類型的圖標，這是個人的想法。如果有一個類似的項目管理軟件，那就很不錯了。