導言
項目本身無好壞之分，項目管理有做好與做壞之別。在互聯網大廠的體制下，想要做壞一個項目很難（可以通過換人、追加資源等方式消除風險），想要做好一個項目不容易，需要團隊及PM付出大量心血和精力。在這些做好的項目中，我們也觀察到很多PM做的疲憊不堪，甚至厭倦做項目管理工作，更有甚者一度對項目管理工作對技術人員的價值產生懷疑，所以，對於技術PM來說“優雅”做好項目管理至關重要。
優雅是一種態度和狀態，能夠全局掌控項目，面對壓力和挑戰做到從容淡定、胸有成竹；
優雅是一種能力和過程，能夠識別關鍵節點，應對風險和變化做到張弛有度，上通下達；
想要優雅做好項目管理，掌握項目管理的思維、理論、工具和方法至關重要。
集團生態涉及100+BU，有成熟業務諸如淘寶、天貓，也有創新業務達摩院、阿里體育；有純線上互聯網業務阿里媽媽，有線下業務銀泰百貨，也有線上與線下結合盒馬業務；有大量toC的電商營銷業務，也有toB的服務平臺業務，比如千牛、客如雲、阿里雲等。每種業務因爲其定位、面對的客戶、所處發展階段，面臨市場競爭、團隊規模等不同，這就導致了不可能有一套規章制度適用所有業務，淘寶的電商項目管理模式，並不適合靈犀互娛的工作室模式，這也是PMO團隊與業務結合才能大放光彩根本所在。
但沒不是每個BU都能有自己的PMO團隊，而項目管理工作，又會貫穿業務的整個發展過程，爲了順利推進業務發展，團隊中部分技術同學就有PM管理職責，也是擔任PM同學的一種培養。技術人員想要做好項目管理不容易，即需要具備PMO相關管理理論和工具，也需要轉化自己的做事思維模型，還會面臨發展方向選擇是錘鍊技術能力、提升影響力還是轉行做專職PMO或者產品。
基本概念
什麼是項目、項目管理？
項目（ Project ）是爲創造獨特的產品、服務或者成果而進行的臨時性工作。
管理（ Management ）通過實施計劃、組織、領導、協調、控制等職能來協調他人的活動，使別人同自己一起實現既定目標的活動過程。
項目管理（Project Management） 在項目活動中運用專門的知識、技能、工具和方法，使項目能夠在有限資源限定條件下，實現或超過設定的需求和期望的過程。
從項目的基本概況可以看出，每個項目是具備三種基本特徵即獨特性、臨時性、目的性。而項目管理就是在有限資源（時間+成本）的情況，運用專門的知識、技能、工具和方法解決獨特性，達到目的性的過程，而主導這一切的就是項目經理（即PM）。
項目經理( Project Manager )是項目團隊的領導者，首要職責是在預算範圍內按時優質地領導項目小組完成全部項目工作內容，並使客戶滿意。爲此項目經理必須在一系列的項目計劃、組織和控制活動中做好領導工作，從而實現項目目標。
從本質上來說，技術同學做PM都是在承擔項目經理的職責，對初次做項目管理的同學來說除了要接受師兄的言傳身教外，還需要自身掌握項目管理的理論、工具和方法。
項目管理制度在公司中的作用？
在業務發展過程中項目管理如此重要，以至於在互聯網公司治理過程中採用了實虛線管理制度，實線爲直屬彙報關係，虛線爲業務線，通過這種管理方式有效打破部門牆，快速組織內部資源。
項目可以劃分爲兩類，這兩類項目對PM管理技能要求也會有差異，當我們作爲項目PM時，首先要清晰知曉項目的分類，並以此來建立相關的項目管理制度和規範。
一類產品項目（或者叫業務項目），經歷從小到大需要不斷持續迭代，典型特徵就是規模小、持續型，互聯網項目大部分都是這種類型。作爲這類項目的PM，需要業務發展壯大過程中不斷演化系統，因此會需要承擔比較重架構職責，同時還要圍繞團隊效能不斷調整研發流程，這類項目對PM的技術能力、架構能力、團隊管理要求比較高。
另外一類爲戰役項目，基本爲一次性需要大投入高產出，典型特徵爲規模大、階段型，歷年雙十一大促項目基本上爲此類項目。作爲這類項目的PM，需要全局瞭解，明確職責，定義上下游規範，同時還要圍繞團隊效能不斷調整研發流程，這類項目對PM的溝通能力、協作能力、影響力要求比較高。因爲涉及人員衆多，常見的是由PMO團隊來統一管理。
在技術團隊中選擇這兩類項目的PM，一般會有三個出發點。
1、借人成事，拿結果：對項目交付要求極爲苛刻，項目風險高、時間緊、任務重、壓力大，這時候一般會選擇能力強、抗壓好的技術同學擔任PM，以確保拿到結果
2、借事修人，鍛鍊人：項目難度中等，風險可控，從組織鍛鍊人的角度比如鍛鍊協作能力、架構能力等等，可以安排擔任PM，並做好相關兜底安排，這類項目收益很明確，就是以鍛鍊人爲主。
3、識人用人，培養人：難度低，風險不大的項目，對於一些新人、判斷不準、需要進一步摸清能力邊界的技術人員，用來安排擔任PM，通過擔任PM過程中，進一步觀察識別考察。
技術團隊的PM的選定大部分基於以上原則，作爲PM同學在接手項目時不妨做考慮考慮，選定自己的背景，以便於針對性的提升應對。
對於很多初次做PM的或者做過PM後仍然很痛苦，或者是掌握項目管理的流程、工具但在使用過程中仍不能明白其精髓的技術人員，很有可能是項目管理的思維模型尚未建立。當你走上PM崗位時，術是工具、方法、理論，道是做事的思維模型，所以一定要讓自己思維模型做一次升級轉化。
轉化思維模型
大部分技術PM一開始從開發者轉過來，無形中會有一種思維定勢。即要做好交給自己的事情，執行到位是，常見的情況是在項目功能模塊劃分時，往往選擇難度最大的功能模塊來開發，一方面是擔心人別人做不好，影響項目的進展，高風險內容放在自己手裏最放心，另一方面也擔心團隊其他同學有意見，怕團隊中其他人覺得自己作爲PM沒有起到核心作用。這種情況是比較典型的點狀思維、線性思維模式，沒有從整體項目角度來思考項目目標、項目風險、任務分配，其實這種方式纔是項目管理中的大忌，增加項目風險的同時，會讓PM精力分配極爲不合理，導致各方面工作做不好。因此，作爲PM是要先做好三種思維模型的升級轉換。
1、目標導向、計劃先行：作爲項目PM首先要明確項目目標，充分考慮項目風險後，制定詳盡計劃，並能推導出目標結果來，實際執行過程中緊盯目標按照計劃執行，與目標無關的事情再容易也不要做，與目標關係不大又不得不得事情，少精力做或者讓別人做，謹記項目管理是預期性管理，不是超期性管理。
2、以始爲終、積極應對：項目的目的就是爲了“結束”，開始一個項目的目的是爲了Close這個項目，進入一個項目的目的是爲了退出這個項目。對於項目過程中碰到已知或未知的困難，站在終點去思考，一定會完成，所有困難時達成目標必然的過程，保持積極心態應對，不抱怨。
3、團隊協作、通過他人拿結果：作爲PM時已經不是一個人在戰鬥，是一個團隊，而PM是這個團隊的領導者，首先要讓團隊成員彼此看見、消除誤解，再次明確分工、職責邊界、協作協議，團隊團隊成員、共同努力才能一起拿結果，不要最後是個人成功了，項目卻失敗了。
從開發到PM，是類似於從演員到導演的轉化，也是從戰術思維到戰略思維的升級過程，這一步是裏，一定要做好。才能坦然面對項目管理過程的各種問題，比如別人埋怨、各種突發的風險等。
項目管理核心概念
項目管理概念出現於20世紀中葉，20世紀60年代成立項目管理協會PMI（Project Management Institute，PMI）。PMI一直致力於項目管理領域的研究工作，並制定了行業標準，由PMI組織編寫的《項目管理知識體系PMBOK指南》已經成爲項目管理領域最權威教科書。在項目經理認證方面，PMI推出的項目管理資格認證PMP(Project Management Professional)，感興趣的同學可以考一個。
《項目管理知識體系PMBOK指南》最新版已經到第7版，在內容上並沒有延續以前的五大過程和十大知識領域的結構，而是將五大過程組變成了十二項原則，十大知識領域變成了八大績效域，雖然結構變化挺大，但相關領域知識內容變化不大。第七版更加強調VUCA（烏卡時代）和在不確定性中如何敏捷相關的內容，更加強調績效領域的相互作用關係，但缺乏績效領域的邏輯關係，感興趣的同學可以瞭解下。《PMBOK指南》第六版的內容有比較強的邏輯性，適合體系化的分享，一樣可以應用於現在的項目，所以本次分享還是以第六版的內容爲主，
項目過程週期全景（五大過程）
實際工作中，我們參與的項目基本經歷以下過程，大家基本也是按照下面流程過程進行工作排期，覆蓋整個項目週期，這只是項目管理過程中要經歷的工作，過程中涉及的相關理論和工具是不知道的，所以這也是我們很多項目拷貝一個別人做的項目語雀文檔，就可以做項目管理的原因，關鍵動作補缺位，也不會出大錯，但做完後總是感覺不得法。在這個過程中看不到溝通管理、也看不多人力資源管理（圈人），能做好但做不優雅。
PM指南中定義一個項目五大過程，項目從開始到結束主要經歷，啓動、規劃、執行、監控、收尾，在這五大過程組中涉及到整合管理、干係人管理、進度管理、成本管理、質量管理、溝通管理、人力資源管理、採購管理、風險管理10大領域知識。
五大過程中，每一個過程都有些關鍵動作要執行，結合實際項目經驗，爲了便於記憶我把裏面過程、核心動作了總結。整個項目過程中三字訣來說。
過程一：定目標，核心涉及三個動作，圈資源，明確項目的各類資源情況，比如前端、服務端、產品具體參與人員，能參與的程度，全部精力還是一半都要明確清楚，外部依賴資源等等；定規範，完成項目團隊的組建，定義團隊開會制度、日報週報、風險上報，產品需求變更流程制度規範等；確需求，明確項目背景，完成需求範圍的確認，需求方案評審等等。
過程二：抓過程，核心涉及三個動作，做排期，做好項目人員任務分配、里程碑、項目詳細排期，關鍵路徑拆解等；進評審，完成交互/UI評審、技術方案評審、測試評審，評審的動作也要做到排期內，切勿出現等到評審完成後再確定排期的事；識風險，實際研發過程管理、進度跟蹤、把控，發現識別解決風險等等。
過程三：達結果，核心涉及三個動作，保交付，確保項目如期上線交付；做好項目覆盤總結項目過程中的得與失，如果再來一遍那些部分會堅持做好，那些部分會放棄，一定要做好覆盤總結，這纔是團隊成長的關鍵，歸好檔，項目prd文檔、設計文檔、架構方案文檔、郵件等等資料都要做好總結沉澱，以備後面同學學習。
十大領域知識
在項目過程階段會涉及到十大領域知識，每個階段重點涉及哪方面的知識可以查閱《PMBOK指南》，每項領域知識內都有詳細介紹。
正如我們所知，項目管理並不侷限於軟件行業，針對軟件行業，整合管理、干係人管理、進度管理、風險管理、溝通管理是特別重要的領域知識，需要重點掌握，針對這些重點領域知識，結合項目實際管(碰)理(到)經(的)驗(坑)，後面會做一些更細緻的分享。
爲什麼要學習項目管理理論？
作爲技術人，主要工作是開發，又不想走到管理崗位，還有些社恐，有必要學習項目管理知識麼？或者覺得自己做的項目挺好的，雖然不懂什麼項目管理理論，但項目都按時發佈上線了，還有必要學習項目管理知識？有這樣以爲的技術PM可能不少，主要還是有些內容沒有看清楚
當前世界發展越來越快，變化也越來越大，因爲信息的互聯互通也讓這個世界變的更加複雜烏卡（VUCA）時代，《PMBOK》第七版的變化也是爲了更好應對這個世界發展而出來的。再次，今天商業運營基本規則還是，運用公司體制將各種資源、系統、方法、人員結合在一起，在規定的時間、預算和項目目標範圍內完成項目的各項工作，快速、高效完成價值創造，贏得商機，對於具體實施的人來說這離不開完備的理論支撐。最後從項目上來說，新軟件的開發、新建築的創造、一次家庭出遊等都可以看做是一個項目，需要用心經營才能做好，而更關鍵的是每個人的一生也可以看做是一個項目，具備臨時性、獨特性、目的性的特徵，需要做好人生規劃（計劃），並堅定不移的經歷、學習、提升（執行），才能得到自己想要的生活（項目目標）。所以無論是當前時代、商業運營還是個人發展角度來說，都需要掌握項目管理相關的知識。
項目管理的理論體系可以應用到各類行業，比如建築工程、通信、電子、化工、金融等各行各業。爲了在互聯網產品中更好掌握應用項目管理的技能，還需要知曉掌握軟件軟件生命週期，軟件開發流程。根據不同的項目特性，選擇不同的開發模型。
軟件開發模型
軟件開發模型(Software Development Model)是指軟件開發全部過程、活動和任務的結構框架。軟件開發包括需求、設計、編碼和測試等階段，有時也包括維護階段。軟件開發模型能清晰、直觀地表達軟件開發全過程，明確規定了要完成的主要活動和任務，用來作爲軟件項目工作的基礎。對於不同的軟件系統，可以採用不同的開發方法、使用不同的程序設計語言以及各種不同技能的人員參與工作、運用不同的管理方法和手段等，以及允許採用不同的軟件工具和不同的軟件工程環境。-摘抄自百度百科
瀑布模型
瀑布模型是較早出現的標準軟件開發模型，於1970年W·Royce提出。該模型給出了固定的順序，將生存期活動從上一個階段向下一個階段逐級過渡，如同流水下瀉，最終得到所開發的軟件產品。這是一個非常經典的模型，即使在互聯網盛行的今天也沒有完全消亡，比如說Scrum每一個迭代內，都可以看做是一個小的瀑布模型。還有一些常見的外包項目、2B交付類項目都是採用這種模型。
圖片來源：https://www.wendangwang.com/doc/b901e3c258faf493da109ebec47d22dc22821c9f/3
瀑布模型的優勢：分工清晰，階段目的非常明確，有助於提升階段效率；其次因爲在早期能夠明確項目的範圍和概況，在開發階段也能有效組織和調配資源，中間過程變數小，交付預期明確。
瀑布模型的劣勢：各階段需要清晰、詳盡的文檔，在開發中也需要撰寫大量的文檔，這個過程增加大量時間，也極大的增加了工作量；其次項目後期展示成果給客戶增加項目不滿足期望的風險，常有交付功能不是客戶期望的情況產生；再次需求變更，因爲要涉及各階段，變更成本非常高。
適用場景：軟件需求十分明確且不會頻繁變化的項目，比如外包類項目，2B類項目。
迭代模型
迭代模型出現時間也比較早，早期被稱之爲“分段模型（stagewise model）”。從一定程度來說每次迭代開發都是一次完整地經過所有工作流程的過程：需求分析、設計、實施和測試工作流程，也可以說是小型的瀑布式項目組合。這種分割的好處也顯而易見，就是階段目標可檢驗。
圖片來源：https://www.cnblogs.com/liuqiuyue/p/10662488.html
迭代模型的優勢：每個迭代階段都可驗證，成功降低項目交付風險；其次靈活性高，新的需求變更可以下個迭代中解決，成功彌補了瀑布模式不能需求快速變更的短板。
迭代模型的劣勢：最終交付物可能無法預期，先期規劃和後期交付可能會差別巨大；其次迭代模型需要開發、業務團隊高頻高效的溝通，爲了保障溝通質量，需要在溝通前做好充分的準備。但現實情況是多數情況下溝通時間不能保證，溝通效率不能保證。
適用場景：需求不明確、創新性和需要搶佔市場的項目，比較適合2C項目
增量模型
增量模型又稱演化模型、漸進模型，增量模型是把待開發的軟件系統模塊化，將每個模塊作爲一個增量組件，從而分批次地分析、設計、編碼和測試這些增量組件，運用增量模型的軟件開發過程是遞增式的過程。相對於瀑布模型而言，採用增量模型進行開發，開發人員不需要一次性地把整個軟件產品提交給用戶，而是可以分批次進行，而每次開過過程又可以作爲一次迭代開發。增量模型對軟件設計要求非常高，整個體系架構需要具備開放性與穩定性，能夠順利的不斷集成各種增量組件。
圖片來源：https://blog.csdn.net/qq_38262266/article/details/86585435
增量模型的優勢：可以分批次地提交軟件產品，使用戶可以及時瞭解軟件項目的進展，相比迭代的優勢是增量模型的交付是全局可用，不會是隻是讓用戶體驗一個迭代內的功能；其次在軟件設計中以組件爲單位進行開發，能夠降低了軟件耦合開發的風險。
增量模型的劣勢：要求待開發的軟件系統可以被模塊化，如果待開發的軟件系統很難被模塊化，那麼將會給增量開發帶來很多麻煩。互聯網項目中，需求會拆分成模塊進行迭代，因此模塊拆分不合理也會造成效率問題。
適用場景：需求非常明確，可模塊化開發的項目，適合客戶端類項目開發。
模型對比
除了上述三種經典模型外，還有螺旋模型，演化模型、模型模型等，其他模型基本是這三種模型上的強化或調整，從事軟件開發核心掌握着三種模型即可，我們用一張圖對比三種模型的差異。
如果軟件從一開始定義到最後產出交付的相同度定義爲可預測性，那麼瀑布模型方式是最好的，迭代模型是最差的。如果從軟件使用目的出發按照更接近客戶真實場景定義爲適應性，那麼瀑布模型是最差的，而迭代模型是最好的。
以上三種模型在傳統軟件交付市場都有很好的實現場景，在很多互聯網項目上也證明了其價值。B/S模式(互聯網項目)和C/S模式(軟件項目)相比一個重要特徵是，發佈即用戶可見，這種快速的用戶可見模式和傳動的軟件交付後等待用戶更新相比，帶來了很多新的挑戰，比如出現問題後快速修復能力，新功能快速驗證的能力等等，這些挑戰最終指向瞭如何在不確定性中建立快速適配變化的軟件研發模式。而傳統的軟件模型是爲了達到最終交付目標建立的流程模式，強調詳盡的文檔、嚴格的流程機制、完備的工具能力、周祥的計劃，而所有這些動作都會讓時間變長，不適合快速變化的B/S模式項目，因此，爲了適應快速變化的B/S模式項目一種新的方法應運而生。
敏捷方法
敏捷方法是一種從20世紀90開始出現的一種新型軟件開發方法，是一種應對快速變化的需求的一種軟件開發能力，更強調開發團隊與業務專家之間的緊密協作、面對面的溝通（認爲比書面的文檔更有效）、頻繁交付新的軟件版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重軟件開發中人的作用。進入21世紀隨着互聯網的大流行，敏捷開發的概念開始廣泛的流行，敏捷方法通過創造變化和響應變化在不確定和混亂的環境中取得成功的能力非常適合互聯網行業的發展。
敏捷方法並不是全新的理論體系，敏捷方法基於敏捷宣言定義的價值觀和原則的一系列方法和實踐的總稱，可理解爲在原有軟件開發方法基礎上整合——取其精華，去其糟粕，是一種以人爲核心、迭代、循序漸進的開發方法。敏捷方法中有很多落地實踐，比如常見的Scrum、XP極限編程、精益、看板、水晶、DSDM動態系統開發、FDD功能驅動開發等等。
極限編程
極限編程（ExtremeProgramming，簡稱XP）是一種輕量級的、靈巧的軟件開發方法，強調可適應性以及面臨的困難，主要目標是降低因需求變更而帶來的成本問題。在具體工程中會把複雜的開發過程分解爲一個個相對比較簡單的小週期，在每一個週期裏面，項目人員和客戶都可以非常清楚開發進度、變化、待解決的問題和潛在的困難等，而且可以根據實際情況及時地調整。
極限編程以溝通、簡單、反饋、勇氣和尊重爲價值標準，以13種方法指導的開發框架。
圖片來源：https://zhuanlan.zhihu.com/p/511512621
極限編程模式對開發和測試團隊要求非常高，團隊中的人員水平必須具備非常高的水平這個模型才能運轉成功，比如測試驅動開發TDD，先寫測試代碼、再寫程序代碼進行測試，再比如結對編程，2名開發人員用一個鍵盤、一臺顯示器、寫一段代碼，這在大部分公司幾乎不可能存在。因爲這種方式質量提升多少不可見，效率倒是可見的降低了，至少從表面看是這樣的。
極限編程的優勢是具備非常好的工程實踐能力。TDD、結對編程不適合自己的項目，但不影響持續集成、重構、簡單設計等的實踐方法在項目中落地。
Scrum
Scrum是迭代式增量軟件開發過程，Scrum包含了一系列實踐和預定義角色的過程骨架，通過實踐3個角色（Scrum Master，Product Owner，Team）、3個工件（Product Backlog，Increment，燃盡圖），5個活動（Sprint，Sprint planning meeting，Daily standup meeting，Sprint review，Retrospective meeting），再加5大價值觀（專注、勇氣、公開、承諾、尊重）來指導軟件開發的一種機制，在Scrum實踐中Scrum Master類似項目PM角色。
圖片來源：https://blog.csdn.net/baidu_35805755/article/details/123345576
Scrum是一種機制、一種框架而非解決策略，是建立在使用它的人的集體智慧之上的，實現了經驗主義的科學方法，這種機制非常不適合頻繁變化的團隊，因爲好不容易建立的團隊信任很容易因爲人員的變動而缺失。
對比
極限編程和Scrum這兩種機制雖然都屬於敏捷方法範疇，但在實踐中也有不少差異。比如，迭代長度不同，極限編程的迭代長度1-2周，Scrum的長度在2-4周；再比如迭代過程中是否可以修改需求，極限編程過程中是可以允許需求變動的，如插入需求，則要考慮用另外等時間的需求將其替換，而Scrum一般是不允許這麼做的；再比如在迭代中是否嚴格按照優先級來，極限編程務必要遵守的，而Scrum可以很靈活，可以不按優先級來做，最後一點差異在研發過程中是否嚴格按照工程方法，來保障進度或者質量，極限編程有嚴格工程實踐約束，必須嚴格遵守，而Scrum來說不是那麼嚴格，用開發者自覺保障。
造成極限編程和Scrum的差異的根本原因是，極限編程更注重通過強有力的工程約束來保障進度和質量，即以工程約束爲核心，而Scrum更強調人的作用和價值，是以人爲核心，強調建立自組織模式。在實際工作中，作爲PM時最好是從管理上使用Scrum（團隊自組織），而在工程實踐中創建適合自己團隊XP。
掌握項目管理知識及軟件開發模型後，順利完成中小型項目的交付問題不大。但想要到藉助團隊能力優雅的做好，就要在關鍵節點下功夫。
項目管理領域重點知識
目標設定
目標的價值在於聚焦能量和引發行動。項目目標做的好（科學合理）能夠給人以鼓勵，催人奮進和向上，能夠把團隊內限的資源和精力用在最有意義的事情上，清晰的目標是也動力產生的源泉，它會不停地激勵我們把它變成現實。不好的項目目標會變成了團隊沉重的負擔，項目目標設定至關重要。
初次做項目PM的時候，很容易把項目目標設定爲某某日期按時上線或者無故障發佈等等。按時上線是非常重要的一環，但這裏面缺乏對質量的要求，對性能的要求，也無法體現團隊人員的成長等等。設定目標時，不要從單一維度出發我們要從多維度出發，設定目標要具備SMART原則，即目標具體、可衡量、可實現。如下例所示，右側項目的目標設定明顯要好於左側。
每個項目都有獨特性、臨時性、目的性。那麼如果找到項目的目標，可以考慮用6W2H思考法。
6W2H思考法：也叫八何分析法、6W2H標準化決策&評價模型，是一種通用決策方法。做任何工作都應該從6W2H來思考，這有助於我們的思路的條理化，杜絕盲目性。大到業務思考、業務決策、技術架構設計等，小到一個類的定義，一張表結構的設計，都可以使用該方法。
那麼技術人員做項目管理，可以從哪幾個方向設定項目目標呢，這裏給出一個圖，供參考。
對於初級PM來說可以從如上幾個方向設定項目目標，在每個項目上靈活運用。比如你初次接手一個項目，這個項目是創新方向的嘗試，產品需要從0-1，團隊也是新組建的需要磨合。這時候的目標可以這樣設定。
業務目標：通過完成XXXX等核心功能建設，配合市場完成新產品行業發聲。
技術目標：完成XX系統從0-1的建設，核心XX接口rt達到50ms。
團隊目標：建設團隊研發流程體系，實現按雙週發佈機制；通過團隊大練兵打造一支狼性團隊。
目標的設定，一定要根據項目實際情況進行，這就需要PM充分了解項目的背景、公司的訴求、市場情況，做出針對性的目標，而上述這些信息的獲取，除了要自己去學習外，還需要和項目的干係人做好充分溝通，瞭解他們對項目的訴求，制定的項目目標，才能讓各方滿意。
干係人管理
干係人即項目相關人員，在項目管理過程中，我們打交道最多的相關人員有如下
在實際項目管理中，不能忽略下面的這些項目關係人的訴求，所以項目目標制定時，一定要充分和各方干係人做好溝通管理。
大家可以嘗試把關係人放到下面不同方格內，針對不同關係人的難點做關鍵動作。
A方格：項目發起人、業務負責人
B方格：技術負責人、中臺服務提供方
C方格：PD、UED、DEV、QA
D方格：財採等
做好乾系人管理明確他們的訴求後，那麼就知道AB方格干係人的目標一定要作爲項目核心目標來定義，並與他們做好充分溝通確認，C的目標作爲重要支撐目標來定義。
進一步可以思考下，週報、晨會的目標對象是哪方干係人？他們核心關注點是什麼，思考清楚才能寫好項目週報，開好每個晨會。
溝通管理
信息的傳遞會因爲表達、介質、編碼、情緒等影響產生丟失，這就是溝通的原罪，你內心有100%想說的，到真正行動時可能只有20%的部分。溝通的本質不是你說沒說、說了多少，而是在溝通的對象理解了多少。溝通不是一次性的需要多次反覆確認。
溝通是一種建立溝通關係的雙向過程，通過溝通我們可以在不借助實力和權威的前提下，導致想法和行爲的改變，項目管理上的溝通是指有效溝通，想要做到有效溝通，需要建立團隊的溝通機制和善用工具。可以在團隊中建立這樣的溝通原則，併成爲團隊內明確下來。
1.醜話說在前面，先定義規則機制要求，獎罰說清楚
2.讓溝通在一個頻道上，統一團隊術語
3.讓“承諾”變的神聖、有效，不失信於他人
4.讓各環節的交付標準變的明確，利他就是利己
5.提倡換位思考，讓合作變的愉快
做到有效溝通還要善於利用Email、電話等工具，不同工具要用在適當的場景內才能產生價值。EMail，用於重大事項同步周知；電話/視頻會議，日常管理或者關鍵內容彙報；釘釘，有問題及時溝通；文檔中心，項目文檔協作、沉澱。
在項目管理過程中PM是溝通的中心，PM幾乎要花50%的時間用在溝通上，工作中50%的障礙也是在溝通中產生的，爲什麼會這樣，因爲PM在溝通過程中會碰到前後端專業有GAP缺乏共同語言、業務產品各方目標不一致、團隊成員職責不清問題推諉、項目進度不透明等溝通障礙。針對這些溝通障礙，可以針對不同的干係人，制定不同的溝通策略，對項目的業務方和領導及時做好彙報和請示，對你的合作伙伴（中間件、依賴方）做好合作和談判，明確大家的目標，對產品經理就要做好引導和確認，對項目組成員要做好協商。唯有此PM才能做到 外圓內方，財源滾滾(一位PMO同學的分享，非常有道理)。
風險管理
風險種類
在項目管理過程中可能會出現各種風險，比如需求評審有遺漏、需求有變更、工作拆分有遺漏、需求理解不充分、測試環境不穩定、人員經驗不足、團隊積極性不高、質量較差等等問題。下面有個項目管理過程中可能出現的風險，作爲項目PM可以照章比對。
（來源一位PMO同學非常全面的整理）
風險的識別和應對
項目管理過程中風險無處不在，有些風險無關緊要，有些風險會嚴重影響目標達成。PM不是孫悟空沒有火眼金睛，無法識別所有項目風險，但PM可以掌握風險識別的方法並應用，確保儘量識別出特別嚴重的風險，進行處理。
方法一：找專家來判斷，可以請教有經驗的同事、專家請他們把把脈。
方法二：組織頭腦風暴，有更多視角的輸入，便於發現風險死角。
方法三：組織專題會議，集思廣益，深度探討，便於發現隱藏風險。
方法四：數據分析，養成看報表、看數習慣，發現異常波動及時跟進處理，把風險扼殺在搖籃裏。
對於風險的識別，PM要充分調用團隊的力量。
風險是任何項目中不期望出現的但又無法避免的，面對風險，我們可以用規避、降低、轉移、接受風險這幾種方式進行處理。對於PM來說想要把風險從危轉機，就需要未雨綢繆，定義風險處理原則讓團隊提前達成共識，可以考慮從這三方面建立規範
1、意識建設，明確風險全員有責全員處理，大家一榮俱榮一損俱損的團隊意識。
2、建立風險快速上報處理機制，鼓勵大家積極主動上報風險，積極主動第一時間採取措施。
3、明確責任到人，明確獎罰標準、對不上報造成失誤的要罰，對消除風險有補救措施的給予鼓勵。
工具推薦
對於技術PM來說，需要心力、腦力、體力同時在線，不僅要主動承擔、隨時補位，還要積極樂觀、時刻保持清醒的頭腦，做問題的終結者。除了要掌握項目管理、軟件開發模型的理論外，還需要在個人管理及項目管理過程中掌握幾款工具，便於個人和項目提效。
時間管理
時間管理的核心是精力管理，每個人的精力都是有限的，要把自己的精力用在重要的事情上，這樣產出纔是高效的，作爲項目中心的PM，項目的大小變化都會匯聚到項目PM這邊來，可以通過緊急重要四象限來管理所有事項，並按照事項所在象限，分配時間精力來做。
具體各個象限佔用時間，大家可以根據自己情況調整，核心原則是把精力放在重要的事情（當下or未來），即與目標達成緊密相關，精力分配我們建議按照以下比例來分配。
1.重要且緊急（45%）嚴重阻塞項目進度的事情，例如技術方案設計、具體任務拆解、後端接口定義、核心主鏈路開發，阻塞測試的BUG等，這些問題不解決，干係方不能正常推進工作，必須優先解決。
2.重要不緊急（35%）不阻塞項目進度，但未來可能有影響的事項。例如某非核心鏈路功能（消息發送之類的），可適當延後一段時間，但需要有一個明確的時間點，需要follow整體項目排期，隨着項目推進，該類事項很可能上升成重要且緊急。
3.緊急不重要（15%）例如一些客戶反饋的線上問題，並可以安排團隊其他同學來跟進解決，在工作間隙要多關注。
4.不重要也不緊急（5%）暫時可有可無的需求，技術PM需要深入瞭解業務背景，再結合當下業務現狀，做出自己合理的判斷。比如一些不重要的需求，可以和業務溝通此類需求是否可以推遲到下個迭代做，或者當下使用最低的成本來做。
工作分解結構（WBS）
在任何項目中，工作分解都是重中之重。這個過程決定項目的成功程度、資源使用情況、風險等。在軟件項目中，常用方式是根據功能模塊來做工作分解，把模塊拆分成任務，再把任務拆解成具體的一項工作，安排到每個人的日常工作上來，這樣一個過程就是工作分解結構（簡稱WBS）。在軟件項目中除了用功能模塊來拆分外，還可以按照部門、職能、地域、實施過程等來拆解。具體項目管理過程中，要多嘗試幾種分解方式，然後找到資源、成本、效率的最佳平衡點。
關鍵路徑法（CPM）
一個項目拆分成任務後，任務與任務之間有前後依賴關係，任務有輕重緩急（權重），執行任務的人員也有能力差異，如何能夠最優化做好排期安排，這時可以用關鍵路徑法（CPM）來進行最長路徑的拆解，關鍵路徑是通過確定最長的依存活動範圍並測量從頭到尾完成這些活動所需的時間來一種方法。如下所示，嘗試找一下下圖的最短路徑。
PM指北
作爲技術開發人員，做PM時首先是轉化自己的思維模型，其次要做好角色轉換。無論之前個人多麼成功，從做項目經理開始就要開始做從一個人成功走向一個團隊成功轉型，從關注個人的事情到關注團隊事情、人、資源、流程機制等。
明白PM職責就是通過周密的計劃，管理好項目中的人、事、物，達成目標後，掌握理論、工具、方法再通過多次實踐，總結，就不能做到預(項)事(目)不(管)慌(理)。項目管理也不是隻付出而沒有收益的角色，通過項目管理實踐至少可以提升這5方面的能力。
1.溝通表達能力：技術PM是最瞭解項目業務的人，是問題諮詢的接口人，PM會面臨PD問進度、測試問邏輯、研發挑戰架構等等，能有效清晰的表達出來讓別人理解至關重要。
2.組織協調能力：遇到問題需要決策，技術PM組織協調者，圈人、建場子、做計劃。在涉及多工種、多任務的工作中統籌跟進落實。
3.技術架構能力：技術PM也是一把代碼好手，不僅項目要管得好，架構體系也要理的清，如果團隊內沒有架構師角色，我主動擔起來。
4.風險識別能力：項目管理過程會涉及PRD漏洞、技術方案設計漏洞、資源抽調、人員變動、提測質量差等風險，技術PM要結合項目的驅動因素，時刻保持對風險的敏感度，做的早發現早處理，將項目風險降到最低。
5.影響力、抗壓能力、系統分析能力等也將有不同程度的提升。
作者 | 光照
點擊立即免費試用雲產品 開啓雲上實踐之旅！
本文爲阿里雲原創內容，未經允許不得轉載。