概述

作者有幸獲得領導的欣賞，從一個技術人員變成技術經理，而且是大資料資料中臺的技術經理，所以學習一些技術管理知識和專案管理知識就非常必要，機會難得，對我而言意味著千載難逢，現在把最近學習的專案管理的知識分享給大家，作為鞏固和記錄。

為什麼要學習專案管理

事實上，專案管理能力，已經成為一項職場人士的必備技能。通常來講，程式設計師精進的道路大概有兩條：一條是走個人能力線，成為技術專家；另一條是藉助團隊能力往前走，成為技術管理者或業務管理者，只是這條路上的管理崗位是需要時機和坑位的，可遇不可求。但是，專案管理則很不同，只要你在一個多人協作的團隊，就一定會有專案管理的需求和機會。蓬勃興起的專案管理學習熱潮，為程式設計師開闢出第三條精進之路。而且，不同於技術管理，這條路線走起來，幾乎不需要任何外界依賴因素。一開始你甚至並不需要有組織的明確授權，你只需要在做好自己的基礎上，學會更多的專案管理技能和方法，以專案整體目標為己任，主動操心和解決專案團隊的問題，幫助團隊做得更好就可以了。如果你這麼做了，你的 leader 一定會很開心，你的技術之路也會越走越寬廣。實際上，我身邊的很多技術管理者，都非常希望自己團隊的程式設計師能夠具備專案管理的 sense 和能力。在許多公司，已經有越來越多的主程開始承擔專案管理職責，在他們的績效考核中，也會明確寫入一定比例的專案管理責任，這種型別的專案負責人已經逐漸成為組織中的中流砥柱。具備專案管理能力的程式設計師，無疑會在這個程式設計師嚴重同質化的局面下，擁有更多的競爭優勢。除此之外，我認為，專案管理是新一代“進化型”程式設計師的重要底層能力。

專案管理作為一門學科，經過多年發展已經呈現出龐大的知識體系，光國際標準就有三套。就拿國內普及度最高的 PMI 標準體系來說，它將專案管理分為十大知識領域和五大過程組，共有 49 個子過程，600 多頁內容。對於很多初學者來說，實戰經驗缺乏，書本知識會顯得愈發晦澀難懂。不是所有人都可以很幸運，能在關鍵成長期遇到師傅的引導。如果你完全依靠自己去摸索，要麼在實踐中撞得“頭破血流”，要麼迷失在大部頭理論的海洋中，無法快速找到真正有效的解決之道。專案管理是科學、藝術的結合體，同時也是一門手藝。只有經過實踐操作的磨礪，你才能真正掌握使用所有框架、方法和工具的正確時機和火候。我們借用“體機用”的模型來看，“體”是本體，對應於專案管理的知識體系，比如《專案管理知識體系指南》；“用”是效用，對應於各種紛繁複雜的專案管理實踐，比如某某公司的專案管理做法。這些都是可描述、可傳授的，市面上你很容易可以找到相應的資料。但是，這些內容都無法真正滿足實戰中多樣化的學習需求。專案管理作為一門實踐科學，最難掌握的，其實是“體機用”的這個“機”。這裡說的“機”不光指時機，同時還意味著環境和條件，也就是說將知識技能和具體的“場景”相結合，才能發揮出真正的效用。

專案管理小知識，越來越發覺，專案經理必備的幾個要素很重要：
1、溝通！溝通！溝通！重要的事情說三遍，對業主、上級、下屬建設不同的溝通渠道，不同的溝通方法及頻次。
2、計劃做的好，沒啥用，也得做；風險控制很重要，提前暴露風險，做好風險應對策略。
3、臉皮要厚，敢說也得敢幹，不要怕說錯，敢於試錯。
4、讓自己成為業務專家才有更多話語權，領導力來源於崗位，能讓人尊重的更多是專業技能。
5、習慣覆盤，對制定的專案計劃出現偏差及時修正。

角色轉換

