创业公司的技术团队，本质上就是人和事，用合适的人搞定特定的事，人才的瓶颈就是这家公司产品落地速度和上线质量的瓶颈，因此人是第一位的，对于前端团队来说，如何一步步形成有综合战斗力的团队，取决于搭建什么层次的前端梯队，如果所有人一视同仁，培养同样的能力栈，发挥同样的兴趣向，跟进同样的业务线，那么这个梯队的扁平就会带来致命的团队瓶颈：能力可复制但不能互补，能力可递进但很难跨越，不能互补和很难跨越会导致团队内的技术路线过于单一，技术思维趋于固化，至于技术储备的丰富性和技术沟通带来的碰撞就更有限，最终导致人做事越来越机械化，甚至失去最初的技术初心。
公司的人员、业务和技术现状出发，由于端的碎片化和技术框架的不稳定性，就必须在质量保障上投入巨大的人力保证产品可用，而人才能力局限性和数量的匮乏，就跟产品的质量保证成为了天然的矛盾，不可协调，代码撺太快，线上天天都是 Bug，代码撺太慢，产品节奏跟不上，至于跟工程师天天宣讲要小心小心再小心，能起到的作用也不大，因为工程师本身的能力也是参差不齐的，所以就必须把团队先拆成两部分，一部分做基建支持，一部分做业务支持，基建支持的同学研发整个团队的工具脚手架、抽象和打磨团队的基础通用组件、长期维护项目的通用架构，这些投入都会反哺到业务支持的同学，业务的同学可以放心大胆的基于基建的成果做上层业务开发，稳定的工程基础有了保障，上层的业务代码做质量保障难度就大大降低了。
除了分出来人做基建，做业务，还需要有核心的技术骨干，做技术前瞻性的研究，为团队 3 个月后，半年后，甚至 1 年后的技术方向，做必要的调研、测试和实验性开发，因为对于刀耕火种的早期技术团队，从原始人到迈向外太空跨空间作战，这中间还差着很多个关键的技术迭代节点，这些关键的技术迭代节点，一部分是靠外招技术专家和资深的工程师来输血发力，还有一大部分是需要靠团队内部长期的积累沉淀，也就是人才内部培养。
总结:
- 基建的同学负责输出工具系统、基础组件、流程规范，保证内部效率最大化和质量的有效保障
- 架构的同学负责攻克技术底层难点，调研先进技术，升级团队技术架构，沉淀技术方案，锁定和推进团队未来技术方向
- 业务的同学负责产品跟进，高频使用基建产品，并通过反馈来优化团队的技术基础设施，同时基于业务来抽象更多的基建需求
基建、架构、业务这三个角色并不是相互独立，而是互有重合各有侧重，一个业务的同学，可能也同时在负责基建的事情，一个基建的同学，可能也同时在参与架构的设计，业务也时不时的参与开发，架构和基建必须依托于业务场景来做，不能脱离了场景，不然会输出畸形的难以落地的技术方案。
上面是人员的分工，还有三个重要的保障,列举一下:
- 团队人员的兴趣栈、能力栈和业务要尽量匹配
- 团队人员的阶段性目标、长期规划要跟进公司的职业晋升路线和能力模型
- 团队要有持续性的内部技术互动分享和对外的技术理念、方法方案分享
最后一点，就是资源流转，架构的同学，基建的同学和业务的同学的梯次关系是从下到上，越下越接近技术本质，越上越接近业务结果，越向下需要越好的技术实力，越向上需要越好的业务理解能力，这两个能力都是核心能力，需要让团队成员沿着梯队关系慢慢流动起来，业务中技术能力好的同学可以有机会沉下来做做基建，长期埋头基建的同学可以有机会上去做做业务，业务理解不错技术沉淀又好的同学可以继续沉下去参与架构，这样团队内部的同学都可以有多样性的技术场景和业务场景，一旦有同学请假、陷在别的业务不能抽调，马上就有同学可以补位进来开发，不会影响到产品上线节点。
方法论：
- 人才梯队要有层次：基础架构、基建和业务上层等
- 人才成长要有规划：兴趣栈、能力栈和公司关系
- 人才能力要有扩展：单人能力和互补后的团队能力
以人为过程，以事为结果，人事之间要有动态的机制形成互惠互补的关系，只有这样，团队才会初心不变，激情常在。
网友评论