原文链接在此

这篇文章既是对我之后要做的事情的介绍，也是代表快手商业化前端团队的招聘。我们想要打造一支有追求、重视自我提升的团队，去做真正有技术价值，有挑战的事情。

1 要做的事情

可以概括为：打造以“结构化的需求表述”为中心的 Web 应用研发体系。

在现在很多公司的的研发体系中，对需求的表述是散落在不同的地方的，例如：

• 以自然语言的形式存在 prd 中，例如大部分的概念、流程。
• 以图片的形式存在视觉稿中。例如页面信息，跳转关系。
• 以片段的形式存在代码中，例如业务规则等。

这些信息不只是散落，往往还经过了不同的角色翻译，最后成了不同的产物。

以“结构化的需求表述”为中心的首要目标是这些与具体实现无关的信息收纳到一起，成为 “single source of truth”。其次，将需求表达结构化指的是，使用“产品经理等非程序员也可理解的”，并且“程序可识别”的结构来重新表达这些信息，例如：

• 将 prd 中的概念用实体关系图表达出来
• 将产品中的页面、跳转关系等用产品地图表达出来
• 将业务中的规则等用树、图等可由程序读取的结构表达出来

最终使得我们能得到一份像建筑图纸一样的 Web 产品蓝图，它与具体实施技术无关。利用这份图纸：

• 消除掉组织中低效地角色之间的沟通
• 将一定复杂度内的工作自动化
• 作为质量和效能评估的输入
• 作为业务能力沉淀的索引

第一点除了可以直接消除各个角色间对于产品本身的理解鸿沟之外，还可以与项目管理工具结合起来，将研发流程之间的沟通工作也消除掉。例如平台可以自动在设计师完成视觉稿上传后，通过 IM 工具来通知相关负责的工程师。

研发中参与角色越多、流程越复杂，消除低效沟通越有意义。同时它也是降低工作成本，使得低技术价值工作外包化的前提之一。

第二点自动化。现实中可能只有真的业务非常简单的组织才有可能完全实现自动化，大部分时候只能无限趋近。在趋近过程中，我们在前端要达成的是：

对于简单交互，能通过视觉稿自动生成，或者由设计师使用搭建系统完成视图部分。 对于无特异性、中等交互复杂度的场景，使非专业前端或者外包工程师能通过搭建系统来完成。使组织支撑能力可以弹性变化。 对特异性强或者交互复杂的场景，才由专业的前端工程师介入。 针对这几点，我们要做的具体工作有：

基于 Sketch 的设计稿生成可用页面工具。未来可能要做在线的设计工具。 可渐进扩展的搭建系统。 可把控的前后端一体的研发框架。它决定着使用门槛、和质量工具上下限。在不断地探索和结构化需求的表达时，框架也是直接作为沉淀概念的载体。 我们会不断将“仍然需要专业工程师参与的场景”加入到团队的“研究池”中，作为指导框架和工具的发展的来源，将其逐渐转化为可自动生成或者由非专业工程师处理的场景。

关于第三点中所提到的质量保障。有了产品设计蓝图后，可以更好地承载质量相关的信息，例如业务中的关键路径等、与外部系统的链接、业务的复用等。当进行迭代时，质量系统可以根据这些信息来自动判断迭代影响的范围，甚至自动进行回归。

关于效能评估。在过去的项目管理及效能相关的工作经验中发现，我们目前基于需求缺陷数、代码行数、工作时长、人数的效能评估方法对效能提升几乎没有任何指导意义。例如有的项目本身业务或者已有的代码就很复杂，沟通理解占用了很多时间怎么算？有的工程师为了后续业务扩展更快，所以花了更多时间设计了更好的抽象怎么算？

其中的关键在于工程最后体现出来的复杂度是很多不同类型复杂度的综合产物，如果不把其中业务本身的复杂度、底层技术的使用复杂度、框架认知的复杂等等都区分开，我们就无法正确评估出工程师自身代码产生的复杂度，无法评估其研发、维护等所带来的收益和债务。