美國電影中經常有句話說，Great power means great responsibility（能力越強，責任就越大）。專案管理這個崗位，讓我從管好自己的事，到開始操心別人的事，責任範圍一下子擴充套件開來。這種責任範圍的擴大，極大地鍛鍊了我的全域性分析能力、統籌規劃能力、以及溝通協調能力。但由於並非天生適合跟人打交道，剛開始時，我絲毫體會不到什麼 power，反倒經常感覺有勁兒使不出來，被新的責任壓得喘不過氣來。正是這段經歷，讓我對想要從程式設計師轉做專案管理的同學，有了更多的同理心和體諒。結合我的經歷，我把這個轉換過程中常見的問題，歸納為以下三大誤區：

誤區 1：凡事恨不得事必躬親

當我做程式設計師時，我的工作是高度可控的，我可以把每天的工作安排得井井有條。但在做專案管理之後，我發現自己的產出全部依賴別人的工作，於是我會經常性地陷入一種抓狂的狀態，著起急來，甚至會忍不住衝上去，替別人做好人家本該做好的事情。但是，後來我慢慢地意識到，對於團隊長期的發展而言，這種行為的效率是最低的。可當時的我，跟自己直接去做相比，想辦法影響他人去把事情做好，要難得多。那麼，如何影響他人去做好一件事呢？在不斷地反思之後，我總結出了成功施加影響的三個層次，分別是讓人知道要做（Awareness）、有動力做（Desire）和有能力做（Ability）。

我曾經跟一位產品總監合作，他交待工作非常言簡意賅，團隊只知道最終輸出的指令和結論，但完全不清楚背景，更不用說明白他的思考過程是什麼，以及為什麼要這樣做了。有一次，他的下屬跟我說：“老大昨天晚上突然給我打電話，讓我馬上把就要上線的活動停掉，不要再做了。”他非常困惑，因為團隊已經投入了一個月的精力，馬上就要見到成果了，但沒等他問為什麼，老大就直接把電話掛了。這樣的團隊，聽上去應該執行力不錯，老大的指令都會被立馬執行，可事實卻並非如此。我發現他們完全談不上有做事的動力，很多時候都只是照章辦事，出了問題也不敢去問，結果往往導致執行效果與預期相差甚遠。對照剛剛我們所講的三個層次，這應該只是第一個層次。單方面的工作交待和告知，停留在淺層次的資訊傳達上，只是讓人知道要做，但並不足以讓人產生動力，去促成有效的行動。

事後我瞭解到，這位總監之所以著急叫停，是為了規避短期的政策風險。在我和他溝通之後，他主動找來這位下屬，講明瞭自己的意圖。隨後，他們一起制定了一種合理的策略，經過調整之後，這個活動還是如期上線了。這個例子告訴我，在把工作授權給別人時，對於動力（Desire）的關注尤為重要。講清楚為什麼要做，為什麼要現在做，獲取理解及認同，激發團隊的動力是專案經理成功授權工作的關鍵。在動力的基礎上，你還要確保你所選擇的人有相應的能力來做到這件事情。如果現階段的團隊都沒有對應的能力，該怎麼辦呢？專案成功關鍵路徑上的核心能力缺失，是你作為專案管理人員，要當作最高優先順序的風險管理的事項。

從外部引入相應的人才，是最直接有效的方式。除此之外，你還可以去積極爭取短期借調、內部轉崗等。從長期來看，你還需要有意識地發現和投資那些團隊中最有潛力的人，給他們安排相應的工作輔導，開展有針對性的培訓等，幫助專案組成員發展相應能力，讓事情真正落地。以上，就是授權工作時，成功施加影響的三個層次，從讓人知道要做、到有動力做，再到有能力做。

誤區 2：追在別人屁股後面做監工

在我做專案管理的第一年，經常會有種“趕鴨子上架”的無奈。通常情況下，我會在心裡設定一個目標，然後費盡心力地把大家往一處趕，但往往我趕得越是賣力，鴨子們就越是跑得到處都是。其實，專案經理最該做的，不是每天逐個人逐條事項的監督，而是要明確目標，建立機制，並讓這個機制運轉起來，最終在專案組形成一種良性的秩序。

