转载

前端技术专家(P8)的规划能力如何训练，答案全给你

前端早早聊大会，前端成长新起点，帮你提前二十天，站在新的起跑线，目标成为 用得上，听得懂，抄得走 的前端大会，计划 2020 年办 12 期，由前端早早聊与掘金联合举办。

第五届 - 前端监控体系如何搭建/用户行为/产品质量如何跟踪，4 月 25 日举行，8 位讲师，8 个小时，全天直播，报名链接： huodongxing.com/go/tl5

本文为第四届 - 前端职业规划专场讲师 - 远舟的分享 - 《如何做出专家级别的技术与技术产品规划》：

内容概要

大家好，非常高兴能在早早聊的规划专场，和大家分享我对前端做技术与技术产品规划的一些思考和心得。

先来了解下今天要分享的内容概要，先简单认识一下，之后从 为什么 ， 怎么做 ，以及举个栗子来讲做 规划的具体思路 。

1. 认识一下

2010 年，毕业后跟随几个老哥创业。
之后由于对前端动效比较感兴趣，所以于 2011 年底加入阿里，成为 alibaba.com 轻骑兵业务的一个切图仔。
12 年，开始参与 alibaba.com 的 DPL 体系建设。
14 年，成为 alibaba.com DPL 负责人并晋升高级前端工程师。
15 年底，开始搞 Fusion Design。
16 年，晋升前端专家。
18 年，离开 B2B 中台团队到了新零售一线盒马
- 从 0 到 1 搭建门店数字化业务和前端团队
- 从 0 到 1 建设货架可视化
- 多端多角色工作台
- 决策任务流
- 线上线下体验系统等。
2019 年，考虑自身发展，离开盒马来到税友 B 端，负责大前端团队，探寻体验技术在 B 端对数字化转型升级的商业价值。

2. 为什么要做规划

2.1 捷径？

大家想不想知道从前端小萌新迅速成长为前端专家的捷径？俗话说，书山有路勤为径，我要好好写代码。

我们先从两个例子看下从 小萌新 到高手的过程，然后我们再看看前端是否有捷径。

王者荣耀可能我们很多人都玩过，青铜的玩家就是 biubiubiu，黄金的玩家稍微有点操作，铂金的玩家知道去 Gank 包抄了，钻石的玩家会看阵容，王者玩家基本能判断敌人在什么地方干啥了。这里有个特点不知道大家有没有发现： 每个层级要求的能力是有差别的

，虽然王者也是在 biubiubiu，但王者除了 biubiubiu 之外明显会的更多。

我们再看一个从一段代码到一个技术产品的例子。前端最早可复用的代码应该就是类似 reset，normalize 的代码了，之后为了更大程度的复用和解耦，有了模块化，模板，表单场景这样的解决方案，再之后为了让这些“物料”能够更好用，更方便的去用，所以就有了辅助设计开发这些物料的平台工具，规范，机制。这里也有个特点：不同的发展阶段要解决的问题不光是量的区别，问题的类型也发生了变化，那么所需的能力也自然会发生变化。

那我想问大家，从青铜到王者，你需要多久？1 年还是 3 年？从切页面到前端专家，5 年？还是 10 年？不同人会不一样。但如果我们提前知道每个阶段或者级别所需要的技能和能力，并且在练习和写代码的过程中刻意练习这些技能，那我们可以加速这个从当前阶段跨向下一个阶段的过程。

所以，捷径就是少走弯路，就是更早的知道下个阶段的要求，主动避开一些没必要踩的坑，我们要从好好写代码变成有规划的好好写代码，所以 一个好的技术规划，就是一条捷径 。

2.2 规划有什么用

那来点正经的， 规划到底有什么用 ？

从 价值层面 ，假如说你是一个团队的 leader，或者你是一个团队的核心的同学，那么如果你会做规划，这个时候团队的协作的目标感会更聚焦，协同性也会更强。然后整体的产出也都会更加完整，会减少很多重复建设，然后在设计整个解决方案的时候，你考虑会更完备，而不会说今天想完这个之后，明天又发现类似的另外一个问题。
在 自己的能力 上，首先可能一开始大家都是在解决一些短期的项目的问题，通过规划会慢慢转变成我怎么去解决长期的复杂问题。然后在规模上，原来我们可能只关注自己的问题，但自己的问题如果到一定程度，我们慢慢就会涉及到别人，是不是也遇到类似的问题，或者遇到了我遇到的问题，或者是遇到一些我没有遇到的问题，直到能解决大家的问题，规划可以让我们更早的识别到这些问题。
在之后就是从自己 思考能力的角度 。其实刚才堂主也讲到，P8 他的思考维度是不一样的。这个维度其实就是从这里出现的，你在一开始去想自己的问题的时候，可能是比较单点的散点的单维度的。我们从解决 单点问题 开始，慢慢的你会发现这些问题，它有一些逻辑的关系的，或者有一些 共通性 。我们就可能会从横向、纵向、全局、长期深入、多视角、多维度的方向去思考这些问题。
最后就会慢慢去建立起自己的一个 思考框架 ，让自己思考问题的过程更加完整、有序。