我们使用产品的蓝图将需求本身独立出来，提供了将业务交互、模型等认知复杂度和代码认知复杂度分离的可能。当实现了复杂度的单独计算之后，就可以通过业务复杂度的计算值自动判断项目是否需要专业前端工程师参与，甚至结合项目管理工具实现自动分配。在交付后通过代码复杂度算法来对效能进行正确评估。组织中的低效人力管理工作也可以得以降低和消除。

更重要的是，对复杂度的探索本身本事是和对需求的理解及结构化紧密相关的，能极大推动体系的前进。

关于最后一点“作为业务能力沉淀的索引”。

大部分组织中的沉淀都是从实施的技术这一侧开始的，利于基于某种语言的框架、具备某种特性的数据库等。这些沉淀的载体是可以直接是代码，是 sdk，或者直接线上的 api 。那对于产品的沉淀呢？可不可以类似 Github 有个 Producthub ？

实际上产品中有很多值得沉淀的知识，例如社交产品中的用户之间关系设计、内容审核流程等等。哪怕是看起来最简单“交友流程”，仔细深入就会发现有很多要考虑的细节，例如连续被拒绝 3 次怎么办，是否不允许再申请？这个 “3” 次是不是可以用户来设置？

产品蓝图作为索引实现产品能力的沉淀的意义在于：

• 直接沉淀各个角色都可理解甚至直接可用的产品知识。像开源软件一样实现产品知识的爆炸式共享。
• 当蓝图与整个工程体系结合得足够好之后，甚至可以实现产品级的搭建和复用。
• 当和项目管理体系结合好之后，可以让所有人对产品的成本有真正的认识。
• 给组织内的所有技术发展提供更明确的方向指引、价值评估。

只有释放产品的生产力才能真正为组织带来价值。站在这个角度去看，研发体系建立的首要目标就是实现产品能力的沉淀。希望达成的是：在这个系统中，任何产品所需要的具体能力都具备一定的“智能”，能理解结构化的需求，然后进行支撑，而不再是工程师手工地去使用。例如我要做个社交产品，我的需求中结构化地描述了用户之间的关系，并且描述了有几度的关系查询需求，那么提供存储能力的系统应该自动地帮我选择相应图数据库。第一次实现时，可能需要工程师写出根据一些特征来判断选择什么数据库的代码。但当我再有类似需求时，就不在需要工程师了，这些代码变成了“经验”沉淀在存储系统里，能“智能”地帮我选择了。

对需求的结构化描述是实现产品蓝图，实现产品能力沉淀很重要的一步，能做到什么程度，有过哪些探索可以参考我之前的文章：

突破 web 应用研发效能的叹息之墙

同时从代码侧也可以有更多的探索，使得代码语义与需求语义更加一致。推荐参考：

Database in the Browser, a Spec

综上，我们的团队将要做（但不限于）的具体事情有：

• 产品蓝图
• Sketch 工具(已有基础)
• 在线设计工具(筹)
• 搭建系统(已有基础)
• 基于认知的需求复杂度分析算法
• 基于认知的代码复杂度分析算法
• 质量体系(已有基础)
• 效能评估体系
• 研发工具
  • WebIDE
  • 浏览器插件(已有基础)
  • IDE 插件

我们太需要愿意去挑战甚至创造未来的你加入了。也期待你带来更多超越这个体系的想法。

2 价值观和团队文化

我们认为：

2.1 顶层设计与认知迭代比实施更重要

顶层设计和承认认知迭代的价值是团队及每个成员成长的关键。

我们的顶层设计是所有人参与，在严格的逻辑框架下产生的。我们鼓励讨论和冲突，因为认知本来就是在不断的冲突和实践反馈中迭代的。让错误的认知被反驳，人才会得以更新和成长。保障正确的认知不管来自于谁都得到极大的支持和实施，才能得到最有价值的反馈，成为所有人的收获。