比如，專案經理要帶大家一起開啟動會，清晰願景目標，定義階段里程碑和完成標準，接著制定分段執行的計劃，把事情的所有環節從頭到尾捋順了；專案經理要建立上下游協同的流程規則，明確各個角色在整個過程中的職責，獲得大家的認同和共識；專案經理還要建立站會、週會等制度和模版，讓進展和風險通過這些良好設計的資訊渠道匯聚，藉助規則和工具來達到監控的目的。我會在接下來的內容中，把我的經驗系統化、分步驟地傳遞給你。這裡你需要記住的是，專案管理並非要讓你成為監工，要始終依靠流程和規則來約束大家的行為。當成熟的秩序在團隊中形成之後，從日常瑣事中解放出來的專案經理，就可以集中精力去做願景驅動、激勵團隊等更高層面的工作，真正做到變“趕”為“引”。

誤區 3：拿著錘子，看哪裡都是釘子

我曾經見過一位新官上任的專案經理，可能是因為終於得到施展的空間了，一上來就左突右攻，恨不得把十八般武藝全都套上去，結果激起了許多不必要的麻煩。開站會也好，電子看板也罷，本來都是好工具，但是如果引入過程不當或時機不對，會讓團隊產生牴觸心理，最終拿不到好的效果。看到專案中的問題，哪裡都很想修理一下，這種心情我非常能理解。但是，你要知道的是，每個專案的現有執行方式，都有它本身的背景和成因，不管現有方法是否先進，都是更加適應本土環境的。在這個課程中，我會跟你分享很多新的方法和工具。但我擔心的是，越是好學生，越有馬上上手實踐的衝動：“看到好的東西，我就想馬上在自己的實踐中嘗試一下。”如果你也是這樣，那麼，我要提醒你，先不要急，你要與專案中的重要干係人加強溝通，理清前因後果，多想想自己的專案現階段到底最需要什麼，這對專案管理方法的成功推進至關重要。每個專案都有它獨特的情境。你可以試著問自己幾個問題：

在你的專案組中，時間、成本、質量、範圍這幾個因素，到底哪個更重要？哪些是允許有一定調整空間的？

各個角色目前的痛點在哪兒？哪些是最先需要解決的？這些問題背後潛在的原因是什麼？

團隊對於這個痛點的改進是否有真實需要？需求的迫切程度如何？

你的老闆或專案發起人對於專案管理以及你本人的定位是怎樣的？關於這些問題與可能的改進，你是否與其溝通過並達成了一致？

如果你打算引入新方法或工具，更適合用怎樣的路徑進行，是自上而下地全面推廣，還是自下而上地一步步優化呢？最有可能從哪個問題切入？

總的來說：

第 1 個誤區是凡事都要親力親為。遇到事情時，你不要自己直接去做，而是要想辦法驅動他人去做好事情。在授權工作時，有三個層次，從讓人知道要做，到讓人有動力做，再到有能力做。你需要講清楚為什麼要做，為什麼要現在做，獲取理解及認同，激發團隊的動力，同時為每個任務選擇能力匹配的授權物件。

第 2 個誤區是追著別人做監工。做專案管理，不是要你變成監工，而是要你帶領團隊明確目標，建立機制，並讓這個機制運轉起來，要始終依靠流程和規則來約束大家的行為。

第 3 個誤區是拿著錘子看哪裡都是釘子。每個專案的現有執行方式，都有它本身的背景和成因，你要與專案中的重要干係人加強溝通，理解前因後果，從專案和團隊當前的真實痛點出發，找到真正解決問題的方法和步驟。如果你已經走上了專案管理之路，在開始系統學習之前，你最好整體梳理一下自己所在專案組的背景情況，這將會為你之後的學習和實踐找到方向。

