阅读 2493

前端职业规划 - 现在很多前端团队都改名叫体验技术团队了, 那什么是体验技术?

前言

一种职能或者工种的诞生都伴随着这类职能在整个价值创造的链条中定位的变化, 从软件工程师到按语言划分再到按职能划分, 每一个职能背后都有有一个核心内容驱动这项职能的发展, 职能发展的好就会有更长的生命周期和更宽广的衍生选择.

在软件行业发展的这几十年里, 驱动软件技术发展的核心要素是数据, 早期的软件发展来源于用户对数据计算的需求, 从第一台计算机诞生完成最基本的数据计算工作到数据的含义趋于广义, 涵盖了现实世界中的大部分内容, 过去 "数据 = 数字", 如今 "数据 = 世界"

世界上的大多数事物都可以用数据来表示, 包括我们人类. 而这种广义的数据定义大大驱动了软件技术的发展, 在这段时间, 对广义数据的管理需求催生了现代软件技术中广为人知的那些东西, 比如云计算, 大数据, 机器学习, 神经网络, 直到 10年前基本上大部分的软件工程师学习和发明的技术都是数据驱动的.

为什么说是 10年前, 因为广为人知的前端工程师这个特殊职能的诞生大约是在 10年前. 前端工程师是一个大大有别于传统软件工程师定义的职能, 在最初任何对 JavaScript 和互联网应用开发技术感兴趣, 对浏览器感到好奇的人都可以试着从事前端开发工作.

所以我感到困惑, 是什么催生了这样一个职能从软件工程师中分离出来, 甚至在最初的低门槛都很难让人将前端开发工作和软件工程师联系起来.

正文

软件工程师的主观与客观, 理性与感性

作为一名软件工程师, 大多数的时候我们是客观并且理性的, 我们像计算机一样评估客户的需求, 通过严谨的逻辑思维和优秀的编码能力完成软件的设计和开发工作, 确保客户对数据管理和操作的需求得以实现, 这种特征即使到了现在你也可以在很多服务端工程师身上感受到.

大多数 Java程序员看起来都有这样的特征, 他们相对低调也不对感性的艺术的东西感兴趣, 但是如果你打开 GitHub, 会发现喜欢开源的使用 JavaScript 开发的前端工程师, 大多有着非常感性的一面, 比如各种极限运动, 音乐爱好者或者职业的乐队, 旅游博主等等

包括我本人在从事编程工作前是一名配音爱好者, 并且还小有名气. 😁

从事前端开发工作的人会有更强的主观意识, 往往会因为一些个人的喜好就动手实现, 有时候写代码可能仅仅是因为自己的兴趣. 喜欢造各种各样的轮子来改善自己的编程体验.

这让我有种感觉, 在软件工程师领域可能粗分的话只有两类人

  • 活蹦乱跳的前端工程师
  • other

从这个角度去看, 前端工程师更像是将软件工程师中的主观与感性分离出来产生的职能, 而剩下的被数据驱动的职能因为互联网时代到来, 数据量井喷式的增长变得更加客观和理性, 例如算法, 服务端, 运维工程师等.

计算机是冰冷的, 没有感情的, 理性和客观的特质更符合计算机的特征, 或者说更符合我们对技术这个词的传统定义, 因此 CTO 作为公司内的技术群体的领导者就必须更加客观和理性.

但是时代变了, CS 时代客户通常为软件功能付费, 同时购买其他传统的通过人来传递的服务, 比如售后, 实施, 驻场, VIP 等等. 功能就像计算机的开机键一样, 冰冷却没有感情, 开就是开, 关就是关, 不会有惊喜, 也不会有意外, 一切都在合同里拟定好了.

这一时期的软件工程师的关注点 99% 都是在软件客观理性的一面, 和服务不同, 客户的对于功能的心理感受或者说体验是没有差异的. 同样的, 按照功能付费也致使企业不会花心思在一个已经卖出去的功能上想太多.

直到互联网的诞生, 互联网企业打破了软件只有功能性这一特征, 早期的内容型门户网站开始为用户提供 服务

SaaS 并不是企业级软件的专属定义

早在 SaaS 被定义之前, 或许免费为网民提供互联网服务的软件就已经实现了这一定义, 只是免费罢了.

提供服务和提供功能的最大差异在于, 提供服务会让企业的关注点从原有标准的功能向着不标准个性化的用户体验迁移, 这种关注点的迁移也致使软件工程师群体内那些更感性, 更有主观体感更有同理心的人逐渐演变成了一种新职能 - 前端工程师

用户喜欢什么颜色? 用户喜欢什么样的界面布局, 如何操作更方便, 怎么改善用户的操作体验, 提升转化率? 一系列关于用户体验的问题被不断的抛出来, 而原有的软件研发智能体系完全无法招架, 产品经理, 软件研发工程师开始怀疑人生了, 因为无法有效的将问题的答案标准化, 原有的职能开始演变, 分裂, 然后变成了现在这样子

在这里我主要指国内的研发职能变化, 和国外还是有比较大的差异的.

导致这一切的核心因素在于当软件研发体系开始从原有的客观的理性的模式切换到了更加主观的感性的模式, 但数据驱动的本质并没有变, 而且数据的问题变得更严重了, 因此整个研发体系分裂成了两个部分

  • 感性的, 更强调主观分析, 同理感受的 产品设计, UI 设计, 前端工程师
  • 理性的, 更强调客观评估, 受数据驱动的 服务端, 运维, 算法工程师

