從4月份開始，由於備考《系統整合專案管理工程師》的原因，部落格沒有持續更新，在上半年考試結束之後，又對專案進行了一些收尾的工作。下面就這段時間的學習作一個記錄和總結吧。

在學習的過程中，提煉了一些自己認為比較重點的內容進行整理，在專案管理的五大過程和十大知識領域中，其中所囊括的內容可應用到所有的行業中，專案管理的知識具有通用性和適用性，比如土建工程的專案可行性研究報告和資訊系統的專案可行性研究報告其輸出基本一致。

在一般的系統整合專案中，當一個專案啟動後，要進行需求分析、評審、管理等過程，在政府性的採購專案中，這些整合工作都會按照正常流程在進行，一步一步的把專案進行持續交付，直到收尾，這是一個相對規範的過程。

由於目前我國網際網路行業的迅猛發展，大量的系統整合專案人員大量進入了私營企業內部進行工作。並且，由於國家喊出“大力創新、萬眾創業”的口號下，千千萬萬的專案就此落地開花。

網際網路專案只爭朝夕，時間就是生命，一個創意從靈感突現到寫下第一行程式碼，可能就是在一天之內；市場，並沒有留給創業者太多的思考時間，繼而進一步擠壓了專案管理的空間；從而導致倉促立項、野蠻開發、後期維護BUG不斷，甚至導致專案流產。當初的團購網站，從一夜之間百花齊放、藍天碧海，到最後永珍俱滅、一地雞毛，留下美團一家獨大，這為我們從專案管理的角度進行研究提供了很好的素材和經驗。

快速開發迭代的能力背後是龐大資源的支援，人力資源管理、成本管理、質量管理、干係人管理，在獨角獸的背後，是貪婪的資本運作。

但是無論如何，成功的專案的背後都是藉助於龐大的資源，獲得大量的工具支援，然後提供強勁的輸出結果。在五大過程和十大知識領域中，包含了一個很重要的工具和技術，就是“專家”支援，比如政府採購專案中，技術專家的評審必須佔評標委員會成員席位的2/3以上，這是硬性指標。藉助專家在系統整合專案管理領域的專業知識，確保專案高效、穩定、規範的進行運轉。

快速迭代是把雙刃劍，在龐大的資源面前，快速迭代就像裝上了渦輪的汽車，其迭代能力得到進一步的提升，運轉效率也更高，專案文件、報告、配置都得到了很好的提升和保障，但是對於上面提到了倉促立項、野蠻開發；這種型別的專案通常也打著快速迭代的口號、由於缺乏資源的支援，大量的削減了專案執行過程，比如不作專案可行性研究詳細報告，甚至不作可行性研究初步報告，僅憑腦子裡面的靈光一現，就馬上投入資金、專案強行上馬，這可能就是系統整合專案行業中自嘲的：我有一個很好的想法，就差一個程式設計師了！

很多時候，上面的自嘲並非玩笑，比玩笑更可怕的是，這個玩笑是真實的存在。在這種背景下，系統整合專案管理具有非常迫切的現實需求意義。

在很多私營企業中，很多時候都是老闆一言堂，說幹就幹，而且要大幹快上；專案管理的過程在這些企業中就像笑話一般的存在，並且由於“全棧工程師”的原因，系統整合的開發人員通常身兼多職，既是裁判員也是運動員，少部分系統開發人員本身也並不具有專案管理的思想，他們一心只想著完成老闆的要求（並非需求），然後拿到工資，至於是否規範、以後怎麼樣，天知道，大不了辭職一走了之。

他們不知道什麼叫CCB，換句話說，老闆就是CCB，在這樣的企業中工作，老闆就是狂風暴雨的大海上漂泊的一葉小舟，風雨飄搖，顧不了太多，該扔的不該扔的都得先扔掉了。而有經驗的，具備良好的系統整合專案管理經驗的開發人員，他們會把這一葉小舟上的物品收拾得井井有條、在船頭漏水的時候，知道在艙底存放著修補工具，按圖索驥、臨危不亂。

溝通是一門藝術。在圖書館裡面堆砌了大量的關於人際溝通方面的書籍，用以幫助人們進行有效的溝通。

在系統整合專案中，溝通管理作為一項重要的內容被單獨列出，一個運轉良好的專案，必然是一個有效甚至是高效溝通的過程，這種對專案干係人的溝通管理，持續貫穿到整個專案的生命週期中，專案經理作為其中的紐帶，負責將整個溝通過程進行無縫的連線；對干係人的溝通，又分為水平溝通和垂直溝通，其中最為有效的方式，就是面對面的溝通，在系統整合專案中，距離不會產生美，只會帶來衝突和矛盾。

溝通的方式很多，比如常見的文件、郵件、即時通訊工具、會議、討論、通知、訪談、專家指導，溝通的線路數量隨著干係人的持續加入會成指數級上升，比如當前專案組中有5名成員，此時，溝通線路為25條，如果後續新加入4名成員，該專案組的溝通線路將會上升到61條，在如此複雜的溝通線路中，想要進行有效的溝通，就必須充分利用各種各樣的溝通管理工具，以達到溝通管理的高效輸出。

有效的溝通是解決衝突的重要途徑，衝突的形成就是有障礙的溝通，在干係人資訊不對稱的時候，就會造成資訊孤島，衝突就無法避免；另外，有效的溝通一定是妥協的結果，妥協的力量來自方方面面，有可能是專案基線的調整，也有可能是資源的投入，無論是何種結果，都需要完整的記錄到專案文件中，就像領導開會通常都是用腦子和嘴巴直接傳遞資訊，但是作為領導的助理，則必須將資訊文件化、流程化。

有一項非常重要的工作，在專案管理的過程中常常被弱化甚至被忽略，那就是專案收尾。

有些專案的收尾工作非常複雜，有些則非常簡單，但是無論如何，我們都可以圍繞專案自身，去做一些必要的工作，千萬不能就地解散，各回各家各找各媽；部分收尾工作內容具有普適性，根據專案干係人的不同，他們關注專案收尾的工作內容的重心也不盡相同。

比如建設方關注的是專案的建設質量，是否如期按照專案基線和詳細設計完成，承建方關注專案交付後資金交付，專案組內部需要進行專案總結、資料歸檔；有些專案還需要組產品交付後啟動新的工作，比如專案後續維護管理，或者是一些長期的專案，需要持續交付，直到專案的終止。

零零散散的寫了一大堆心得體會，大家將就看看