騰小云導(dǎo)讀

(資料圖片)

程序員對工作量評估不準確？日常臨時問題打亂排期？怎么讓大家對需求的理解一致？如何既保證開發(fā)效率又保證質(zhì)量？項目管理是「把事情做對」的重要能力之一。知識型工作者包括程序員，在工作中都不知不覺中扮演著「非職業(yè)項目經(jīng)理」的角色。具備項目管理能力，對程序員職業(yè)發(fā)展、個人生活都有重大價值。本文詳細分析程序員如何進行進度管理、質(zhì)量管理和風(fēng)險管理。

看目錄

1為什么開發(fā)者需要懂項目管理

1.1項目管理是“通過別人做成事情”的能力

1.2項目管理能輸出個人影響力

1.3項目管理對個人生活也有價值

2開發(fā)者在項目管理中會遇到哪些問題

2.1 開發(fā)者的痛點

2.2 怎么衡量項目管理的“好/壞”？

2.3 開發(fā)者需要哪些能力

3開發(fā)者怎么做好項目管理

3.1如何做好進度管理

3.2如何做好質(zhì)量管理

3.3 如何做好風(fēng)險管理

4 總結(jié)

本文由騰訊MoonWebTeam團隊的賴文輝、蔡卓倫、劉冬、陳長吉協(xié)作完成

??

01

為什么開發(fā)者需要懂項目管理

“動機”有時比“行動”更重要。了解一個事物的價值，能讓事情做的更好。學(xué)習(xí)項目管理能帶來什么好處呢？《項目管理精華》一書將項目管理視為「21 世紀獨有的工作」，作者認為每一名知識型工作者都在工作中不知不覺中扮演著「非職業(yè)項目經(jīng)理」的角色。開發(fā)者其實就是典型的知識型工作者?？傮w來說項目管理對開發(fā)者的職業(yè)發(fā)展和個人生活均有著很大的價值。

1.1 項目管理是「通過別人做成事情」的能力

古往今來，如何驅(qū)動一個人做成一件事情，一直都是一個人稀缺的能力。

漢高祖劉邦有一句經(jīng)典名言：“夫運籌策帷帳之中，決勝于千里之外，吾不如子房(張良)。鎮(zhèn)國家，撫百姓，給饋饟，不絕糧道，吾不如蕭何。連百萬之軍，戰(zhàn)必勝，攻必取，吾不如韓信。此三者，皆人杰也，吾能用之，此吾所以取天下也?！闭莿罹邆鋮f(xié)調(diào)張良、蕭何、韓信三人協(xié)同工作的能力，才使得其能奪取天下，建立大漢王朝。

反觀劉邦的對手項羽，當初憑著個人英雄主義，勢力一度增加。但勢力增大、地盤擴大后，面對紛繁復(fù)雜的戰(zhàn)爭形勢，他沒能協(xié)調(diào)好手下的將領(lǐng)，沒做到知人善用。最終落得“至今思項羽，不肯過江東”的下場。

而項目管理正是使他人協(xié)同做成一件事情，達成目標的能力。試想一下，擁有這樣能力的人，在哪個團隊會不受歡迎？而且這樣的能力并不會隨著年齡而降低，反而越老越吃香。

1.2 項目管理能輸出個人影響力

項目管理中很多做事情的方法都很符合「為人處事」之道，例如學(xué)會及時同步信息的能力。將各類信息及時且高效的以合理的渠道同步給對應(yīng)的角色，就很容易成為別人眼中「靠譜的人」。

《微權(quán)力下的項目管理》一書講到項目經(jīng)理往往需要有個人魅力去影響他人做事，進而達成目標。項目管理能提升與各類干系人打交道的能力，進而提升一個人在組織內(nèi)的個人影響力。

1.3 項目管理對個人生活也有價值

其實生活中很多事情都符合寬泛的項目的定義。舉個例子，房屋裝修就是非常典型的項目：

裝修工期長，涉及各種材料購置。一次性購置材料會阻礙工人干活，分批購置，又怕丟三落四忙不開；等師傅進場再買，又擔心延誤工期。除此之外，裝修還需要與各類工種打交道，要合理安排各工種工作排序、工期管理。在裝修中，能不能少花點錢，就看一個人“成本管理“做得怎么樣；能不能快點住進新房子取決于一個人的“進度管理”；而能不能住的安心，就要看“質(zhì)量管理”有沒有做好。

生活中處處是項目，掌握項目管理的能力，對于個人生活大有裨益。

02

開發(fā)者在項目管理中有會遇到哪些問題

說了這么多好處，大家一定很關(guān)心開發(fā)者在工作中怎樣做好項目管理。在講怎樣做好之前，我們先探討一下在項目管理中有什么痛點，再分析下在開發(fā)項目中哪些部分涉及項目管理以及如何衡量項目管理成功與否，最終目的是提煉出開發(fā)者需要的項目管理能力。

2.1 開發(fā)者的痛點

作者在寫文章之前調(diào)研了身邊部分開發(fā)者同事在項目管理上的痛點，總結(jié)起來主要包括以下幾類問題：

工作量評估問題：工作量評估不準確。進度問題：日常雜事或者臨時問題打亂排期。外部依賴問題：設(shè)計/后臺等外部資源延期/需求變更，怎么推動解決？溝通問題：如何讓大家對需求的理解保持一致？效率和質(zhì)量平衡問題：怎么既保證開發(fā)效率又保證質(zhì)量？...

工作量評估問題：工作量評估不準確。進度問題：日常雜事或者臨時問題打亂排期。外部依賴問題：設(shè)計/后臺等外部資源延期/需求變更，怎么推動解決？溝通問題：如何讓大家對需求的理解保持一致？效率和質(zhì)量平衡問題：怎么既保證開發(fā)效率又保證質(zhì)量？...

2.2 怎么衡量項目管理的好與壞

也許大家都做過項目管理，但是怎樣知道做的好不好？為了回答這個問題，作者咨詢了幾位做項目經(jīng)理的同事，他們講述了很多要素。綜合來看，以下三個要素是都有提到的：進度、質(zhì)量以及成本。這三要素最終會影響到項目的目標。

進度是否符合預(yù)期？

這個很容易理解和衡量。你是不是按時完成了項目中每個里程碑階段的任務(wù)？你是不是按照預(yù)期的時間交付了項目中所規(guī)劃的功能點？延期往往也是項目中最容易出現(xiàn)的風(fēng)險。

質(zhì)量是否達標？

項目的質(zhì)量是最為重要的要素。直接關(guān)系到各個利益相關(guān)者，直接影響項目目標的達成。作為開發(fā)工程師，質(zhì)量是否達標也關(guān)系到個人及團隊的技術(shù)口碑。

成本是否可控？

你是否設(shè)法在預(yù)算范圍內(nèi)交付某個項目？這個預(yù)算究竟是高還是低？和平均線偏差多少？對于開發(fā)人員而言，可以關(guān)注投入的機器資源及人力成本是否合理。

2.3 開發(fā)者需要哪些能力

在大家關(guān)注的邊界里，基于衡量好壞的標準并以解決實際痛點為目標，可以提煉出我們需要的能力模型：進度管理、質(zhì)量管理、風(fēng)險管理。由于成本管理不是痛點，所以此處不提。下文我們展開講述。

03

開發(fā)者怎樣做好項目管理

以下將從進度管理、質(zhì)量管理、風(fēng)險管理三項展開闡述如何做好項目管理。

3.1 如何做好進度管理

如何合理地利用資源、按時完成項目是做好項目管理最基本的要求。大多數(shù)失敗的項目是由于不合理的進度規(guī)劃導(dǎo)致的。所以做好進度管理是做好項目管理的關(guān)鍵。接下來將詳細地介紹進度管理基本的概念和內(nèi)容，以及做好項目管理的基本流程和思路。