当然每个人可能思考方向都不太一样，但如果你有自己的思考框架，那么你在想问题解决问题的时候，你肯定会更加的高效。

所以， 技术规划本身其实是一个思考框架 。

3. 怎么做规划

3.1 规划的思考方式

然后我们说一下， 怎么做规划 ？

首先我们去通过这样一个图来看一下，规划的思考方式，就是你做规划和不做规划的思考方式的区别。整个做规划的过程，它是一个从发散到收敛的过程。

我们做规划的时候，一开始都是先发散，发散的过程中，你可能有很多美好的设想，可能会分析各种各样的数据，线上的各种各样的问题，然后用户的吐槽、团队同学的吐槽、你自己的吐槽，会有很多这样的信息，我们都把它当成一个感性的信息。

我们要把这些信息通过结构化的方式收敛到一个思考框架中，这个思考框架如右边的图，就是我们今天要讲的怎么做规划的核心内容。

第 1 个，就是 现象与根本问题 ，识别清楚要解决什么问题是第一步，很多时候识别问题比解决问题更重要。
之后是 定位与目标 ，就是我们打算做什么，做到什么程度。
再之后，针对这样一个 定位和目标 。我们去定义解决方案，其实就是 架构和解决方案 。
核心解决方案 有了之后，就是我们怎么去把解决方案做好，我们就会需要有 打法策略 。
再通过一些 项目管理 项目运作的方式，把我们的打法策略 有保障的运作好 。
如果是相对长期的项目，那就需要预估中间可能会遇到什么的风险，就是阻碍。
在我们做一段时间后需要去复盘看是否需要做 方向微调 。

那么整个过程下来，用大白话说就是，你要解决什么问题，你打算怎么解决，你的解决方案是什么，在技术和产品上包含什么？如果要做，他的轻重缓急、切入点，跟抓手是什么，团队里需要什么样的人几个人来做，谁在什么时候做什么，中间可能遇到什么问题，怎么解决。最后我们去回看这个目标，去纠偏，看中间有没有走歪了。

这是一个大体的一个思考模式，后面我会去详细具体的去讲。

3.2 现象与问题的识别

先看现象和问题，它会决定我们做规划的完整性。如果我一开始就只想到了这一个问题，或者只想到其中某一部分问题，没有想完整，那么这个时候你后面做出来规划也只是围绕解决这部分问题来的，这时候做的事情就可能偏掉或者歪掉。

在这个过程中，我们假如说 this 是我们要做的规划，或者是我们现在当前所处的位置，那么我们会有一些自己抛出来的问题，要把这些问题变得更加的完整或者是更加的全面，有一些常用的方法：

第 1 个是 追问法 ，举个例子，天很蓝，为什么天是蓝的呢？天空中有很多光线的折射，为什么它会发生折射呢？就这样一步一步去追问下去，一般至少要追问 3 层。
第 2 个是 关键词联想 ，我们平时可能会遇到一些技术上的问题，甚至我都不知道这个问题到底是从哪出来的。这个时候我可以去想一些它的关键词，拿纸把它写下来，之后去搜索它相关的内容。当我们逐渐得到这些信息的时候，其实我们就慢慢就会在脑子里形成一张类似地图的东西，慢慢驱散脑子中关于这个问题的迷雾，直到知道这个问题的全景。
第 3 就是 分维度思考 ，就是从不同的角度或者属性上去沿着这个维度扩展思考。
第 4 就是一个原则，就是做到 问题不重复，不遗漏 。

常见的一些分析维度，比如这个事情发展到什么阶段，跟你通过一些数据分析发现的情况，用户价值的未来预判的等等这些，从这些角度做思考可以帮助你更完整的思考问题，这里抛出来一些供大家平时参考。

说几个这个过程可能会经常遇到的问题：

