研发高阶能力之「技术规划」

为什么规划是高阶能力

• 明确 什么是正确的事 （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 好不好使）和意愿（有没有动力去推）？此命题我另写一篇文章聊聊