剖析在做進度管理中的重難點，主要從評估工作量、依賴管理、意外事項的處理三個方面進行分析。下面我們展開介紹。

3.1.1 如何做好工作量的評估

做好工作量評估是做好進度管理最關(guān)鍵的一步，合理地對需求進行分析和拆分，明確各個階段具體的事項，再根據(jù)日常的工作經(jīng)驗，對各事項所花費的時間加以估算，才能將整個大的需求的工作量評估得更加準確。

需求詳細方案設(shè)計

做好工作量評估的第一步，是做好詳細需求方案的設(shè)計。一份完整的需求方案設(shè)計包括：概要設(shè)計、詳細設(shè)計、監(jiān)控、容災(zāi)等內(nèi)容。前期有詳細的方案設(shè)計，才能對項目整體上有更好的把控，同時也有助于任務(wù)拆解等工作。

在做完需求詳細設(shè)計方案后，再通過有開發(fā)經(jīng)驗的工作人員評審。一般經(jīng)驗豐富的開發(fā)人員能夠通過設(shè)計方案發(fā)現(xiàn)背后的風(fēng)險，能夠及時將架構(gòu)設(shè)計的不合理、兼容性未考慮等問題提前暴露出來，同時也能更加明確工作量。理論上來說，在完成需求方案評審后，后續(xù)的改動很少，整體的工作時長更加可控。

這里需要重點關(guān)注的是，如果開發(fā)周期大于一個月，建議分成多個需求迭代，以降低迭代周期，小步快跑。

合理拆解，明確職責

在完成需求方案詳細設(shè)計后，對任務(wù)進行合理拆解。怎樣拆解才是合理的？首先我們詳細介紹下4個拆解的原則。

原則	含義
兩天原則	拆解之后的單個任務(wù)不能太長。太長的話，就會存在工作量評估不準確、整體項目難以把控的問題。同時也不利于工作的合理分配，不能更好地利用人力資源。如果時間太短，就會導(dǎo)致工作交付的頻率過快，開發(fā)者的工作之間也會存在著一定的耦合。拆解的粒度太小，會增加一定的溝通成本，得不償失。最好工作拆解的粒度為一至兩天。
成果作為導(dǎo)向原則	任務(wù)拆解應(yīng)該以可交互的結(jié)果作為導(dǎo)向，并且一定要有輸出。這個輸出應(yīng)該是完整的，不然這個拆解就拆解得不夠透徹，或者說不算一個任務(wù)。
責任到人原則	拆解之后的任務(wù)項，有且只能有一個負責人。即使許多人都可能在其上工作，也只能由一個人負責，其他人只能是參與者。
任務(wù)分層原則	任務(wù)拆解的過程也是一個解耦的過程，避免多個任務(wù)之間有耦合。拆解的過程應(yīng)該是自上向下的，從一個大的任務(wù)，按照其特性進行任務(wù)拆解，不斷地拆解成子任務(wù)，直到拆解到一至兩天的工作量，并且是一個可交付的工作項。

下面我們詳細了解下如何進行任務(wù)拆解。以正常迭代一個 h5 項目的功能為例，一共有四個大的功能模塊，三個開發(fā)人員。那么我們需要：

事項	解析
自頂向下，逐層拆解	通過 WBS 的工具，對項目進行拆解。為保證任務(wù)拆解之后的完整性，應(yīng)將整體的項目自上向下，逐層拆解。這有利于排查項目開發(fā)的各個階段是否有遺漏。按照項目的研發(fā)流程進行拆解任務(wù)，再將各個任務(wù)進一步細分到所需時間為兩天。
落實負責人，確認拆解是否合理	將每個任務(wù)落實到該任務(wù)負責人，負責人能夠從自己的角度出發(fā)，進一步思考該任務(wù)的拆解是否合理，同時也能夠明確自己所負責的任務(wù)需要和誰對接，更能夠了解聯(lián)調(diào)的成本。
總體復(fù)盤，確認有無遺漏任務(wù)	最后大家根據(jù)開發(fā)經(jīng)驗，梳理整體流程有無遺漏，如單元測試，埋點開發(fā)，聯(lián)調(diào)，代碼的 mr 等。

估算工作，知曉預(yù)期

在對任務(wù)進行拆解后，下一步是對任務(wù)進行工作量評估。這個過程在項目管理中，也是一個非常棘手的事情。工作量評估不準確，就會直接導(dǎo)致該任務(wù)項出現(xiàn)問題。評估的時間偏多，會存在著資源浪費的問題；評估的時間偏少，將直接造成當前任務(wù)延期完成，同時阻塞后面模塊的開發(fā)，損失更大。

接下來介紹兩種工作量估算方式，一種是自上而下的估算方式，一種是自下而上的估算方式。

估算模式	解析
自上而下	自上而下的估算方式是以項目總體為估算對象。這對于有類似項目經(jīng)驗的工程師來說較容易評估。方法是將工作結(jié)構(gòu)從頭部向尾部依次分配、傳遞工作量，直到到達WBS 的最底層。其特點是：項目初期信息不足，只能初步分解工作結(jié)構(gòu)，很難將最基本的工作詳細內(nèi)容列出來。估算的精度較差。估算的工作量小，速度快。
自下而上	自下而上的估算方式是，先估算各個工作項的工作量，再自下而上的將各個工作量進行匯總，算出總的工作量。其特點是：估算的精度高。估算的成本較大。缺少子工作項之間的工作量估算。

項目初期信息不足，只能初步分解工作結(jié)構(gòu)，很難將最基本的工作詳細內(nèi)容列出來。估算的精度較差。估算的工作量小，速度快。

自下而上自下而上的估算方式是，先估算各個工作項的工作量，再自下而上的將各個工作量進行匯總，算出總的工作量。其特點是：

估算的精度高。估算的成本較大。缺少子工作項之間的工作量估算。

3.1.2 如何做好依賴管理

因為外部依賴而導(dǎo)致項目延期的情況在工作中屢見不鮮，常見的諸如：

準備開始開發(fā)了，發(fā)現(xiàn)設(shè)計稿還未就緒。準備聯(lián)調(diào)的時候，發(fā)現(xiàn)我們上下游的技術(shù)團隊的接口還未就緒。可以聯(lián)調(diào)的時候，因為上下游的鏈條很長，出現(xiàn)推諉甩鍋。

...

以下是一些針對外部依賴問題的解決方法。

