在阿里，我如何作好技術項目管理？

阿里妹導讀：在技術公司、尤爲是互聯網公司，技術人員做爲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(其餘數據使用方)，項目驗收前要再次確認。

---

本文做者：墨玖

閱讀原文

本文來自雲棲社區合做夥伴「阿里技術」，如需轉載請聯繫原做者。