以行业属性对抗流动性——对于前端团队发展的思考

Posted 2021-04-30 早行远客

       上一篇文章提到，我们的团队在前端（主要是微信应用、App等方面）做了不少的尝试，有了一些成果但也遇到了不少困惑，尤其是在团队组建方面。简言之，我们发现团队会有一个明显的发展周期，团队规模的会呈现“增长—萎缩”的循环，对产品的发展和团队能力的建设都会产生很不利的影响，最直接的问题是团队规模总是上不去，产品线也无法快速发展壮大。多说一句，我估计很多产品的在发展过程中都会遇到这样的瓶颈，例如前几年我们在“银保通”产品发展的时候也遇到了类似周期性的问题，但解决之道并不一样（银保通产品主要是靠产品的成熟度和“点线面体”的扩展来解决这一问题，未来有机会的话我们可以另文讨论）。本文是我们经过这一段时间的实践和思考，对团队组建思路的总结。

     

       想解决问题，我们需要先分析问题，首先从前端产品的特性开始：按照我们“接地气”的实践法，我们总结了三个特点：

       第二，逐渐趋同性，前端产品中所实现的模式也好，创意也好，如果说在市场的作用下证明有效，那么很快会被学习推广开来，即便是有变形或改进，也能看出比较清晰的脉络。所以可以引出下面第三点：

      所以，我们可以看到，客户在做选择的时候，更看重的是团队的能力和经验，直白的说第一重要的是选择人或团队，而不是你手里有什么现成的东西（客户会想：有也不是我的创意啊）。既然如此，我们首先要做的是对团队能力的分解和分析。按照我们现在的情况，一个前端开发团队大约需要的能力有如下这些维度：

                           

 

       从我们的实践来看，行业属性和人员流动性是呈反比例关系的。部分能力和行业属性关联性很低，属于到处适用的“通用能力”，具备这样能力的人员归属感必然相对较差，也就往往导致了前文所提高成本、周期性高流动的困惑。

       但是本质上说，我们做的依然是行业属性很强的应用系统/软件，实现保险业务的场景和需求依然是软件的基本要求。所以，我们的团队组建和管理的基本原理，是以行业属性对抗流动性，以行业属性高的角色为核心向行业属性低的角色辐射。所以每个能力点的要做好的事也是不同的：

• 对于美工和交互设计，鼓励学习业务知识，保持团队的层次和新老结合。

• 对于架构设计，要做好文档建设和培训，还有就是建立足够的样板程序。

• 对于业务属性强的部分，可为团队之核心，主要成员特别强调学习能力：应在我们传统团队的业务骨干中选拔一批学习能力强的干部进行培养，要求其对前端能力链条中的各环节都有了解，甚至熟悉，技术实力越强越好。鼓励（甚至某种意义上的“强迫”）他们学习新技术和新架构。能达到“进得了书房（界面设计）、出得了厅堂（业务模式设计和分析），上得了房梁（技术和架构）”的完美水平最好，当然现实一些的是“出得了厅堂（业务模式设计和分析），上得了房梁（技术和架构）”二合一的高水平。简而言之，就是越来越接近（或成为）理想中的产品经理。

 

      其次，团队的组织模式也有讲究。前端团队的组建，应该进行按能力角色的组合成小团队（3-5人）。不要轻易形成大团队（超过10个人）或大集团（尤其是职能单一的大团队更是大忌）。即便是大项目，也建议以小组（团队）组成敏捷团队的模式进行实施（前端产品线不论是业务需求、技术或者产品形态，都是实施敏捷开发很好的方向，但这涉及的面太大，我们就不在这展开讨论了）。

      各小团队间的能力是基本重复的，可替代的，我们鼓励内部良性竞争。

 

 

       每个小团队（组）应至少有核心成员1人，小组具备完整的实施能力。其中美工等能力角色可以借用大组织资源，但其在小团队中的角色是存在的，人员也是相对固定的（对一个小团队而言）但可以是几个小团队复用的（对担任角色的员工而言）。这样做的目的是便于形成长期默契的配合，而且便于考核和能力的培养。

      特别的，架构设计角色，我们现在基本都由各组核心成员兼任，并且形成产品线方向的架构组，以便提高团队整体的技术竞争力和降低学习成本。

 

      发展中遇到的问题，只能由更坚决、更高效的发展来解决。本文内容是基于我们现在的问题和认知水平，也许并不十分成熟，或则业界已有更好的方法，希望本文能够抛砖引玉，带来更多的建议和不同的解决方法。