解決方法	解析
明確責任人和交付時間，避免模糊	這是第一步。當一個事情出現(xiàn)多個負責人的時候，責任的邊界就會模糊，就容易互相推諉的情況，這就是責任分散效應(yīng)。三個和尚沒水喝的故事就是一個典型案例。因此對于每個依賴項，我們需要明確其責任人，并溝通明確每個人對應(yīng)依賴的交付時間，把責任人和交付時間提前確定清楚，可以減少很多爭議和推諉。當項目涉及很多團隊的時候，可以使用資源依賴列表，當遇到問題時，可以快速查找負責人及其應(yīng)當交付的時間點。例子：云游 XX 活動的資源依賴列表
形成信息對齊機制	確定了接口負責人后，如果不及時進行信息對齊，也會出現(xiàn)跑偏的情況。反面案例：A 項目依賴外部的 sdk的 某個升級版。在最初的對齊方案中，sdk 方承諾不會修改原有的接口調(diào)用方式。而實際聯(lián)調(diào)中才發(fā)現(xiàn)不僅接口調(diào)用方式發(fā)生了巨大變化，還有部分被依賴的接口直接在新版本中移除，導(dǎo)致A方需要花費大量時間進行兼容。如果提前對齊而不是等到聯(lián)調(diào)階段才介入，就能規(guī)避上述問題。關(guān)于信息對齊方式，有以下幾種：不定期的非正式溝通在里程碑等關(guān)鍵節(jié)點通過面對面、電話、企業(yè)微信等方式進行信息對齊。對齊內(nèi)容包括：開發(fā)進度、依賴事項進展、技術(shù)方案變更等，對于一些關(guān)鍵性的結(jié)論，最好有文字落地以用于回溯。定期的例會機制如定期晨會機制。在會議上對齊項目進度，可以提前發(fā)現(xiàn)可能存在的風(fēng)險。記錄會議紀要并通過群消息/文檔/郵件的形式通知到項目的相關(guān)干系人。項目 owner 機制應(yīng)當確定一個項目 owner，對項目整體負責，把關(guān)整體節(jié)奏，負責組織會議。把相關(guān)信息進行整合，并同步給項目的相關(guān)干系人。
求同存異，達成共識??	作為項目組的成員，大家的核心目標應(yīng)是一致的，就是讓這個項目能夠如期保質(zhì)上線。但在實際執(zhí)行中，各個依賴方因為各自的問題，會出現(xiàn)一些偏差。只要能核心目標是一致的，相關(guān)的問題就可以通過溝通解決。案例：春節(jié)活動需求變更 PK作為最重要的傳統(tǒng)節(jié)日，很多業(yè)務(wù)團隊都會針對春節(jié)這個時間節(jié)點運營、上線活動，作者曾經(jīng)遇到過在臨近提測時，活動仍在被提需要大量變更的情況（運營人員要疊加功能，設(shè)計人員則提出更多特效的要求），開發(fā)人員如果接受了大量變更，不僅意味著不斷加班，更可怕的是會由此帶來很大的質(zhì)量風(fēng)險，一旦出現(xiàn)嚴重問題，會得不償失。最后只能是開發(fā)人員聯(lián)合測試人員，跟運營和設(shè)計進行了溝通，研發(fā)側(cè)認可變更對于提升活動效果有作用，同時也對變更可能帶來的延期，以及影響線上質(zhì)量等風(fēng)險進行了全面分析評估。雙方基于共同的目標做出了協(xié)商和讓步（既保證活動效果，同時也保證活動正常安全上線）。
情感賬戶，軟性推動	當項目依賴某個外部團隊的人員支持，而這個事情并不是對方當前工作范圍內(nèi)的，并不是對方第一優(yōu)先級的工作，該怎么辦？大部分情況，有些開發(fā)者會在溝通未果的情況下，通過上升到leader去推動事情落地，這是一種解決方案。更優(yōu)的方案是建立相關(guān)依賴方的“情感賬戶”，借助“情感賬戶”去軟性推動。大家都知道銀行賬戶就是把錢存進去，作為儲蓄，以備不時之需。“情感賬戶”里儲蓄的是人際關(guān)系中不可或缺的信任。經(jīng)營好「情感賬戶」，也是經(jīng)營好一個人與合作伙伴的信任關(guān)系。在日常工作中多吃虧，讓自己的「情感賬戶」適當“存儲”。例如自己曾經(jīng)抽出休息時間幫助合作伙伴解決問題，當需要對方協(xié)助的時候，相信也能得到積極的響應(yīng)，這也是常說的“吃虧是福"。

不定期的非正式溝通

在里程碑等關(guān)鍵節(jié)點通過面對面、電話、企業(yè)微信等方式進行信息對齊。對齊內(nèi)容包括：開發(fā)進度、依賴事項進展、技術(shù)方案變更等，對于一些關(guān)鍵性的結(jié)論，最好有文字落地以用于回溯。

定期的例會機制

如定期晨會機制。在會議上對齊項目進度，可以提前發(fā)現(xiàn)可能存在的風(fēng)險。記錄會議紀要并通過群消息/文檔/郵件的形式通知到項目的相關(guān)干系人。

項目 owner 機制

應(yīng)當確定一個項目 owner，對項目整體負責，把關(guān)整體節(jié)奏，負責組織會議。把相關(guān)信息進行整合，并同步給項目的相關(guān)干系人。求同存異，達成共識??作為項目組的成員，大家的核心目標應(yīng)是一致的，就是讓這個項目能夠如期保質(zhì)上線。但在實際執(zhí)行中，各個依賴方因為各自的問題，會出現(xiàn)一些偏差。只要能核心目標是一致的，相關(guān)的問題就可以通過溝通解決。案例：春節(jié)活動需求變更 PK作為最重要的傳統(tǒng)節(jié)日，很多業(yè)務(wù)團隊都會針對春節(jié)這個時間節(jié)點運營、上線活動，作者曾經(jīng)遇到過在臨近提測時，活動仍在被提需要大量變更的情況（運營人員要疊加功能，設(shè)計人員則提出更多特效的要求），開發(fā)人員如果接受了大量變更，不僅意味著不斷加班，更可怕的是會由此帶來很大的質(zhì)量風(fēng)險，一旦出現(xiàn)嚴重問題，會得不償失。最后只能是開發(fā)人員聯(lián)合測試人員，跟運營和設(shè)計進行了溝通，研發(fā)側(cè)認可變更對于提升活動效果有作用，同時也對變更可能帶來的延期，以及影響線上質(zhì)量等風(fēng)險進行了全面分析評估。雙方基于共同的目標做出了協(xié)商和讓步（既保證活動效果，同時也保證活動正常安全上線）。情感賬戶，軟性推動當項目依賴某個外部團隊的人員支持，而這個事情并不是對方當前工作范圍內(nèi)的，并不是對方第一優(yōu)先級的工作，該怎么辦？大部分情況，有些開發(fā)者會在溝通未果的情況下，通過上升到leader去推動事情落地，這是一種解決方案。更優(yōu)的方案是建立相關(guān)依賴方的“情感賬戶”，借助“情感賬戶”去軟性推動。大家都知道銀行賬戶就是把錢存進去，作為儲蓄，以備不時之需。“情感賬戶”里儲蓄的是人際關(guān)系中不可或缺的信任。經(jīng)營好「情感賬戶」，也是經(jīng)營好一個人與合作伙伴的信任關(guān)系。在日常工作中多吃虧，讓自己的「情感賬戶」適當“存儲”。例如自己曾經(jīng)抽出休息時間幫助合作伙伴解決問題，當需要對方協(xié)助的時候，相信也能得到積極的響應(yīng)，這也是常說的“吃虧是福"。

3.1.3 如何處理意外事項

排期后進入開發(fā)，還是會存在各種事情影響項目的進展。例如：插入一些高優(yōu)的需求，或者說發(fā)生一些不可控的因素如疫情等等導(dǎo)致人力不足，從而影響項目的進展。下面我們詳細介紹幾種情況及其處理方式。

1. 需求的變更

在設(shè)計詳細需求方案中，如果考慮得不夠周全，開發(fā)過程中就會產(chǎn)生需求變更。

處理方式：

?判斷需求變更的大小，如果是樣式修改等簡單變更，半小時能解決的小問題，可以協(xié)助快速調(diào)整；如果工作量在 0.5 天以上，并且需要依賴第三方接口，則需要將整體的需求重新評估，重新梳理排期，并同步給干系人。先保證核心的業(yè)務(wù)流程不變，高收益的工作量優(yōu)先處理，保證正常的上線時間，后續(xù)有余力再對其它功能點進行迭代優(yōu)化。?

?判斷需求變更的大小，如果是樣式修改等簡單變更，半小時能解決的小問題，可以協(xié)助快速調(diào)整；如果工作量在 0.5 天以上，并且需要依賴第三方接口，則需要將整體的需求重新評估，重新梳理排期，并同步給干系人。先保證核心的業(yè)務(wù)流程不變，高收益的工作量優(yōu)先處理，保證正常的上線時間，后續(xù)有余力再對其它功能點進行迭代優(yōu)化。?

2. 高優(yōu)需求插入