其他專案小便籤：
1.如果專案經理忙於瑣碎的細節，自己成為瓶頸，無法有效管理團隊，那麼團隊必然失控。很多時候專案出了問題，自己一個熬通宵解決，感覺沒有一個人幫得上忙。專案組成員都有一種事不關己高高掛起的狀態。
2.資訊中心要求使用微服務技術來做系統，受限於專案組技術儲備和業務壓力，第一階段我堅持使用SpringBoot技術+傳統技術實現，而沒有使用SpringCloud元件，千方百計確保專案關鍵模組先上線，讓業務部門看到希望，給團隊看到希望。這樣做的後果是，業務保住了，但是系統立馬面臨改造，相當於技術上做無用功，好在這些技術工作慢慢都消化在專案推進中。最後的結果是業務和技術都保住了，現在回顯起來，自己的決策應該是對的，那時我一個人基本站在了資訊中心對立面，甲方專案經理都要絕交了。事後專案上線了，執行穩定，業務部門滿意，資訊中心才慢慢改變態度，並對我的決定表示理解，說“不管是乙方專案團隊還是資訊中心都是為業務部門服務，他們滿意了，專案就成功了”。
3.在專案管理中，我通過引入日報機制（必須傳送日報）、週報（通過釘釘釋出，裡面包括關鍵使用者、甲方專案經理）、每週四釋出程式碼（開發輪著部署程式碼）、建立專案組成員工作特點清單（記錄他們的工作特點，在進度控制中採取不同策略，執行力強的人不用天天催，執行弱的人半天催一次），每週五過周計劃，然後週日晚上整理下週的計劃，並當天晚上釋出到工作群，每月階段性彙報，等機制慢慢讓專案步入正軌。
4.我總結的是：要做好一件事情：事前規劃（計劃管理）+把事情做好（質量管理）+執行力（過程管理）+有效的溝通匯報。

十大領域五大過程組

專案管理是一門古老的科學，既包含工程技術、管理技術，又與組織行為學息息相關，比如系統科學、行為科學、心理學等，同時還涉及金融、會計等經濟學範疇，逐漸發展成為了一門多維度、多層次的綜合性交叉學科。

專案管理的歷史

1917 年，美國一位名叫亨利·甘特的機械工程師，發明了著名的甘特圖，就是一張標明計劃與實際完成情況的圖表。美國機械工程師協會和管理學會曾經專門設立亨利·甘特金質獎章，並把第一枚授予了已故的甘特，當時他所享有的盛譽可見一斑。時間切換到 1957 年，美國的路易斯維化工廠。他們把檢修流程精細分解後，竟然發現，只要縮短最長路線上工序的工期，就能夠縮短整個檢修的時間。這就是至今專案管理工作者還在應用的“關鍵路徑法”，簡稱 CPM。到了 20 世紀 60 年代初，舉世矚目的“阿波羅”登月計劃，更是讓專案管理方法從此風靡全球。進入 90 年代後，專案管理逐步標準化，國際上逐漸形成了三大專案管理的研究體系，分別是歐洲的國際專案管理協會（IPMA）、美國專案管理協會（PMI）和英國的 PRINCE2 體系。我要介紹的十大領域五大過程組，就是出自在國內普及度最高的美國 PMI 標準體系。

什麼是專案管理

要登上月球，光有巨集大的想法可遠遠不夠，你還需要讓這個想法成為現實的大量資源，以及一套科學嚴謹的落地方法。“專案管理就是變理想為現實，化抽象為具體的一門科學和藝術。”這是我聽到過的對專案管理最為精闢的總結。《專案管理知識體系指南》這本大部頭可以說是專案管理領域的聖經，它的第一版是由 PMI 組織了 200 多名世界各國專案管理專家，歷時四年完成的，目前已經演進到第六版，可以說是集世界專案管理界精英之大成了。現在，就讓我帶你去看看這本書中對專案以及專案管理的官方定義。

專案是為創造獨特的產品、服務或成果而進行的臨時性工作。專案管理就是將各種知識、技能、工具與技術應用於專案活動，以滿足專案的要求。

具體來講，專案管理就是指把各種系統、方法和人員結合在一起，在規定的時間、預算和質量目標範圍內，完成專案的各項工作，對組織資源進行計劃、引導和控制。由於專案管理的知識體系過於龐大，PMI 把它分為專案管理五大過程組和十大知識領域，共 49 個子過程。今天，我們先來了解一下專案管理的十大領域。

專案管理的十大知識領域

專案管理的十大領域，將專案管理的工作內容劃分為：整合管理、範圍管理、時間管理、成本管理、質量管理、人力資源管理、溝通管理、干係人管理、風險管理和採購管理。其中，進度、成本、質量、範圍是 4 個核心領域，風險、溝通、採購、資源、干係人管理是 5 個輔助領域和 1 個整體領域，如下圖所示：

