研發高階能力之「技術規劃」

為什麼規劃是高階能力

• 明確 什麼是正確的事（what、why），前置於 如何正確的做（how）。真有能力明確，就可以不用親自做

• 提出正確的問題，比解決問題更難

• 權力/權威/影響力，建立在 比別人都更正確

• 規劃強依賴的 事理邏輯（what、why），長於 數理邏輯（how）的程式設計師好多都學不會或沒機會學或不願學，因而具有稀缺性

• 上級、下級的年終業績，相當一部分來自規劃。產品沒規劃，研發就沒活幹，研發沒規劃，晉升就沒材料

• 基於對業務和行業的趨勢判斷，制定中/長/短期技術規劃，確保企業的技術投入（投什麼、投多少、怎麼投、投哪裡、以什麼樣的節奏投）可以幫助業務獲得長/中/短期的競爭優勢，這是業務的 技術合夥人 的核心職能

企業有三類角色：worker、partner、owner，不同角色基於不同的身份認同，工作在不同的平面，表現出不同的行為，創造出不同的價值，從而分配不同的蛋糕份額

什麼是規劃

類比定義：近似於創業用的 商業計劃書，是用來向老闆要資源的，是要 銷售 出去讓老闆 買單 的，甚至可以說，規劃就是 謀求多方共贏的生意

嚴肅定義：基於 本質問題 的 整體性 思考，給出 長期性 的 發展願景。這些是規劃與計劃的區別所在

• 本質問題：沿著更高抽象度的方向上溯思考，對 問題本身再追問，就有可能觸達本質問題。比如問“某公司長期發展前景如何”，如果一直追問到“企業為什麼會存在”，就是非常本質的問題了（TK 也舉過一個例子：“蘋果為什麼是紅色的” -> “紅色為什麼是紅色的”）。

  • 參考：5-why

  • 參考：第一性問題

• 整體性：（時間維度）看到歷史、現狀和未來，瞭解前因後果、來龍去脈；（空間維度）對內看清業務全景、系統框架、上下游關係，對外看到所有可對標的物件

  • 反例：從過往有限經歷中積攢孤立的、零散的、區域性的、單點的問題。比如發現某個技術模組需要最佳化，這個事本身可能是對的，但不看整體，就不知道這件事的優先順序（也許有更重要的事被忽略），也不知道這件事和業務階段是否匹配（也許是該做，但不是現在做），更不知道這件事該不該你做

• 長期性：規劃的作用是提供燈塔指引照亮前路，咱們國家的規劃一次做五年，業務部門的技術規劃一般一次做一年。不過實操層面講，要麼身處於確定性領域的早期或初級階段，要麼身處於需要長期探索的模糊領域，不然要給出一年的規劃確實不容易

  • 反例：追趕對標物件的現狀

• 發展願景：要描繪業務在期中/期末的局面會有怎樣的正向變化，要講做成什麼、做到什麼，這才是 賣點，不要講要執行哪些動作、完成哪些任務，你應該 給老闆一份選單，而不是菜譜

  • 反例：把規劃寫成計劃、todo 列表、需求集合、任務彙總、技術方案、技術科普

  • 反例：從團隊已有能力或 個人 發展願景出發，定義還能做什麼、還想做什麼

  • 反例：脫離業務 從技術應用、技術成長、技術新鮮感角度找問題

不謀全域性者，不足謀一域；不謀萬世者，不足謀一時

規劃的基本原則

• 利益導向。功利的講，要有衝勁，心志上應謀求做大收益，事關你和你的上級/下級的年底績效（老闆總是希望規劃能 involve 更多人）。要知道老闆想要什麼，因為老闆想要的，才是你的業績。老闆想要的是能解決實際問題，脫離業務/公司利益的技術規劃，老闆一定不會買單

  • 前端核心利益：效能、體驗、質量、效率
  • 後端核心利益：可用性/穩定性、質量、效率
  • 業務核心利益：增長、留存、轉化、降本增效...

• 預期明確。規劃寫完後要讓老闆形成穩定預期：一共幹哪幾個 專案（專案是公司事務運作的基本單元）、分別解決什麼問題、需要投入多少資源、能獲得什麼效果/收益？“明確”的標準是不用親自下場做任何事，也能大體預見每件事會被什麼人、以什麼方式、用多長時間、完成到何種程度。簡單說就是必須 能落地。要是一堆資源投下去，最後不能落地，意味著給公司造成巨大投資損失，要理解管理者對此風險的高度警惕心理，預期不明一定會噴你

  • 反例：規劃依賴合作方支援，卻事先未與合作方溝通，或者依賴的外部方案調研不充分，讓老闆感覺是紙上談兵，心裡沒譜