我们每个人都要成为既是最好的队友也是最好的对手，团队的成长才能产生加速度越来越快，才能使团队带来的成长高于个人努力地成长。

我认为从更长远的未来来看，正确的认知比任何短期经济收益都更有价值，所以愿意为其投入更多的时间和资源。

缺乏顶层设计和愿意承认认知价值的地方往往平台林立、部门占山割据互相争斗、急于夺取眼前利益而放弃正确的方向。这样的环境对每个人来说都是浪费生命。

2.2 团队的成长建立在个人成长之上

相比于去做具体的事情，我们更加鼓励并且会直接组织引导每个人去进行系统性的学习。大部分时候我们缺的都不是实施能力。正如在开源领域看到的情况一样，社区出现一出现新的思路，国内的开发者就能迅速跟上，甚至在工程细节上还才能做得更好。我们缺的是去提出这些想法的能力，去探索和结构化未知的能力。是这些想法带来了质变。而它不是通过不停地做得到的，更多地要依靠系统性的学习和探索。

2.3 应该聪明而勤奋地活着

聪明加上勤奋比只是聪明好，只是聪明比只是勤奋好。当然这两者并不冲突，聪明往往来自于勤奋。但要注意的是勤奋并不等于忙碌。我们要的勤奋是“主动”去改善自己、认识环境甚至改善环境的意志力，而不是“被动”地花费更多的力气去忍耐环境。

3 希望的伙伴

• 扎实的编程功底或者极强的理工科思维。
• 理智思考。
• 有自我追求。
• 自信但不自负。

我们没有任何年限或者经历之类的硬性限制，你甚至可以不熟悉前端。只要你对我们想做的事情感兴趣，满足以上条件就欢迎你来应聘。

4 关于职位和如何应聘

当前职位所属部门为：快手商业化技术部-前端研发-通用技术组。

Base 地：杭州 /北京。

部门前端研发人数目前 150+，今年仍会有大幅扩充。

招聘职级和薪酬对标业内 p5-p8 。

需要准备的：

• 公开的专栏、文章、代码仓库等技术积累（如果有）。
• 技能树（如果认为以上的文章、代码等已经足够说明自身的能力，并且包括了知识边界，可以省略技能树。）
  • 地址：技能树飞书版 或者 技能树语雀版 或者 xmind 文件
• 请独立完成公开的面试题。
  • 地址：https://github.com/ariesate/interview
  • 请尽量提交你认为你能完成的“最难”的 3 道题答案。请“独立自主”答题，记录每道题答题时间，在 github 上创建公开的 repo 提交答案和答题花费的时间。

关于技能树的进一步说明：

使用在线平台编辑技能树时请：

• 请注册平台账号后将文档添加到自己的空间中进行编辑。
• 删除自己不具备的节点，增加自己有的。如果觉得很难判断，可以进一步将已有节点细化。
• 使用图例中每个等级对应的颜色来标注自己对相应技能掌握的程度。
• 编辑完请将“分享”设置为“互联网上获得链接的人可阅读”，语雀中点击分享即可拿到链接。

技能树只是用来作为提高沟通效率的工具，并不是决定性考核。相比于拥有更多具体技能，我们更倾向于招募编程基础扎实的伙伴，所以请如实编辑，不要有任何压力，相信这些内容或许在其他场合也能帮你提高沟通效率。

最后请将

• 文章代码等地址
• 技能树在线地址或者 xmind 文件。
• 面试题答案地址

一并通过邮箱发送至 [email protected] ，谢谢！

5 关于校招、实习生

我们接受 2022 春招，同时不符合春招条件的实习也可以。对校招和实习生来说，没有对外积累的文章或者技能树不够全面也没关系。任何能证明你不是个平庸地人的事情都可以，例如校内成绩或是自己特殊的经历。

6 关于我

有任何问题可以通过我的微信联系我：18268028026 。

关于我过去的研究和经历可以参见我的知乎上的文章。

关于我过去对外的公开招聘可以从 V2EX 上找到：V2EX sskyy

原文链接在此