學會了這些過程方法之後，不管你做什麼，都可以按照專案管理的框架和方法去做。我們來藉助一個實際場景，幫助你更好地理解。比如，你的部門最近有大量新員工入職，同時業務發展涉及越來越多的跨部門合作，領導希望你組織一場跨部門的籃球競技活動，讓大家以最快的速度熟悉起來。接到這個任務以後，如果你熟悉專案管理十大領域，就可以嘗試從以下十個角度，快速地進行完整而有效的分析思考。

1. 干係人管理：如何管理干係人？

首先，你要弄明白一件事：在這個活動中，哪些人會是你的干係人？專案發起人對活動的預期效果是什麼？比如說增進團隊的協作，提升凝聚力等。除此之外，這個專案是否存在更多的潛在干係方，可以助力到活動的成功舉辦呢？比如，經過一番瞭解，你發現 HR 部門最近剛剛成立了團建組，很願意為活動提供贊助，那麼，這時你需要思考，如何拿到這筆贊助？HR 總監對於活動的訴求又是什麼？最後，分析完干係方之後，你要思考一下，如何更好地管理干係人的期望和影響？活動過程中的各類決定，都需要誰來拍板？干係人要以什麼樣的方式參與？

2. 範圍管理：做什麼？

分析完各方干係人的訴求，就可以進一步來劃定專案交付的範圍了。在這個過程中，你的主要任務是搞清楚到底要做到哪些事，才能更好地達成各方的期望。比如，這次籃球賽的預期目標具體是什麼？是更關注活動的參與度和投入度、部門之間的合作交流，還是活動的對外影響力？你要確保圍繞著預期目標來設計相應的活動方案，然後再進一步確定活動前、活動中、活動後分別要完成的具體工作。

3. 進度管理：花多長時間？

把理想變為現實，你需要一步一步來。進度管理，就是說你要規劃好階段性步驟，同時明確每個里程碑的目標成果和時間安排。比如，活動的總工期是一個月，那麼你可以分為四個階段來進行：

第一階段，啟動專案並確認概要方案設計；

第二階段，規劃並落實人力和各項資源的投入；

第三階段，確定具體的活動流程和詳細分工，完成活動前的各項準備工作；

第四階段，做好活動當天現場的統籌和運作。

4. 成本管理：花多大代價？

你要思考一下，活動預算有多少？資金什麼時候到位？如何使用？你要去關注整個預算中成本最高的開銷是什麼，比如是一筆價格不菲的教練費，然後，你要判斷這筆投入可能帶來的收益，也就是說錢是否用到了刀刃上？總之，你要從全域性視角去思考，如何更有效地管理專案的各項投入，以達到更加匹配目標的預期效果。

5. 質量管理：達到什麼要求？

從這個角度來說，你需要先確定這次活動圓滿成功的標準是什麼，是現場參與人數、參與者滿意度、管理者的滿意度，還是對外傳播效果？然後，以終為始，思考一下，你需要引入哪些必要的流程和方法，以保障活動效果的達成。

6. 資源管理：有多少內部資源？

你要知道，公司內有哪些核心資源是可以使用的？比如，宣傳渠道、設計人員和經費支援等。另外，公司內部有哪些人可以作為支援活動的志願者呢？公司可以提供活動所需的哪些物品？

7. 採購管理：有多少還要買？

確定了可以使用的公司資源以後，你要接著思考，還有哪些是需要外部採購？有哪些工作需要外部人員支援？如果經費受限，是否可以通過交換資源的方式，來獲取更多的外部支援？

8. 溝通管理：如何管理溝通？

從這個角度出發，你需要考慮的是，活動策劃團隊、執行團隊分別通過什麼方式來進行專案溝通？與發起人和贊助方的溝通方式和頻率是怎樣的？你如何保持團隊內外專案資訊的高效傳遞，使用什麼方式來同步進展？

9. 風險管理：如何應對風險？