最典型的就是，没啥问题，没发现啥问题。 发现问题本身其实就是一种能力 ，很多时候其实是我们没发现问题，可能是没有深入去问、深入去联想，也可能是不知道有更好的解决方法，所以就觉得好像没啥问题。但如果是这样的话，那么你在规划的一开始就已经结束了。
然后，第 2 个比较常见的问题就是**把表面现象当做问题。**看起来是一个问题，但实际上它不是问题，他是一个表面现象。很多时候我们可能只想了一层，这个时候如果我们要去把问题想全面的话是需要去做追问的，是需要去往下至少要挖三层，你才能逐渐对这个问题有一个感觉。

关于现象和问题，我推荐大家去看一本书《你的灯亮着吗？》，这本书其实是帮助大家去建立一种识别问题和思考问题的方法的一本书，我觉得挺好的，也挺入门的一本书。

3.3 定位

前面那个部分就是我们去尽量发散，从我们当前的第 1 个问题出发，去发散发散很多，直到我们把 现象和问题明确清楚 。我们就到了第 2 步： 做定位 ，做定位的时候我们就要去收敛了，假设右边图中这四个方向是我们发散问题的方向，那么我们需要从这 4 个方向，收敛到一个问题域的交集。

这个时候其实我们就形成了一个我们要去 解决问题域的范围 ，然后我们就从这个范围中寻找我们的定位，当我们需要抽象出定位的一个描述的时候，我们还是需要去做一些工作的，我们需要去从我们收敛的问题域里面去思考，我们要去解决的最核心的问题是什么，我们想为哪类用户或者场景提供解决方案，大致的解决方案的设想是什么，能给用户带来什么样的价值。

这里有一个简单的模板，可以帮助我们来梳理定位，大家可以参考一下：

我们面向和围绕什么样的场景
然后通过什么样的方式
实现构建什么样的解决方案或者产品
然后帮助什么样的用户提供什么样的价值？

在这过程中有一些要点，就是找定位的过程，可以理解为 找差异化价值的过程 。就是比如像小米它做移动电源，华为也做移动电源，然后比如说我们业界有很多组件库的解决方案：antd，Fusion Design，ElementUI，各种各样的，乍一看很像，但实际上它们是不一样的，因为他们要解决的核心问题是不一样的。这个时候它的核心差异，就是它的定位，否则他会很容易被其他东西取代。

另外，过程中需要着重思考的是， 哪些事情再难你也一定要做，哪些事情再简单你也不做 ，如果想清楚了这些问题，那么你的定位也就七七八八了。如果说你问不出，或者没想到这些问题，那就说明你定位是很不清楚的。

第三个其实和第二个问题类似，如果你清楚了你的定位，那么你一定会有这样一个问题，就是什么事情我们是不做的，但是跟我的定位是很有关系，他会对我的技术的体系或产品形成一些影响，我肯定我一定要去想清楚。

这里面也推荐大家两本书，有一本是《定位》，一本是《你的团队需要一个会讲故事的人》。前面就是讲定位，这本书还是很出名的，偏营销，帮助大家去理解定位的概念。第二本书是你怎么从讲故事的角度去理解你要去做的这件事情，以及它的价值。

其实从我们平时做的业务需求或项目的过程中，也可以有一些感触的。比如说产品经理提过来一个需求，他需要跟我讲清楚我们的用户是怎么样的？他用那个东西要解决什么问题，怎么做的？可能平时他只是讲个流程，但是真正要以故事的方式来讲的时候，他会讲他的价值，他的作用。这个时候你可能会有感触，我这个事情如果这么做的话，确实是有这样一个作用和价值的。平时如果都这么去思考问题，对你去梳理你的定位，其实是非常有帮助的。

3.4 目标

当我们确定了我们定位，以及我们的解决方案大概是要解决什么问题的时候，我们就需要去定义我们要做到什么程度，或者说在什么阶段做到什么程度，这个就是定目标的过程。

这个过程中一般我们需要做目标的拆解，一般是两种方式：

一种是 树形子目标 。就是左边这种，G > A > A1，A2，A3，就是我先有个整体目标 G，比如说我的整个活跃度要提升 20%，从 G 里面拆出来，A 产品提高 10%，A1 产品提高 5%，A2 提高 5%，这是一个树形关系，所有目标相加等于整体目标。
另外一种目标，是 里程碑目标 。比如我认为我的这个事情做到了这个节点，它是一个非常关键的一个事件，一旦我做到这个点，这个时候我会形成一个从量变到质变的过程，或者说到了这个节点，我们的事情就进入了另一个阶段了。

