項目管理日志

時間：2020-10-26 12:40:23 日志我要投稿

項目管理日志

　　項目管理是對一些與成功地達成一系列目標相關的活動(譬如任務)的整體監(jiān)測和管控。以下是項目管理日志，歡迎閱讀。

項目管理日志

　　項目管理日志一

　　第一周：20xx.2.28 至20xx.3.4

　　1、第一天入職事項，SQL和編碼走查

　　2、開發(fā)環(huán)境以及建構;以實戰(zhàn)熟悉，解決服務系統(tǒng)的實施反饋Bug 5個

　　3、開發(fā)環(huán)境以及建構;以實戰(zhàn)熟悉，解決服務系統(tǒng)的實施反饋Bug、新需求 5個

　　在這個過程中發(fā)現(xiàn)的問題以及需要解決的：

　　1)、編碼規(guī)范的遵守和檢查，最終能自覺地執(zhí)行規(guī)范

　　2)、系統(tǒng)界面的UI交互需改進

　　3)、開發(fā)所使用的架構尤其是在進行數(shù)據(jù)查詢、保存等操作時復雜度較大，極易出差錯;

　　4)、開發(fā)人員組成，技術熟練的人較少，依賴性比較大，自我提升和自我學習的能動性不高;

　　5)、系統(tǒng)數(shù)據(jù)字典在后臺管理沒有操作入口，維護不方便

　　針對以上的問題，解決的方案有：

　　1)、更新編碼規(guī)范，嚴格執(zhí)行編碼規(guī)范;同時代碼走查時對于編碼規(guī)范重視。

　　2)、專業(yè)人員做出UI規(guī)范標準，一套公共的樣式庫

　　3)、設計部門對架構進行選擇，在現(xiàn)在的基礎上能增加編碼的效率，同時進行培訓;

　　4)、每周可組織至少一次的技術分享會，對于新人的技術提升是很有幫助的;

　　5)、后臺基礎數(shù)據(jù)維護功能

　　4、OEC系統(tǒng)部署，熟悉掌握了系統(tǒng)部署的流程：

　　1)、獲得升級補丁列表;

　　2)QA進行Build，生成升級補丁包，拷貝到目標服務器;

　　3)在目標服務器上進行系統(tǒng)升級;

　　4)升級完成，告知QA進行測試

　　同時，了解到軟件開發(fā)的現(xiàn)在流程以及感覺到其潛在的問題：沒有或者缺少文檔是最大的浪費!現(xiàn)在的問題在開發(fā)的前期需求分析人員對于需求收集的后續(xù)工作(需求文檔規(guī)范化)沒有做到位，對于需求的描述僅僅靠一個原型靜態(tài)頁面是不夠的，需要有文檔的詳細說明記錄，全體相關人員能共同理解，不出現(xiàn)誤解。

　　還有數(shù)據(jù)字典、數(shù)據(jù)庫設計的變更也是要對相關文檔進行及時地變更。

　　認識到文檔完整的重要性和意義，相關人員要時刻把文檔作為一個工作依據(jù)這樣的重要來做。具體操作來說就是：項目內(nèi)文檔不能缺少，并上傳到文檔庫，相關項目中CVS庫。

　　需求文檔(原始需求資料收集)，需求說明書

　　設計文檔，

　　測試文檔

　　反饋文檔，測試問題列表;客戶反饋記錄。

　　項目里程碑定義模糊?對于達到或者實現(xiàn)的目標嚴格定義，不能陷入無限的迭代中。?

　　知識點學習：

　　項目管理的三個重要概念：檢查點、里程碑、基線

　　項目生命周期中有三個與時間相關的重要概念，我發(fā)現(xiàn)很多人對這三個概念理解不準確，更不知道如何進行控制。因此把這三個概念論述得比較準確的一段文字貼出來，幫助大家理解。

　　這三個概念分別是：檢查點( CheckPoint )、里程碑( Mile Stone )和基線( Base Line )，他們一起描述了在什么時候( When )對項目進行什么樣控制。

　　檢查點

　　指在規(guī)定的時間間隔內(nèi)對項目進行檢查，比較實際與計劃之間的差異，并根據(jù)差異進行調(diào)整�？蓪z查點看作是一個固定 “ 采樣 ” 時點，而時間間隔根據(jù)項目周期長短不同而不同，頻度過小會失去意義，頻度過大會增加管理成本。常見的間隔是每周一次，項目經(jīng)理需要召開例會并上交周報。

　　里程碑

　　完成階段性工作的標志，不同類型的項目里程碑不同。里程碑在項目管理中具有重要意義，我們用一個例子說明：

　　情況一：你讓一個程序員一周內(nèi)編寫一個模塊，前 3 天你們可能都挺悠閑，可后 2 天就得拼命加班編程序了，而到周末時又發(fā)現(xiàn)系統(tǒng)有錯誤和遺漏，必須修改和返工，于是周末又得加班了。

　　情況二：實際上你有另一種選擇，即周一與程序員一起列出所有需求，并請業(yè)務人員評審，這時就可能發(fā)現(xiàn)遺漏并即時修改;周二要求程序員完成模塊設計并由你確認，如果沒有大問題，周三、周四就可讓程序員編程。同時自己準備測試案例，周五完成測試;一般經(jīng)過需求、設計確認，如果程序員合格則不會有太大問題，周末可以休息了。第二種方式增加了 “ 需求 ” 和 “ 設計 ” 兩個里程碑，這看似增加了額外工作，但其實有很大意義：首先，對一些復雜的項目，需要逐步逼近目標，里程碑產(chǎn)出的中間 “ 交付物 ” 是每一步逼近的結果，也是控制的對象。如果沒有里程碑，中間想知道 “ 他們做的怎么樣了 ” 是很困難的'。其次，可以降低項目風險。通過早期評審可以提前發(fā)現(xiàn)需求和設計中的問題，降低后期修改和返工的可能性。另外，還可根據(jù)每個階段產(chǎn)出結果分期確認收入，避免血本無歸。第三，一般人在工作時都有 “ 前松后緊 ” 的習慣，而里程碑強制規(guī)定在某段時間做什么，從而合理分配工作，細化管理 “ 粒度 ” 。

　　基線

　　指一個(或一組)配置項在項目生命周期的不同時間點上通過正式評審而進入正式受控的一種狀態(tài)�；€其實是一些重要的里程碑，但相關交付物要通過正式評審并作為后續(xù)工作的基準和出發(fā)點�；€一旦建立后變化需要受控制。

　　重要的檢查點是里程碑，重要的需要客戶確認的里程碑，就是基線。在我們實際的項目中，周例會是檢查點的表現(xiàn)形式，高層的階段匯報會是基線的表現(xiàn)形式。