你要弄清楚哪些風險可能會妨礙這次籃球賽的成功舉辦，比如天氣因素、場地因素、交通管制、贊助方經費緊張、物料供應延期、公司內外政策變化導致活動被喊停、業務壓力大導致兼職志願者流失等等。你需要提前做好系統性的風險識別，分等級制定應對策略。

10. 整合管理：如何實現整體最優？

整合管理是要告訴你，作為這個活動的大內總管，你該如何去統籌全域性，整合並協調各個環節的利益衝突和工作安排，在不斷變化的情境下，根據活動的目標“裁剪”出合適的過程、方法和工具，進行有效管理，從而達到全域性的最優效果。

看到這裡，你應該會發現，即使只是一場簡單的團建活動，想要真正把它做好，其實並不容易，你需要多方位的思考框架來指導落地實踐。有同學給我留言說，自己同時並行著很多專案，一頭霧水，不知道從哪裡著手。我剛剛介紹的這十大領域，就提供了十個有效的思考角度，包含了你能想到的專案運作的方方面面。不管是多難多複雜的專案，所包含的要素無非就是這些，你都可以借鑑我們剛剛使用的框架進行拆解，逐個梳理，快速理清頭緒。

總結：首先，我給你簡單介紹了專案管理的發展歷程，以及專案管理的官方定義。接著，藉助實際案例，我們對專案管理的十大領域進行了層層拆解。實際上，專案管理工作的涉及面非常廣。關於專案管理的職責定位，不同組織在實踐應用的過程中，給出的定義各不相同。我所在的網易杭研專案管理部，將我們多年的實踐經驗提煉總結成了 12 個字：保目標，助決策，提效能，促協作。

專案管理的五大過程組

很多人應該都聽說過 PDCA 迴圈，它最早來自於質量管理領域，意思是做任何事情，都要經過規劃（Plan）、執行（Do)、檢查 (Check) 和行動 (Act) 這四個步驟，又稱戴明環。可以說，這四個步驟提供了一個簡易的思考和做事框架。需要注意的是，這個迴圈並不是執行一次就結束了，而是周而復始、螺旋上升的。別看它很簡單，實際上，越是簡單的東西，就越是普適！

戴明環的應用非常廣泛，其中就包括專案管理領域。PMI 遵循 PDCA 的法則，將所有的專案管理活動分成了五大過程組，分別是啟動過程組、規劃過程組、執行過程組、監控過程組和收尾過程組。如下圖所示：

啟動過程組（千里之行，始於足下）

啟動過程組意味著正式開始一個專案，或者是開始一個專案中的新階段，包括識別干係人和制定專案章程兩個子過程，我們先來說說制定專案章程。啟動過程組是最容易被忽略的過程組之一，越是持有結果導向的人，就越容易馬上直奔主題去做，根本不管什麼專案章程。

最近我的一個專案經理，就遇到了這樣的情況。他的團隊中來了一位新的負責人，新官上任之後，立馬開始快速推進一個新的戰略專案。這位負責人總覺得進度太慢，就整天抓著這位專案經理不放，讓他反覆催著大家每條事項要結果，弄得他苦不堪言。在瞭解了具體情況之後，我發現，這個專案之所以推進困難，是因為大家的配合意願不高。尤其是那些涉及上下游銜接合作的環節，很少有人會主動推著往前走。究其根源，這是因為大家對這個專案有很多疑問，比如，這個專案的整體願景是什麼？做這些任務，是為了達成什麼目標？怎麼才能把這些任務和現有的工作安排得很協調呢？他們看不到專案整體，只是在完成一條條的具體任務。

這位專案經理非常有責任心，總是各個節點反覆不斷地去催，一個一個環節去推動，但他越是賣力，越覺得推進困難。我跟他說：“你這樣看似很努力，但其實這就像是拿著小鏟子推土，效率太低。就算你晚上都不睡覺，恐怕也只能這樣。”那麼，更有效率的方式是什麼呢？其實，我們在啟動一個新專案或新階段時，首先要建立專案章程，並且通過啟動會去公開確認。啟動會的作用，就好比一個大型的推土機，是面對專案組全員，正式宣告一個新專案或新階段的開始，公開確認專案章程，包括明晰各方干係人的期望和訴求，設定願景目標和重要里程碑，確定責任分工和溝通機制等。

