在技術公司、尤其是互聯(lián)網(wǎng)公司，技術人員作為 PM(項目經(jīng)理)是非常常見的。

[[274079]]

圖片來自 Pexels

有些同學得心應手，有條不紊，能得到清晰穩(wěn)定的預期結果;有些同學則在過程中遇到各種鬧心的事，最后不是項目上不了線，就是帶著問題或各種人員的不滿硬上。

當然這兩種都是比較極端的結果。理性思考下，這里面有沒有規(guī)律在?今天，阿里高級開發(fā)專家墨玖和你聊聊，如何做好一個技術項目的 PM。

目標分析

對于任何事情要有清晰的目標才能精確把握，如何做好一個技術項目的 PM?首先我們看到這里面目標最起碼應該是：如期交付有質量保障的項目產出。

這里有幾個需要我們注意的結果關鍵詞：

• 如期交付(守時守信)
• 質量保障(保質保量)
• 項目產出(完整結果)

當然還有最重要的因素：人+過程。阿里有句老話叫做：沒有結果的過程是放屁，沒有過程的結果是垃圾。

所以，項目管理也是一樣。我們既要結果，又要過程，當然，還要這里面人舒服 。

這里我們再總結提取下目標：

項目目標：如期交付(守時守信)、質量保障(保質保量)、項目產出(完整結果)。

人員目標：舒服、有成就、有成長。

過程目標：風險控制、信息同步。

接下來我們就按照項目的生命周期來看看以上目標要怎樣才能更好地達成。

目標達成

項目啟動

項目啟動重要點是需求宣講，俗稱畫餅拉人。任何一個項目都會有既定的目標和預期，但是這個目標大家認不認?如何衡量結果好壞?做完后有沒有成就感?

這是項目后續(xù)成敗的關鍵。所以你需要思考好這些東西，才能和大家宣講、才能拉人干事。

不然人家都不知道你要干啥、干了有啥好、為啥要(賣力)給你干。作為項目 PM 的你定義好項目目標、衡量結果(ROI)、人是尤為重要的 。

這里提幾點建議和思考：

• 目標：你為何要做這件事?
• 目標：你的目標有沒有足夠明確?有沒有清晰的大圖?
• 目標：做這件事的意義是什么?
• 結果：你有沒想清楚這個目標的關鍵因素，核心指標是什么?
• 結果：有沒有附加的影響和因素?是好的還是壞的?
• 人：你自己是否足夠清晰能夠完成項目的重要因素?尤其是大的項目 top-down 的思考。
• 人：你能為大家提供什么來確保順利的分工配合?越俎代庖、撒手不管都是不可取的。
• 人：這個項目需要哪些人?哪些角色?他們核心關鍵是哪些?
• 人：參與這個項目的同學能得到什么?失去什么?共贏嗎?
• 人：參與的同學的成就感在哪里?

當你思考和整理好以上這些東西，才能做好項目(需求)的啟動和宣講。目前我們很多項目的組織方式，是由多個角色完成的。

常見的方式是運營或業(yè)務或產品做了項目中的一部分或所有，然后到需求階段再由技術同學跟進后半段。

這個角色有多人共同分擔并不沖突，重要的是我們要配合默契、銜接得當、相互補位，拿到共贏結果。

工作過程中我見到過激情澎湃的 KO，也見過稀里糊涂到直接開車，所以生活(工作)還是需要一些儀式感。注意做好這些點，項目后面會順暢很多。

需求評審

一般需(hua)求(bing)宣(la)講(ren)完畢后，很快會進入需求評審階段。這里是需求細化，明確重要節(jié)點。

作為一個項目 PM 你必須要做到小需求了如指掌、大需求合理拆分 。這個階段最好是個時間段而不是一個時間點。

尤其是對于互聯(lián)網(wǎng)，我們講究的是快速，節(jié)約大家時間。你有必要提前深入介入，了解需求邏輯和范圍。

這里會遇到如下幾類問題：

①需求(描述或意義)不明確、理解不一致

解：不要牽強、不要害羞。描述不清楚的講(寫)清楚;意義不清楚的增加解釋。

