业务场景:中后台为主,其他不好说,毕竟没深入干过 =,=
(一)
在浏览一位转岗候选人的 ATA 时,又顺藤摸瓜重温了这两篇文章:
• 《前端技术体系大图最全详解 | 阿里技术20年》这篇文章讲得很好,非常体系化的讲解了“阿里的前端技术体系”,搭建、智能化、工程中台、Node、数据可视化、国际化、中后台、跨端,有过去、有当下、更有未来。就是有一个小问题,这些都是工具链,是生产工具,负责这些个工具链的前端同学占全体前端的 10% 左右吧。无形之中把 10% 的工具链生产者放到一个高光位置,那么剩下的 90% 的负责直接产出业务价值的前端同学呢,他们在哪儿,他们的形象是模糊的,他们的去向是未定的。但是倘若没有这 90% 去使用那 10% 的工具链,这 10% 的价值如何体现?
• 《前端核心竞争力的演变》在某种意义上,这篇文章恰恰是对上文的补充,这篇文章关注“人”而不是“物”,总结为一张图,对于这张图,非常认可,同时也启发我结合自己的经验思考在此基础上进行一些补充,稍后见下文
团队就是一群人干一堆事,团队的发展核心奥义之一就是人的发展,有了优秀的人才才能做出好样的业务,拿到棒棒的结果。
(二)
好的方向 + 好的人才 = 好的结果
首先来讲好的人才,或者说“前端的核心竞争力”
技术这个板块,什么是基本功,不再赘述,什么是工具链,基本就是《前端技术体系大图最全详解 | 阿里技术20年》所列举的典型案例。但这还不够。
回到“前端”这个词,本身意味着“人机交互”,意味着“用户与产品交互”,这里面隐含着什么是好的交互、怎么做到好的交互。怎么做到好的交互,很大程度上依赖于我们的技术能力,什么是好的交互,则意味着我们要了解用户、了解产品、了解领域背景,并且要总结出一套方法论来衡量及指导具体的开发。这一块目前是缺失的,但也是非常关键的。
所以,这里我补充了“体验”这个板块,里面包括了设计 sense 和产品 sense 两个子域,我们不是设计师,我们也不是 PD,但我们要有必要的体验专业基础知识及 sense。产品设计是一项很专业的工作,也要视产品本身具体对待,但是一些大的产品方向(以我熟悉的中后台为例),比如:
• 减少流程断点,适度的产品融合
• 清晰的产品概念及其逻辑层次,清晰的网站地图,减少用户迷失
• 便捷的打开、访问、处理,有效的用户反馈路径
• 统一的品牌认知,产品认知
这些都是 common sense,在此基础上可以有更多的思考与扩展,但是很遗憾,我一直没有见到针对中后台领域的具有实战指导意义的产品方法论或者设计方法论,这也已经严重制约了中后台产品的发展,至少就我了解而言,搓逼的 PRD 往往导致产品平庸、无疾而终,这在中后台司空见惯。
第三个板块是“领域知识”。前端一直莫名背负着“前端不懂业务”“前端离业务远”“前端就得听后端的”这些“原罪”。领域知识的“宽、广、深”和技术上的“宽、广、深”至少在一点上是很有可比性的,就是它们本质上都是天然带有相对性的,要辩证地唯物地看待。让一个搞应用开发的和搞中间件开发的比性能的深度,怎么比?让一个搞中间件开发的和搞 Linux 开发的比操作系统,怎么比?脱离背景讲尺度,有点儿耍流氓。我带团队一直强调大家一定要深入业务,一定要有领域深度,是要和后端比业务深度还是和 PD 比业务熟悉度?恐怕都不是的。前端对领域知识的宽,要宽到你可以合纵连横,主导整合多个功能模块、甚至多个产品,给用户以一致化的好体验,所以每个产品你都是要如数家珍的;前端对领域知识的深,要深到你可以对产品提出真正有价值的、并且是 creative 的产品建议,把体验 feature 打造成产品的核心 feature,成为用户 buy-in 的点,如果是商业化产品,你的建议能不能降本,能不能增收,能不能是个卖点?在这个点上,后端的领域模型,业务模型,甚至商业模型,我们是要略懂的。这些建议不是单纯 PD 或者设计师可以想到的,这些建议是化学反应后的增值性建议,是创新性建议,必然来自于我们对前端技术、领域知识、体验知识的综合性掌握。前端给产品的第一价值是体验,领域知识为体验创新服务。术业有专攻,闻道有先后,在领域知识这个点上,前端必须站起来,理直气壮的说话。
最后,结合“技术”、“领域知识”、“体验”三个板块,回归到前端的核心竞争力,我总结一句话:在综合掌握运用前端技术、领域知识、体验知识的基础上,给产品提供(以体验为核心竞争力的)建设性的解决方案,帮助业务成功的能力。这样的新·前端,我给它一个“新”·岗位名词“体验产品工程师”,以体验为抓手的促成产品成功的工程师。关键词是“促成成功”,所以如果更进一步,我们甚至可以说这就是“产品工程师”!