阿里妹導讀：在技術公司、尤其是網際網路公司，技術人員作為PM(專案經理)是非常常見的。有些同學得心應手，有條不紊，能得到清晰穩定的預期結果；有些同學則在過程中遇到各種鬧心的事，最後不是專案上不了線，就是帶著問題或各種人員的不滿硬上。當然這兩種都是比較極端的結果。理性思考下，這裡面有沒有規律在？今天，阿里高階開發專家墨玖和你聊聊，如何做好一個技術專案的PM。

目標分析

對於任何事情要有清晰的目標才能精確把握，如何做好一個技術專案的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 根據各負責角色工作評估做出簡要排期和專案需求+參與方核對各方訴求，確定最終版本。這裡也會遇到幾個問題：

1. 排期時間過長。解：拆分、加人、分階段。建議最小工作單元評估最好不要超過2人日。
2. 其他專案排期衝突。解：分析是產品節奏衝突還是人員(資源)衝突，確認好各自目標再共同協商總體排期。
3. 重要階段未給足充分時間，如設計階段、系統聯調、冒煙、測試、內測等經常忽略項。解：提前協商溝通好協調。

最後，專案排期要和各參與同學溝通清楚投入度和時間節點。一定要明確幾個重要的時間點：設計評審、測分評審時間、提測時間、產品驗收時間、釋出時間(如果客戶端還要根據不同端特殊情況分開列出)。同時排期過程中可能遇到的並行風險、人員資源風險及時對外同步。

設計+測分評審

設計之於專案隱患+後期擴充套件、測分之於專案質量風險的意義，技術同學想必都是非常清晰明確的。這不僅僅要求專案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要注意的事項：

1. 安排處理好專案測試環境，確保穩定性。
2. 安排各系統CR節奏，並跟蹤反饋。
3. 安排釋出計劃討論和準備。制定並總結初步釋出執行計劃(單點對應明確責任人)。
4. 安排討論確定版本限制相容方案。
5. 安排準備線上功能開關和灰度方案。
6. 重要專案要有釋出預演。
7. 預發和線上不隔離的系統要注意單獨考慮預評估發測試風險。有必要的給出操作步驟。

產品驗收

一般情況測試完成後就到產品驗收環節了。這個過程有些同學可能就直接不問或者任憑產品驗收結果做最後的質量兜底。這是極為不可取的，原因是一般的產品驗收最多隻會跑到整體專案 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(其他資料使用方)，專案驗收前要再次確認。

本文作者：墨玖

原文連結

本文來自雲棲社群合作伙伴“阿里技術”，如需轉載