隨著各個專案實施的展開，專案各多多少少都出現了一些問題，或者是發生了事故，或者指揮和管理出現一些混亂，影響了工作目標，留下了隱患。及時總結這些經驗教訓是非常必要的，下面從專案管理角度對出現的問題和事故進行分析和總結。
1、對專案經理的現場指揮
關於對專案經理的指揮，現在感覺有些混亂。專案經理在公司時還好，方便協調和管理，但他們在客戶現場會遇到很多問題，商務的，技術的，有時還混合在一起。跟他們溝通的渠道也多，銷售、商務、老闆…… 可能就會有多個指示或者資訊傳給他們，且還不完全相同，如果專案經理個人的能力和經驗足夠，可能會處理得讓公司和客戶都比較滿意，否則，他們會無所適從。
比如去年某專案組第一次到客戶現場，發現此前在家準備的一套調研計畫完全用不上，突然變成要馬上寫出方案並交給客戶評審，作為專案總監，我怪他們沒有留出一點家裡評審的時間，所以要求往後推一推，而銷售總監則說越早評審越好。
另乙個專案組也是這樣，有關需求控制，如何跟客戶談，跟誰談，主要是銷售和專案經理在溝通，老闆也會有指示。作為專案管理部門的最高領導，我本人也不是每個業務領域都很熟悉，我在銷售、專案經理、老闆之間把話傳來傳去的，可無論哪一方，對傳遞的指示和資訊提出問題，再說出一大套實際情況如何如何，我真是有些暈。例如專案經理一直跟我說他在檢驗中心的需求調研屬於售前，是按照銷售的指示來做的。說給客戶做好需求，寫好報告便於拿下這塊。因為我對涉及的業務也不熟悉，由我來給專案經理傳達指示也真怕耽誤事。雖然我名義上應該管這些事情。
所以，還是得有必要明確哪一類問題誰做主，比如屬於客戶關係、合同範圍，專案經理就應當聽銷售的。不能教條得去進行專案管理。
上週加了個班，這也是來本公司加班時間最長的一次，兩個總監、三個部門經理加上專案組的3個人，竟然從晚上6：00一直乾到凌晨7：00！而且說起來可笑，加班內容居然是做最初級的文字校對和審核工作。因為這次是諮詢專案，最終交付物就是文件。所以客戶也格外仔細，要說我們公司規模也不算小，平時質量體系流程抓得挺嚴格，誰知還是出了錯，公司藉此一查，好傢伙，才發現很多文件都有問題，只是作為軟體企業，一般最終交付物都是軟體，客戶也沒那麼認真罷了。 總結出文件常見錯誤有：
一．
模板使用
1.未使用最新發布的模板；
2.擅自改變模板的結構或內容。
二．
檔名不規範
3.檔名中「專案編號」與《專案任務書》中確定的「專案編號」不一致；
4.檔名中缺少下劃線「_
」； 5.
記錄類文件檔案名中的日期格式不規範，日期格式應為「yyyymmdd
」； 6.
記錄類文件檔案名中的日期與檔案編號中的日期不一致。
三．
檔案封面不規範
7.技術類文件封面「檔案編號」中的「專案編號」與《專案任務書》中的「專案編號」不一致；
8.技術類文件分模組編寫時，「檔案編號」中未將可選標記「【】」刪除；
9.記錄類文件「檔案編號」中的日期格式不規範，日期格式應為「yyyymmdd
」；
10.封面中的「專案名稱」與《專案任務書》中的「專案名稱」不一致；
11.封面的審核、評審日期與相應《評審報告》/
《會簽單》中的相應日期不一致；
12.封面審核、評審人及日期未填寫；
13.封面版本號中不應寫「v
」，且應與歷史記錄、頁首中的版本不一致；
14.文件公升版後，封面的審核、評審日期與歷史記錄中對應版本的審核、評審日期不一致。
四．
頁首不規範
15.頁首中的版本號與封面、歷史記錄中的不一致；
16.頁首中的版本號仍保留模板中的版本號，未按實際文件填寫。
歷史記錄不規範
17.
歷史記錄中仍保留模板的內容，並未填寫實際文件的歷史記錄；
18.
歷史記錄中的日期格式不規範；
19.
文件公升版後，未填寫歷史記錄（檔案審批記錄、檔案變更記錄）。
六．
目錄不規範
20.
完成文件後，沒有重新提取目錄；
21.
目錄字型大小、字型不統一；
22.
目錄中存在小型大寫字母。
七．
正文不規範
23.
字型大小大小不一致，有的是小
四、有的是五號；
24.
行距不一致，有的為單倍行距、有的為1.5
倍行距；
25.
有些段落首行未縮排或縮排距離不符合要求；
26.
標點符號使用不當，且全形/
半形不分；
27.
插入時是在段前空兩格狀態下插入的，此時設定居中時實際並未居中；
28.
有些插入的中有滑鼠、輸入法等無用資訊；有些插入的上有馬塞克；
29.
有些和題注、**和**題注分在兩頁上；
30.
有些文字描述太過口語化；
31.
某些章節下未填寫內容但沒有給出原因；
32.
有些章節保留了原有模板中的說明性文字或示例，沒有刪除；
33.
如紙質簽字的文件（如評審報告、會簽單、基線申請單等），對應的電子文件未按紙質填寫完整。
八．
編號不規範
34.
標題使用混亂，且有時出現標題不連續的情況；
錯誤重複在犯
上週緊急處理了1個專案事故，說起來真是感嘆不已：這個事故居然兩個月內重複了3次，結果雖然一樣，但是犯錯的過程卻每次都不一樣。
公司嚴格執行「內，外網」制度，凡是最後要提供給客戶的軟體都必須從內網拷出，拷貝的流程極為嚴格。一般是專案經理提交 「軟體出廠申請單」 ，說明要拷貝的模組名稱和license起止日期，以及要安裝的機器mac位址。期間經過實施部、開發部、質量部、商務部的審核，公司總裁簽字之後，運維部才會拷貝出來，拷貝出來之後實施工程師還要當場驗證一把，確認無誤，才會帶到客戶現場進行安裝部署，可就是這樣嚴密的流程，竟然2個月內出了3次事故！由於最後一道審核人是公司老闆，老闆脾氣又大，出點事情就把大家抓過來痛罵一頓，搞得人人噤若寒蟬，各個緊張兮兮的，不可能不重視啊，可是偏偏還就老出事，真是邪乎了！
於是，我組織各部門認真反思總結了一下發生在該項目的問題，尤其是專案管理上的漏洞，追究責任是次要的，關鍵是要引以為鑑，後續專案不要再出現類似的事情了！
第一次事故大概在5月上旬，專案組給客戶安裝系統試執行，到了現場發現系統使用者不能登入。專案經理當時就有些慌張，因為以前未發現，想到老闆最恨已經出廠刻盤的軟體系統再重新刻盤，心裡就有些緊張。接到報告後，我安慰他，不要著急，想想原因。經查明是由於在此之前的系統版本都是啟動jboss和license兩個服務，而該專案版本為jboss和license的整合版本，只需要啟動jboss服務即可。測試人員修改了伺服器啟動規則，卻沒有及時通知實施人員，實施人員不知情，啟動了jboss和license兩個服務，導致個別license檔案衝突，系統使用者不能登入。應該說這一次的事故主要是由於以下幾點造成的：
1）專案參與人員沒有做到知識共享，資訊傳遞不充分；
2）實施人員只在測試環境對系統進行驗證，沒有充分驗證系統的有效性；
3） 實施人員在出盤這項工作中比較依賴測試部，對自己的本職工作不清晰，沒有從業務及實際環境對系統進行驗證工作；
過了不到1個月，因為修改了一些bug，第二次給客戶安裝系統時，專案經理和實施人員在現場的系統除錯過程中，發現系統中的用到的第三方軟體的乙個功能出錯，又打**報告申請重新刻盤。這一回，又是各部門一通忙活，認定為給該系統安裝的第三方軟體版本不對，經查明，主要原因在於測試提供給刻盤的第三方軟體版本與該專案所需要的軟體版本不符造成的。這次我認為跟部門領導對於員工的責任心意識教育不夠有關，明明公司三令五申，不能擅自更換軟體版本，非要那麼隨意，想換就換！除此之外，沒有將第三方軟體納入配置管理也是1大問題，版本無人管啊，也是容易亂！
近日，該專案終於要驗收了，雖說出了點事情，但總的說來，這個專案控制得還是不錯的，進度，成本和質量都還可以。出了兩次事故，我們也反覆強調注意事項，同時彌補管理上的各種漏洞，要求各個部門經理作為第一責任人。大家都想這回怎麼著也該沒事了。誰知上週我正開會呢，開發部經理神色慌張得來找我：「劉老師，***專案現場又出事了，說是license錯誤！」天！不過這次大家倒都挺鎮靜的，處理突發事故也有經驗了噢，不到半小時，就找到原因，商務人員對license生成軟體操作不熟悉，生成的license檔案不對，而不到客戶的機器上安裝是查不出這個錯誤的。前幾次都是運維部生成的license ,自從老闆要求實現「三權分立」的思想，就把生成license的工作交給了商務部。如何保證商務人員也能正確生成license檔案，還得在流程上增加一條啊！
看樣子，無論多麼完善的制度和流程都有改進的空間啊。
程式設計心得體會總結
1.需求變更時，從根本上解決問題與採用取巧的方式規避問題相比，短期來看，也許需要花費更多時間與精力。但從長期講，取巧的方式難於適應變化，需求的稍微變動可能就需要花費更多的精力，以及犧牲 的可讀性。2.方法的名字應該精確的表達方法所做的事情，它應該是方法最好的注釋。方法應盡量簡單，不應負責過多的事情，...
ngrx心得體會總結
ngrx心得體會總結 乙個典型的場景 新增店鋪商品，其中店鋪有多個，每個店鋪有不同的商品分類，商品分類可以多級！injectable export 新增店鋪商品 effect startaddshopgoods this.oftype actiontypes.startaddshopgoods pi...
專案管理之心得體會
團隊管理 1，對下屬要承諾多兌現 承諾太多而兌現太少 則給員工欺騙的感覺，使失去信任。2，要責任明確，不要把自己的任務 下放給下屬去處理，如 工作量的評估確認 讓開發人員自己估計 肯定是不準確的。3，自己有較廣闊的知識，較豐富的人生體驗 不是指工作本身經驗 這樣可使下屬員工更信服於你。4，多激勵員工...