前言
不同规模的公司都有自己独立的前端研发部门, 无论是大前端亦或是小型业务团队, 小到几人大到上百人.过去关于前端研发团队的组织架构都是因势利导自然而然的发展. 名目繁多, 团队形式各异, 但基本脱离不开两个部分的组成
- 业务研发
- 技术研发
随着现代软件复杂度的不断提升, 前端技术的丰富和用户对体验, 企业对数据的要求越来越高, 这种二元结构越来越无法满足前端研发团队发展的需求, 甚至一定程度上, 业务研发和技术研发中形成了天然的矛盾和对立.
因此在这里我抛砖引玉, 讨论下当下我们该试着如何解开这个问题和矛盾
正文
核心矛盾还是利益
我们知道, 大多数前端团队的组织架构会分为业务研发和技术研发, 可能各个公司在这两部分会有一些细分, 但我认为大同小异.
- 业务研发, 主要就是满足业务需求, 实现产品功能
- 技术研发, 通常被称为是搞技术基建的, 帮助业务研发提升效能
这种划分原则在早期其实问题不大, 是前端研发团队在发展过程中自然形成的. 因为和基本软件复用原则一致, 当我们在业务研发中发现可以抽象并共享的代码时, 我们自然而然会将其抽出来, 然后将这种模式或者工具独立管理和维护, 为了保障维护的资源, 于是就有了技术研发团队, 这个技术研发团队随着时间推移.
越来越多的基础技术设施被抽象和定义, 开源技术的发展, 最终变成了当下的基础架构. 但矛盾也随之而来.
首先让我们重新认识下基建, 或者说技术基建
技术基建的超前部署
只要一家企业的技术团队要搞基建, 就一定需要做规划, 我相信有过类似经验的同学应该知道, 所有的基建规划都是超前的. 即不是满足当下需求, 而是一定程度上开发超过当下需求的基建.
比如组件库, 可能当下业务只是需要一个库, 但基建可能会就组件库的定义, 开发, 设计过程进行更完整的规划.
又比如脚手架, 对于业务来说无非就是 yarn dev → yang build, 但对于基础架构, 需要为以后的 CI/CD 线上研发做提前部署, 确保平滑对接.
这其实和我国的基建模式类似, 不是先有需求才有基建, 而是基建会带来需求. 因此基建着眼于长期利益, 并且尽可能考虑未来的需求, 而不是当下.
但业务不是. 业务研发需要根据市场的变动随时调整, 要具有灵活性和高可变性, 或者你可以将业务和资本挂钩, 资本是什么, 资本是短期利益的追逐者, 大部分资本是非理性的, 具有投机性, 虽然我们都希望我们的产品, 我们的业务能有长期规划, 有长期的价值考虑, 但实际情况是, 大部分企业都追逐短期利益. 这造成了业务研发天然的短视情况.
一个追逐长期, 一个追逐短期, 就造成了典型的二元思维. 对于基础架构而言, 长期利益要求牺牲一定的短期利益, 而对于业务研发而言, 短期利益牺牲了就没有利益了.
不幸的是, 对于大多数基础架构实施团队来说, 普遍缺乏必要的产品化能力, 往往都懂技术但不懂怎么将技术产品化, 长期利益的兑现周期无法控制, 当长期利益的兑现周期变得很长, 业务研发的短期利益就会牺牲超过业务方能承受的阈值. 最终造成矛盾的爆发.
基建要强推, 业务不买账, 然后业务自己造轮子, 导致整个技术体系愈发的分裂, 最终双输.
技术基建的落地策略
虽然在前端开源生态中, 有大量被验证过的基础技术, 但实际真的运用到自己的团队依然是一个复杂的过程. 大多数情况下, 都需要进行改良, 甚至重新实现.
另外前端技术的更替周期过快, 导致部分基础技术在未来会成为新的历史债务, 为此在落地过程中还要做好整体升级迁移的设计.
这就要求整个基建的落地策略需要遵循因地制宜, 循序渐进, 小范围试点, 大范围推广的原则.
但据我所知目前的前端研发团队搞基建基本靠强拆
强拆是违法的
中国自改革开发以来, 地方政府依赖土地财政大搞基建, 结果造成了大量的鬼城, 鬼路, 这些隐形债务都变成了当下的政策顽疾. 当年你拆的有多爽, 今年治理起来就有多头疼
技术基建也一样, 不是搞下去就一定会有长期收益, 不是搞组件库就一定是对的, 也不是搞工程体系就一定有效果. 凡事没有绝对. 不注重落地策略最终都会自食恶果.
抛弃二元思维, 打造三元结构
二元思维是非此即彼, 你输我赢, 首先我们要认识到基础架构和业务研发的对立是天然不可调和的, 不能指望通过常规手段加以解决, 也不能指望靠牺牲业务研发的利益来达成基建的推动. 这对于前端研发团队的 leader 来说要承担的风险就太大了.
为此我设想加入一个新的结构
- 业务架构
首先不同于业务研发, 业务架构不隶属于业务团队, 依然属于独立的组织, 有独立的资源保障和独立的决策权. 同时和基础架构不同, 业务架构除了对技术侧的关注, 同时要关注业务侧.
业务架构的定位与职责
对于业务架构而言, 其主要职责有两项
-
以统一技术标准为核心原则, 分析, 抽象, 定位业务问题, 从现有的技术工具/产品中寻求组合, 提供系统性的非单点的解决方案.
-
和基础架构共建业务架构治理工具箱. 把基础架构的技术工具/产品进行组合完善输出给业务研发.
业务架构师的核心能力
- 抽象, 能将细碎的业务问题抽象成技术问题
- 系统, 不是单点的, 而是系统的解决业务问题
- 技术, 具备独立研发和完善技术产品/工具的能力
业务架构师的核心工作要求
合作共赢
避免二元思维, 既要让业务在发展中得到基建支持的好处, 能够逐步升级, 平稳过度. 又要让基础架构的产出能够在正确的方向上推进. 这就很考验一个业务架构师的综合素质. 可以说业务架构师是未来前端研发团队真正的驱动核心和纽带. 对于庞大的前端研发团队来说, 合格的业务架构师能确保整个技术体系平稳发展和迭代. 将资源的投入产出做到最优化.
业务架构师的核心原则
统一技术标准
在不违反这一核心原则下, 业务架构师可以灵活调整, 贴合业务来指定业务架构的治理方案, 通过技术手段来实现长短期利益的平滑过度. 为业务提供过渡性方案, 在基础架构没有完工之前, 保障业务在统一的技术标准下进行研发.
后话
当然这个世界上能量是守恒的, 在一定程度上, 业务赢了, 技术赢了, 业务架构也赢了, 所以谁输了? 业务研发输了. 春秋战国百家争鸣, 为无数思想家创造了各种实现自身价值的舞台, 但是自秦废除败家, 独尊儒术, 就关闭了这一机会通道, 事实上随着技术标准化的推进,业务研发的施展空间会越来越小, 过去是因为捆绑了业务的利益导致业务研发可以和基础架构之间进行抗衡, 一定程度上保留了一些造轮子的空间, 但一旦从二元过度到三元结构, 业务架构师的加入, 会让大多数水平一般的业务研发失去发展空间. 可以说 10 个业务研发可以出一个业务架构师, 那剩下的 9 个呢? 自然是当了干电池...
