👉騰小云導讀
程序員對工作量評估不準確？日常臨時問題打亂排期？怎麼讓大家對需求的理解一致？如何既保證開發效率又保證質量？項目管理是「把事情做對」的重要能力之一。知識型工作者包括程序員，在工作中都不知不覺中扮演着「非職業項目經理」的角色。具備項目管理能力，對程序員職業發展、個人生活都有重大價值。本文詳細分析程序員如何進行進度管理、質量管理和風險管理。
👉 看目 錄
1 爲什麼開發者需要懂項目管理
1.1 項目管理是“通過別人做成事情”的能力
1.2 項目管理能輸出個人影響力
1.3 項目管理對個人生活也有價值
2 開發者在項目管理中會遇到哪些問題
2.1 開發者的痛點
2.2 怎麼衡量項目管理的“好/壞”？
2.3 開發者需要哪些能力
3 開發者怎麼做好項目管理
3.1 如何做好進度管理
3.2 如何做好質量管理
3.3 如何做好風險管理
4 總結
本文由騰訊MoonWebTeam團隊的賴文輝、蔡卓倫、劉冬、陳長吉協作完成
01、 爲什麼開發者需要懂項目管理
“動機”有時比“行動”更重要。瞭解一個事物的價值，能讓事情做的更好。學習項目管理能帶來什麼好處呢？《項目管理精華》一書將項目管理視爲「21 世紀獨有的工作」，作者認爲每一名知識型工作者都在工作中不知不覺中扮演着「非職業項目經理」的角色。開發者其實就是典型的知識型工作者。總體來說項目管理對開發者的職業發展和個人生活均有着很大的價值。
1.1 項目管理是「通過別人做成事情」的能力
古往今來，如何驅動一個人做成一件事情，一直都是一個人稀缺的能力。
漢高祖劉邦有一句經典名言：“夫運籌策帷帳之中，決勝於千里之外，吾不如子房(張良)。鎮國家，撫百姓，給饋饟，不絕糧道，吾不如蕭何。連百萬之軍，戰必勝，攻必取，吾不如韓信。此三者，皆人傑也，吾能用之，此吾所以取天下也。”正是劉邦具備協調張良、蕭何、韓信三人協同工作的能力，才使得其能奪取天下，建立大漢王朝。
反觀劉邦的對手項羽，當初憑着個人英雄主義，勢力一度增加。但勢力增大、地盤擴大後，面對紛繁複雜的戰爭形勢，他沒能協調好手下的將領，沒做到知人善用。最終落得“至今思項羽，不肯過江東”的下場。
而項目管理正是使他人協同做成一件事情，達成目標的能力。試想一下，擁有這樣能力的人，在哪個團隊會不受歡迎？而且這樣的能力並不會隨着年齡而降低，反而越老越喫香。
1.2 項目管理能輸出個人影響力
項目管理中很多做事情的方法都很符合「爲人處事」之道，例如學會及時同步信息的能力。將各類信息及時且高效的以合理的渠道同步給對應的角色，就很容易成爲別人眼中「靠譜的人」。
《微權力下的項目管理》一書講到項目經理往往需要有個人魅力去影響他人做事，進而達成目標。項目管理能提升與各類干係人打交道的能力，進而提升一個人在組織內的個人影響力。
1.3 項目管理對個人生活也有價值
其實生活中很多事情都符合寬泛的項目的定義。舉個例子，房屋裝修就是非常典型的項目：
裝修工期長，涉及各種材料購置。一次性購置材料會阻礙工人幹活，分批購置，又怕丟三落四忙不開；等師傅進場再買，又擔心延誤工期。除此之外，裝修還需要與各類工種打交道，要合理安排各工種工作排序、工期管理。在裝修中，能不能少花點錢，就看一個人“成本管理“做得怎麼樣；能不能快點住進新房子取決於一個人的“進度管理”；而能不能住的安心，就要看“質量管理”有沒有做好。
生活中處處是項目，掌握項目管理的能力，對於個人生活大有裨益。
02、 開發者在項目管理中有會遇到哪些問題
說了這麼多好處，大家一定很關心開發者在工作中怎樣做好項目管理。在講怎樣做好之前，我們先探討一下在項目管理中有什麼痛點，再分析下在開發項目中哪些部分涉及項目管理以及如何衡量項目管理成功與否，最終目的是提煉出開發者需要的項目管理能力。
2.1 開發者的 痛點
作者在寫文章之前調研了身邊部分開發者同事在項目管理上的痛點，總結起來主要包括以下幾類問題：
- 工作量評估問題：工作量評估不準確。
- 進度問題：日常雜事或者臨時問題打亂排期。
- 外部依賴問題：設計/後臺等外部資源延期/需求變更，怎麼推動解決？
- 溝通問題：如何讓大家對需求的理解保持一致？
- 效率和質量平衡問題：怎麼既保證開發效率又保證質量？
- ... |
2.2 怎麼衡量項目管理的好與壞
也許大家都做過項目管理，但是怎樣知道做的好不好？爲了回答這個問題，作者諮詢了幾位做項目經理的同事，他們講述了很多要素。綜合來看，以下三個要素是都有提到的：進度、質量以及成本。這三要素最終會影響到項目的目標。
- 進度是否符合預期？
這個很容易理解和衡量。你是不是按時完成了項目中每個里程碑階段的任務？你是不是按照預期的時間交付了項目中所規劃的功能點？延期往往也是項目中最容易出現的風險。
- 質量是否達標？
項目的質量是最爲重要的要素。直接關係到各個利益相關者，直接影響項目目標的達成。作爲開發工程師，質量是否達標也關係到個人及團隊的技術口碑。
- 成本是否可控？
你是否設法在預算範圍內交付某個項目？這個預算究竟是高還是低？和平均線偏差多少？對於開發人員而言，可以關注投入的機器資源及人力成本是否合理。
2.3 開發者 需要哪些能力
在大家關注的邊界裏，基於衡量好壞的標準並以解決實際痛點爲目標，可以提煉出我們需要的能力模型：進度管理、質量管理、風險管理。由於成本管理不是痛點，所以此處不提。下文我們展開講述。
03、 開發者怎樣做好項目管理
以下將從進度管理、質量管理、風險管理三項展開闡述如何做好項目管理。
3.1 如何做好進度管理
如何合理地利用資源、按時完成項目是做好項目管理最基本的要求。大多數失敗的項目是由於不合理的進度規劃導致的。所以做好進度管理是做好項目管理的關鍵。接下來將詳細地介紹進度管理基本的概念和內容，以及做好項目管理的基本流程和思路。
剖析在做進度管理中的重難點，主要從評估工作量、依賴管理、意外事項的處理三個方面進行分析。下面我們展開介紹。
3.1.1 如何做好工作量的評估
做好工作量評估是做好進度管理最關鍵的一步，合理地對需求進行分析和拆分，明確各個階段具體的事項，再根據日常的工作經驗，對各事項所花費的時間加以估算，才能將整個大的需求的工作量評估得更加準確。
- 需求詳細方 案設計
做好工作量評估的第一步，是做好詳細需求方案的設計。一份完整的需求方案設計包括：概要設計、詳細設計、監控、容災等內容。前期有詳細的方案設計，才能對項目整體上有更好的把控，同時也有助於任務拆解等工作。
在做完需求詳細設計方案後，再通過有開發經驗的工作人員評審。一般經驗豐富的開發人員能夠通過設計方案發現背後的風險，能夠及時將架構設計的不合理、兼容性未考慮等問題提前暴露出來，同時也能更加明確工作量。理論上來說，在完成需求方案評審後，後續的改動很少，整體的工作時長更加可控。
這裏需要重點關注的是，如果開發週期大於一個月，建議分成多個需求迭代，以降低迭代週期，小步快跑。
- 合理拆解，明確職責
在完成需求方案詳細設計後，對任務進行合理拆解。怎樣拆解纔是合理的？首先我們詳細介紹下4個拆解的原則。
下面我們詳細瞭解下如何進行任務拆解。以正常迭代一個 h5 項目的功能爲例，一共有四個大的功能模塊，三個開發人員。那麼我們需要： 事項 | 解析 | | -------------- | ----------------------------------------------------------------------------------------------------------- | | 自頂向下，逐層拆解 | 通過 WBS 的工具，對項目進行拆解。爲保證任務拆解之後的完整性，應將整體的項目自上向下，逐層拆解。這有利於排查項目開發的各個階段是否有遺漏。按照項目的研發流程進行拆解任務，再將各個任務進一步細分到所需時間爲兩天。 | | 落實負責人，確認拆解是否合理 | 將每個任務落實到該任務負責人，負責人能夠從自己的角度出發，進一步思考該任務的拆解是否合理，同時也能夠明確自己所負責的任務需要和誰對接，更能夠了解聯調的成本。 | | 總體覆盤，確認有無遺漏任務 | 最後大家根據開發經驗，梳理整體流程有無遺漏，如單元測試，埋點開發，聯調，代碼的 mr 等。
- 估算工作，知曉預期
在對任務進行拆解後，下一步是對任務進行工作量評估。這個過程在項目管理中，也是一個非常棘手的事情。工作量評估不準確，就會直接導致該任務項出現問題。評估的時間偏多，會存在着資源浪費的問題；評估的時間偏少，將直接造成當前任務延期完成，同時阻塞後面模塊的開發，損失更大。
接下來介紹兩種工作量估算方式，一種是自上而下的估算方式，一種是自下而上的估算方式。 估算模式 | 解析 | | ---- | ------------------------------------------------------------------------------------------------------------------------------------------------- | | 自上而下 | 自上而下的估算方式是以項目總體爲估算對象。這對於有類似項目經驗的工程師來說較容易評估。方法是將工作結構從頭部向尾部依次分配、傳遞工作量，直到到達WBS 的最底層。其特點是：項目初期信息不足，只能初步分解工作結構，很難將最基本的工作詳細內容列出來。 估算的精度較差。 估算的工作量小，速度快。 | | 自下而上 | 自下而上的估算方式是，先估算各個工作項的工作量，再自下而上的將各個工作量進行彙總，算出總的工作量。其特點是： 估算的精度高。 估算的成本較大。 缺少子工作項之間的工作量估算。
3.1.2 如何做好依賴管理
因爲外部依賴而導致項目延期的情況在工作中屢見不鮮，常見的諸如：
- 準備開始開發了，發現設計稿還未就緒。
- 準備聯調的時候，發現我們上下游的技術團隊的接口還未就緒。
- 可以聯調的時候，因爲上下游的鏈條很長，出現推諉甩鍋。
...
以下是一些針對外部依賴問題的解決方法。
| 解決方法 | 解析 |
|---|---|
| 明確責任人和交付時間，避免模糊 | 這是第一步。當一個事情出現多個負責人的時候，責任的邊界就會模糊，就容易互相推諉的情況，這就是責任分散效應。三個和尚沒水喝的故事就是一個典型案例。因此對於每個依賴項，我們需要明確其責任人，並溝通明確每個人對應依賴的交付時間，把責任人和交付時間提前確定清楚，可以減少很多爭議和推諉。當項目涉及很多團隊的時候，可以使用資源依賴列表，當遇到問題時，可以快速查找負責人及其應當交付的時間點。例子：雲遊 XX 活動的資源依賴列表 |
| 形成信息對齊機制 | 確定了接口負責人後，如果不及時進行信息對齊，也會出現跑偏的情況。反面案例：A 項目依賴外部的 sdk的 某個升級版。在最初的對齊方案中，sdk 方承諾不會修改原有的接口調用方式。而實際聯調中才發現不僅接口調用方式發生了巨大變化，還有部分被依賴的接口直接在新版本中移除，導致A方需要花費大量時間進行兼容。如果提前對齊而不是等到聯調階段才介入，就能規避上述問題。關於信息對齊方式，有以下幾種：不定期的非正式溝通 在里程碑等關鍵節點通過面對面、電話、企業微信等方式進行信息對齊。對齊內容包括：開發進度、依賴事項進展、技術方案變更等，對於一些關鍵性的結論，最好有文字落地以用於回溯。定期的例會機制 如定期晨會機制。在會議上對齊項目進度，可以提前發現可能存在的風險。記錄會議紀要並通過羣消息/文檔/郵件的形式通知到項目的相關干係人。項目 owner 機制 應當確定一個項目 owner，對項目整體負責，把關整體節奏，負責組織會議。把相關信息進行整合，並同步給項目的相關干係人。 |
| 求同存異，達成共識 | 作爲項目組的成員，大家的核心目標應是一致的，就是讓這個項目能夠如期保質上線。但在實際執行中，各個依賴方因爲各自的問題，會出現一些偏差。只要能核心目標是一致的，相關的問題就可以通過溝通解決。案例：春節活動需求變更 PK作爲最重要的傳統節日，很多業務團隊都會針對春節這個時間節點運營、上線活動，作者曾經遇到過在臨近提測時，活動仍在被提需要大量變更的情況（運營人員要疊加功能，設計人員則提出更多特效的要求），開發人員如果接受了大量變更，不僅意味着不斷加班，更可怕的是會由此帶來很大的質量風險，一旦出現嚴重問題，會得不償失。最後只能是開發人員聯合測試人員，跟運營和設計進行了溝通，研發側認可變更對於提升活動效果有作用，同時也對變更可能帶來的延期，以及影響線上質量等風險進行了全面分析評估。雙方基於共同的目標做出了協商和讓步（既保證活動效果，同時也保證活動正常安全上線）。 |
| 情感賬戶，軟性推動 | 當項目依賴某個外部團隊的人員支持，而這個事情並不是對方當前工作範圍內的，並不是對方第一優先級的工作，該怎麼辦？大部分情況，有些開發者會在溝通未果的情況下，通過上升到leader去推動事情落地，這是一種解決方案。更優的方案是建立相關依賴方的“情感賬戶”，藉助“情感賬戶”去軟性推動。大家都知道銀行賬戶就是把錢存進去，作爲儲蓄，以備不時之需。“情感賬戶”裏儲蓄的是人際關係中不可或缺的信任。經營好「情感賬戶」，也是經營好一個人與合作伙伴的信任關係。在日常工作中多喫虧，讓自己的「情感賬戶」適當“存儲”。例如自己曾經抽出休息時間幫助合作伙伴解決問題，當需要對方協助的時候，相信也能得到積極的響應，這也是常說的“喫虧是福"。 |
3.1.3 如何處理意外事項
排期後進入開發，還是會存在各種事情影響項目的進展。例如：插入一些高優的需求，或者說發生一些不可控的因素如疫情等等導致人力不足，從而影響項目的進展。下面我們詳細介紹幾種情況及其處理方式。
1. 需求的變更
在設計詳細需求方案中，如果考慮得不夠周全，開發過程中就會產生需求變更。
處理方式：
- 判斷需求變更的大小，如果是樣式修改等簡單變更，半小時能解決的小問題，可以協助快速調整；如果工作量在 0.5 天以上，並且需要依賴第三方接口，則需要將整體的需求重新評估，重新梳理排期，並同步給干係人。
- 先保證核心的業務流程不變，高收益的工作量優先處理，保證正常的上線時間，後續有餘力再對其它功能點進行迭代優化。
2. 高優需求插入
在業務的開發過程中，可能存在被高優需求插入的情況，如果被高優需求插入，直接帶來的影響是延後當前的工作完成時間。
處理方式：
評估高優需求的工作量，以及影響當前項目的程度。如果在 0.5 天以內，沒有被依賴的下游時，再評估對排期影響不大的情況下是否可以快速響應。並第一時間反饋風險，確保各干係人都有一個心理預期；如果大於 0.5 天的需求，則建議反饋給項目干係人來安排其他人來解決。
3. 不可抗力的因素
不可抗力在項目的開發過程中也是不可避免的。如開發人員有急事需要請假，又或者因爲疫情導致辦公效率低下，從而影響項目的進展。
處理方式：
- 如果是一些身體原因導致辦公效率低下。在不影響整體項目交付的情況下，適當的延長完成項目的時間；若影響到整體項目交付的時間，則應該暴露該風險，進行項目計劃調整。
- 如果完全不能投入開發，應該儘早的將此事向上級報備，由上級進行統一的人力調整，交由其他人投入開發。
4. 內部依賴延後
內部依賴延後影響到項目的進展也是項目開發中經常發生的事情。最好的做法是依賴前置。如果在規定的時間，沒辦法進行交付產物，則會給項目帶來延期風險。
處理方式：
- 將自身的業務流程做好，依賴部分通過模擬的方式解決。
- 將聯調的時間後移，先開發其他的功能模塊。
- 如果已經是最後聯調階段，則需要再次調整交付的時間，同時將該風險同步給相關的干係人。
3.2 如何做好質量管理
質量管理的價值就是保證項目質量以達成項目目標，降低因爲產品質量問題帶來的損失。
3.2.1 通過流程規範提高質量
研發流程是一個精細的過程。需要通過建立執行規範來實現工作標準化和程序化，確保產出質量穩定和高團隊工作效率，降低人爲因素導致的質量問題。
1. 制定研發流程規範
制定流程有時會讓人反感，覺得降低了研發效率。但規範的流程可以大大提升項目的質量，好的流程都是在實踐中不斷總結出來的，是項目的最佳實踐。
當然流程也不是一成不變的，它需要根據我們的具體情況不斷調整優化，才能適應當下的需要。另外應當儘量將流程變成 CICD 的約束，通過系統來約束、控制，減少其對人的依賴。
具體到研發團隊介入一般可分爲需求評審、方案設計、需求開發、測試驗收、發佈上線、項目覆盤六個步驟。這裏提供之前所在前端研發團隊的研發流程圖用以參考：
2. 嚴格執行Code Review
code review 的好處不僅僅是能夠大大提高代碼質量，減少代碼 bug，還能從心理上（自己寫的代碼要給別人審覈）讓自己更認真嚴謹些。另外 CR 交流也非常有利於提升團隊的工程素養，可以針對性補強開發者的知識盲區，糾正不良習慣。
3. 制定發佈checklist
每次發版上線都應當是如履薄冰。爲了保證上線順利，發佈完善的 checklist可大大規避低級錯誤，減少不必要的事故。
發佈 checklist 一般可以分爲服務、機器、流程三部分，通過日常工作中累計容易出錯的地方，將其整理收集起來，持續完善。
這裏提供一份參考案例：
| 階段 | 事項 | 是否通過 |
|---|---|---|
| 提測前 | 根據前期編寫的測試用例進行整體自測 | |
| 根據埋點文檔驗證埋點，確保埋點中的事件和維度不多報、不漏報、不錯報、不重複報、報的時機正確 | ||
| 根據設計稿疊圖並截圖（2+測試機），確保無視覺問題 | ||
| 確保分支的代碼 CR 通過 | ||
| 確保代碼已發佈到測試環境，並確認頁面能夠正常訪問 | ||
| 確保創建了提測單，提測單包含測試用例地址、測試範圍、測試入口和二維碼、終端環境、埋點文檔地址 | ||
| 確保需求單狀態扭轉到增量測試中 | ||
| bug修復後 | 涉及到功能、邏輯、埋點、樣式和交互變更：重新走本次需求邏輯部分的自測、涉及樣式的疊圖、CR 和發佈測試環境流程，確保全流程無誤 | |
| 確保bug單狀態扭轉到已處理，並通知測試同學驗證，保證在 1D 之內扭轉到已關閉 | ||
| 確保需求單狀態扭轉到待發布 | ||
| 發佈前 | 確保產品體驗、設計走查、測試都通過 | |
| 確保所有代碼（功能+bug 修復）都已經通過 CR，合入 master | ||
| 確保正式環境配置文件中的配置都是正式環境的配置 | ||
| 如圖片有新增和修改，確保圖片已經進行過壓縮 | ||
| 確認接口監控的數據正常，業務錯誤碼屏蔽正常，不誤報 | ||
| 上線前和產品運營確認線上配置是否正確，涉及運營資源是否到位 | ||
| 和後臺、終端確認好發佈順序，並確保按照約定順序發佈 | ||
| 確保在羣裏進行發佈周知，提交的發佈審批通過才能進行發佈 | ||
| 發佈後 | 待 CDN 生效後，用非公司 wifi 訪問頁面，確保頁面正常，同時確保所有的資源都是正式的 CDN 地址 | |
| 關注告警羣消息，關注告警監控平臺流量監控是否有較大波動，JS 報錯、接口錯誤率是否有上漲，關注是否有告警 | ||
| 發佈出現問題，及時在羣裏周知並回滾，通知leader，並尋求團隊成員協助定位排查 | ||
| 發佈外網後需要留守至少 30 分鐘 | ||
| 確保需求單狀態扭轉到已交付和已接受 |
很多時候不起眼的清單發揮着非常重要的作用。例如飛機起飛前的檢查清單、手術前後的檢查清單，都守護了無數的生命。更多清單相關內容推薦一本書叫作《清單革命》。
3.2.2 管理變更影響
變更是程序異常的主要原因。 在需求設計階段提前對變更進行評估、規劃，可以確保在對程序最小負面影響的情況下實施這些變更。同時在團隊內進行有效的協商和溝通，可以確保所有的變更都具有可追溯性。下面分別介紹下如何通過詳細設計評審技術方案和通過架構設計上隔離變更。
- 通過詳細設計評審技術方案
編寫技術文檔對部分工程師來說是反感的事情，但好的項目質量一定是設計出來的，而不是測試出來的。
所以在正式編碼前，詳細思考、設計整體方案並編寫成技術文檔在組內評審，是規避質量風險非常好用的方法，也是非常好的開發習慣。它可大大減少編碼階段的質量風險。
以之前筆者團隊爲例，我們還整理了團隊詳細文檔模板，把大家做詳細設計需要考慮的點都囊括了進去，避免大家遺漏。如性能設計、監控日誌設計、安全風險設計、用例設計、容災設計等，既是模板也是詳細設計的 checkList。
- 通過架構設計上隔離變更
許多開發者在職業生涯中最害怕的莫過於修改老代碼，有些老代碼讀起來雲山霧罩，完全搞不懂業務邏輯和代碼關係、也不明白這塊代碼爲什麼這麼寫、那塊代碼是什麼意思。使得大家戰戰兢兢、寸步難行。
與之相反的「好代碼」一般都遵循軟件工程概念中的高內聚低耦合原則，模塊之間相互隔離。常見的隔離方式如下：
| 隔離方式 | 解析 |
| 分層架構 | 分層架構的一個重要原則是每層只能與其下方的層發生依賴。由於各層間鬆散的耦合關係，使得開發者可以專注於本層的設計，而不必關心其他層的設計或本次變更會影響到其它層，只需保持本層的接口穩定。大型系統中推薦使用 DDD (領域驅動設計)，將系統拆分成展現層、應用層、領域層、基礎設施層。 |
| 組件化設計 | 組件化可以比喻爲積木。其工作方式信奉獨立、完整、自由組合。目標就是儘可能把設計與開發中的元素獨立化，使它具備完整的局部功能，再通過自由組合來構成整個產品。 |
| 特性開關 | 目前最爲常用的隔離方式還是特性開關。這種方式隔離較爲徹底，如果某種場景不需要該特性，直接關閉開關即可，缺點在於代碼中可能會存在許多開關邏輯。 |
| 資源隔離 | 從物理上隔離變更導致的影響，通常使將其以服務、靜態資源、網絡、內存、進程等方式進行隔離，通過使變更帶來的影響在可控範圍內，隔離其對其他資源的影響。 |
3.2.3 功能迴歸的能力
功能迴歸能力是指：通過自動化的迴歸測試，尋找原始設計中沒有預料到的錯誤。這裏需要考慮到2件事：
第一，有效的測試是設計出來的。
測試左移的意思就是說盡可能地在前期規避質量問題，以提高效率。大家都知道越早發現問題，修復 bug 的成本越低。例如在設計階段發現 bug 只需要改寫流程圖，編碼階段只需要修改代碼，測試階段需要重新走 git 合併 mr 流程，要是到了上線後才發現問題將直接影響是線上用戶，那麼其修復成本和前面的這些相比可能會沒有上限。
- 設計階段：做詳盡的需求分析和測試用例設計，好儘早發現不合理的地方，儘早暴露問題，以便團隊能更早的在需求評審階段識別並修復缺陷。
- 編碼階段：研發可以依照測試用例自行編寫單元測試、接口測試來驗證核心邏輯是否正確。儘可能確保所有代碼被測試到，所有的業務流程都能被測試用例覆蓋到。
第二， 接入自動化測試平臺。
DevOps 工具是目前最適合做測試的集成管理平臺，從需求提交到產品迭代，從產品設計到代碼構建、測試管理、持續集成，整個流程貫穿軟件行業生命週期。在平臺的基礎上將各環節的數據收集、沉澱成量化指標。如在代碼構建階段的流水線集成代碼規範檢測、代碼質量檢測、單元測試、安全性校驗等工具，能夠產出代碼重複率、單測覆蓋率、安全問題數、頁面性能等有效衡量項目代碼質量的數據指標。
3.2.4 發現問題和定位問題的能力
研發階段要儘量保證質量，不出現 BUG。上線後需要確保一旦出現問題，能快速通過告警發現，並快速定位找到原因，從而最大限度降低對現網的影響。下面我們將介紹如何利用監控告警發現問題、規範日誌快速定位問題和利用智能化監控平臺。
第一，利用監控告警發現問題。
在需要監控告警前，開發者需要先定義需要關注哪些問題？筆者主要涉及前端工作，這裏提下前端團隊一般需要關注的問題：
| 類型 | 指標 | 案例 |
| 腳本問題 | 頁面js錯誤、接口錯誤、頁面白屏、資源加載錯誤 等 | 頁面 JS 錯誤 xx is not defined |
| 性能問題 | 首屏耗時、首屏可見耗時、接口平均耗時、接口成功率 等 | 檢測到近 5 分鐘領取禮包接口接口成功率下降觸發告警 |
| 業務問題 | 流量下跌、核心鏈路轉化率下跌、特定業務錯誤上升 | 雲遊戲用戶排隊耗時提高導致用戶流失，需要額外開啓設備 |
然後再跟進對應指標配置所對應的告警策略。
第二，規範日誌快速定位問題。
線上項目的程序出問題，程序本身不會說話只會安安靜靜的掛機。但導致這一現象出現一般就是業務代碼寫得有問題。
如何讓程序能夠「說話」，並準確的說出有價值的信息，這就是日誌的核心價值。日誌要解決的問題是：程序是不是按預期執行？用戶在系統上幹了什麼？程序有沒有執行錯誤？問題是誰造成的？合理日誌的要素如下：
| 合理日誌的要素 | 解析 |
| 日誌時間 | 日誌作爲事件的表述，事件發生的時間是一定要具備的。 |
| 日誌級別 | 應該根據日誌的重要性或嚴重程度劃分等級，常用的日誌級別有：DEBUG、INFO、WARN、ERROR，只有合理定義日誌級別，才能避免日誌混亂。日誌級別也是日誌告警的關鍵條件。 |
| 業務標識 | 用來區分日誌屬於哪塊業務，因爲日誌都是跟業務相關聯的，通過該部分內容便於按業務進行日誌歸類聚合。 |
| 日誌內容 | 根據不同的日誌等級，在日誌內容上會有不同的側重點，儘量描述清楚。 |
| 異常堆棧 | 堆棧異常信息有助於程序異常的排查定位，但這部分信息的記錄輸出，對系統性能有一定的影響，應該酌情考慮，如果記錄異常信息足夠定位異常，就不要打印整個堆棧。一般是 ERROR 打印異常堆棧，WARN 不打印，還有就是通過日誌框架打印，避免用 printStackTrace 方法打印。 |
| 追蹤 ID | 對於單次用戶行爲需要一個唯一的ID 貫穿全鏈路日誌，方便對用戶行爲進行追蹤，錯誤信息也能夠查詢到用戶行爲的上下文，方便定位日誌。 |
日誌記錄的時機如下：
| 日誌記錄的時機 | 解析 |
| 程序流程 | 記錄程序的流轉分支，在關鍵代碼邏輯的執行前後進行相應的日誌輸出，有助於代碼調試。但要避免不必要的日誌輸出，比如一般只在循環體前後記錄日誌，而不在循環體內重複記錄，過多的日誌反而會影響閱讀。 |
| 遠程調用 | 遠程調用也屬於程序流程的一部分，但第三方遠程調用的日誌信息級別，應該與一般的調試日誌區別對待，因爲涉及到外部系統的交互，在出入口處記錄請求響應的信息，這相當重要。 |
| 系統初始化 | 系統初始化需要依賴一些關鍵配置參數，這些參數決定系統的啓動狀態，應該把這些系統初始化信息記錄起來。 |
| 核心業務操作 | 系統用戶進行核心業務操作的行爲，也應該進行記錄，便於進行操作審計。 |
| 可預期的異常 | 這類異常應該有效記錄起來，通過警告方式反饋給相關人員加以關注，避免頻繁發生，最終演化爲不可控的錯誤。 |
| 預期外的錯誤 | 這類異常發生時，要有詳盡記錄，並通知相關人員介入處理，並預留時間作出響應，因爲這種錯誤已經影響系統的正常使用。 |
第三，智能化監控平臺。
每次排查告警問題對程序員而言都是體力活，都想能夠輕鬆，快速的查看日誌，更進一步還有監控平臺能夠直接告訴問題是什麼、怎麼解決。近年來就產生出一些智能數據分析平臺，利用大數據技術及機器學習技術對 IT 基礎架構及應用系統所產生的海量日誌進行實時分析。
能實現大量的日誌模式發現並進行聚類，將大量的日誌原文轉化爲少量的日誌模式，並反應相應模式在日誌原文中的佔比，這大大減少了人工篩選時間，幫助運維人員更快的定位到故障原因。
如果更進一步，那就是在發生告警的時候其可以提供一張監控大盤、影響範圍、觸發異常用戶的全鏈路日誌。信息密度的提高能夠協助我們快速感知服務的整體狀況、評估風險等級，全鏈路日誌也能輔助開發者更快捷的定位問題，提高告警信息觸達的效率和質量。
3.3 如何做好風險管理
如果用一句話來形容風險，應該是這樣的：
風險如鬼魅在深淵潛藏，它可能出現在項目中任何一個環節，在未來的某個時刻出現，對開發者負責的項目產生破壞性的影響。
下面我們分別聊一聊風險管理管的是什麼，以及在實際項目中我們要注意哪些。
3.3.1 風險管理管的是啥
- 風險的本質
風險的本質是一種不確定性帶來的損失。項目風險實質上是項目的三要素：進度、成本、質量中，一個或多個受到了影響，最終影響了整體項目目標的達成。
- 風險的特徵和構成要素
風險具備以下特徵：
| 日誌記錄的時機 | 解析 |
| 客觀性 | 風險是客觀存在的，不以人的意志爲轉移，項目中存在風險是常態 |
| 不確定性 | 風險是否造成損失，以及損失的程度，是不確定的 |
| 可觀測 | 單一風險存在不確定性，但是總體來講是有規律的，有辦法預測的 |
| 可變性 | 風險會隨着應對措施的進行而消失，不會一層不變 |
而風險的構成則包含三要素：風險因素、風險事故、損失。
風險因素會引發風險事故，風險事故會進一步帶來損失。
例如：小 A 是某個緊急項目的研發負責人之一，項目既定的時間是 2022 年 1 月 1 日上線，此時正值解除疫情防控，身邊越來越多的同事感染，小A所在項目組的研發成員也陸續感染，最後項目不得不延期。
可以想想：對於小 A 所在的項目組，風險因素，風險事故，損失是什麼？
- 風險管理怎麼做
風險管理從流程上主要做四件事：風險識別、評估、應對和溝通。下面展開介紹。
風險識別：
核心是找出可能產生風險的“風險因素”，識別分析這些“風險因素”究竟有哪些特徵，可能會影響項目的哪些方面。例如上述小 A 的例子，風險因素就是疫情的放開帶來的感染風險，其特徵就是會導致成員患病無法工作，影響就是項目的延期。
| 風險識別方法 | 解析 |
| 頭腦風暴法 | 一些人聚集起來，進行頭腦風暴，通過彼此的溝通交流，想法、建議、意見進行碰撞，一起發現問題。 |
| 專家調查法 | 由相關領域的專家組成風險小組，通過徵求專家的意見，然後開發團隊綜合彙總整理，再反饋給專家，再次徵求專家的意見，反覆進行 4～5 輪，最終專家們的意見會趨於一致，達成共識。 |
| 情景分析法 | 識別關鍵影響因素，基於該因素可能發生的場景，進行場景內容的分析，進而發現風險可能造成的後果。 |
| 覈對表法 | 將項目範圍、目標、成本、質量要求、進度、類似項目成功或失敗的原因等列在一張表上，進行一一覈對。這種方法可以識別到進度風險、成本風險、質量風險等。 |
| 流程圖法 | 需要建立項目的全鏈路流程圖以及各子域流程圖，這些流程圖可以涵蓋項目的整體流程以及分支細節。通過將實際情況與流程圖一一對比，便可識別風險。 |
上述小 A 的例子屬於進度風險，通過「覈對表法」是比較容易識別到疫情防控開放這個風險因素的。
風險評估：
對已識別出來的風險因素，進行系統分析和研究，評估其帶來風險的概率，造成損失的範圍和程度。
風險評估一般有“定性分析”和“定量分析”兩種：
- 定性分析：根據風險的重要程度和發生概率等指標對風險因素進行排序。
- 定量分析：將體現風險特徵的指標量化，以強化對風險因素的認知。 |
定量分析包括“蒙特卡洛法”、“敏感分析法”、“決策樹”、“影響圖”等，都是非常專業的分析方法。實際上，作爲非專業項目經理的技術人員，一般通過定性分析就可以對風險進行評估了。
如上述小A的例子如果不採取措施，疫情防控的解除帶來的延期風險會隨着時間推移不斷接近嚴重度100%。
風險應對：
在評估完風險的概率和損失範圍之後，就可以爲風險應對提供參考依據了。
風險應對主要以下幾種方法：
| 方法 | 說明 | 例子 |
| 規避風險 | 消除風險因素進而規避風險的產生 | 1、 改變項目目標包含的範圍2、 投入更多的成本（人力、資金） |
| 轉移風險 | 將風險轉移給第三方 | 購買保險 |
| 減輕風險 | 降低風險發生的概率或受影響程度 | 1、 將雞蛋放在不同籃子2、 兜底策略 |
| 接受風險 | 對即將發生的風險，不採取措施 | / |
如上述小A的例子，從“規避風險”的角度，我們可以投入更多的備份人力，或者調整項目目標（如調整上線時間）。從減輕風險的角度，我們可以實施分散辦公（居家辦公），減少項目組成員被“一鍋端”的風險。從接受風險的角度，如果項目因爲疫情帶來的延期是可以接受的，也可以不採納任何措施。
風險溝通：
這也是最重要的，當風險出現時，及時的跟項目干係人做好溝通，以調整項目干係人的預期。
3.3.2 實際項目我們要關注哪些風險
以上是項目管理中，針對風險管理的基本手段。作爲開發人員，大家日常參與的項目，又有哪些會遇到的風險呢？如何更好的應對呢？接下來我們介紹完幾個最長出現的風險後，分別爲各位分享性能風險、安全風險和容災性風險的應對措施。
1、最常出現的風險
從風險的本質出發，最常遇到的風險：
| 風險 | 解析 |
| 進度方面的風險 | 因爲外部依賴、需求變更或者高優需求插入，帶來項目延期風險。這裏在進度管理章節，已經重點介紹瞭如何管理依賴，如何跟產品人員溝通需求變更，以及如何管理好自身的排期。 |
| 質量方面的風險 | 主要是在項目研發環節中會產生質量問題，如自測不充分導致提測期間 bug 數過多，在質量管理一節中也介紹了對應的解決方案。 |
| 成本方面的風險 | 降本增效是最近兩年的主題，大家對成本的關注越來越多。成本也是一項重要風險，特別是大項目，但因爲不是開發通點，本文不展開討論。 |
除了“進度管理”、“質量管理”中提到的解決方法。“進度風險”、“質量風險”，通過前文提到“風險識別”=>"風險評估"=>"風險規避"=>"風險溝通"這些通用的方法論也是可以解決的。
除了“進度風險”和“質量風險”，研發人員，還有一些特定的風險因素需要關注。
2. 性能風險
性能是非常容易被忽視的風險。 研發人員可能忙碌於功能的實現，保障項目正常上線，往往非常容易忽視項目中可能存在的性能問題。
從風險發現的角度，開發者可以通過「性能檢查清單」，梳理出可能帶來性能風險的因素，並在項目開發過程中規避化解。
從風險評估的角度出發，項目性能低下可能會直接帶來項目轉化率的下跌。例如一個支付頁面如果沒有做好弱網支持，在弱網打開慢，就會帶來的支付轉化率不高的問題，進而影響收入。
從風險應對的角度來說，針對核心頁面（例如上述提到的支付頁面），需要採取措施規避風險。非核心頁面（例如一個不重要的介紹頁），可以採取一定措施減輕風險或者是接受風險（從成本角度出發，針對性能做優化可能需要花費更多時間）。
3. 安全風險
安全是互聯網永恆的話題。在當下互聯網環境中，安全風險可以分爲“合規化”帶來的法務風險，以及系統實現漏洞帶來的風險。
- 合規化風險
是因爲不符合相關的法律法規導致的政策風險，如 app 因爲實現疏忽使某些場景未滿足某個保法。
從風險識別的角度出發，可以通過“專家調查法”來發現，通過請求公司的法務，對相關項目規劃進行法務風險評估，並根據法務人員提供的建議進行調整。
- 系統實現漏洞風險
這則是因爲技術實現的漏洞導致的風險。例如：活動沒有做好防刷，導致獎品被刷；頁面沒有做好腳本過濾被 xss 注入攻擊。
以風險識別的角度來說，可以採用「流程法」，對每個環節可能帶來的安全風險進行梳理，如：
- 在“開發測試階段”，確認工程是否在流水線中接入“代碼掃描工具”；
- 在“上線階段”，確認服務是否接入”安全掃描“工具進行掃描；
- 在“運營配置階段”，確認相關運營系統的配置是否經過審查測試
可以採用「覈對表法」，整理常見的安全措施，並在項目研發階段對照覈對：
- 涉及數據查詢修改，必須有登錄態校驗。
- 涉及數據修改，必須要有 token 校驗，避免 CSRF 攻擊。
- 所有輸入都需要白名單校驗，包括從 URL 獲取數據、從 cookie 獲取數據、從表單獲取數據等，避免 SQL 注入、XSS 攻擊等。
- 涉及福利相關，必須有黑產打擊策略。
- 是否有嚴格的用戶權限校驗。
- 涉及外部對接時，必須包含加密或驗籤環節。
- 還存在哪些安全隱患？
- 是否考慮防安全掃描。
針對一些重點項目（比如量級龐大的春節活動），也可以採用「專家調查法」，提交相關的技術方案給到業務安全的人員進行審查，以發現系統設計存在的潛在安全漏洞。
從風險評估的角度出發，與安全相關的風險往往是無法忽視的，是第一優先級需要解決的，因此風險應對手段，往往是需要採取對應措施來規避風險。
4. 容災性風險
缺失針對系統運行異常情況的處理，也是一種潛在風險。從風險識別的角度，同樣也可以使用「覈對表法」來覈對潛在的異常情況是否都有對應的處理措施：
服務可用性相關的核對錶：
-
系統即將面臨的最大流量是多少？
-
需要提前多久跟運維溝通擴容？
-
系統各個環節能承受的流量壓力，哪些環節需要擴容？
-
如果流量陡增、服務過載時，系統有沒有做兜底降級方案?
-
有沒有做多地部署，規避單點風險？
-
...
邏輯實現相關的核對錶：
-
數據結構是否變更，如果變更是否考慮老數據兼容？
-
邊界條件是否。
-
運行環境可能存在的兼容性問題？（前端經常遇到）
-
.... |
從風險評估的角度出發，需要根據服務/頁面的重要性，採取對應的風險應對措施：
一些核心場景（如支付場景），相關服務/頁面一旦出現問題就是直接的經濟損失，因此就需要採取措施規避風險。
一些對用戶感知不是很明顯的場景，則可以採納兜底降級的方案。例如信息流場景下，在面對突增流量衝擊時，推薦系統所能承受的流量壓力要遠遠低於接入服務的承受範圍，這個時候，接入服務就需要保護推薦服務，通過返回兜底數據，減少流量對推薦系統衝擊。
04、 總結
爲什麼開發也要懂項目管理？開發如何做好項目管理？相信各位讀者已有一定感知。本文首先介紹了項目管理對大家在職業和生活中的價值，接着以項目管理中的痛點爲切入點，整體介紹了項目管理中需要掌握的三大能力——進度管理、質量管理、風險管理。
其中進度管理包含工作量評估、依賴管理、處理意外事項等；質量管理包含流程規範建設、管理變更影響、提升功能迴歸能力、提升問題發現和定位效率等；風險管理包含風險管理的基礎方法論，以及實際項目中容易忽視的性能風險、安全風險、容災性風險等。
最後期望本文能幫助開發者提升項目管理技能，提升「把事做成」的能力，成爲合作伙伴眼中「靠譜」的人。以上是本次分享的全部內容，歡迎各位開發者在評論區交流。如果你覺得內容有用， 歡迎分享、點贊、在看。感謝支持。
-End-
原創作者｜賴文輝、蔡卓倫、劉冬、陳長吉
技術責編｜賴文輝、蔡卓倫、劉冬、陳長吉
「變化」對程序員而言是個極大的挑戰，這是萬年老話題了。客戶需求在變，老闆要求在變，產品經理的需求也在變。有程序員表示，當我抱怨變化帶來的加倍工作量，也許還會遭到吐槽：“你程序不怎麼樣啊，不能順應我的變化。”🤒 面對變化，你有怎樣的經驗和方法呢？你有什麼評估工作量的妙計？當變動發生，日常雜事和臨時問題出現打亂排期，你怎麼解決？可以做些什麼來減少「變動」？
歡迎在評論區聊一聊你的看法。在3月24日前將你的評論記錄截圖，發送給騰訊雲開發者公衆號後臺，可領取騰訊雲「開發者春季限定紅包封面」一個，數量有限先到先得😄。我們還將選取點贊量最高的1位朋友，送出騰訊QQ公仔1個。3月25日中午12點開獎。快邀請你的開發者朋友們一起來參與吧！
最近微信改版啦
很多開發者朋友反饋收不到我們更新的文章
大家可以關注並點亮星標
不再錯過小云的知識速遞