好的目标一般都比较简单。就是我一看到这个东西，我就知道你要做什么事情，让大家就非常聚焦。有些时候我们的目标就很难去定出来。觉得这么定有不好，那么定也不是，或者定 30 定高了，定 50 定低了。有时候就需要粗暴的去拍一个，因为定目标这个事儿，我们首先需要有一个聚焦的东西，让我们能一起往目标去走，之后才是走多远。

3.5 技术架构/技术产品架构

第 3 个部分，是讲我在 做技术架构和技术产品架构时的一个思路 。

首先你如果要去画一个架构图的话，那么你得先明确你的架构目标是什么？这个架构目标就是来承接前面的定位和目标所定义的东西的。

架构图的种类非常多，不同类型的架构图画法也不同，这里从一个简单抽象图来解释我的理解，我理解的架构设计的目的都是为了理清关系，让每个点都能合理的安置在一个系统中，使系统整体能够高效稳定运作，而关系则会多种多样，我们的设计模式都是在描述 A 与 B，或者多个角色之间的关系，以及怎么重构这些关系来解决问题。

第一步，是针对你之前梳理的出来的要解决的问题想解决方案，把这些解决方案根据不同的维度列出来。

可能一开始你就是像下面左下角这个图一样，abcdef 你随便扔，随便列，就是一堆的各种各样的解决方案，或者功能，或者技术能力，跟一个标签云一样，之后开始从不同的维度去思考他们之间的关系。可能会有很多种各种各样的关系，但是你这里只需要 围绕你的架构目标去定义所需要解释的关系 。这些关系的梳理可能会把某些解决方案或者能力打散，或者合并。当然，如果有现成的一些设计模式或者架构模型刚好契合你现在的情况，那就直接往上套了。

只要你做到 逻辑自洽 ，内容、角色之间的关系能够讲得清楚，其实就可以。并不意味着说好像比如有很多人画了各种各样的架构图，你看觉得很有道理，但是你可能从另外一个方式来画，或者从另外一个角度来讲，你画的也有道理，也能讲清楚，其实是一样的，没关系的，没有一个所谓的标准答案说一定是怎么样的。比如 MVC，你把 M 放左边 C 放右边画或者是你反过来画，倒过来画，它都是 MVC，只要是你 MVC 的每个模块它的定义是清楚的，他们之间的关系是清楚的就可以。

然后，针对第四点其实非常关键，就是 针对关系中的核心问题，设计解决方案 。如果你是一个架构，那么你不只是说针对 ABC 提供解决方案，你更需要去思考的是，为什么把 ABDE 放到了一起？把它们放在一起之后，我提供什么样的一个方案，去支撑他们合在一起的关系，是一个容器么？然后 ABDE 的模块跟 GH 这个模块，他们是通过什么协议去对接？再比如，CFI 放在了最下面，他和上层是支撑关系么？那他通过什么来支撑上层？流程？接口？服务？

最后，第 5 步，就是你 拿一个实际的案例或问题套进去 。这个案例和问题还是从前面你的规划，就是你的现象、问题、定位、目标出发，套进去。

刚才不是说要讲故事吗？你就通过讲故事的方式套那些问题，第 1 步做什么，第 2 步做什么，看你这个架构图能不能跑的通？你看会不会有什么卡点？如果说都能跑得通，就初步的验证就通过了，就可以往下走。

再说下， 做架构设计中经常遇到的问题 。

第 1 个可能遇到问题就是照搬。我可能一开始看那些大佬们画的架构都是这么画的，所以我也这么来画。但实际上如果你是从前面的问题到定位到过程去思考的，那么你是不太会照搬一个东西过来的，一般都是你自己先有一个完整自己的思考。
然后第 2 个是 逻辑自洽 。这个是刚才讲过的，架构里的关系是逻辑自洽的，如果把它放到一起，结果解释不清楚，或者他们之间都是互斥的，你把它放到一起，这个就是有问题的。
第 3 个是 目标不清晰 。比如发现跟你前面的问题，或者你的定位目标关系很弱，或者关系是有偏差的，这个时候也是会出现问题的，因为你的架构都不是来解决你前面的问题的，那架构肯定是有问题的。
第 4 个是**只有架没有构。**逻辑是 ok 的，但是你落到关键的模块之间的关系上的时候，没有对应的有效的解决方案去支撑，或者是这个架构看起来逻辑是合理，但是没办法比较有效的解决你前面的问题。这个架构就很难成立。

这 4 个都是我在做架构设计的时候，非常常见的问题。