PM 都要搞清楚搞明白，這樣你才能夠在中后期答疑解惑環(huán)節(jié)，節(jié)約信息同步成本。實在不行就回到最開始的目標上去：意義在哪里?

②關鍵人員沒拉到位

解：這個其實我們經(jīng)常會遇到，原因也有很多。事前列好人員信息版(可以放心里)是一個很好的習慣，我個人習慣用釘釘群公告+云雀 Note 頁。事中則需要補救和充分溝通了，還好我們的同學都很能相互理解。

③需求范圍膨脹

解：這個問題也是我們項目中常見導致項目最終崩潰的原因。所以你是需要提早接入需求的，最起碼要比評審早。

確認好項目的人員投入數(shù)量、投入度，確認好本次重要目標和次要目標。適當?shù)臅r候要做需求拆解，不要做超量(加班也可能搞不定)的計劃。不要做好好先生。你要清楚你的職責是如期交付有質量保障的完整結果。

除以上問題外，對于大型的跨團隊的項目可能當下是無法詳細看清全局的。這就需要大 PM 在這個時候量力而行盡早分揀分派、劃定二級責任人。

在互聯(lián)網(wǎng)公司，需求評審過不過一般都會提到需求溝通和宣講。所以，需求評審一般是 PM 認同了項目目標和意義的，這個要特別注意。

所以具有 PM 角色的你(們)要更多的做配合需求拆分細化、答疑解惑;而不是一堆問題瞎懟(這可以發(fā)生在宣講或再靠前)。

這里我提下幾個重要的點：

• 需求評審要提前做好信息充分公開有會議邀請，關鍵人員要拉到位。
• 評審后關鍵參與人明確自身工作目標和職責。
• 重要信息、問題和困難收集。同時做好信息公開同步。
• 重大設計、困難單列單獨跟進。

完成以上后，項目人員也基本鋪開了。接下來更多的需要并行。

項目排期

評審完畢后緊接著的就是再次的資源盤點和目標對焦，簡要的 Recheck 確保補齊。

這時 PM 根據(jù)各負責角色工作評估做出簡要排期和項目需求+參與方核對各方訴求，確定最終版本。

這里也會遇到幾個問題：

• 排期時間過長。

解：拆分、加人、分階段。建議最小工作單元評估最好不要超過 2 人日 。

• 其他項目排期沖突。

解：分析是產品節(jié)奏沖突還是人員(資源)沖突，確認好各自目標再共同協(xié)商總體排期。

• 重要階段未給足充分時間，如設計階段、系統(tǒng)聯(lián)調、冒煙、測試、內測等經(jīng)常忽略項。

解：提前協(xié)商溝通好。

最后，項目排期要和各參與同學溝通清楚投入度和時間節(jié)點。

一定要明確幾個重要的時間點：設計評審、測分評審時間、提測時間、產品驗收時間、發(fā)布時間(如果客戶端還要根據(jù)不同端特殊情況分開列出)。同時排期過程中可能遇到的并行風險、人員資源風險及時對外同步。

設計+測分評審

設計之于項目隱患+后期擴展、測分之于項目質量風險的意義，技術同學想必都是非常清晰明確的。這不僅僅要求項目 PM，對于核心的系分、測分設計人員也提出嚴格要求。

務必保證：

• 重要流程有圖、有文字、有用例覆蓋。
• 重要設計方案、測試方案要提前溝通討論評估風險和影響。
• 需要考慮資金、安全、性能、風險的，單列 To Do List+Check List。
• 重要設計影響對外同步。

對于技術型的 PM，最好滿足其中一項：

• 項目中的核心設計者。
• 業(yè)務 Owner 或核心。

這里主要是考慮到技術項目 PM(實在不行要有核心設計人員)對于業(yè)務定型、技術定型在業(yè)務中后期的影響著實太大。

此階段開始作為過程跟蹤重要手段需要有常規(guī)的項目日報和風險提示了。建議對于工作日小于 20 人日的項目可以不用每天發(fā)項目日報，有風險及時同步即可。