• 重點突出。傷其十指不如斷其一指，一刀見血勝過四面開花，看全不等於面面俱到，沒重點一定會被噴。通常最理想的結構是在一條主線上提煉 3 個有份量的核心問題

• 使用者導向。要有產品思維，規劃寫給誰看的？如何讓“使用者”低成本理解到位？

  • 瞭解 reviewer 的知識背景。對於沒有技術背景的老闆，肯定不會去 review 技術內容，只會去 review 事理邏輯，你就得換個寫法，不要用技術語言

  • 控制學習成本。儘量不要發明新概念，儘量用通用詞彙。凡是需要透過 額外解釋 才能讓人理解到位的語句，都要最佳化

  • 邏輯結構追求 金字塔 + MECE。因為理解成本低、傳達資訊效率高、最能體現是否想全、符合老闆審美、方便老闆 review

  • 結論先行。先拋觀點再解釋，先拍結論再論過程。要換位理解啊，時間管理對於老闆而言是個重大命題，因為時間永遠不夠用，所以老闆通常都是沒耐心的

  • 用圖表說話。一圖勝千言，老闆沒耐心看大段大段的文字內容

  • 精簡幹練。寫作上追求短句，忌諱沒有 資訊量 的詞句，偏細節的支撐性內容最好摺疊

• 意圖清晰。每一處資訊都要有意圖，你寫的每一個標點符號都應該表示你想讓老闆知道什麼。為什麼這裡要新增這個內容、為什麼要做這個分類、為什麼要畫這個方塊、為什麼這個方塊要塗色、為什麼這裡要連一根線、為什麼這根線要這麼連......沒有具體目的，只會徒增困惑

• 邏輯關係一致。問題與策略、策略與目標、目標與結果指標的關係得一致

  • 反例：做一件事是為了提效，但結果指標裡卻提到“提升點選率/PV/UV”（目標與結果指標的關係不一致）

  • 反例：做 Serverless 的一個成果是縮短了釋出時長，可縮短髮布時長為什麼要靠 Serverless？（策略與目標的關係不一致）

• 嚴肅專業。假定這份規劃要拿去融資一個億！必須體現專業性，錯字、口語化表達、邏輯不嚴密，都是硬傷

“向上抽象思考”得長期練，尤其是一線幹活的人，凡事第一想到的就是 how —— 我個人如何執行。要擺脫 how，在更前置、更高抽象度的層面思考，屬實不容易，一是因為老闆們長期工作的抽象層面，對於長期浸泡在實施細節裡幹活的人而言往往很陌生，如果不主動就沒時間或沒機會接觸；二是因為具體練法基本都是程式設計師不習慣甚至反感的一類事：寫週報有意識寫出能讓上級直接複用的內容、寫會議紀要、寫總結/自評（STAR 模型、SCQA 模型）、寫規劃、寫立項文件、晉升答辯、推動說服他人做事、開會、彙報、寫 OKR、對人給出評價、組織管理協同...做完這些最好還有高人指點，或者有更優樣本對照

想清楚 how 當然沒問題，只是規劃材料的重點是 邏輯，寫作上要避免陷入“how”，要學會 向上抽象1～2層，有鮮明而凝鍊的觀點（重度彙總），有經過抽象和量化的事實（輕度彙總），只列舉起必要支撐作用的事實明細並且最好摺疊起來，不要講技術方案和執行動作層面的內容

規劃的核心內容

業務背景

• 寫背景，主要是因為 reviewer 不一定了解你所在的業務和你從事的方向（例如架構師），所以得講清楚業務是做什麼的（解決的核心問題、服務的核心指標）、團隊的職責與使命是什麼

問題識別

• 判斷問題真偽和重要性的基本方法：1、多問 so what？ 2、不解決有什麼 影響/後果/風險？3、此問題 是否影響老闆決策要不要買單？

• 如果一件事需要 1~n 個人幹半年到一年，那麼對應要解決的問題 scope 一定不能太小。問題太小說明理解太淺、標準太低、沒追求，問題大沒關係，但要看能不能完成，否則會產生過高的預期

• 對於某個框架或系統，盤問題的一種基本方法是確定目標架構與現狀的 diff，既體現對現狀的不滿（差距），又展現了演進的目標

• 問題的難點：規劃裡講難點，主要是客觀識別問題的性質（高度模糊？協同複雜度高？實現複雜度高？達標標準嚴苛？...）和阻礙目的達成的風險/卡點/阻礙，一方面體現為什麼這個問題過往一直沒有被很好解決，另一方面也有預期管理的隱含意義（因為難，所以需要人、需要時間）。和晉升材料裡講難點有一定區別，晉升材料是要突出個人🐮逼，講難點是要體現出“我能搞好而別人搞不好”

  • 難點案例：解決方案可能對相關利益方造成的影響，如何採取相應策略及措施，使得各利益方能接受建議方案