然后是技术产品架构这个事情，其实 技术产品架构就是产品架构 ，而产品架构最核心的东西其实是产品 Sense，如果你是从做解决方案出发的，在思考一件事情时，先思考他的价值，你慢慢就会建立起自己的产品 Sense。

技术产品架构它更多偏向在领域模型基础上的功能架构，通过业务需求和问题，用户流程抽象聚类出来的，哪些是抽象服务，哪些是具象功能，功能之间的关系是什么；例如以用户为实体做领域抽象, 或者以商品为实体做业务抽象, 再去看用户和商品之间的产品功能关系, 发现就不仅仅只是简单的用户浏览商品所以需要一个商品列表界面这样的问题了。如果从产品架构上能看出你的产品定位是什么，基本上产品架构就七七八八了。

明确不同用户、角色所需要的业务功能的分层，在架构上不同的承接方式。一般是 C 是金字塔、漏斗，B 是决策、流程、任务，例如：面对浏览阶段的客户和转化阶段的客户; 面对决策者和任务执行者。

3.6 打法与策略

然后讲一下 打法和策略 ，到这个阶段的时候，我们可能已经有一个相对完整的定位和方案了。

我们做技术的很多时候会觉得我把一个东西设计开发出来很容易，但是我要在公司或者在团队里面去推动落地，很难。总是感觉我做着做着，好像今天有什么事情耽误了，然后我做了好长时间，觉得他价值出不来，老板又不认同了，我就又做不下去了。

这个时候其实是需要讲究 打法跟策略 的，你怎么把这件事情更好的去完成和推动落地。

第 1 个，比如说我现在要做一套监控体系，我是先打算做采集的 SDK 还是先做可视化服务？

我可以先把服务搭起来，拉一些伪数据，然后老板一看 demo 挺清楚，好像是我们想要的东西，好，你开始做吧！

我也可以先做采集 SDK，先把数据存下来，如果没有数据，我分析个什么呢？是不是？那可能也都不是。可能是先根据业务的需求去设计字段模型，我要分析什么，我要分析性能还是分析用户的行为数据，还是要去分析业务转化数据？基于我要分析什么，我再去看，我的模型是什么样的，字段是怎么样的，Schema 是怎么样的，定义好 Schema，后面假如说我要加字段减字段，我就能很容易去扩展。

第 2 个，比如说你是打算全部做完这些功能，等文档都完善了之后，在所有业务线去落地铺开落地，还是说我先打算做出一个雏形后，直接到某个业务线落地，之后再去人肉的给他去做分析，先去解决他的问题？你打算在先在流量小的页面去尝试落地，还是说打算在一个流量非常大的性能非常差的页面去落地？

这个时候其实也比较讲究，如果你把这个东西全做完，做得非常完美，之后再去落地。这个时候它的好处是，你的用户他们会觉得这个东西一看，啊，这么好用，抓紧都用起来。如果你要是一开始是半成品，他会觉得你这个东西这里不好，那里不全。

但从另一个情况来看，如果你先做一个半成品去试点。试点之后你发现我发现我原来之前的思路是有问题的，我先验证，其实就是类似于小步快跑啊、快速迭代的方式，我去验证它，有什么问题我立马去修复它，修复完之后再让用户去用，这样快速的去验证，就会避免我费了好大的劲做一个成品出来，结果成品不是大家想要的，或者里面某部分就压根就不需要，结果浪费了很多资源，这种情况也很常见。

然后你打算在流量小的页面试点，还是打算在页面流量比较大，但是性能最差的落地试点。如果你在流量大、性能差的页面落地，其实是说你可能需要短期内去验证你的方案是有效的，然后你需要尽早的去给业务带来价值。那这个时候你可以尝试这种方式，但是如果你一开始你不确定，你觉得你这个方案可能会出很多问题，你就先在一个量很小的页面，先去尝试不要影响业务，这样的话你落地的压力就会小很多。

第 3 个，是你打算边开发边写文档，还是全写完之后再补文档？

可能也是很多人遇到的问题。因为你写的过程中，可能后面经常会变，这个时候你写完文档，后面还要再改，你就浪费很多时间，你可以根据情况来进行选择，我觉得我之前的设计已经非常完整，所以我先写省的后面忘了。但大多数情况可能就是我在开发完了之后，我在补文档，等产品比较稳定了，我再把文档全补上去。

其实讲了这么多，其实都是在讲怎么能够 更好的去把你的解决方案，或者这个事情可以推动下去 。或者说为了你 更顺滑，更有效达成你的目标 。你打算是以什么形式？什么人，先做什么后做什么？