很多程式設計師剛開始做專案經理時，思維沒有轉過來，一拿到專案，就會立刻進入分析、設計、寫程式碼的狀態，卻沒有意識到，如果在啟動會上把這些問題交待清楚了，就會省去非常多的後期溝通成本。如果涉及到跨部門的專案，啟動會就更加重要了。專案經理要積極創造一個場合，邀請更高的管理層出面，講清楚專案的背景、目標和重要性。除此之外，啟動會也是專案管理人員獲得公開授權的有效方式，可以讓你之後的推進工作更容易開展。

規劃過程組（運籌帷幄，決勝千里）

規劃過程組可以說是專案管理工作中最為繁重的一個環節了。如果說啟動是要明確目標，那麼，規劃就是要把願景目標轉化為可落地的行動方案和工作路線。對規劃過程組進行有效管理, 可以更容易地獲取干係人的認可和參與。你需要根據預期目標，明確專案範圍，確定專案的里程碑階段目標，為專案的執行做好各項準備。對於一個複雜專案來說，規劃通常是一個漸進明晰的過程，近期的規劃往往是最具體的，需要拆分到具體版本和工作項（如下圖所示），而遠期的規劃則相對比較模糊。隨著收集和掌握的資訊逐漸增多，規劃也要進一步動態細化，不斷更新。我會在第 5 講中著重講一講規劃的常見問題，給你分享一份常見的避坑指南。

執行過程組（言出必行，行之必果）

規劃做好之後，就是考驗執行力的時候了。這個階段重在整合資源，推進專案落地，完成專案管理計劃中確定的工作以實現專案目標。如果在啟動和規劃環節做好了，到了執行環節，專案經理反而會輕鬆一些。這就好比汽車在高速上跑起來之後，如果你設定了 100 碼的定速巡航，汽車自己就會執行運轉。這時，你的工作更側重於確保專案一直在正確的軌道上，確保各個環節按照規劃進行，並且能夠真正做到位。那麼，怎麼來判斷是否做到位了呢？這就要講到監控過程組了。

監控過程組（審時度勢，沉著應變）

執行並不意味著在任何情況下都要一成不變。當外界環境或內部要求發生變化時，專案管理者也要審時度勢，沉著應變，適時地調整各方，以更好地實現目標。為了做到這一點，你需要定期對專案的進展、範圍、質量等進行跟蹤和監控，識別目前的進度與計劃之間的偏差，從而快速準確地採取辦法進行糾正和調整。在專欄後面的內容中，我會跟你介紹一下，如何通過一些大盤或報表，有效地監控專案中的各項資訊。

收尾過程組（慎終如始，則無敗事）

收尾過程組是五個過程中的最後一個，而頭和尾都是最容易被忽略的，所以我要重點強調一下。在這個階段，你要交付專案成果，組織團隊的回顧覆盤，歸檔所有文件等組織過程資產，正式結束一個專案或階段。就像剛剛結束一場大考一樣，專案釋出上線之日，就是專案經理的解放日，專案經理可能會想：“管它是死是活，我都不想再看第二眼了。”這種心情我非常能理解，但虎頭蛇尾其實是最應該規避的毛病。所謂慎終如始，則無敗事。重要的事說三遍：“覆盤！覆盤！覆盤！”不管專案成功與否，“趁熱”覆盤都是極為重要的一步。就我們團隊而言，我們不光會覆盤正常結束的專案，對於那些中途被叫停的非正常“死亡”專案，我們會格外重視，並立即覆盤。我把這種覆盤會稱為“驗屍會”。這樣的覆盤通常會帶給我們很多有價值的資訊和啟示，比如哪些致命風險需要在一開始就被很好地管理和應對，再來一次的話，我們該怎麼做。

網際網路專案管理的職責定位

五大過程組是非常經典的專案管理模型，但是從網際網路類業務的情境來看，我們往往會覺得很迷惑，因為專案與專案之間的邊界相互交疊在一起，產品需求就如同海浪一樣，一波未平，一波又起，大浪中夾雜著小浪。除非產品下線，否則“造浪機”在整個產品的生命週期中根本就不會停息，看不到哪裡是盡頭，又哪來的啟動和收尾呢？

