概述
技术上最大的收获是前端团队的独立以及UED与前端团队的融合,思维上要有产品思维,体验思维。
一、前端的价值
玉伯说前端的核心价值,可以等同为一个问题:“公司为什么需要前端团队?前端团队因何而存在?” 。我的理解是公司的需求是仅仅实现产品的功能还是想做成真正的的产品?大部分的公司都是想做真正的产品,但是在实际的实施过程中会走偏,特别时传统行业和以后端为主的产品,基本上很难产生精致的产品。
核心:组织设计上前端集中化可以为公司降本增效、提升产品体验并为业务创造一些可能
分工是整个社会效能提升的关键。工业社会的分工极大提高了社会运转效率。以前农业社会衣食住行所需要的东西都可以自己生产,这叫做自闭环,效率是极低的。正是因为有了社会分工,整个人类社会才飞速发展。
在大厂前后端分离之后,前端都早已成立独立的团队集中化管理,给我们带来了大量体验及其棒的产品。当时我从大厂离职之后去了一家集电商、2C金融、营销、B端金融的互联网消费金融公司,而我们的前端团队最多的时候才13人,了解电商的都知道,就算13个前端都去搞电商都不够,更何况还需要去支持金融业务。实际上我们能够以极少的前端去支撑公司的大量业务并做了APP、H5、中后台产品,并且都还做的不错,主要得益于集中管理,深挖基建,多做工具。这是团队集中管理的好处。
后面经历的一些公司前端分散在各个业务条线,每条业务条线甚至每个产品都想招自己的前端,结果是前端人数过多,人员流动快,产品稀烂。试想,当几十甚至上百个前端以及其小的个位数分散到不同的业务条线上时,前端如何做技术积累、如何做产品优化,在产品和后端主导的业务条线上他们没有自己的地位,很难更不愿以精致的心态去做事情。其实组织设计上,前端团队如果集中在一起可以带来效率提升。假设一个业务需要30个前端支撑,放到一起可能只需要20个人或者更少的人就可满足业务需求。
集中管理的好处是可以复用经验,可以更高效更专业的去支撑业务发展。前端团队放在一起,能够给业务更专业的指导或者专业的反馈。前端团队的存在,是因为技术专业分工能带来整体效能的提升。同时前端团队往往会是一个整体,集中化可以降低公司的整体成本。
关于怎么为业务创造一些可能?
- 前端是离用户最近的
- 前端更懂如何实现
当前很多公司特别是B端公司的误区:产品和后端主导产品,配置1或2个前端,这样的产品基本上没有做持续的,甚至几年之后产品还是老样子,吃老本。
二、注重体验:把简单留给用户也把简单留给自己
体验分为两层来理解,一个是用户体验,另外一个是研发体验。有个理论是世界是简单的,比如我们做数学或者物理题的时候,当我们解题思路过于复杂的时候基本上就是进入了误区。开发也是一样的,当我们写了很多代码还是完成不了功能时,可能是我们的思路错了!
守住体验的基线,体验基线就是体验地板,是体验默认不糟心。 体验基线的提升是系统化工程,经常会比单点的体验天花板的提升更难。
关于体验一定要结合不同的行业客户使用场景来设计。
三、关于小程序和客户端
1、关于小程序
小程序的出现前提是有航母级应用作为载体,比如微信、支付宝作为航母级载体催生了微信和支付宝小程序,拓展了前端技术的应用。
支付宝小程序应用是基于支付宝小程序技术的生态开放业务,是生态开放的最好载体。
小程序的好处:
- 降低成本
- 降低开发门槛
- 技术普惠
未来的发展趋势:
- 低代码或者无代码
- 文档即应用
- 国外PWA
2、前端工程化
前端工程化的本质是让一群人做好一堆事,这一堆事指的是业务和基础设施。让前端同学可以基于这些平台更好的协同工作。
团队前端工程化出现的必要条件就是前端团队的独立。
3、前端和客户端
前端特点是快和灵活,发版速度快,研发效能高。
客户端适应场景是对性能要求高的场景,或者开发技术工具、网络、端智能和容器。
目前的以前端为主,客户端为辅,两者的结合是客户端搭台,前端唱戏。
三、关于开源
1、开源的建议:
- 首先时阅读源码,看代码为主,逐步参与文档讨论,写核心;
- 其次时社区运作,探讨如何设计,设计先行,文档先行,提交代码。
YUI3做的很好,但是社区却越来越不喜欢。将精力开始转向产品思考。从产品的角度看开源项目,决定开源成败的关键是产品本身的设计理念和思路是否符合潮流
2、开源的收获
- 深度感受写代码的快乐
- 意识到代码是工具,用技术实现的产品价值点
- 社区异步协调的美好体验
- 文档的重要性,清晰表达,文档先行的理念,亚马逊’六页纸‘管理理念
国内开源:等代码差不多才开源不好,别人没机会参与,古典产品主义者。
好的开源项目、产品:极简化、删无可删,你只要加功能,你就输了。微信的摇一摇和Linux差不多。
《大教堂与集市》中讲“只要有足够多的 beta 测试者,几乎所有的问题都会很快呈现,自然会有人把它解决”,这种笃定和相信,今天是否还能大面积看到?“集市”精神就是社区精神,人的价值感、人与人的连接就在大大小小的社区里,开源社区就是一个庞大的意义共同体,而每个开源项目小组也是意义共同体,能够找到意义共同体的人无疑是幸福的。
3、关于内源(Inner Source )
- 防止重复建设
时至今日,在软件界依旧会有一个观念叫做“Not Invented Here”,不是在我这里发明的我就不认,因为不是我亲手创造的,用起来我就觉得不放心或者不顺手,所以总想在自己的业务领域去发明轮子。这就是轮子满天飞的原因,不光是前端,后端轮子更多。
内源有个好处,Inner Source 真正用途是解决人性的问题,一定程度上能解决“Not Invented Here”的问题。
4、开源于商业化
很多做开源商业化的公司模式就是:开源就是商业本身。我开始也很好奇,这句话怎么理解呢?其实他们是分版本的,有一个开源版本来做影响力,另外的专业版本收费。
开源本身可以增加用户买单的信任度,因为你有开源版本,又有专业版,别人可以看到开源版本的代码,它不是黑盒,用户会更有信任感。
另外,通过开源可以抢占话语权,通过撬动一些生态的力量,然后一起去定义标准。通过开源可以博得业界声量,让业界开始认可而逐步成为事实标准,先开源就会抢占先机。
有了信任感、影响力,以及获得制定标准的话语权之后,往往就能够圈一波自然粉,会有很多用户跟随,其实这也是私域运营,到最后一步才会做付费。
这个模式能不能成功,这一波做开源商业化的能不能起来?还要再观察,因为 VC 的钱也刚进来,最终要看买单的客户有多少,是否能够支撑开源商业化的公司可以持续往前走。
四、产品
1、参与内部赛马
对我来讲,这段经历最大的收获是,发现做产品原来这么难。之前我做前端开发,是在支撑产品经理做产品,经常会觉得产品经理提的需求不太靠谱。在赛马之后,自己对产品经理的心态有了很大的变化,觉得产品经理真心不容易。
意识到技术不是万能的,技术只是工具,技术是产品的实现手段。
真正的技术深度可能在什么地方?在学术界,在各种科研实验室。而在大厂里,所谓的技术深度往往只是工程成熟度,真正的有深度的技术创新凤毛麟角。
在大厂里,技术更多是为产品和为运营服务的。很多时候,一个产品成功了,背后的技术就被说得很牛,然而很牛的产品,往往并不代表用到的技术就很牛,两者有交集,但并不多。
第二个收获,在当时可能自己已经有了初步的团队意识,开始知道很多事情单枪匹马是干不成的,需要有团队才有机会去把一些事情做得更长远或者更有可能性。
心态收获,遇到事情比较冷静,面对困难或者折腾,不会有太大的情绪起伏,就觉得都没啥,反正都经历过,会有一种看淡的感觉在内心里。
主动寻找机会。
心态很简单,就是好好做技术,同时开始在思考支付宝前端怎么往前走一步等问题。
2、企业级设计的价值(UED与前端的融合带来了无限可能)
如何做好蚂蚁的前端基础设施,蚂蚁前端出问题时,团队如何第一时间能解决。这些是一些基本要求,这些基本要求,就已经可以做很长时间。
当时本职工作是解决前端的问题,同时 2014 年开始组建 UED 团队,服务于金融云等企业级业务,前端团队和 UED 整合在一起,通过技术和设计,共同服务于用户体验,这也是大团队命名为“体验技术部”的初心。
企业级设计的价值!
一旦有了 UED 后,加上前端团队,他们之间就会开始产生化学反应。后来我们能做 Ant Design,跟设计师与前端工程师的化学反应息息相关。Ant Design 的基础是设计理念,在蚂蚁能从体验技术部诞生出来,这是融合带来的特色,不同工种有不同的思维模式,有时真的要放在一起,物理上放在一起,天天在一起碰撞,才有机会做出一些有创新的有特色的事情出来。
UED和前端团队的融合做的努力?
Ant Design立项
研究竞品,后来发现组件库的底层是设计语言
以开源的方式去做 Ant Design,对很多程序员非常有吸引力,会觉得做开源能让自己很有成长感和成就感。
确定 Ant Design 要做后,会一直强调长期主义,要有三五年的长期坚持,才有可能做出一点成绩。
当时的主要布局,是在设计语言、数据可视化、Node.js,还有前端工程化这四个领域,有认真去规划和召集人才,然后坚持长期去做。