每一項工作都應該去總結，而作為專案負責人和主要開發人員的我需要對此做總結，是十分必要的。
先跟大家報告下該專案總體狀況。
1. 參與人員，專案經理培訓生、李浩然、馬娟
2. 專案週期：2012-12-26-2013-02-06
3. 出現的問題
1) bug多,issue多，投訴多
2) 使用者體驗不好
3) 專案流程管理失效
專案負責人需對專案負全部責任，而我作為專案負責人，有著不可推卸的責任，在管理期間對此有深刻的認識。
自高奮勇的自薦自己作為專案負責人，開始自信滿滿的著手該項目的管理，認為是乙個小專案（自認不是乙個專案而是乙個模組功能而已），一開始就為專案的失敗埋下「伏筆」。樂觀地判斷專案的執行。
專案管理過程中也體現了本人管理經驗的不足，且沒有及時地尋求幫助。管理中沒有嚴格遵守專案管理流程，出現了很多問題。如團隊成員不能及時了解專案進展、需求變動過多、反饋資訊記錄混亂、開發測試流程不規範、不能及時了解團隊成員情況、實際與計畫情況差別大等等。問題是嚴重的，結果是殘酷的。想作為一名合格的專案經理，我還剛剛起步，路途遙遠而險峻，我還要掌握更多的生存之道。
就該專案我需要去學習了解記住下面的問題：
主要開發人員和專案負責人不能為同一人，易矛盾。
兩者為同一人時，開發人員在遇到問題時會使專案設計向開發妥協。應此需盡量避免兩者為同一人。如果為同一人的情況下需要為開發留下足夠的時間，讓兩者工作合理並行。
1.了解團隊成員特點，有效調整資源分配
日常關注成員，主動增加交流機會
2. 可以延期來保證產品質量
不能拿質量開刀，定期公布專案進行，每日例會能促進專案如期進行。
3. 不要依靠郵件記錄問題，郵件只用於溝通，及時的將問題存入相應的文件中
4. 作為專案經理需要充分掌握需求
開發中需求的變動與專案經理對需求的理解程度息息相關。
5. 學會調動資源
有可利用資源時可以利用，在遇到一些難題時最好能及時想到借助其他資源
6 晚上加班的工作效率不高
永遠別拿「加班」開刀
從郵件中整理文件或者到最後整理文件資訊是痛苦的，也必定導致資訊的丟失
8. 工作中多問永遠不會有壞處
多問問題是好孩子，孩子問問題別人樂意指導，多次問同性質的問題值得思考
9. 分配任務時明確責任人和交付時間
10.產品的成功 取決於使用者的滿意度，在產品任何階段都要及時的和終端使用者溝通
11 會議經驗：
1.會前確定會議內容，安排好內容進行順序。
2.沒有整體掌握專案，做到心中有數，可能導致會議不可控
3.需整體掌握專案進度，對工作量、專案週期等做到心中有數
1.在關鍵時刻（如：出現討論激烈難以有結論的問題）需快速暫定，會後討論
2.會前讓參與人對會議流程有整體了解
3.結束會議時需及時在過一遍會議內容，以達共識。
4.結束會議時可告知下次會議內容
1.自我總結與會議內容整理
2.跟進會議待確認內容
由於自己是專案負責人，因此放縱了作為開發人員的我。沒有按照以往開發的標準要求自己，只想快速完成任務給測試人員測試，有bug時再修改。結果可想而知。
自己需要學習了解記住下面的問題：
別給自己雙重標準，出自自己之手的開發任務都要給出高質量，不能區別對待
對於開發時間的估算，不能認為功能很簡單，開發時間必定很短。作為前端開發人員需要給自己預留更多的時間以處理特殊情況，一般可以在估算有時上再加2倍時間作為可答覆的開發計畫用時。
質量第一，即使超期也要保證質量，不要為趕進度而完成開發。需要時刻記住自己的質量信譽。
雙重身份的自己，每個身份都沒有做好。但我信心依舊，我相信一路走下去，我的腳步只會越來越穩，越來越優美，感謝在路上幫助我的人，指出我不足的人，謝謝你們。因為你們，我才能更好的成長。
-----------------------------------------end------------------------------------
專案的需求管理 個人的理解
2009 03 23 需求管理可以很粗泛，但是認真地一條條死扣的話真的會增加好多任務作量。需求管理也是專案管理中的一種手段，在最早期與客戶達成一致的目標，為的是讓專案越走越順暢。如果一味流於形式，流程，投入工作的人卻還不明白需求管理的要義，那麼就是在浪費本來就緊張的資源 所以說需求管理要做到什麼程度...
需求管理之專案中如何更好的控制客戶需求
凡是做過不止乙個國內的專案的專案主管人員可能都經歷過這種場合 公司的銷售人員興沖沖的拿來乙份與客戶簽訂的合同交給你，聲稱這專案又搞定了，但是當你拿過來合同 或者任務委託書 一看，關於專案範圍的說明只有寥寥數行，要麼是一些高舉高打的套話，要麼只說專案都包含什麼樣的模組，而對具體的業務只是一兩句話就完事...
面對客戶需求變更該怎麼辦？結合專案管理總結幾點
本人負責pdu專案配置管理系統的開發，全面負責配置管理系統功能的需求分析，開發設計，功能驗證及整體的聯調。專案在開發將近完成的時候，客戶與產品經理溝通需要變更需求，產品經理將更改的需求跟我溝通了下，我和底層人員溝通並分析了需求變更的可能性及工作量，後來感覺問題不大就直接開始變更設計。等到開發完成後將...