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