学了阿里中台，却依然做不好系统？ 聊聊阿里的项目管理
戳藍字“CSDN云計算”關注我們哦！
作者 | 墨玖
來源|? 阿里技術
導讀：在技術公司、尤其是互聯網公司，技術人員作為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 根據各負責角色工作評估做出簡要排期和項目需求+參與方核對各方訴求，確定最終版本。這里也會遇到幾個問題：
排期時間過長。?解：拆分、加人、分階段。建議最小工作單元評估最好不要超過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(其他數據使用方)，項目驗收前要再次確認。
福利
掃描添加小編微信，備注“姓名+公司職位”，加入【云計算學習交流群】，和志同道合的朋友們共同打卡學習！
推薦閱讀：
做了中臺就不會死嗎？每年至少40%開發資源是被浪費的！
美女主播變大媽：在bug翻車現場說測試策略
漫畫高手、小說家、滑板專家……解鎖程序員的另一面！
手把手教你如何用Python模擬登錄淘寶
鴻蒙霸榜 GitHub，從最初的 Plan B 到“取代 Android”？
每天超50億推廣流量、3億商品展現，阿里媽媽的推薦技術有多牛？
真香，朕在看了！
總結
以上是生活随笔為你收集整理的学了阿里中台，却依然做不好系统？ 聊聊阿里的项目管理的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： let's silim怎
- 下一篇： Boost：can_queryr的使用测