在業(yè)務(wù)的開發(fā)過程中，可能存在被高優(yōu)需求插入的情況，如果被高優(yōu)需求插入，直接帶來的影響是延后當前的工作完成時間。

處理方式：

評估高優(yōu)需求的工作量，以及影響當前項目的程度。如果在 0.5 天以內(nèi)，沒有被依賴的下游時，再評估對排期影響不大的情況下是否可以快速響應(yīng)。并第一時間反饋風(fēng)險，確保各干系人都有一個心理預(yù)期；如果大于 0.5 天的需求，則建議反饋給項目干系人來安排其他人來解決。

3. 不可抗力的因素

不可抗力在項目的開發(fā)過程中也是不可避免的。如開發(fā)人員有急事需要請假，又或者因為疫情導(dǎo)致辦公效率低下，從而影響項目的進展。

處理方式：

如果是一些身體原因?qū)е罗k公效率低下。在不影響整體項目交付的情況下，適當?shù)难娱L完成項目的時間；若影響到整體項目交付的時間，則應(yīng)該暴露該風(fēng)險，進行項目計劃調(diào)整。如果完全不能投入開發(fā)，應(yīng)該盡早的將此事向上級報備，由上級進行統(tǒng)一的人力調(diào)整，交由其他人投入開發(fā)。?

如果是一些身體原因?qū)е罗k公效率低下。在不影響整體項目交付的情況下，適當?shù)难娱L完成項目的時間；若影響到整體項目交付的時間，則應(yīng)該暴露該風(fēng)險，進行項目計劃調(diào)整。如果完全不能投入開發(fā)，應(yīng)該盡早的將此事向上級報備，由上級進行統(tǒng)一的人力調(diào)整，交由其他人投入開發(fā)。?

4. 內(nèi)部依賴延后

內(nèi)部依賴延后影響到項目的進展也是項目開發(fā)中經(jīng)常發(fā)生的事情。最好的做法是依賴前置。如果在規(guī)定的時間，沒辦法進行交付產(chǎn)物，則會給項目帶來延期風(fēng)險。

處理方式：

將自身的業(yè)務(wù)流程做好，依賴部分通過模擬的方式解決。將聯(lián)調(diào)的時間后移，先開發(fā)其他的功能模塊。如果已經(jīng)是最后聯(lián)調(diào)階段，則需要再次調(diào)整交付的時間，同時將該風(fēng)險同步給相關(guān)的干系人。

將自身的業(yè)務(wù)流程做好，依賴部分通過模擬的方式解決。將聯(lián)調(diào)的時間后移，先開發(fā)其他的功能模塊。如果已經(jīng)是最后聯(lián)調(diào)階段，則需要再次調(diào)整交付的時間，同時將該風(fēng)險同步給相關(guān)的干系人。

3.2 如何做好質(zhì)量管理

質(zhì)量管理的價值就是保證項目質(zhì)量以達成項目目標，降低因為產(chǎn)品質(zhì)量問題帶來的損失。

3.2.1 通過流程規(guī)范提高質(zhì)量

研發(fā)流程是一個精細的過程。需要通過建立執(zhí)行規(guī)范來實現(xiàn)工作標準化和程序化，確保產(chǎn)出質(zhì)量穩(wěn)定和高團隊工作效率，降低人為因素導(dǎo)致的質(zhì)量問題。

1. 制定研發(fā)流程規(guī)范

制定流程有時會讓人反感，覺得降低了研發(fā)效率。但規(guī)范的流程可以大大提升項目的質(zhì)量，好的流程都是在實踐中不斷總結(jié)出來的，是項目的最佳實踐。

當然流程也不是一成不變的，它需要根據(jù)我們的具體情況不斷調(diào)整優(yōu)化，才能適應(yīng)當下的需要。另外應(yīng)當盡量將流程變成 CICD 的約束，通過系統(tǒng)來約束、控制，減少其對人的依賴。

具體到研發(fā)團隊介入一般可分為需求評審、方案設(shè)計、需求開發(fā)、測試驗收、發(fā)布上線、項目復(fù)盤六個步驟。這里提供之前所在前端研發(fā)團隊的研發(fā)流程圖用以參考：

2. 嚴格執(zhí)行Code Review

code review 的好處不僅僅是能夠大大提高代碼質(zhì)量，減少代碼 bug，還能從心理上（自己寫的代碼要給別人審核）讓自己更認真嚴謹些。另外 CR 交流也非常有利于提升團隊的工程素養(yǎng)，可以針對性補強開發(fā)者的知識盲區(qū)，糾正不良習(xí)慣。

3. 制定發(fā)布checklist

每次發(fā)版上線都應(yīng)當是如履薄冰。為了保證上線順利，發(fā)布完善的 checklist可大大規(guī)避低級錯誤，減少不必要的事故。

發(fā)布 checklist 一般可以分為服務(wù)、機器、流程三部分，通過日常工作中累計容易出錯的地方，將其整理收集起來，持續(xù)完善。

這里提供一份參考案例：

階段	事項	是否通過
提測前	根據(jù)前期編寫的測試用例進行整體自測
	根據(jù)埋點文檔驗證埋點，確保埋點中的事件和維度不多報、不漏報、不錯報、不重復(fù)報、報的時機正確
	根據(jù)設(shè)計稿疊圖并截圖（2+測試機），確保無視覺問題
	確保分支的代碼CR通過
	確保代碼已發(fā)布到測試環(huán)境，并確認頁面能夠正常訪問
	確保創(chuàng)建了提測單，提測單包含測試用例地址、測試范圍、測試入口和二維碼、終端環(huán)境、埋點文檔地址
	確保需求單狀態(tài)扭轉(zhuǎn)到增量測試中
bug修復(fù)后	涉及到功能、邏輯、埋點、樣式和交互變更：重新走本次需求邏輯部分的自測、涉及樣式的疊圖、CR 和發(fā)布測試環(huán)境流程，確保全流程無誤
	確保bug單狀態(tài)扭轉(zhuǎn)到已處理，并通知測試同學(xué)驗證，保證在 1D 之內(nèi)扭轉(zhuǎn)到已關(guān)閉
	確保需求單狀態(tài)扭轉(zhuǎn)到待發(fā)布
發(fā)布前	確保產(chǎn)品體驗、設(shè)計走查、測試都通過
	確保所有代碼（功能+bug修復(fù)）都已經(jīng)通過CR，合入 master
	確保正式環(huán)境配置文件中的配置都是正式環(huán)境的配置
	如圖片有新增和修改，確保圖片已經(jīng)進行過壓縮
	確認接口監(jiān)控的數(shù)據(jù)正常，業(yè)務(wù)錯誤碼屏蔽正常，不誤報
	上線前和產(chǎn)品運營確認線上配置是否正確，涉及運營資源是否到位
	和后臺、終端確認好發(fā)布順序，并確保按照約定順序發(fā)布
	確保在群里進行發(fā)布周知，提交的發(fā)布審批通過才能進行發(fā)布
發(fā)布后	待 CDN 生效后，用非公司 wifi訪問頁面，確保頁面正常，同時確保所有的資源都是正式的 CDN 地址
	關(guān)注告警群消息，關(guān)注告警監(jiān)控平臺流量監(jiān)控是否有較大波動，JS 報錯、接口錯誤率是否有上漲，關(guān)注是否有告警
	發(fā)布出現(xiàn)問題，及時在群里周知并回滾，通知leader，并尋求團隊成員協(xié)助定位排查
	發(fā)布外網(wǎng)后需要留守至少 30 分鐘
	確保需求單狀態(tài)扭轉(zhuǎn)到已交付和已接受

很多時候不起眼的清單發(fā)揮著非常重要的作用。例如飛機起飛前的檢查清單、手術(shù)前后的檢查清單，都守護了無數(shù)的生命。更多清單相關(guān)內(nèi)容推薦一本書叫作《清單革命》。