阿里时期的 淘宝 ued, 其实就是将这里提到的前面的部分整合的部门. 当然产品除外, 虽然我觉得产品从职能上看应该属于研发体系, 但目前大多数公司依然将其作为独立部门.

若干年后, 支付宝第一次提出了体验技术这个概念. 在我看来有一定的历史必然性. 从功能到服务, 因为服务必须关注用户体验, 而前端工程师毕竟是软件工程师衍生出来的, 再怎么强调产品感, 设计感, 大家毕竟是一个战壕的, 还是码农, 技术依然是我们的主心骨, 但如果仅仅只依托于技术, 显然不能定义前端工程师, 因为我们的大部分工作的重心其实是用户体验, 而这里的用户发展到现在内容已经非常丰富了, 它包括

  • 通常所说的用户, 互联网网民, 白领, 男人女人
  • 客户, 企业软件的订阅和服务的对象
  • 开发者, 使用开源技术的前端开发者, 使用前端开发出来的各种系统的其他软件工程师, 服务端, 算法, 运维
  • 非开发者, 使用前端开发出来的系统的产品经理, 设计师, 运营, 市场等等所有非开发者.

这一时期至今, 对于体验技术的定义可能就是, 围绕广义的用户体验展开工作的技术工作者

体验的双面含义和内在双螺旋

在中文字典里, 体验是指人对于某些事物的心理感受, 当我们说要提升一个人的体验, 或者体验很好, 这种感受其实是非常主观并且感性的, 因为心理感受是有基线的, 例如 当你独自加班到深夜, 突然你在使用的某个软件给你一碗鸡汤

"献给深夜中孤独的你, 每天都要加油鸭!!"

你会产生很好的体验, 并且近乎一个体验峰值, 甚至为此写一篇文章或者日记来记录这一个时刻, 或者发个朋友圈之类的.

但是显然这种体验是不可捉摸的. 即使我们能够抓取到有多少人在这个时间加班的数据, 你也无法感受到此时此刻加班者的内心活动, 你不知道他当时的心理基线, 因此你无法确保这样的对于用户来说会有怎样的心理感受, 显然在目前来看, 这是技术无法准确评估的.

不过 马斯克 的脑机接口技术可能在未来打破这一论断, 当然我们能准确的捕获使用者的大脑活动, 就能评估你的心理感受, 从而提供相应的服务. 不过关于这一点我觉得更倾向于这是一种数据技术而不是体验技术, 因为将人数据化之后给出相匹配的动作, 这显然和体验无关了. 如果到了那一天, 感性和主观也被数据化, 整个软件研发体系可能再度发生变化.

因此关注体验的技术不应该是用技术去测量体验. 如果有那样的技术, 我们就不需要关注体验了, 因为可以通过算法和数据模型来解决问题. 关注点就又回到了数据上.

如果说体验的感性的一面是心理感受, 那体验这个词理性的一面应该是 experience.

体验技术的英文是 experience technology, 而 experience 在 wiki 上的解释更多的是 经验

相对于心理感受, 一个人的经验往往是既成事实的, 比如我们开车回家, 开个十几次就不需要导航了, 又比如我们在丛林中探险, 已经知道哪些植物有毒了, 又或者我们做过某个项目, 在类似项目中不用再踩相同的坑.

经验是相对标准的, 一个人的经验是从相同, 反复之中获取的. 而这种反复的相同的经验却又和你的体验息息相关

我之前在顶楼花园里种花, 因为要每天都浇水, 花又多, 每次都需要做一系列重复动作, 费时费力, 虽然我通过重复浇花这件事情积攒了浇花的经验, 几乎不会有多余的动作, 但这件事对我来说已经没法在提升效率了, 这种无法提升的沮丧让我体验很差, 并且维持在一个较低的心理感受上, 一想到浇花心理就烦得紧, 后来我就网上搜自动浇花, 发现还真有这样的系统, 于是我把零部件买回来组装好, 当系统开始运作的时候, 我感受到了自己的经验转化成技术的那种喜悦, 那种体验感, 此时我的体验达到了一个峰值, 在随后慢慢回落.

后来有一段时间下雨, 原来自己浇嘛, 肯定下雨天不浇了, 现在是自动的没这功能, 我又换了个雨天感应, 之后又因为想远程控制换了个代 wifi 的. 这些技术更新让我的体验始终在上升, 后来我碰到自己浇花的人都会给他们推荐自动浇花这个系统.

我举这个例子其实想说明的是, 我们前端技术的发展其实也是这样一条路径, 受到体验和经验的双重驱动, 因为用户打开网页慢, 我们通过技术提升性能改善加载速度来提升体验, 这是体验路径, 因为运营每次搞活动都要跑一整套活动页面开发的流程, 我们将运营在流程中相同的重复的经验通过技术转化成系统, 用技术产品来改善运营的体验. 这是经验路径.

通过技术直接提升用户的心理感受或者通过技术将用户的经验转化成产品提升用户的心理感受, 这两条路径交织在一起形成了用户体验提升的双螺旋

Experience Technology 正向增长螺旋→ 从可复制的 Experience 中寻求最佳 practice, 通过 Technology 将其 productization 从提而提升用户体验形成新的 Experience

后话

我不知道改名叫体验技术团队的前端团队们是否思考过这个问题, 在我看来, 体验技术团队或者体验技术工程师(不叫前端了)是受到体验(经验)驱动, 我们使用发明创造改良的技术的动因都来自于用户体验和用户经验转化. 这种完全不同的技术发展路径应该和数据驱动的技术发展路径有着本质的不同, 但是又有多少前端团队真的去思考过这种不同呢?