超過的最好每日有項目詳細進度， 根據(jù)項目復雜度不同粒度可以精確到單人負責的模塊。重要的是過程跟蹤+問題及時反饋解決。

[[274080]]

研發(fā)過程

研發(fā)過程中一般大家精力都會集中在各自項目負責模塊上。同時對于我們這種互聯(lián)網(wǎng)公司，變化又是家常便飯。

這里有個原則是信息跟蹤和同步評估要充分?？赡苌婕暗脚牌谡{整的，要及時溝通和調整。也要注意風險和項目范圍把控。

這時你可能會有如下幫助：

• 項目空間任務列表(aone 有批量功能)
• 排期進度表(云雀)
• 需求變更實錄表(云雀)
• 人員負責表(云雀)
• 風險跟蹤列表(云雀或 aone)
• 過程進度日報：模塊進度條百分比、當日工作主要內容、風險同步與處理。
• 重要邏輯影響對外同步(如表邏輯、業(yè)務邏輯變更的，需同步對應使用方)。

冒煙+聯(lián)調+提測

大家都知道大多數(shù)的線上技術問題都可以在測試階段提前發(fā)現(xiàn)。而 PM 要思考的是測試前我們能做什么?

提測前的冒煙、聯(lián)調包含了必要的單元測試、功能測試和部分集成測試。尤其是對于多系統(tǒng)聯(lián)動的項目冒煙和聯(lián)調的質量直接影響到測試效果和線上問題量。

這里 PM 一定要提前溝通評估安排好時間控制和冒煙聯(lián)調節(jié)奏，有必要的話集中閉關+小階段目標設定可以實行 。

同時對于復雜的項目由于整體節(jié)奏和工作壓力等原因參與人員很容易陷入自我流程和模塊邏輯里。

在聯(lián)調階段作為 PM 最好能設計出幾個經(jīng)典業(yè)務場景作為聯(lián)調目標，對項目的整體質量做提早把控。

重要項目特殊建議：

• 全量(70%+)含憑證冒煙。
• 流程覆蓋設計+測試執(zhí)行(PM)。
• 閉關聯(lián)調+分模塊分階段聯(lián)調半日目標進度。
• 獨立的項目聯(lián)調環(huán)境準備。
• 關鍵鏈路的日志標要求。

無論是作為核心開發(fā)還是純 PM，此階段都需要主動去檢查項目的研發(fā)交付程度。包含但不限于主業(yè)務流程、特殊分支邏輯等。

你可以根據(jù)項目重要程度復雜程度來判斷是否需要精細化。同時此階段也很容易暴露缺失或錯誤邏輯。

我個人做法是小型項目自己設計場景 Case 走;大型項目聯(lián)合核心研發(fā)測試一起設計場景 Case;同時注意對產品交互和 Demo。

測試

項目到了測試階段大部分的開發(fā)工作已經(jīng)基本結束了。我們這里討論一種場景是開發(fā)測試由不同人員執(zhí)行。

測試 Bug 要督促做到日清，不能日清的需要有原因跟蹤。本階段一般也是 Code Review 集中階段。

PM 應直接或間接的對于關鍵鏈路設計、流程日志記錄、編碼規(guī)范要著重把關。

同時產品發(fā)布+回滾方案在本階段要做準備了。一般來說每個團隊發(fā)展到 2 年后都會有比較規(guī)范的發(fā)布計劃模板。

這里我們著重提及幾點 PM 要注意的事項：

• 安排處理好項目測試環(huán)境，確保穩(wěn)定性。
• 安排各系統(tǒng) CR 節(jié)奏，并跟蹤反饋。
• 安排發(fā)布計劃討論和準備。制定并總結初步發(fā)布執(zhí)行計劃(單點對應明確責任人)。
• 安排討論確定版本限制兼容方案。
• 安排準備線上功能開關和灰度方案。
• 重要項目要有發(fā)布預演。
• 預發(fā)和線上不隔離的系統(tǒng)要注意單獨考慮預評估發(fā)生測試風險。有必要的給出操作步驟。

[[274081]]

產品驗收

一般情況測試完成后就到產品驗收環(huán)節(jié)了。這個過程有些同學可能就直接不問或者任憑產品驗收結果做最后的質量兜底。

這是極為不可取的，原因是一般的產品驗收最多只會跑到整體項目 Case 的 30% 不到，越是大越是復雜的項目這個比率越是低。

產品驗收的目標是檢查產品功能完整性、產品體驗，而對 C 的線上用戶幾乎會全方位無死角覆蓋。

所以這次是你產品(功能)細節(jié)問題的最后一次機會?？紤]到項目成本+收益+重要程度，對于特殊項目需要單獨的組織參與人員設計并執(zhí)行內部驗收，以確保多人更大范圍的產品檢驗。

