如何才能從技術走向項目管理pmp？
謝邀~
確實做管理也是不少技術人在職場晉陞中的一條常規路線~本人也是。
但是管理和做技術差距真的是非常大，做技術管理呢差距稍微小一點，這個還好。
那麼如何從技術走向PMP項目管理呢？
第一步、獲取認證或者知識體系
不是說一定要去獲取認證，而是說你在獲取認證的過程中能夠系統化的學習到PMP項目管理的知識，減少走彎路的可能。
關於PMP的含金量我看有人已經回答了，這裡我直接上我之前的一份答案吧~
在國內 PMP 有多少含金量？?www.zhihu.com
第二步、實踐
這裡可能會有疑惑，就是我職位不是管理如何實踐，其實很簡單~
因為PMP的項目管理不僅僅針對工作中的項目，pmp對項目的定義是任何事情都可以當做項目來管理，不論是生活中的，還是工作中的。所以這麼說你應該明白怎麼實踐，將你學習到的PMP知識先按部就班的去分析事情，熟悉後你自然而然就會有相應的思維了。
第三步、直接干
其實做項目管理有兩種方式，第一晉陞，第二跳槽。
不論是那一種方式由於你經歷了前兩步，第三步都比較容易~
對於任何事情要有清晰的目標才能精確把握，如何做好一個技術項目的PM？首先我們看到這裡面目標最起碼應該是：如期交付有質量保障的項目產出。這裡有幾個需要我們注意的結果關鍵詞：如期交付(守時守信)、質量保障(保質保量)、項目產出(完整結果)。當然還有最重要的因素：人 + 過程 。阿里有句老話叫做：沒有結果的過程是放屁，沒有過程的結果是垃圾。所以，項目管理也是一樣。我們既要結果，又要過程，當然，還要這裡面人舒服 。
這裡我們再總結提取下目標：
1. 項目目標：如期交付(守時守信)、質量保障(保質保量)、項目產出(完整結果)；
2. 人員目標：舒服、有成就、有成長；
3. 過程目標：風險控制、信息同步。
接下來我們就按照項目的生命周期來看看以上目標要怎樣才能更好地達成。
目標達成
項目啟動
項目啟動重要點是需求宣講，俗稱畫餅拉人 。任何一個項目都會有既定的目標和預期，但是這個目標大家認不認？如何衡量結果好壞？做完後有沒有成就感？這是項目後續成敗的關鍵。所以你需要思考好這些東西，才能和大家宣講、才能拉人幹事。不然人家都不知道你要幹啥、幹了有啥好、為啥要(賣力)給你干。作為項目PM的你定義好項目目標、衡量結果（ROI）、人是尤為重要的 。這裡提幾點建議和思考。
1. 目標：你為何要做這件事？
2. 目標：你的目標有沒有足夠明確？有沒有清晰的大圖？
3. 目標：做這件事的意義是什麼？
4. 結果：你有沒想清楚個目標的關鍵因素，核心指標是什麼？
5. 結果：有沒有附加的影響和因素？是好的還是壞的？
6. 人：你自己是否足夠清晰能夠完成項目的重要因素？尤其是大的項目top-down的思考。
7. 人：你能為大家提供什麼來確保順利的分工配合？越俎代庖阻、撒手不管都是不可取的。
8. 人：這個項目需要哪些人？哪些角色？他們核心關鍵是哪些？
9. 人：參與這個項目的同學能得到什麼？失去什麼？共贏嗎？
10.人：參與的同學的成就感在哪裡？
當你思考和整理好以上這些東西，才能做好項目(需求)的啟動和宣講。目前我們很多項目的組織方式，是由多個角色完成的。常見的方式是運營或業務或產品做了項目中的一部分或所有，然後到需求階段再由技術同學跟進後半段。這個角色有多人共同分擔並不衝突，重要的是我們要配合默契、銜接得當、相互補位，拿到共贏結果。
工作過程中我見到過激情澎湃的KO，也見過稀里糊塗到直接開車，所以生活(工作)還是需要一些儀式感。注意做好這些點，項目後面會順暢很多。
需求評審
一般需(hua)求(bing)宣(la)講(ren)完畢後，很快會進入需求評審階段。這裡是需求細化明確重要節點。作為一個項目PM你必須要做到小需求了如指掌、大需求合理拆分 。這個階段最好是個時間段而不是一個時間點。尤其是對於互聯網，我們講究的是快速，節約大家時間。你有必要提前深入介入，了解需求邏輯和範圍。這裡會遇到如下幾類問題：
1. 需求(描述或意義)不明確、理解不一致。 解：不要牽強、不要害羞。描述不清楚的講(寫)清楚；意義不清楚的增加解釋。PM都要搞清楚搞明白，這樣你才能夠在中後期答疑解惑環節，節約信息同步成本。實在不行就回到最開始的目標上去：意義在哪裡？
2. 關鍵人員沒拉到到位。解：這個其實我們經常會遇到，原因也有很多。事前列好人員信息版(可以放心裡)是一個很好的習慣，我個人習慣用釘釘群公告+雲雀 note 頁。事中則需要補救和充分溝通了，還好我們的同學都很能相互理解。
3. 需求範圍膨脹。解：這個問題也是我們項目中常見導致項目最終崩潰的原因。所以你是需要提早接入需求的，最起碼要比評審早。確認好項目的人員投入數量、投入度，確認好本次重要目標和次要目標。適當的時候要做需求拆解，不要做超量(加班也可能搞不定)的計劃。不要做好好先生。你要清楚你的職責是如期交付有質量保障的完整結果。
除以上問題外，對於大型的跨團隊的項目可能當下是無法詳細看清全局的。這就需要大PM在這個時候量力而行儘早分揀分派、劃定二級責任人。在互聯網公司，需求評審過不過一般都會提到需求溝通和宣講。所以，需求評審一般是PM認同了項目目標和意義的，這個要特別注意。所以具有PM角色的你(們)要更多的做配合需求拆分細化、答疑解惑；而不是一堆問題瞎懟(這可以發生在宣講或再靠前)。這裡我提下幾個重要的點。
1. 需求評審要提前做好信息充分公開有會議邀請，關鍵人員要拉到位。
2. 評審後關鍵參與人明確自身工作目標和職責。
3. 重要信息、問題和困難收集。同時做好信息公開同步。
4. 重大設計、困難單列單獨跟進。
完成以上後，項目人員也基本鋪開了。接下來更多的需要並行。
項目排期
評審完畢後緊接著的就是再次的資源盤點和目標對焦，簡要的 recheck 確保補齊。這時 PM 根據各負責角色工作評估做出簡要排期和項目需求+參與方核對各方訴求，確定最終版本。這裡也會遇到幾個問題：
- 排期時間過長。 解：拆分、加人、分階段。建議最小工作單元評估最好不要超過2人日 。
- 其他項目排期衝突。解：分析是產品節奏衝突還是人員(資源)衝突，確認好各自目標再共同協商總體排期。
- 重要階段未給足充分時間，如設計階段、系統聯調、冒煙、測試、內測等經常忽略項。解：提前協商溝通好協調。
最後，項目排期要和各參與同學溝通清楚投入度和時間節點。一定要明確幾個重要的時間點：設計評審、測分評審時間、提測時間、產品驗收時間、發布時間(如果客戶端還要根據不同端特殊情況分開列出)。同時排期過程中可能遇到的並行風險、人員資源風險及時對外同步。
設計+測分評審
設計之於項目隱患+後期擴展、測分之於項目質量風險的意義，技術同學想必都是非常清晰明確的。這不僅僅要求項目PM，對於核心的系分、測分設計人員也提出嚴格要求。務必保證：
1. 重要流程有圖、有文字、有用例覆蓋。
2. 重要設計方案、測試方案要提前溝通討論評估風險和影響。
3. 需要考慮資金、安全、性能、風險的，單列 todolist + checklist。
4. 重要設計影響對外同步。
對於技術型的 PM，最好滿足：
1.項目中的核心設計者；
2.業務 owner 或核心，其中一項。
這裡主要是考慮到技術項目 PM(實在不行要有核心設計人員)對於業務定型、技術定型在業務中後期的影響著實太大。
此階段開始作為過程跟蹤重要手段需要有常規的項目日報和風險提示 了。建議對於工作日小於20人日的項目可以不用每天發項目日報，有風險及時同步即可。超過的最好每日有項目詳細進度， 根據項目複雜度不同 粒度可以精確到單人負責的模塊 。重要的是過程跟蹤+問題及時反饋解決。
研發過程
研發過程中一般大家精力都會集中在各自項目負責模塊上。同時對於我們這種互聯網公司，變化又是家常便飯。這裡有個原則是信息跟蹤和同步評估要充分。可能涉及到排期調整的，要及時溝通和調整。也要注意風險和項目範圍把控。這時你可能會有如下幫助：
1. 項目空間任務列表(aone有批量功能)
2. 排期進度表(雲雀)
3. 需求變更記實錄表(雲雀)
4. 人員負責表(雲雀)
5. 風險跟蹤列表(雲雀或aone)
6. 過程進度日報：模塊進度條百分比、當日工作主要內容、風險同步與處理。
7. 重要邏輯影響對外同步(如表邏輯、業務邏輯變更的，需同步對應使用方)。
冒煙+聯調+提測
大家都知道大多數的線上技術問題都可以在測試階段提前發現。而PM要思考的是測試前我們能做什麼？提測前的冒煙、聯調包含了必要的單元測試、功能測試和部分集成測試。尤其是對於多系統聯動的項目冒煙和聯調的質量直接影響到測試效果和線上問題量。這裡PM一定要提前溝通評估安排好時間控制和冒煙聯調節奏，有必要的話集中閉關+小階段目標設定可以實行 。同時對於複雜的項目由於整體節奏和工作壓力等原因參與人員很容易陷入自我流程和模塊邏輯里。 在聯調階段作為PM最好能設計出幾個經典業務場景作為聯調目標，對項目的整體質量做提早把控 。重要項目特殊建議：
1. 全量(70%+)含憑證冒煙。
2. 流程覆蓋設計+測試執行(PM)
3. 閉關聯調+分模塊分階段聯調半日目標進度。
4. 獨立的項目聯調環境準備。
5. 關鍵鏈路的日誌標要求。
無論是作為核心開發還是純PM，此階段都需要主動去檢查項目的研發交付程度。包含但不限於主業務流程、特殊分支邏輯等 。你可以根據項目重要程度複雜程度來判斷是否需要精細化。同時此階段也很容易暴露缺失或錯誤邏輯。我個人做法是小型項目自己設計場景 case 走；大型項目聯合核心研發測試一起設計場景 case；同時注意對產品交互和 demo。
測試
項目到了測試階段大部分的開發工作已經基本結束了。我們這裡討論一種場景是開發測試有不同人員執行。測試 bug 要督促做到日清，不能日清的需要有原因跟蹤。本階段一般也是 code review 集中階段。PM應直接或間接的對於關鍵鏈路設計、流程日誌記錄、編碼規範要著重把關 。同時產品發布+回滾方案在本階段要做準備了。一般來說每個團隊發展到2年後都會有比較規範的發布計劃模板。這裡我們著重提及幾點PM要注意的事項：
0. 安排處理好項目測試環境，確保穩定性。
1. 安排各系統CR節奏，並跟蹤反饋。
2. 安排發布計劃討論和準備。制定並總結初步發布執行計劃(單點對應明確責任人)。
3. 安排討論確定版本限制兼容方案。
4. 安排準備線上功能開關和灰度方案。
5. 重要項目要有發布預演。
6. 預發和線上不隔離的系統要注意單獨考慮預評估發測試風險。有必要的給出操作步驟。
產品驗收
一般情況測試完成後就到產品驗收環節了。這個過程有些同學可能就直接不問或者任憑產品驗收結果做最後的質量兜底。這是極為不可取的，原因是一般的產品驗收最多只會跑到整體項目 case 的30%不到，越是大越是複雜的項目這個比率越是低。產品驗收的目標是檢查產品功能完整性、產品體驗，而對C的線上用戶幾乎會全方位無死角覆蓋。所以這次是你產品(功能)細節問題的最後一次機會。考慮到項目成本+收益+重要程度，對於特殊項目需要單獨的組織參與人員設計並執行內部驗收，以確保多人更大範圍的產品檢驗。
這個事情有兩個重要意義：
1. 項目產品信心建立。
2. 項目產品功能體驗review。
一般性的準備我這裡也列舉下：
1. 產品驗收checklist；
2. 驗收環境準備；
3. 驗收數據準備；
4. 驗收問題列表；
5. 變更列表(雲雀或aone)，此時的改動要特別注意變更風險和範圍評估；
6. 數據、BI、埋點驗收準備；
7. 產品驗收數據收集(可選)。
項目發布
在以上階段都完成後，就到了項目發布的最重要階段。在準備好發布計劃的前提下。要注意多系統聯動的 發布時間節奏、依賴控制、風險控制、線上驗證等把握。嚴格執行發布流程和回滾方案的同時，注意以下幾點：
1. 提醒系統發布前中後檢查，建立通知機制（發布群）。
2. 系統發布要注意API變更、數據及表結構變更等對線上邏輯的影響評估。(一般預發布已經做了)
3. 發布後的線上檢查，特別注意檢查本身會否影響線上功能和數據。
4. 最好做到發布功能有開關+線上白名單。
5. 複雜項目的發布一般會選在在晚上，但同時要做好分班跟進計劃。
6. 發布完、線上驗證完畢後，項目發布郵件及通知同步要到位。
復盤總結
互聯網公司，唯快不破。再快的產品功能發布 也需要回到我們最初的本源，目標有沒有達成？所以回到我們項目起初制定的目標和衡量標準，需要有個目標達成總結。重要的點提及下
1. 項目目標衡量數據統計。
2. 過程優缺點復盤,揚長避短(非所有項目)。
3. 較為成功的項目要及時安排慶祝(儀式感很重要)。
其他的補充
互聯網公司有個很大的挑戰就是，項目節奏壓力。同時通過以上我們也可看到想要做好一個項目是需要付出很多的，有很多東西都是默默地背後的。項目也好，產品功能也好。都是人做出來的。再牛逼的業務宣講、再清晰的目標設定、再精細流程把控最終都逃不過人這個核心的落腳點。作為PM你要時刻反思：
- 真正的業務訴求是什麼？
- 項目有沒有偏離軌道？
- 這個人跟你做項目能不能得到成長、成就？
- 他有沒有被你推到了牆角？
- 你是否能觀察判斷到可能的風險並最好規避、次之解決？
- 你會否會因為一個項目，一場仗而得到一批幹將？
這是除了項目結果以外我們需要思考的。不僅僅是業務或技術，這是走的長遠、是準備未來。
關於數據變更(結構+數據)：包含表結構變更、數據格式變更、數據內容變更等 在系分階段要同步BI(其他數據使用方)，項目驗收前要再次確認。
希望可以幫助您，知乎PC端點擊我需要學習交流可以一起學習交流，還有資料提供哦！
發佈於 2020-03-19繼續瀏覽內容
知乎發現更大的世界打開
Chrome繼續
雨之希留保持良好心態這個就會涉及到轉型的問題。其實我就是這樣走過來的。我的建議如下：
- 開始學習項目管理相關知識。不要認為項目管理不用學就可以管理好項目。最好考一個PMP。
- 最好先是做一個技術負責人，然後再是項目管理。
- 讓領導知道你想做項目管理的想法。
這個就會涉及到轉型的問題。其實我就是這樣走過來的。我的建議如下：
- 開始學習項目管理相關知識。不要認為項目管理不用學就可以管理好項目。最好考一個PMP。
- 最好先是做一個技術負責人，然後再是項目管理。
- 讓領導知道你想做項目管理的想法。
技術工作和項目管理工作工作是存在很大區別的：技術以嚴謹求進，項目管理工作以藝術求精。從技術工程師到技術經理、項目管理工作乃至項目管理工作帶頭人，是一個從蠶蛹到蝴蝶的完美蛻變。因此，這就註定了該過程必將充滿著痛苦與掙扎。
可以參加聽一下：
免費直播|停工不停學，戰「疫」學習兩手抓--如何從技術走向管理-在線訂票-互動吧?www.hdb-cdn4.cn
你還真是看得起pmp，我也搞不清為啥有那麼多人覺得這是個多麼牛逼的東西，需要跪舔或者掌握什麼如來神掌似的神功才能做項目經理。
技術轉行做pmp，你要是覺得考個證就算入門了，那就去考證。如果你是說怎麼才能做項目管理或者產品管理，那你就去做產品經理啊！兄弟，搞起來啊
推薦閱讀：