3.2.2 管理變更影響

變更是程序異常的主要原因。在需求設(shè)計階段提前對變更進行評估、規(guī)劃，可以確保在對程序最小負面影響的情況下實施這些變更。同時在團隊內(nèi)進行有效的協(xié)商和溝通，可以確保所有的變更都具有可追溯性。下面分別介紹下如何通過詳細設(shè)計評審技術(shù)方案和通過架構(gòu)設(shè)計上隔離變更。

通過詳細設(shè)計評審技術(shù)方案

編寫技術(shù)文檔對部分工程師來說是反感的事情，但好的項目質(zhì)量一定是設(shè)計出來的，而不是測試出來的。

所以在正式編碼前，詳細思考、設(shè)計整體方案并編寫成技術(shù)文檔在組內(nèi)評審，是規(guī)避質(zhì)量風(fēng)險非常好用的方法，也是非常好的開發(fā)習(xí)慣。它可大大減少編碼階段的質(zhì)量風(fēng)險。

以之前筆者團隊為例，我們還整理了團隊詳細文檔模板，把大家做詳細設(shè)計需要考慮的點都囊括了進去，避免大家遺漏。如性能設(shè)計、監(jiān)控日志設(shè)計、安全風(fēng)險設(shè)計、用例設(shè)計、容災(zāi)設(shè)計等，既是模板也是詳細設(shè)計的 checkList。

通過架構(gòu)設(shè)計上隔離變更

許多開發(fā)者在職業(yè)生涯中最害怕的莫過于修改老代碼，有些老代碼讀起來云山霧罩，完全搞不懂業(yè)務(wù)邏輯和代碼關(guān)系、也不明白這塊代碼為什么這么寫、那塊代碼是什么意思。使得大家戰(zhàn)戰(zhàn)兢兢、寸步難行。

與之相反的「好代碼」一般都遵循軟件工程概念中的高內(nèi)聚低耦合原則，模塊之間相互隔離。常見的隔離方式如下：

隔離方式	解析
分層架構(gòu)	分層架構(gòu)的一個重要原則是每層只能與其下方的層發(fā)生依賴。由于各層間松散的耦合關(guān)系，使得開發(fā)者可以專注于本層的設(shè)計，而不必關(guān)心其他層的設(shè)計或本次變更會影響到其它層，只需保持本層的接口穩(wěn)定。大型系統(tǒng)中推薦使用 DDD (領(lǐng)域驅(qū)動設(shè)計)，將系統(tǒng)拆分成展現(xiàn)層、應(yīng)用層、領(lǐng)域?qū)?、基礎(chǔ)設(shè)施層。
組件化設(shè)計	組件化可以比喻為積木。其工作方式信奉獨立、完整、自由組合。目標就是盡可能把設(shè)計與開發(fā)中的元素獨立化，使它具備完整的局部功能，再通過自由組合來構(gòu)成整個產(chǎn)品。
特性開關(guān)	目前最為常用的隔離方式還是特性開關(guān)。這種方式隔離較為徹底，如果某種場景不需要該特性，直接關(guān)閉開關(guān)即可，缺點在于代碼中可能會存在許多開關(guān)邏輯。
資源隔離	從物理上隔離變更導(dǎo)致的影響，通常使將其以服務(wù)、靜態(tài)資源、網(wǎng)絡(luò)、內(nèi)存、進程等方式進行隔離，通過使變更帶來的影響在可控范圍內(nèi)，隔離其對其他資源的影響。

3.2.3 功能回歸的能力

功能回歸能力是指：通過自動化的回歸測試，尋找原始設(shè)計中沒有預(yù)料到的錯誤。這里需要考慮到2件事：

第一，有效的測試是設(shè)計出來的。

測試左移的意思就是說盡可能地在前期規(guī)避質(zhì)量問題，以提高效率。大家都知道越早發(fā)現(xiàn)問題，修復(fù) bug 的成本越低。例如在設(shè)計階段發(fā)現(xiàn) bug 只需要改寫流程圖，編碼階段只需要修改代碼，測試階段需要重新走 git 合并 mr 流程，要是到了上線后才發(fā)現(xiàn)問題將直接影響是線上用戶，那么其修復(fù)成本和前面的這些相比可能會沒有上限。

設(shè)計階段：做詳盡的需求分析和測試用例設(shè)計，好盡早發(fā)現(xiàn)不合理的地方，盡早暴露問題，以便團隊能更早的在需求評審階段識別并修復(fù)缺陷。編碼階段：研發(fā)可以依照測試用例自行編寫單元測試、接口測試來驗證核心邏輯是否正確。盡可能確保所有代碼被測試到，所有的業(yè)務(wù)流程都能被測試用例覆蓋到。

設(shè)計階段：做詳盡的需求分析和測試用例設(shè)計，好盡早發(fā)現(xiàn)不合理的地方，盡早暴露問題，以便團隊能更早的在需求評審階段識別并修復(fù)缺陷。編碼階段：研發(fā)可以依照測試用例自行編寫單元測試、接口測試來驗證核心邏輯是否正確。盡可能確保所有代碼被測試到，所有的業(yè)務(wù)流程都能被測試用例覆蓋到。

第二， 接入自動化測試平臺。

DevOps 工具是目前最適合做測試的集成管理平臺，從需求提交到產(chǎn)品迭代，從產(chǎn)品設(shè)計到代碼構(gòu)建、測試管理、持續(xù)集成，整個流程貫穿軟件行業(yè)生命周期。在平臺的基礎(chǔ)上將各環(huán)節(jié)的數(shù)據(jù)收集、沉淀成量化指標。如在代碼構(gòu)建階段的流水線集成代碼規(guī)范檢測、代碼質(zhì)量檢測、單元測試、安全性校驗等工具，能夠產(chǎn)出代碼重復(fù)率、單測覆蓋率、安全問題數(shù)、頁面性能等有效衡量項目代碼質(zhì)量的數(shù)據(jù)指標。

3.2.4 發(fā)現(xiàn)問題和定位問題的能力

研發(fā)階段要盡量保證質(zhì)量，不出現(xiàn) BUG。上線后需要確保一旦出現(xiàn)問題，能快速通過告警發(fā)現(xiàn)，并快速定位找到原因，從而最大限度降低對現(xiàn)網(wǎng)的影響。下面我們將介紹如何利用監(jiān)控告警發(fā)現(xiàn)問題、規(guī)范日志快速定位問題和利用智能化監(jiān)控平臺。

第一，利用監(jiān)控告警發(fā)現(xiàn)問題。

在需要監(jiān)控告警前，開發(fā)者需要先定義需要關(guān)注哪些問題？筆者主要涉及前端工作，這里提下前端團隊一般需要關(guān)注的問題：

類型	指標	案例
腳本問題	頁面js錯誤、接口錯誤、頁面白屏、資源加載錯誤 等	頁面 JS 錯誤 xx isnot defined
性能問題	首屏耗時、首屏可見耗時、接口平均耗時、接口成功率 等	檢測到近 5 分鐘領(lǐng)取禮包接口接口成功率下降觸發(fā)告警
業(yè)務(wù)問題	流量下跌、核心鏈路轉(zhuǎn)化率下跌、特定業(yè)務(wù)錯誤上升	云游戲用戶排隊耗時提高導(dǎo)致用戶流失，需要額外開啟設(shè)備

然后再跟進對應(yīng)指標配置所對應(yīng)的告警策略。

第二，規(guī)范日志快速定位問題。

線上項目的程序出問題，程序本身不會說話只會安安靜靜的掛機。但導(dǎo)致這一現(xiàn)象出現(xiàn)一般就是業(yè)務(wù)代碼寫得有問題。