問題及其挑戰，就是 STAR 原則中，ST 部分要講的東西

定策略

• 策略不是技術方案，更不是動作步驟，而是對多條路徑該走哪條不該走哪條的方向性判斷，比如技術選型就是一種策略，講為什麼用這個方案做。更具體的 how 層面的細節，老闆沒那個時間精力關注，也不需要關注，因為對老闆而言，只要 方向 正確，剩下的無非是投多少資源的事

  • 策略案例：“農村包圍城市，武裝奪取政權”

• 如果你要做的事（how）是對的，那麼背後一定對應著一個正確的邏輯，來證明 how 是對的，老闆 review 規劃，就想看這個邏輯，基本不 care 你的 how。這個邏輯一定比 how 更前置、更本質、更抽象

• 問題正確 + 策略可行，事情的 確定性 就有了，就可以 立項 了，如果還能定義出可衡量的目標，事情就可以外包出去讓別人幹了

• 策略要和問題對應上，避免問題寫一套（單純盤問題），策略寫另一套（為了把要做的事情套進去）

定目標

• 明確要達成什麼樣的結果，既管理所有人的預期，也管理所有人的產出。目標是“脫產階段”完成分析推演後的最終輸出，是“生產階段”的最初輸入

• 怎麼判斷目標是高是低？關鍵是 建立 benchmark

  • 明確天花板/終局。知道什麼是最好、什麼是可能範圍的極限。5000m 跑 18 分鐘是快是慢？看看世界紀錄就知道了

  • 橫向對標。問題難度、目標難度、水平高低，都很不容易感知，必須有辦法明確，對標就是一種有效方法，一方面校準目標、論證目標合理性，避免自己閉門造車，另一方面可建立準確的體感和預期。不對標，就是缺少技術視野的表現

    • 對標內容：問題對標、能力對標、思路/策略對標、效果對標、方案對標

• 好目標的標準：SMART

  • Specific 具體：對上具體，從目標管理的角度考慮，“就用這麼多資源、就幹這麼多事”；對下具體，從派發任務的角度考慮，確保理解的一致性，避免被曲解，導致執行偏差、反覆確認、推倒重來。不具體就證明沒想清楚，一定會被挑戰

  • Measurable 可衡量：沒有指標，就沒有管理，可量化勝於具體的行動計劃，因為方便老闆 check 結果，因而老闆更願意買單。對於難以準確量化或者根本無法拿到真實結果的場景，有一個模糊的、預估的、有一定合理邏輯支撐的指標，也好過沒指標

  • Attainable 可達成：判斷是否可達成的一種方法是 拆解，可參考亞馬遜 可控輸入指標。
    從管理角度，可考慮把目標設定稍微高一些（取其上而得其中）

  • Relevant 相關的：緊扣更上一級的目標

  • Time-bound 截止時間：目標是一個決策，“走哪裡、走多遠”，不能走一輩子。如果一件交給別人做的事，既可以衡量，也有 Deadline，那麼管理的可預期性就非常強了

  • 好目標案例：年度高等級故障減半

• 目的與目標的區別：目的一般已經內涵在提出的問題裡了，目的的近義詞是動機、意圖、願景、初心、使命、慾望、痛點、需要，而目標是說要達成的具體狀態/結果，以“APP 跨端重構專案”為例：

  • 目的：提高動態化釋出能力，縮短髮版週期；提升雙端複用，降低開發成本
  • 目標：截至 xx 時間點，頁面覆蓋率、釋出覆蓋率、需求覆蓋率分別達到 xx%、xx%、xx%

實施路徑

• 為什麼要講實施路徑：建立“可落地”的穩定預期，尤其是長期專案

• 實施路徑和實施步驟的區別：實施路徑是指到各個階段要達成什麼效果/狀態，可階段性的進行 check，而實施步驟是對動作的拆解，二者的抽象度不再一個層次上

• 實施路徑的寫法參考：

方向/模組	專案	Q1	Q2	Q3	Q4
xx	專案 A	里程碑 1	里程碑 2	里程碑 3	里程碑 4

協同資源及風險

• 要辦成規劃的事，所需的能力和資源（人、錢、物）不一定都是“我”或“我的團隊”已經具備的，由於外部依賴通常不直接可控，這就構成了專案落地的風險。所以要伸手向組織索要支援，哪些事依賴老闆去推動，你得告訴他，並說清楚必要性（講清上下游協同關係，以及如果沒有相關支援，後果是什麼）

• 涉及跨部門協同的場景通常比較複雜，得預判能不能驅動？對於直接驅動的人，他有沒有能力和意願？如果是透過驅動 a 來驅動 b，那麼 a 有沒有能力（說話對 b 好不好使）和意願（有沒有動力去推）？此命題我另寫一篇文章聊聊