前言
有招聘前端的，欢迎联系情封vx:zhgb_f2er。前端早读课招聘季第82期
快手商业化团队招聘从这开始~~
这篇文章既是对我之后要做的事情的介绍，也是代表快手商业化前端团队的招聘。我们想要打造一支有追求、重视自我提升的团队，去做真正有技术价值，有挑战的事情。
1要做的事情可以概括为：打造以“结构化的需求表述”为中心的Web应用研发体系。
在现在很多公司的的研发体系中，对需求的表述是散落在不同的地方的，例如：
以自然语言的形式存在prd中，例如大部分的概念、流程。
以图片的形式存在视觉稿中。例如页面信息，跳转关系。
以片段的形式存在代码中，例如业务规则等。
这些信息不只是散落，往往还经过了不同的角色翻译，最后成了不同的产物。
以“结构化的需求表述”为中心的首要目标是这些与具体实现无关的信息收纳到一起，成为“singlesourceoftruth”。其次，将需求表达结构化指的是，使用“产品经理等非程序员也可理解的”，并且“程序可识别”的结构来重新表达这些信息，例如：
将prd中的概念用实体关系图表达出来
将产品中的页面、跳转关系等用产品地图表达出来
将业务中的规则等用树、图等可由程序读取的结构表达出来
最终使得我们能得到一份像建筑图纸一样的Web产品蓝图，它与具体实施技术无关。利用这份图纸：
消除掉组织中低效地角色之间的沟通
将一定复杂度内的工作自动化
作为质量和效能评估的输入
作为业务能力沉淀的索引
第一点除了可以直接消除各个角色间对于产品本身的理解鸿沟之外，还可以与项目管理工具结合起来，将研发流程之间的沟通工作也消除掉。例如平台可以自动在设计师完成视觉稿上传后，通过IM工具来通知相关负责的工程师。
研发中参与角色越多、流程越复杂，消除低效沟通越有意义。同时它也是降低工作成本，使得低技术价值工作外包化的前提之一。
第二点自动化。现实中可能只有真的业务非常简单的组织才有可能完全实现自动化，大部分时候只能无限趋近。在趋近过程中，我们在前端要达成的是：
对于简单交互，能通过视觉稿自动生成，或者由设计师使用搭建系统完成视图部分。
对于无特异性、中等交互复杂度的场景，使非专业前端或者外包工程师能通过搭建系统来完成。使组织支撑能力可以弹性变化。
对特异性强或者交互复杂的场景，才由专业的前端工程师介入。
针对这几点，我们要做的具体工作有：
基于Sketch的设计稿生成可用页面工具。未来可能要做在线的设计工具。
可渐进扩展的搭建系统。
可把控的前后端一体的研发框架。它决定着使用门槛、和质量工具上下限。在不断地探索和结构化需求的表达时，框架也是直接作为沉淀概念的载体。
我们会不断将“仍然需要专业工程师参与的场景”加入到团队的“研究池”中，作为指导框架和工具的发展的来源，将其逐渐转化为可自动生成或者由非专业工程师处理的场景。
关于第三点中所提到的质量保障。有了产品设计蓝图后，可以更好地承载质量相关的信息，例如业务中的关键路径等、与外部系统的链接、业务的复用等。当进行迭代时，质量系统可以根据这些信息来自动判断迭代影响的范围，甚至自动进行回归。
关于效能评估。在过去的项目管理及效能相关的工作经验中发现，我们目前基于需求缺陷数、代码行数、工作时长、人数的效能评估方法对效能提升几乎没有任何指导意义。例如有的项目本身业务或者已有的代码就很复杂，沟通理解占用了很多时间怎么算？有的工程师为了后续业务扩展更快，所以花了更多时间设计了更好的抽象怎么算？
其中的关键在于工程最后体现出来的复杂度是很多不同类型复杂度的综合产物，如果不把其中业务本身的复杂度、底层技术的使用复杂度、框架认知的复杂等等都区分开，我们就无法正确评估出工程师自身代码产生的复杂度，无法评估其研发、维护等所带来的收益和债务。
我们使用产品的蓝图将需求本身独立出来，提供了将业务交互、模型等认知复杂度和代码认知复杂度分离的可能。当实现了复杂度的单独计算之后，就可以通过业务复杂度的计算值自动判断项目是否需要专业前端工程师参与，甚至结合项目管理工具实现自动分配。在交付后通过代码复杂度算法来对效能进行正确评估。组织中的低效人力管理工作也可以得以降低和消除。
更重要的是，对复杂度的探索本身本事是和对需求的理解及结构化紧密相关的，能极大推动体系的前进。
关于最后一点“作为业务能力沉淀的索引”。
大部分组织中的沉淀都是从实施的技术这一侧开始的，利于基于某种语言的框架、具备某种特性的数据库等。这些沉淀的载体是可以直接是代码，是sdk，或者直接线上的api。那对于产品的沉淀呢？可不可以类似Github有个Producthub？
实际上产品中有很多值得沉淀的知识，例如社交产品中的用户之间关系设计、内容审核流程等等。哪怕是看起来最简单“交友流程”，仔细深入就会发现有很多要考虑的细节，例如连续被拒绝3次怎么办，是否不允许再申请？这个“3”次是不是可以用户来设置？
产品蓝图作为索引实现产品能力的沉淀的意义在于：
直接沉淀各个角色都可理解甚至直接可用的产品知识。像开源软件一样实现产品知识的爆炸式共享。
当蓝图与整个工程体系结合得足够好之后，甚至可以实现产品级的搭建和复用。
当和项目管理体系结合好之后，可以让所有人对产品的成本有真正的认识。
给组织内的所有技术发展提供更明确的方向指引、价值评估。
只有释放产品的生产力才能真正为组织带来价值。站在这个角度去看，研发体系建立的首要目标就是实现产品能力的沉淀。希望达成的是：在这个系统中，任何产品所需要的具体能力都具备一定的“智能”，能理解结构化的需求，然后进行支撑，而不再是工程师手工地去使用。例如我要做个社交产品，我的需求中结构化地描述了用户之间的关系，并且描述了有几度的关系查询需求，那么提供存储能力的系统应该自动地帮我选择相应图数据库。第一次实现时，可能需要工程师写出根据一些特征来判断选择什么数据库的代码。但当我再有类似需求时，就不在需要工程师了，这些代码变成了“经验”沉淀在存储系统里，能“智能”地帮我选择了。
对需求的结构化描述是实现产品蓝图，实现产品能力沉淀很重要的一步，能做到什么程度，有过哪些探索可以参考我之前的文章：突破web应用研发效能的叹息之墙
同时从代码侧也可以有更多的探索，使得代码语义与需求语义更加一致。推荐参考：