如何讓程序能夠「說話」，并準確的說出有價值的信息，這就是日志的核心價值。日志要解決的問題是：程序是不是按預(yù)期執(zhí)行？用戶在系統(tǒng)上干了什么？程序有沒有執(zhí)行錯誤？問題是誰造成的？合理日志的要素如下：

合理日志的要素	解析
日志時間	日志作為事件的表述，事件發(fā)生的時間是一定要具備的。
日志級別	應(yīng)該根據(jù)日志的重要性或嚴重程度劃分等級，常用的日志級別有：DEBUG、INFO、WARN、ERROR，只有合理定義日志級別，才能避免日志混亂。日志級別也是日志告警的關(guān)鍵條件。
業(yè)務(wù)標識	用來區(qū)分日志屬于哪塊業(yè)務(wù)，因為日志都是跟業(yè)務(wù)相關(guān)聯(lián)的，通過該部分內(nèi)容便于按業(yè)務(wù)進行日志歸類聚合。
日志內(nèi)容	根據(jù)不同的日志等級，在日志內(nèi)容上會有不同的側(cè)重點，盡量描述清楚。
異常堆棧	堆棧異常信息有助于程序異常的排查定位，但這部分信息的記錄輸出，對系統(tǒng)性能有一定的影響，應(yīng)該酌情考慮，如果記錄異常信息足夠定位異常，就不要打印整個堆棧。一般是 ERROR 打印異常堆棧，WARN 不打印，還有就是通過日志框架打印，避免用 printStackTrace 方法打印。
追蹤 ID	對于單次用戶行為需要一個唯一的ID 貫穿全鏈路日志，方便對用戶行為進行追蹤，錯誤信息也能夠查詢到用戶行為的上下文，方便定位日志。

日志記錄的時機如下：

日志記錄的時機	解析
程序流程	記錄程序的流轉(zhuǎn)分支，在關(guān)鍵代碼邏輯的執(zhí)行前后進行相應(yīng)的日志輸出，有助于代碼調(diào)試。但要避免不必要的日志輸出，比如一般只在循環(huán)體前后記錄日志，而不在循環(huán)體內(nèi)重復(fù)記錄，過多的日志反而會影響閱讀。
遠程調(diào)用	遠程調(diào)用也屬于程序流程的一部分，但第三方遠程調(diào)用的日志信息級別，應(yīng)該與一般的調(diào)試日志區(qū)別對待，因為涉及到外部系統(tǒng)的交互，在出入口處記錄請求響應(yīng)的信息，這相當重要。
系統(tǒng)初始化	系統(tǒng)初始化需要依賴一些關(guān)鍵配置參數(shù)，這些參數(shù)決定系統(tǒng)的啟動狀態(tài)，應(yīng)該把這些系統(tǒng)初始化信息記錄起來。
核心業(yè)務(wù)操作	系統(tǒng)用戶進行核心業(yè)務(wù)操作的行為，也應(yīng)該進行記錄，便于進行操作審計。
可預(yù)期的異常	這類異常應(yīng)該有效記錄起來，通過警告方式反饋給相關(guān)人員加以關(guān)注，避免頻繁發(fā)生，最終演化為不可控的錯誤。
預(yù)期外的錯誤	這類異常發(fā)生時，要有詳盡記錄，并通知相關(guān)人員介入處理，并預(yù)留時間作出響應(yīng)，因為這種錯誤已經(jīng)影響系統(tǒng)的正常使用。

第三，智能化監(jiān)控平臺。

每次排查告警問題對程序員而言都是體力活，都想能夠輕松，快速的查看日志，更進一步還有監(jiān)控平臺能夠直接告訴問題是什么、怎么解決。近年來就產(chǎn)生出一些智能數(shù)據(jù)分析平臺，利用大數(shù)據(jù)技術(shù)及機器學(xué)習(xí)技術(shù)對 IT 基礎(chǔ)架構(gòu)及應(yīng)用系統(tǒng)所產(chǎn)生的海量日志進行實時分析。

能實現(xiàn)大量的日志模式發(fā)現(xiàn)并進行聚類，將大量的日志原文轉(zhuǎn)化為少量的日志模式，并反應(yīng)相應(yīng)模式在日志原文中的占比，這大大減少了人工篩選時間，幫助運維人員更快的定位到故障原因。

如果更進一步，那就是在發(fā)生告警的時候其可以提供一張監(jiān)控大盤、影響范圍、觸發(fā)異常用戶的全鏈路日志。信息密度的提高能夠協(xié)助我們快速感知服務(wù)的整體狀況、評估風(fēng)險等級，全鏈路日志也能輔助開發(fā)者更快捷的定位問題，提高告警信息觸達的效率和質(zhì)量。

3.3 如何做好風(fēng)險管理

如果用一句話來形容風(fēng)險，應(yīng)該是這樣的：

風(fēng)險如鬼魅在深淵潛藏，它可能出現(xiàn)在項目中任何一個環(huán)節(jié)，在未來的某個時刻出現(xiàn)，對開發(fā)者負責的項目產(chǎn)生破壞性的影響。

下面我們分別聊一聊風(fēng)險管理管的是什么，以及在實際項目中我們要注意哪些。

3.3.1風(fēng)險管理管的是啥

風(fēng)險的本質(zhì)

風(fēng)險的本質(zhì)是一種不確定性帶來的損失。項目風(fēng)險實質(zhì)上是項目的三要素：進度、成本、質(zhì)量中，一個或多個受到了影響，最終影響了整體項目目標的達成。

風(fēng)險的特征和構(gòu)成要素

風(fēng)險具備以下特征：

日志記錄的時機	解析
客觀性	風(fēng)險是客觀存在的，不以人的意志為轉(zhuǎn)移，項目中存在風(fēng)險是常態(tài)
不確定性	風(fēng)險是否造成損失，以及損失的程度，是不確定的
可觀測	單一風(fēng)險存在不確定性，但是總體來講是有規(guī)律的，有辦法預(yù)測的
可變性	風(fēng)險會隨著應(yīng)對措施的進行而消失，不會一層不變

而風(fēng)險的構(gòu)成則包含三要素：風(fēng)險因素、風(fēng)險事故、損失。

風(fēng)險因素會引發(fā)風(fēng)險事故，風(fēng)險事故會進一步帶來損失。

例如：小 A 是某個緊急項目的研發(fā)負責人之一，項目既定的時間是 2022 年 1 月 1 日上線，此時正值解除疫情防控，身邊越來越多的同事感染，小A所在項目組的研發(fā)成員也陸續(xù)感染，最后項目不得不延期。

可以想想：對于小 A 所在的項目組，風(fēng)險因素，風(fēng)險事故，損失是什么？

風(fēng)險管理怎么做

風(fēng)險管理從流程上主要做四件事：風(fēng)險識別、評估、應(yīng)對和溝通。下面展開介紹。

風(fēng)險識別：

核心是找出可能產(chǎn)生風(fēng)險的“風(fēng)險因素”，識別分析這些“風(fēng)險因素”究竟有哪些特征，可能會影響項目的哪些方面。例如上述小 A 的例子，風(fēng)險因素就是疫情的放開帶來的感染風(fēng)險，其特征就是會導(dǎo)致成員患病無法工作，影響就是項目的延期。

