研发高阶能力之「技术规划」 | 木戈手机站

木戈手机站

当前位置: 首页 » 攻略 » 研发高阶能力之「技术规划」

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

为什么规划是高阶能力

  • 明确

    什么是正确的事

    (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 好不好使)和意愿(有没有动力去推)?此命题我另写一篇文章聊聊

猜你喜欢
本类排行