阿里妹導讀
本文作者分享了自己做pm多年的實踐經驗，從什麼是pm到如何做好技術pm做出了詳盡的解答。
前言
工作已經很多年了，最近受邀分享一下如何做好技術pm，所以也就有了此文。並不是說自己做的有多好，有一些實踐經驗分享出來和大家一起探討一下，也非常歡迎大家指正。
什麼是pm（專案管理）
專案管理是在有限的成本下，把控專案的質量和進度，保證專案順利交付。成本、質量、進度之間相互制約相互影響，需要在這之中找到平衡點。並在專案執行的過程中持續關注專案的價值，推進專案價值最大化。
技術pm的職責
總結來說，專案pm就是在專案立項後，協調專案的方方面面，確保專案按期上線。專案pm的職責大概涉及需求、開發、測試、上線、維護五個階段，對於每個階段的具體職責，以下我做了一些簡要說明。
需求階段
1.需求調研前期，深入理解業務訴求，配合業務、產品完成需求的調研並完善需求，有時，可以提供給業務、產品一些建議，協助讓產品需求更加完善，更加合理。
2.需求評審階段，仔細聽取產品需求，確認產品需求內容無遺漏，無不合理需求。對於各個功能點的交付難度有大概的預估，對於難度較大的非主幹鏈路需求，必要時可以建議分迭代交付。
3.需求評審後，評估整體技術方案，確保整體方案合理完善，並協調各域完善技術方案的細化補充，並組織完成技術方案評審，鎖定並確認專案排期。
4.技術方案評審完畢後，找相關開發同學確認，細化開發、聯調階段的排期，確保專案推進可控，不會出現重大延誤風險。越大的專案建議越細，因為時間週期越長越容易交付延誤。
開發階段
1.專案開發階段，及時跟進確認專案進展（重大專案最好日日跟進統計，降低風險），保證專案有序推進；識別並發現專案風險，跟進解決專案風險，確保專案可交付（需要有主動性，主動推進落地）；專案變更&風險資訊及時拉通對齊，確保變更資訊對各關注物件透明，必要時可以採用日會、週會、日報、週報等形式。
2.專案tc評審時，作為pm需要關注各域測試用例完整性和有效性，確保相關開發、測試無內容gap，無遺漏需求。
3.專案聯調階段，確保各域聯調有序進行，對於不符合聯調預期的加大關注協調解決聯調問題，風險項及時跟進並推進解決。
4.專案聯調完畢後，協調組織功能預演，確保專案順利提測，重大專案建議先開發內部提前預演一遍，確保真實預演提測時不會存在較多阻塞，提測質量差，這裡如果發現較多不符合預期，可以提前重點解決。
測試階段
1.專案提測後，及時關注測試進展以及bug處理情況，確保測試穩定開展，專案bug及時收窄。重大專案可以考慮每天過bug，確保解決效率和問題拉齊。
2.專案釋出前，組織釋出計劃評審，確保各域釋出無遺漏、釋出無故障風險；協調各域完善監控，確保上線後相關問題可以及時發現；協調各域梳理並完成資損對賬，確保專案上線有資損問題及時發現並止血。
3.專案釋出前，組織uat評審，確保上線交付功能符合業務預期，如果有gap在開發環境解決。
上線階段
1.專案釋出時，即時跟進各域釋出進展，確保專案順利釋出。必要時協調開發測試在安全生產釋出後，進行線上的迴歸測試。
2.專案釋出後，協調測試同學一起進行線上迴歸，確保業務真實使用時無線上問題，業務順利上線。
3.業務首次使用時，跟進並陪同解決問題，確保首次順利使用。
專案維護階段
專案正式運營階段，關注業務問題、關注監控、對賬，確保系統穩定，業務順利展開。並作為業務介面人給業務同學答疑解惑。
重點事項與一些技巧
做好大型專案的pm，我理解主要有五方面的難點，這裡和大家重點說明，分別是技術複雜性（專案越大，方案越複雜）、團隊協作與溝通（跨團隊協作多）、時間和資源管理（人員多、週期長）、風險管理（未知風險多）、質量控制（內容多，質量保障成本高）。
技術複雜性
技術複雜性主要體現在兩方面內容，第一是整體方案的合理性，整體方案決定了後續整個專案後續是如何演進的，合理的架構方案可以讓專案在後續持續迭代並高度複用，細節方案上，專案pm主要需要關注各個域是否包含了所有內容，會不會存在遺漏的，以及在方案後續擴充套件性的一些考慮。
整體方案的合理性
這裡要考驗你如何確認一個合理的整體方案，這裡你需要考慮的因素有穩定性、可靠性、可擴充套件性等。自身需要提升知識儲備，提升技術硬實力當然是必要的，但是不是人人都是各方面的高手，可以信手拈來。這裡還有一些常用手段供參考，例如善借於物、借鑑歷史方案、找領域專家諮詢關鍵建議、設定mini版本等，這裡具體如何實施，下面我會詳細說明。這裡也要避免過於扣細節導致整體方案評估的時間過長，影響專案交付，整體方案評估確認後相關同學拆解回去在細化方案。這裡還有一點要注意的，如果是重要專案的整體方案設計，由於每個人都有侷限性，建議在細化前都找老闆過一遍，確保後續事項推進不存在返工的情況。
善借於物
整個網際網路發展已經很久了，集團也是國內數一數二的網際網路公司，可以說，有很大一部分的業務場景集團內都遇到過，所以這裡需要優先看看集團內是否有現有的能力可以使用，如果有，在評估合理無風險的情況下，可以直接使用，不要再重複造輪子了，重複造輪子成本高、風險大、對業務額外價值也不大。有那個力氣，我們可以花更多的力氣去做好業務的個性化場景能力，確保業務更好更快的發展。
這裡舉個例子
比如說閒魚需要做限購能力，調研發現集團現有bbq限購，也非常符合閒魚的場景，則直接接入使用就可以了；又比如說，閒魚需要做區域限售能力，發現集團現有的sic限售能力非常全面，足以應對閒魚的所有場景，也是直接接入使用就可以了。
借鑑歷史方案
我們開發大部分做的需求其實都是沒有現成產品的，如果有的話，大部分在需求階段產品已經評估打回了。但是相似的產品是非常多的，瞭解相似方案的架構以及一些痛點，可以讓我們更加好的設計當前專案的整體方案。
找領域專家諮詢關鍵建議
有些時候，你做的專案不是你的強項，且透過集團內外的相關文件也沒有找到靠譜的方案。這個時候，你可以找在這方便經驗豐富的專家諮詢，可以讓整體的技術方案更加合理。這裡有一點是特別要注意的，由於每個人都有自己的工作，你去找別人諮詢其實是耽誤了別人的時間，所以我們需要體現我們的專業性，並且要讓對方更加願意幫助你。這裡幾個方式是可以參考使用的。
a.找別人諮詢前，自己先有一個系統性的梳理，確保對專案和方案是有充分了解的，並且提問問題是非常專業的，不是一些低階的問題。
b.複雜的問題不建議在釘釘上溝通，釘釘上溝通效率低下，對別人耽誤的時間多，可以選擇語音或者直接去對方工位溝通，語音溝通的話記得提前先徵得對方同意。
c.帶上一杯奶茶、咖啡，一瓶飲料等去溝通，可以讓對方更加願意幫助你。受人恩惠讓大家更願意幫助別人。
這裡舉個例子
比如說閒魚想做一個購物車，這裡可以找業務平臺的購物車同學諮詢相關方案設計，也可以找各業務線購物車的開發同學諮詢，由於溝通內容較多，直接找了相關同學線下溝通。
設定mini版本
如果一個方案確實是要自行開發時，在保證專案可順利交付的同時，都是需要考慮通用性架構的，誰也不希望自己的方案是被一次使用後續無法迭代的。通用性就意味著成本，這裡方案設計時可以考慮留著通用性擴充套件，但是不用把整體方案設計的非常複雜，可以在最初考慮一個最簡潔的版本，達成業務初始的需求就可以了。我能支援系統成為一個牛逼的系統，但是不用一開始就非常牛逼。
細節方案的完備性
細節方案部分主要是由各個域開發同學編寫的，這裡需要確保各個域彙總後涵蓋了所有需求，不存在遺漏。這裡有個方式，技術pm對各域的產品功能做一個梳理，技術方案評審時確認各個功能點都被評審和評估到。
這裡做一個展示示例，可以看到，下面對各域的功能點做了細化拆分，方便對焦是否存在功能遺漏，也方便工作量的評估。
團隊協作與溝通
大型專案涉及域以及人員多，團隊協作與溝通是無法避免的。這裡需要關注在專案過程中如何提高溝通效率，並且減少一些私下對焦，如果有困難時，及時暴露問題尋求幫助。在整個專案推進的過程中，也需要維護好同事關係。
提高溝通效率
大型複雜專案涉及的業務、產品、技術同學非常多，所有溝通也非常多，如何提高溝通效率對於保證專案順利交付非常重要，以下是我在做技術pm期間的一些個人感悟。
減少私下對焦
涉及到協同域的開發內容的，不要私下找對應域的開發同學去評估並投入開發，這種會把這部分內容不透明化，對於相關域的同學來說，也是一直處於打黑工的狀態，應該快速協調產品透過需求的形式去溝通協調，這樣可以讓對方產品協調資源確認優先順序，可以有更多更加官方的資源投入進來，保證專案的確定性交付。
尋求幫助
不同層級、不同職責上的還是有較大差異性的，如果有時候感覺事情推進困難，這種時候需要及時的向老闆、向業務等尋求幫助。尋求幫助時，需要說清楚事情的背景、事情的影響、以及需要的幫助。
這裡舉個例子
維持好同事關係
在專案推進的過程中，維護好一個好的同事關係，可以讓專案的推進更加梳理，以下是我總結的一些方法，大家可以參考。
時間和資源管理
一般一個複雜的專案的時間週期非常長，由於週期長，時間多，大家對於時間和資源的管控就沒有那麼敏銳了，會感覺一切還來得及，到專案接近尾聲了才發現來不及了有重大風險了。作為專案pm，需要做好詳細的時間管理和資源安排，最好精確到每天需要完成的事項，讓專案按天維度來判斷是否是符合預期的，而且在事項安排上，需要做到先緊後松，這樣即使後面出現了風險專案也有交付的可能，而且需要域內先完成聯調，化整為零，提高全鏈路聯調的效率。這裡說一下我常用的方案，就是把各域的功能都拆分到非常細的維度，並且每個維度單獨確認開發完畢和聯調完畢的時間，後續每天找相關同學更新進展（讓大家自己主動填寫比較困難，這裡建議線下一對一對焦，過程是比較累的，效果還是比較好的，勤能補拙）。
風險管理
一個複雜專案，不可能前期面面俱到，保證中途不出現一點問題的，基本上沒有人可以做到，但是我們可以把風險量降到最低，風險提前暴露，提升風險解決效率。
風險預防
有一些風險預防的手段，可以降低專案的風險，提升專案如期交付的可能性，具體如下。
風險識別
什麼事情會導致專案有重大風險，會產生延期的，這裡需要有一個判斷，這裡可能更多的需要多觀察、多實踐，根據自己、別人的歷史經驗發現哪些事項是可能存在較大風險的。這裡是根據過往的經驗識別到的高風險項，如果存在以下這些情況需要高度重視並想辦法快速解決風險。
1.原定方案鏈路走不通的，需要修改需求重新調整方案的。
2.專案實際開發時，發現專案開發工作量遠大於評估量的。
3.專案開發、聯調進度嚴重不符合預期的。
4.評估涉及到需要新的領域投入支援的，尤其是和中臺、支付寶互動的。
5.涉及到bu側未使用能力引入的。
6.財稅法未確認的內容。
風險處理
不同級別的風險處理方式不太一樣，對於低風險正常推進就可以了，對於高風險需要投入比較大的精力去關注。
低風險
對於非主幹鏈路，或者對排期影響可控的風險，正常推進即可，有必要的話，日報週報同步一下進展即可。
高風險
高風險出現，往往會對專案交付產生一些衝擊的，這裡需要提前讓大家知曉這個事情，所以應該在風險暴露的第一時間讓大家知曉這個事情，不要讓持續持續的發酵和隱藏，導致最後真的無法解決。
高風險的事情需要重點投入並花較大的精力去解決，最好每日同步進展，進展中的待辦事項要有deadline，確認解決時間。這裡需要pm抽較大的精力持續跟進並主動去推進。如果事情遇到卡點，主要快速找相關老闆協調資源，商量對策如何解決，如果確實是不好解決的，需要大家周知達成一致。
質量控制
提測前
由於每個開發對可提測的標準不一樣，重大專案可以考慮在提測前一兩天先開發內部進行一輪預演，初步排查整個提測質量，針對不符合預期的域，重點關注推進，必要情況下安排加班或者協調資源進入等。
提測後
提測後需要關注bug的處理效率，確保提測後期bug得到快速收斂。bug儘量做到日結，這裡可以考慮每天群裡通曬一下未處理bug，監督大家快速處理。如果每天bug比較多，可以日會的形式每天過一遍bug，大家拉通對齊一下並快速處理。
提測後也需要把控儘快完善程式碼cr，之前出現過很多釋出前程式碼cr不過調整程式碼導致釋出後功能bug的情況。
釋出前後
監控對賬
專案釋出前需要協調完善系統、業務監控，並補充資損對賬。這是對業務，也是對開發人員的最後一層保護。部分開發同學對監控和對賬不夠重視，所以這裡需要專案pm去check一下確保都是正確有效的。
迴歸測試
專案pm需要協調專案相關的正式包提前一點打出來，全部打包完畢後通知測試進行迴歸驗證。確保驗證無誤後在釋出，歷史也有很多問題是因為打了正式包後未驗證引起的。
線上測試資料驗證
線上釋出完後，需要協調測試同學用測試資料迴歸驗證，線上迴歸可以發現不少問題，避免業務在真實使用時出問題。
嚴控灰度比例
線上業務正式試單後，就可以開始慢慢放量了。這裡技術pm需要嚴格把控專案放量節奏，確保有灰度的過程，防止線上出大批次問題。
一些實操內容參考
專案啟動
專案啟動後，把專案所有相關的人拉到一個群裡面，成立專案產技群，後續並把所有相關的文件資訊更新到群公告中，方便大家後續翻閱。儘可能把所有相關的資訊都更新到群公告中，可以為相關同學節省很多找資料的時間。
確認專案排期
專案排期確認後，需要細化拆分各個子任務，每個子任務責任到人，每個子任務確認交付時間。
技術方案
技術方案需要儘可能細化，方案越細越可靠，時間評估也越準（你會說時間急，最好在方案階段多花時間，後續開發事半功倍）。你需要評估一下，你的技術方案編寫完後，是不是團隊內另外找一個開發來就可以開發的。如果不是，比如花了幾個架構圖、流程圖，你能確認你腦子裡的所有東西都是準確且完備的麼，你能確認你評估的時間是否合理麼。
日報&週報格式
日報&週報的作用主要如下：
1.讓所有人對專案的進展&風險有一個整體的認知，不要存在重大gap。（老闆們再也不用問你專案開展咋樣了）
2.讓相關同學知曉自己存在的待辦項，並透過通曬，周知老闆的形式去push他解決（畢竟誰也不想背鍋）。
3.讓專案的重大風險被周知，更加方便協調到資源，可以更加高效解決。
在日報和週報上，需要先總後分，先說明整體進展和風險，再說分項的內容。先重點後次要，重點內容需要詳細說明，並且對於待辦項需要@到人。
資損對賬文件參考
作為技術pm，你需要體系化的去梳理專案中可能產生資損的場景，然後push相關同學去落地。關於體系化，這裡有兩個建議，按維度拆分梳理會更加全面（比如先按資損角色、再一個域一個域評估）；是否所有新增資損欄位均對賬覆蓋（對新增欄位全部做一遍check）。
專案釋出計劃
專案釋出計劃主要關注幾個點。
1.對齊二方包的打包時間，避免一些域的二方包打包晚影響了其他域的釋出。
2.所有同學一起拉齊需要釋出的內容，記錄在案，避免因為個別同學的疏忽導致部分內容漏釋出。
3.釋出是否有依賴，如果有依賴應該如何解決，確保好釋出關係，避免釋出導致線上故障。
4.根據釋出清單內容，可以持續跟進發布進展，及時發現釋出中存在的風險，早介入早解決。
最後
上面說的主要是一些流程和技巧，此外，專案pm需要有很強的責任心，業務、老闆把專案交付給我們，我們是否可以儘自己所能盡的最大努力去保證專案交付，並且做到沒有邊界，非分內之事，也願意多承擔一些。這樣即使最後專案沒能交付，我們也問心無愧了。
雲上公網架構設計和安全管理
雲上公網的設計可以幫助企業更加統一、安全地管理自己的雲上網際網路出入口，同時可以實現統一監控運維和公網的成本最佳化。
點選閱讀原文檢視詳情。