風(fēng)險識別方法	解析
頭腦風(fēng)暴法	一些人聚集起來，進行頭腦風(fēng)暴，通過彼此的溝通交流，想法、建議、意見進行碰撞，一起發(fā)現(xiàn)問題。
專家調(diào)查法	由相關(guān)領(lǐng)域的專家組成風(fēng)險小組，通過征求專家的意見，然后開發(fā)團隊綜合匯總整理，再反饋給專家，再次征求專家的意見，反復(fù)進行 4～5 輪，最終專家們的意見會趨于一致，達成共識。
情景分析法	識別關(guān)鍵影響因素，基于該因素可能發(fā)生的場景，進行場景內(nèi)容的分析，進而發(fā)現(xiàn)風(fēng)險可能造成的后果。
核對表法	將項目范圍、目標、成本、質(zhì)量要求、進度、類似項目成功或失敗的原因等列在一張表上，進行一一核對。這種方法可以識別到進度風(fēng)險、成本風(fēng)險、質(zhì)量風(fēng)險等。
流程圖法	需要建立項目的全鏈路流程圖以及各子域流程圖，這些流程圖可以涵蓋項目的整體流程以及分支細節(jié)。通過將實際情況與流程圖一一對比，便可識別風(fēng)險。

上述小 A 的例子屬于進度風(fēng)險，通過「核對表法」是比較容易識別到疫情防控開放這個風(fēng)險因素的。

風(fēng)險評估：

對已識別出來的風(fēng)險因素，進行系統(tǒng)分析和研究，評估其帶來風(fēng)險的概率，造成損失的范圍和程度。

風(fēng)險評估一般有“定性分析”和“定量分析”兩種：

定性分析：根據(jù)風(fēng)險的重要程度和發(fā)生概率等指標對風(fēng)險因素進行排序。定量分析：將體現(xiàn)風(fēng)險特征的指標量化，以強化對風(fēng)險因素的認知。

定性分析：根據(jù)風(fēng)險的重要程度和發(fā)生概率等指標對風(fēng)險因素進行排序。定量分析：將體現(xiàn)風(fēng)險特征的指標量化，以強化對風(fēng)險因素的認知。

定量分析包括“蒙特卡洛法”、“敏感分析法”、“決策樹”、“影響圖”等，都是非常專業(yè)的分析方法。實際上，作為非專業(yè)項目經(jīng)理的技術(shù)人員，一般通過定性分析就可以對風(fēng)險進行評估了。

如上述小A的例子如果不采取措施，疫情防控的解除帶來的延期風(fēng)險會隨著時間推移不斷接近嚴重度100%。

風(fēng)險應(yīng)對：

在評估完風(fēng)險的概率和損失范圍之后，就可以為風(fēng)險應(yīng)對提供參考依據(jù)了。

風(fēng)險應(yīng)對主要以下幾種方法：

方法	說明	例子
規(guī)避風(fēng)險	消除風(fēng)險因素進而規(guī)避風(fēng)險的產(chǎn)生	1、改變項目目標包含的范圍2、投入更多的成本（人力、資金）
轉(zhuǎn)移風(fēng)險	將風(fēng)險轉(zhuǎn)移給第三方	購買保險
減輕風(fēng)險	降低風(fēng)險發(fā)生的概率或受影響程度	1、將雞蛋放在不同籃子2、兜底策略
接受風(fēng)險	對即將發(fā)生的風(fēng)險，不采取措施	/

如上述小A的例子，從“規(guī)避風(fēng)險”的角度，我們可以投入更多的備份人力，或者調(diào)整項目目標（如調(diào)整上線時間）。從減輕風(fēng)險的角度，我們可以實施分散辦公（居家辦公），減少項目組成員被“一鍋端”的風(fēng)險。從接受風(fēng)險的角度，如果項目因為疫情帶來的延期是可以接受的，也可以不采納任何措施。

風(fēng)險溝通：

這也是最重要的，當風(fēng)險出現(xiàn)時，及時的跟項目干系人做好溝通，以調(diào)整項目干系人的預(yù)期。

3.3.2 實際項目我們要關(guān)注哪些風(fēng)險

以上是項目管理中，針對風(fēng)險管理的基本手段。作為開發(fā)人員，大家日常參與的項目，又有哪些會遇到的風(fēng)險呢？如何更好的應(yīng)對呢？接下來我們介紹完幾個最長出現(xiàn)的風(fēng)險后，分別為各位分享性能風(fēng)險、安全風(fēng)險和容災(zāi)性風(fēng)險的應(yīng)對措施。

1、最常出現(xiàn)的風(fēng)險

從風(fēng)險的本質(zhì)出發(fā)，最常遇到的風(fēng)險：

風(fēng)險	解析
進度方面的風(fēng)險	因為外部依賴、需求變更或者高優(yōu)需求插入，帶來項目延期風(fēng)險。這里在進度管理章節(jié)，已經(jīng)重點介紹了如何管理依賴，如何跟產(chǎn)品人員溝通需求變更，以及如何管理好自身的排期。
質(zhì)量方面的風(fēng)險	主要是在項目研發(fā)環(huán)節(jié)中會產(chǎn)生質(zhì)量問題，如自測不充分導(dǎo)致提測期間 bug 數(shù)過多，在質(zhì)量管理一節(jié)中也介紹了對應(yīng)的解決方案。
成本方面的風(fēng)險	降本增效是最近兩年的主題，大家對成本的關(guān)注越來越多。成本也是一項重要風(fēng)險，特別是大項目，但因為不是開發(fā)通點，本文不展開討論。

除了“進度管理”、“質(zhì)量管理”中提到的解決方法?！斑M度風(fēng)險”、“質(zhì)量風(fēng)險”，通過前文提到“風(fēng)險識別”=>"風(fēng)險評估"=>"風(fēng)險規(guī)避"=>"風(fēng)險溝通"這些通用的方法論也是可以解決的。

除了“進度風(fēng)險”和“質(zhì)量風(fēng)險”，研發(fā)人員，還有一些特定的風(fēng)險因素需要關(guān)注。

2.性能風(fēng)險

性能是非常容易被忽視的風(fēng)險。研發(fā)人員可能忙碌于功能的實現(xiàn)，保障項目正常上線，往往非常容易忽視項目中可能存在的性能問題。

從風(fēng)險發(fā)現(xiàn)的角度，開發(fā)者可以通過「性能檢查清單」，梳理出可能帶來性能風(fēng)險的因素，并在項目開發(fā)過程中規(guī)避化解。

從風(fēng)險評估的角度出發(fā)，項目性能低下可能會直接帶來項目轉(zhuǎn)化率的下跌。例如一個支付頁面如果沒有做好弱網(wǎng)支持，在弱網(wǎng)打開慢，就會帶來的支付轉(zhuǎn)化率不高的問題，進而影響收入。

從風(fēng)險應(yīng)對的角度來說，針對核心頁面（例如上述提到的支付頁面），需要采取措施規(guī)避風(fēng)險。非核心頁面（例如一個不重要的介紹頁），可以采取一定措施減輕風(fēng)險或者是接受風(fēng)險（從成本角度出發(fā)，針對性能做優(yōu)化可能需要花費更多時間）。

3.安全風(fēng)險

安全是互聯(lián)網(wǎng)永恒的話題。在當下互聯(lián)網(wǎng)環(huán)境中，安全風(fēng)險可以分為“合規(guī)化”帶來的法務(wù)風(fēng)險，以及系統(tǒng)實現(xiàn)漏洞帶來的風(fēng)險。

合規(guī)化風(fēng)險

是因為不符合相關(guān)的法律法規(guī)導(dǎo)致的政策風(fēng)險，如 app 因為實現(xiàn)疏忽使某些場景未滿足某個保法。

從風(fēng)險識別的角度出發(fā)，可以通過“專家調(diào)查法”來發(fā)現(xiàn)，通過請求公司的法務(wù)，對相關(guān)項目規(guī)劃進行法務(wù)風(fēng)險評估，并根據(jù)法務(wù)人員提供的建議進行調(diào)整。

系統(tǒng)實現(xiàn)漏洞風(fēng)險

這則是因為技術(shù)實現(xiàn)的漏洞導(dǎo)致的風(fēng)險。例如：活動沒有做好防刷，導(dǎo)致獎品被刷；頁面沒有做好腳本過濾被 xss 注入攻擊。