事實上，對於大多數網際網路產品而言，研發期和運營期是交織在一起的，並非像傳統軟體那樣，有個清晰的專案交付目標和時間週期。這樣海浪式迭代演進的過程，給追求確定性和控制感的專案管理，帶來了新的挑戰。不過，我們需要承認的是，從專案管理的方法層面來看，經典方法仍然是通用和普適的，只是你需要基於你的場景，找到對應顆粒度下的 PDCA 閉環管理方法。那麼，把我們所講的十大領域五大過程組，放在網際網路的實戰場景中，專案經理到底在做什麼呢？我們說，專案管理有著天然的無邊界屬性，這也就意味著，放眼全域性你能看到的地方，你什麼都得操心、什麼活都得幹。所以，要搞清楚這件事，其實是很難的。別的角色都有自己的輸出、自己的作品和固定的職責，但是好的專案經理卻是融於無形的，整體專案團隊的產出就是專案經理的作品。

你還記得我在上一講的最後提到的我們團隊總結提煉的 12 個字嗎？“保目標、助決策、提效能、促協作。”這 12 個字看上去簡單，卻真的是我們團隊整體智慧的結晶，它不僅體現在專案管理的日常工作中，更體現在專案經理的績效考核、晉升答辯等過程中，是指導專案管理實戰工作的基本綱領，下圖是這個基本綱領的總覽：

我們先從縱向來看，在從戰略到執行的過程中，專案管理的兩項職能是保目標和助決策，這形成了一個圍繞目標驅動的閉環。把業務最頂層的戰略意圖，清晰地反應在每個人每一天的執行中，其實是件非常不容易的事情，需要一層層地進行拆解。首先，你要圍繞組織績效目標，定位出核心的 3～5 件要事，即關鍵戰役，再把關鍵戰役進行規劃分解，拆到可交付可驗收的里程碑，最後落地到版本 / 迭代的工作安排中。

接著，你還要通過清晰而系統的反饋機制和平臺，把執行中的進展狀態、變更、風險等集中呈現，以幫助管理者更好地進行優化和調整。比如，結合產出進度來調整業務策略，通過里程碑狀態資訊來調整目標和規劃的節奏，根據人力投入的分佈，來優化整體的資源配置。這些就是保目標、助決策的部分。然後，我們從橫向去看，提效能和促協作，本質上都是工作在上下游跨角色協同的這條線上，鏈條越長，協同就越是複雜。

提效能是要去關注和消滅團隊中的低價值工作所引發的效能痛點。舉個例子，假如測試環境的部署耗時很長，這已經成為了整個團隊的瓶頸，那你就要想辦法通過技術的手段實現自動化，從而為整條鏈條提速。促協作則是著眼於使用各種專案管理方法和工具，讓高價值工作者可以更好地合作。比如，建立清晰有效的資訊渠道和溝通機制，積極推動各角色達成共識等，實現全域性價值的最大化。

總結一下，保目標、助決策是要打通從戰略到執行的閉環，提效能、促協作則是打通上下游協同的閉環，這 12 個字就是我對於網際網路實戰中專案管理職責定位的理解。關於它們在實戰中的具體應用，我會在專欄後面的內容中詳細地為你介紹。

總結

好了，講到這裡，專案管理的常識我就都介紹完了。十大知識領域和五大過程組，代表了整個專案管理知識領域中的一橫一縱兩條主線。這個知識地圖，為我們後續的學習提供了一套標準框架。

你需要對這些知識有整體的認知，這些基礎理論可以給你的實踐提供專業科學的指導。不過，你沒有必要一一記得，在第二模組“硬技能篇”，我會從這幾個過程組和知識領域出發，結合實踐中的常見痛點，給你介紹更多實用的方法。你要知道，專案管理是一門實踐科學，並不會有什麼一招制勝的銀彈，但是，只要你跟著專欄進行系統地學習，認真思考，謹慎實踐，就必定會在專案管理領域有所成就。

以後關於資料中臺系列的總結大部分來自Geek Time的課件，大家可以自行關鍵字搜尋。