這個事情有兩個重要意義：

• 項目產品信心建立。
• 項目產品功能體驗 Review。

一般性的準備，我這里也列舉下：

• 產品驗收 Check List。
• 驗收環(huán)境準備。
• 驗收數(shù)據(jù)準備。
• 驗收問題列表。
• 變更列表(云雀或 aone)，此時的改動要特別注意變更風險和范圍評估。
• 數(shù)據(jù)、BI、埋點驗收準備。
• 產品驗收數(shù)據(jù)收集(可選)。

項目發(fā)布

在以上階段都完成后，就到了項目發(fā)布的最重要階段。在準備好發(fā)布計劃的前提下，要注意多系統(tǒng)聯(lián)動的發(fā)布時間節(jié)奏、依賴控制、風險控制、線上驗證等把握。

嚴格執(zhí)行發(fā)布流程和回滾方案的同時，注意以下幾點：

• 提醒系統(tǒng)發(fā)布前中后檢查，建立通知機制(發(fā)布群)。
• 系統(tǒng)發(fā)布要注意 API 變更、數(shù)據(jù)及表結構變更等對線上邏輯的影響評估。(一般預發(fā)布已經(jīng)做了)
• 發(fā)布后的線上檢查，特別注意檢查本身會否影響線上功能和數(shù)據(jù)。
• 最好做到發(fā)布功能有開關+線上白名單。
• 復雜項目的發(fā)布一般會選在晚上，但同時要做好分班跟進計劃。
• 發(fā)布完、線上驗證完畢后，項目發(fā)布郵件及通知同步要到位。

復盤總結

互聯(lián)網(wǎng)公司，唯快不破。再快的產品功能發(fā)布也需要回到我們最初的本源，目標有沒有達成?所以回到我們項目起初制定的目標和衡量標準，需要有個目標達成總結。

重要的點提及下：

• 項目目標衡量數(shù)據(jù)統(tǒng)計。
• 過程優(yōu)缺點復盤，揚長避短(非所有項目)。
• 較為成功的項目要及時安排慶祝(儀式感很重要)。

其他的補充

互聯(lián)網(wǎng)公司有個很大的挑戰(zhàn)就是，項目節(jié)奏壓力。同時通過以上我們也可看到想要做好一個項目是需要付出很多的，有很多東西都是默默地背后的。

項目也好，產品功能也好。都是人做出來的。再牛逼的業(yè)務宣講、再清晰的目標設定、再精細流程把控最終都逃不過人這個核心的落腳點。

作為 PM 你要時刻反思：

• 真正的業(yè)務訴求是什么?
• 項目有沒有偏離軌道?
• 這個人跟你做項目能不能得到成長、成就?
• 他有沒有被你推到了墻角?
• 你是否能觀察判斷到可能的風險并最好規(guī)避、次之解決?
• 你會否會因為一個項目，一場仗而得到一批干將?

這是除了項目結果以外我們需要思考的。不僅僅是業(yè)務或技術，這是為了走的長遠、是準備未來。

關于數(shù)據(jù)變更(結構+數(shù)據(jù))：包含表結構變更、數(shù)據(jù)格式變更、數(shù)據(jù)內容變更等在細分階段要同步 BI(其他數(shù)據(jù)使用方)，項目驗收前要再次確認。