前端早早聊大会,前端成长新起点,帮你提前二十天,站在新的起跑线,目标成为用得上,听得懂,抄得走的前端大会,计划 2020 年办 12 期,由前端早早聊与掘金联合举办。
第五届 - 前端监控体系如何搭建/用户行为/产品质量如何跟踪,4 月 25 日举行,8 位讲师,8 个小时,全天直播,报名链接:huodongxing.com/go/tl5
本文为第四届 - 前端职业规划专场讲师 - 远舟的分享 - 《如何做出专家级别的技术与技术产品规划》:
大家好,非常高兴能在早早聊的规划专场,和大家分享我对前端做技术与技术产品规划的一些思考和心得。
大家想不想知道从前端小萌新迅速成长为前端专家的捷径?俗话说,书山有路勤为径,我要好好写代码。
我们再看一个从一段代码到一个技术产品的例子。前端最早可复用的代码应该就是类似 reset,normalize 的代码了,之后为了更大程度的复用和解耦,有了模块化,模板,表单场景这样的解决方案,再之后为了让这些“物料”能够更好用,更方便的去用,所以就有了辅助设计开发这些物料的平台工具,规范,机制。这里也有个特点:不同的发展阶段要解决的问题不光是量的区别,问题的类型也发生了变化,那么所需的能力也自然会发生变化。
那我想问大家,从青铜到王者,你需要多久?1 年还是 3 年?从切页面到前端专家,5 年?还是 10 年?不同人会不一样。但如果我们提前知道每个阶段或者级别所需要的技能和能力,并且在练习和写代码的过程中刻意练习这些技能,那我们可以加速这个从当前阶段跨向下一个阶段的过程。
所以,捷径就是少走弯路,就是更早的知道下个阶段的要求,主动避开一些没必要踩的坑,我们要从好好写代码变成有规划的好好写代码,所以一个好的技术规划,就是一条捷径。
那来点正经的,规划到底有什么用?
当然每个人可能思考方向都不太一样,但如果你有自己的思考框架,那么你在想问题解决问题的时候,你肯定会更加的高效。
所以,技术规划本身其实是一个思考框架。
然后我们说一下,怎么做规划?
首先我们去通过这样一个图来看一下,规划的思考方式,就是你做规划和不做规划的思考方式的区别。整个做规划的过程,它是一个从发散到收敛的过程。
那么整个过程下来,用大白话说就是,你要解决什么问题,你打算怎么解决,你的解决方案是什么,在技术和产品上包含什么?如果要做,他的轻重缓急、切入点,跟抓手是什么,团队里需要什么样的人几个人来做,谁在什么时候做什么,中间可能遇到什么问题,怎么解决。最后我们去回看这个目标,去纠偏,看中间有没有走歪了。
这是一个大体的一个思考模式,后面我会去详细具体的去讲。
先看现象和问题,它会决定我们做规划的完整性。如果我一开始就只想到了这一个问题,或者只想到其中某一部分问题,没有想完整,那么这个时候你后面做出来规划也只是围绕解决这部分问题来的,这时候做的事情就可能偏掉或者歪掉。
常见的一些分析维度,比如这个事情发展到什么阶段,跟你通过一些数据分析发现的情况,用户价值的未来预判的等等这些,从这些角度做思考可以帮助你更完整的思考问题,这里抛出来一些供大家平时参考。
说几个这个过程可能会经常遇到的问题:
关于现象和问题,我推荐大家去看一本书《你的灯亮着吗?》,这本书其实是帮助大家去建立一种识别问题和思考问题的方法的一本书,我觉得挺好的,也挺入门的一本书。
前面那个部分就是我们去尽量发散,从我们当前的第 1 个问题出发,去发散发散很多,直到我们把现象和问题明确清楚。我们就到了第 2 步:做定位,做定位的时候我们就要去收敛了,假设右边图中这四个方向是我们发散问题的方向,那么我们需要从这 4 个方向,收敛到一个问题域的交集。
在这过程中有一些要点,就是找定位的过程,可以理解为找差异化价值的过程。就是比如像小米它做移动电源,华为也做移动电源,然后比如说我们业界有很多组件库的解决方案:antd,Fusion Design,ElementUI,各种各样的,乍一看很像,但实际上它们是不一样的,因为他们要解决的核心问题是不一样的。这个时候它的核心差异,就是它的定位,否则他会很容易被其他东西取代。
另外,过程中需要着重思考的是,哪些事情再难你也一定要做,哪些事情再简单你也不做,如果想清楚了这些问题,那么你的定位也就七七八八了。如果说你问不出,或者没想到这些问题,那就说明你定位是很不清楚的。
第三个其实和第二个问题类似,如果你清楚了你的定位,那么你一定会有这样一个问题,就是什么事情我们是不做的,但是跟我的定位是很有关系,他会对我的技术的体系或产品形成一些影响,我肯定我一定要去想清楚。
这里面也推荐大家两本书,有一本是《定位》,一本是《你的团队需要一个会讲故事的人》。前面就是讲定位,这本书还是很出名的,偏营销,帮助大家去理解定位的概念。第二本书是你怎么从讲故事的角度去理解你要去做的这件事情,以及它的价值。
其实从我们平时做的业务需求或项目的过程中,也可以有一些感触的。比如说产品经理提过来一个需求,他需要跟我讲清楚我们的用户是怎么样的?他用那个东西要解决什么问题,怎么做的?可能平时他只是讲个流程,但是真正要以故事的方式来讲的时候,他会讲他的价值,他的作用。这个时候你可能会有感触,我这个事情如果这么做的话,确实是有这样一个作用和价值的。平时如果都这么去思考问题,对你去梳理你的定位,其实是非常有帮助的。
当我们确定了我们定位,以及我们的解决方案大概是要解决什么问题的时候,我们就需要去定义我们要做到什么程度,或者说在什么阶段做到什么程度,这个就是定目标的过程。
这个过程中一般我们需要做目标的拆解,一般是两种方式:
好的目标一般都比较简单。就是我一看到这个东西,我就知道你要做什么事情,让大家就非常聚焦。有些时候我们的目标就很难去定出来。觉得这么定有不好,那么定也不是,或者定 30 定高了,定 50 定低了。有时候就需要粗暴的去拍一个,因为定目标这个事儿,我们首先需要有一个聚焦的东西,让我们能一起往目标去走,之后才是走多远。
第 3 个部分,是讲我在做技术架构和技术产品架构时的一个思路。
首先你如果要去画一个架构图的话,那么你得先明确你的架构目标是什么?这个架构目标就是来承接前面的定位和目标所定义的东西的。
架构图的种类非常多,不同类型的架构图画法也不同,这里从一个简单抽象图来解释我的理解,我理解的架构设计的目的都是为了理清关系,让每个点都能合理的安置在一个系统中,使系统整体能够高效稳定运作,而关系则会多种多样,我们的设计模式都是在描述 A 与 B,或者多个角色之间的关系,以及怎么重构这些关系来解决问题。
第一步,是针对你之前梳理的出来的要解决的问题想解决方案,把这些解决方案根据不同的维度列出来。
可能一开始你就是像下面左下角这个图一样,abcdef 你随便扔,随便列,就是一堆的各种各样的解决方案,或者功能,或者技术能力,跟一个标签云一样,之后开始从不同的维度去思考他们之间的关系。可能会有很多种各种各样的关系,但是你这里只需要围绕你的架构目标去定义所需要解释的关系。这些关系的梳理可能会把某些解决方案或者能力打散,或者合并。当然,如果有现成的一些设计模式或者架构模型刚好契合你现在的情况,那就直接往上套了。
只要你做到逻辑自洽,内容、角色之间的关系能够讲得清楚,其实就可以。并不意味着说好像比如有很多人画了各种各样的架构图,你看觉得很有道理,但是你可能从另外一个方式来画,或者从另外一个角度来讲,你画的也有道理,也能讲清楚,其实是一样的,没关系的,没有一个所谓的标准答案说一定是怎么样的。比如 MVC,你把 M 放左边 C 放右边画或者是你反过来画,倒过来画,它都是 MVC,只要是你 MVC 的每个模块它的定义是清楚的,他们之间的关系是清楚的就可以。
然后,针对第四点其实非常关键,就是针对关系中的核心问题,设计解决方案。如果你是一个架构,那么你不只是说针对 ABC 提供解决方案,你更需要去思考的是,为什么把 ABDE 放到了一起?把它们放在一起之后,我提供什么样的一个方案,去支撑他们合在一起的关系,是一个容器么?然后 ABDE 的模块跟 GH 这个模块,他们是通过什么协议去对接?再比如,CFI 放在了最下面,他和上层是支撑关系么?那他通过什么来支撑上层?流程?接口?服务?
最后,第 5 步,就是你拿一个实际的案例或问题套进去。这个案例和问题还是从前面你的规划,就是你的现象、问题、定位、目标出发,套进去。
刚才不是说要讲故事吗?你就通过讲故事的方式套那些问题,第 1 步做什么,第 2 步做什么,看你这个架构图能不能跑的通?你看会不会有什么卡点?如果说都能跑得通,就初步的验证就通过了,就可以往下走。
再说下,做架构设计中经常遇到的问题。
这 4 个都是我在做架构设计的时候,非常常见的问题。
然后是技术产品架构这个事情,其实技术产品架构就是产品架构,而产品架构最核心的东西其实是产品 Sense,如果你是从做解决方案出发的,在思考一件事情时,先思考他的价值,你慢慢就会建立起自己的产品 Sense。
技术产品架构它更多偏向在领域模型基础上的功能架构,通过业务需求和问题,用户流程抽象聚类出来的,哪些是抽象服务,哪些是具象功能,功能之间的关系是什么;例如以用户为实体做领域抽象, 或者以商品为实体做业务抽象, 再去看用户和商品之间的产品功能关系, 发现就不仅仅只是简单的用户浏览商品所以需要一个商品列表界面这样的问题了。如果从产品架构上能看出你的产品定位是什么,基本上产品架构就七七八八了。
明确不同用户、角色所需要的业务功能的分层,在架构上不同的承接方式。一般是 C 是金字塔、漏斗,B 是决策、流程、任务,例如:面对浏览阶段的客户和转化阶段的客户; 面对决策者和任务执行者。
然后讲一下打法和策略,到这个阶段的时候,我们可能已经有一个相对完整的定位和方案了。
第 1 个,比如说我现在要做一套监控体系,我是先打算做采集的 SDK 还是先做可视化服务?
我可以先把服务搭起来,拉一些伪数据,然后老板一看 demo 挺清楚,好像是我们想要的东西,好,你开始做吧!
我也可以先做采集 SDK,先把数据存下来,如果没有数据,我分析个什么呢?是不是?那可能也都不是。可能是先根据业务的需求去设计字段模型,我要分析什么,我要分析性能还是分析用户的行为数据,还是要去分析业务转化数据?基于我要分析什么,我再去看,我的模型是什么样的,字段是怎么样的,Schema 是怎么样的,定义好 Schema,后面假如说我要加字段减字段,我就能很容易去扩展。
第 2 个,比如说你是打算全部做完这些功能,等文档都完善了之后,在所有业务线去落地铺开落地,还是说我先打算做出一个雏形后,直接到某个业务线落地,之后再去人肉的给他去做分析,先去解决他的问题?你打算在先在流量小的页面去尝试落地,还是说打算在一个流量非常大的性能非常差的页面去落地?
这个时候其实也比较讲究,如果你把这个东西全做完,做得非常完美,之后再去落地。这个时候它的好处是,你的用户他们会觉得这个东西一看,啊,这么好用,抓紧都用起来。如果你要是一开始是半成品,他会觉得你这个东西这里不好,那里不全。
但从另一个情况来看,如果你先做一个半成品去试点。试点之后你发现我发现我原来之前的思路是有问题的,我先验证,其实就是类似于小步快跑啊、快速迭代的方式,我去验证它,有什么问题我立马去修复它,修复完之后再让用户去用,这样快速的去验证,就会避免我费了好大的劲做一个成品出来,结果成品不是大家想要的,或者里面某部分就压根就不需要,结果浪费了很多资源,这种情况也很常见。
然后你打算在流量小的页面试点,还是打算在页面流量比较大,但是性能最差的落地试点。如果你在流量大、性能差的页面落地,其实是说你可能需要短期内去验证你的方案是有效的,然后你需要尽早的去给业务带来价值。那这个时候你可以尝试这种方式,但是如果你一开始你不确定,你觉得你这个方案可能会出很多问题,你就先在一个量很小的页面,先去尝试不要影响业务,这样的话你落地的压力就会小很多。
第 3 个,是你打算边开发边写文档,还是全写完之后再补文档?
可能也是很多人遇到的问题。因为你写的过程中,可能后面经常会变,这个时候你写完文档,后面还要再改,你就浪费很多时间,你可以根据情况来进行选择,我觉得我之前的设计已经非常完整,所以我先写省的后面忘了。但大多数情况可能就是我在开发完了之后,我在补文档,等产品比较稳定了,我再把文档全补上去。
其实讲了这么多,其实都是在讲怎么能够更好的去把你的解决方案,或者这个事情可以推动下去。或者说为了你更顺滑,更有效达成你的目标。你打算是以什么形式?什么人,先做什么后做什么?
最后这部分,是讲项目计划,我们有了前面的打法策略之后,我们就能模糊的知道我们大致的节奏是怎么样的。
如果拿王者荣耀来举例子,就是在确定前期你是先抓人还是先发育之后,你打算几点几分和谁一起去抓人。这就是项目计划的作用:保障这个过程是按期按质量完成的。
项目计划简单介绍一下,可能大家也都知道有现在主流的两种,一种是左边的瀑布流,Waterfall Model,右边是
Scrum,敏捷迭代,这两种模型模式其实各有各的优缺点。
现在很多人都在讲互联网公司在讲 Scrum 敏捷迭代,双周或者四周冲刺,然后去拿到一个最想发布的一个 MVP,然后去给用户去用完之后,然后我再去更新迭代。
Waterfall 其实是说传统的那种大型软件开发的一个思路,我要交付一个非常完整的产品,这个时候我就去把所有的模块全拆出来,所有的计划全拆出来,然后按部就班的一步步开发,到最后去发布。
不管你用哪种形式,一开始的话你都不用想那么多,直接上工具开搞,觉得哪种好用就用哪种,慢慢找到感觉了之后,如果有需要,再去细化项目管理的过程。像 WBS,Omniplan,Teambition,Redmine,都是挺好用的工具,慢慢你就知道了,这个不用刻意去学,考什么证没必要的。
最后就是我这边举个例子,这个是我从我们公司的一个业务挑战,然后拆解到对应的产品挑战,再到体验技术上的挑战,再到可能所需要的体验、技术能力这样的一个拆解,这个是一个非常广义的,和业务战略层面对接的一个拆解。
我这里拿其中一个来说一下,不再一个个来讲,因为这样的话可能需要花费很长时间。工具价值低,竞争对手多,你做这功能我也做这个功能。这个时候就会对我们的产品体验提出要求,体验就是我的核心竞争力,我们都一样,但我体验更好。
为什么我们现在说体验是 SARS 的最后一个品类,它越来越重要,就是因为它逐渐在产生它的商业价值。
我们当前的发展阶段,产品体验的核心问题,还是在一致性,效率,稳定性上。这个时候,在体验方面,在体验技术方面,那就会涉及到我们的体验系统、性能、监控、稳定性。然后是体验数据,体验分析,之后还有品牌的一致性这些等等。
之后,就是基于这样的体验技术挑战去推导体验技术能力的标签云。同时也需要有一个完整的组织能力,才能保障,才能把这件事情给做下去。
接下来的第 2 步,是怎么把体验技术能力的诉求标签云给拆成,或者是把它给结构化成体验技术架构。
时间有限,我的分享今天就到这里,欢迎大家后续一起交流探讨。