以風(fēng)險識別的角度來說，可以采用「流程法」，對每個環(huán)節(jié)可能帶來的安全風(fēng)險進行梳理，如：

在“開發(fā)測試階段”，確認工程是否在流水線中接入“代碼掃描工具”；在“上線階段”，確認服務(wù)是否接入”安全掃描“工具進行掃描；在“運營配置階段”，確認相關(guān)運營系統(tǒng)的配置是否經(jīng)過審查測試

在“開發(fā)測試階段”，確認工程是否在流水線中接入“代碼掃描工具”；在“上線階段”，確認服務(wù)是否接入”安全掃描“工具進行掃描；在“運營配置階段”，確認相關(guān)運營系統(tǒng)的配置是否經(jīng)過審查測試

可以采用「核對表法」，整理常見的安全措施，并在項目研發(fā)階段對照核對：

涉及數(shù)據(jù)查詢修改，必須有登錄態(tài)校驗。涉及數(shù)據(jù)修改，必須要有 token 校驗，避免 CSRF 攻擊。所有輸入都需要白名單校驗，包括從 URL 獲取數(shù)據(jù)、從 cookie 獲取數(shù)據(jù)、從表單獲取數(shù)據(jù)等，避免 SQL 注入、XSS 攻擊等。涉及福利相關(guān)，必須有黑產(chǎn)打擊策略。是否有嚴格的用戶權(quán)限校驗。涉及外部對接時，必須包含加密或驗簽環(huán)節(jié)。還存在哪些安全隱患？是否考慮防安全掃描。

涉及數(shù)據(jù)查詢修改，必須有登錄態(tài)校驗。涉及數(shù)據(jù)修改，必須要有 token 校驗，避免 CSRF 攻擊。所有輸入都需要白名單校驗，包括從 URL 獲取數(shù)據(jù)、從 cookie 獲取數(shù)據(jù)、從表單獲取數(shù)據(jù)等，避免 SQL 注入、XSS 攻擊等。涉及福利相關(guān)，必須有黑產(chǎn)打擊策略。是否有嚴格的用戶權(quán)限校驗。涉及外部對接時，必須包含加密或驗簽環(huán)節(jié)。還存在哪些安全隱患？是否考慮防安全掃描。

針對一些重點項目（比如量級龐大的春節(jié)活動），也可以采用「專家調(diào)查法」，提交相關(guān)的技術(shù)方案給到業(yè)務(wù)安全的人員進行審查，以發(fā)現(xiàn)系統(tǒng)設(shè)計存在的潛在安全漏洞。

從風(fēng)險評估的角度出發(fā)，與安全相關(guān)的風(fēng)險往往是無法忽視的，是第一優(yōu)先級需要解決的，因此風(fēng)險應(yīng)對手段，往往是需要采取對應(yīng)措施來規(guī)避風(fēng)險。

4. 容災(zāi)性風(fēng)險

缺失針對系統(tǒng)運行異常情況的處理，也是一種潛在風(fēng)險。從風(fēng)險識別的角度，同樣也可以使用「核對表法」來核對潛在的異常情況是否都有對應(yīng)的處理措施：

服務(wù)可用性相關(guān)的核對表：

系統(tǒng)即將面臨的最大流量是多少？需要提前多久跟運維溝通擴容？系統(tǒng)各個環(huán)節(jié)能承受的流量壓力，哪些環(huán)節(jié)需要擴容？如果流量陡增、服務(wù)過載時，系統(tǒng)有沒有做兜底降級方案?有沒有做多地部署，規(guī)避單點風(fēng)險？...

系統(tǒng)即將面臨的最大流量是多少？需要提前多久跟運維溝通擴容？系統(tǒng)各個環(huán)節(jié)能承受的流量壓力，哪些環(huán)節(jié)需要擴容？如果流量陡增、服務(wù)過載時，系統(tǒng)有沒有做兜底降級方案?有沒有做多地部署，規(guī)避單點風(fēng)險？...

邏輯實現(xiàn)相關(guān)的核對表：

數(shù)據(jù)結(jié)構(gòu)是否變更，如果變更是否考慮老數(shù)據(jù)兼容？邊界條件是否。運行環(huán)境可能存在的兼容性問題？（前端經(jīng)常遇到）....

數(shù)據(jù)結(jié)構(gòu)是否變更，如果變更是否考慮老數(shù)據(jù)兼容？邊界條件是否。運行環(huán)境可能存在的兼容性問題？（前端經(jīng)常遇到）....

從風(fēng)險評估的角度出發(fā)，需要根據(jù)服務(wù)/頁面的重要性，采取對應(yīng)的風(fēng)險應(yīng)對措施：

一些核心場景（如支付場景），相關(guān)服務(wù)/頁面一旦出現(xiàn)問題就是直接的經(jīng)濟損失，因此就需要采取措施規(guī)避風(fēng)險。

一些對用戶感知不是很明顯的場景，則可以采納兜底降級的方案。例如信息流場景下，在面對突增流量沖擊時，推薦系統(tǒng)所能承受的流量壓力要遠遠低于接入服務(wù)的承受范圍，這個時候，接入服務(wù)就需要保護推薦服務(wù)，通過返回兜底數(shù)據(jù)，減少流量對推薦系統(tǒng)沖擊。

04

總結(jié)

為什么開發(fā)也要懂項目管理？開發(fā)如何做好項目管理？相信各位讀者已有一定感知。本文首先介紹了項目管理對大家在職業(yè)和生活中的價值，接著以項目管理中的痛點為切入點，整體介紹了項目管理中需要掌握的三大能力——進度管理、質(zhì)量管理、風(fēng)險管理。

其中進度管理包含工作量評估、依賴管理、處理意外事項等；質(zhì)量管理包含流程規(guī)范建設(shè)、管理變更影響、提升功能回歸能力、提升問題發(fā)現(xiàn)和定位效率等；風(fēng)險管理包含風(fēng)險管理的基礎(chǔ)方法論，以及實際項目中容易忽視的性能風(fēng)險、安全風(fēng)險、容災(zāi)性風(fēng)險等。

最后期望本文能幫助開發(fā)者提升項目管理技能，提升「把事做成」的能力，成為合作伙伴眼中「靠譜」的人。以上是本次分享的全部內(nèi)容，歡迎各位開發(fā)者在評論區(qū)交流。如果你覺得內(nèi)容有用， 歡迎分享、點贊、在看。感謝支持。

-End-

原創(chuàng)作者｜賴文輝、蔡卓倫、劉冬、陳長吉

技術(shù)責編｜賴文輝、蔡卓倫、劉冬、陳長吉

「變化」對程序員而言是個極大的挑戰(zhàn)，這是萬年老話題了?？蛻粜枨笤谧儯习逡笤谧?，產(chǎn)品經(jīng)理的需求也在變。有程序員表示，當我抱怨變化帶來的加倍工作量，也許還會遭到吐槽：“你程序不怎么樣啊，不能順應(yīng)我的變化?！?面對變化，你有怎樣的經(jīng)驗和方法呢？你有什么評估工作量的妙計？當變動發(fā)生，日常雜事和臨時問題出現(xiàn)打亂排期，你怎么解決？可以做些什么來減少「變動」？

歡迎在評論區(qū)聊一聊你的看法。在3月24日前將你的評論記錄截圖，發(fā)送給騰訊云開發(fā)者公眾號后臺，可領(lǐng)取騰訊云「開發(fā)者春季限定紅包封面」一個，數(shù)量有限先到先得。我們還將選取點贊量最高的1位朋友，送出騰訊QQ公仔1個。3月25日中午12點開獎?？煅埬愕拈_發(fā)者朋友們一起來參與吧！

最近微信改版啦

很多開發(fā)者朋友反饋收不到我們更新的文章

大家可以關(guān)注并點亮星標

不再錯過小云的知識速遞

?

?