我在传统行业做数字化转型（4）团队篇

在过去的两年时间里，我加入了一家传统行业的企业参与其数字化转型的过程，现在我将我的经历分享出来，本文是第四部分—团队篇，主要会介绍一下我所在的经济适用型团队的建设和管理心得。

上一篇：业务篇 - 介绍了营销、研发和供应链三大业务及我经历的一些转型历程和感受

1 经济适用型技术团队

在传统行业的企业中做数字化转型的技术团队中，不同的企业文化、不同的团队规模、不同的业务类型、不同的发展阶段都对研发团队的管理要求千差万别，这里我主要针对我所在的这一类型的我定义为经济适用型技术团队的建设和管理分享一点我的总结和思考。

作为一个Team Leader（以下简称TL），为何我称我司的技术团队是经济适用型团队呢？

因为，我将它定义为没有光辉的背景和杰出专家人才而属于众多互联网信息技术公司芸芸众生中之一的小团队。

没有光辉的背景，即这个团队并没有做过什么拿得出手或耳熟能详的产品，也没有攻克什么技术难题开源什么知名的中间件项目。

没有杰出的人才，即这个团队也没有来自阿里、腾讯、百度、头条、京东等知名一线互联网公司的技术人才，没有多少互联网高并发级系统的经验。

虽说没有光辉的背景和杰出的人才，但是这样的小团队却是大部分传统企业数字化转型的主力军。因为，传统企业并没有像巨头那样财大气粗，也没有像巨头那样996，传统企业更强调业务交付价值，而非技术交付价值。

因此，私以为打造一支经济适用型技术团队也是传统企业进行数字化转型历程中的重要组成部分。

画外音：在成都选择.NET技术栈，也实在没有多少人有大型互联网企业的经验，包括我自己。更多的人，应该都是具有企业级信息系统项目或者to B端的企业应用的经验，而这些经验其实对于传统企业数字化转型是有用的。

2 团队规模：两个披萨原则

对于团队的规模，我司目前采用的是两个项目组的设置，每个项目组的成员人数在10人左右，差不多符合了敏捷开发所建议的 7±2 以及两个披萨原则。

俗话说“三个臭皮匠顶个诸葛亮”。我们的一个惯性思维就是“多的一定更好”，但在软件研发领域，这种思维并不一定适用。亚马逊CEO认为，“如果两个披萨不足以喂饱一个项目团队，那么这个团队可能就显得太大了”。

实践中一再证明，人数越多，效率越低下，大多数人最终将摒弃自己不同的见解和想法，在集体统一意见中妥协。团队太大，成员之间无法深入沟通，最终会导致推诿塞责，导致项目陷入停滞状态或彻底失败。更重要的是，作为Team Leader，你的精力也是有限的，你没法去帮助所有的团队成员快速成长和收获价值。

在巨作《人月神话》中，作者也提到了在当时提出了一个类似于小型外科手术团队的组织结构来开展工作，并且要在团队内部进行行之有效的沟通。而一个大团队，显然是没法做到行之有效的沟通的。

鉴于此，我们在传统企业做数字化转型之初的团队建设时，需要克制住自己的欲望，保持多个能够进行行之有效沟通和敏捷开发协作的小团队，而非一两个大团队。而每个小团队都会各自负责一条核心业务线，那么这条核心业务线上的所有关联系统应用都会主要由这个小团队进行开发。当然，也不要在做转型之初就把所有的开发工作都分配好，这样你在建设之初就需要N个开发团队的人力招聘了，这显然是不符合持续演进扩张和经济适用的原则的。数字化转型不是短时间（一两年）就可以全部完成的，因此团队的规模也一定是随着转型的进度和企业所处的阶段而改变的。

此外，每个团队在开始不同的业务需求调研和重构的时候，需要与业务部门紧密合作，拉上业务部门对接人形成一个统一的项目组，只有业务专家的加入才是一个完整的项目组。做数字化转型，所有人都需要有一个概念：数字化转型可不单单是信息技术部门的工作，而是整个企业多个部门的协同合作的企业级工作。因此，这也需要自上而下的推动和认知。

画外音：团队每增加一个成员，团队整体工作效率确实会相应提高，但增长率会越来越低。团体的规模越大，成员间的连结变得越复杂。

3 团队发展：选育用留

选

我们都知道互联网公司和大型外企如Microsoft等公司在招人比较严格，需要经过多轮的技术面试和筛选，对学历、背景、经历、经验都有不同程度的要求。

但是，对于计划做数字化转型的传统行业的企业来说，可能初期根本不需要经验特别好的技术人才（但是需要有一个具有企业级视角的架构师或者CIO/CTO，这个角色需要足够的经验和视角，这个钱不能省！），当然一方面也给不起普通开发很高的薪资。因此，我们希望能够招到在当前条件下（工作内容、薪资预算、企业福利等）能够招到的最优人选，但是这往往是一个较为长期的过程，在遇到业务快速发展或者扩张的时候往往会拖后腿甚至成为生产力瓶颈。

综述，对于大多数做数字化转型的传统企业的信息技术团队来说，能够在招人的难易程度以及人才的质量两方面达到公司当前发展阶段的平衡点即可。

育

任何企业、任何团队在任何阶段都缺人才，包括巨头公司，只是程度不同，也就是说仅仅靠招聘很难解决人才短缺问题。

如果很难从市面上招到高度匹配的候选人，可以考虑招聘一些虽行业经验不足但有成长潜力的人选，但要使这类人充分发挥价值，企业必须建立和创造这类人才成长的环境和生态，要能为这些人的成长开辟提高的通道。

刚刚也说道，保持团队在两个披萨原则内的数量，也可以确保TL的精力能够照顾到大部分的团队成员，可以花时间去思考培养他们帮助他们成长。

用

每个岗位对能力要求的侧重点不一样：有的人当前做执行层面的开发驾轻就熟，但如果让他晋级做设计可能不适合；有的人做设计还可以，但如果转做技术管理可能也不适合；有的人做技术管理还可以，但很难取得技术层面的突破性进展。但是，每当有团队成员主动或被动地表达出有意愿尝试更多的工作或者责任时，TL就需要好好考虑了。TL需要挖掘每个确实有主观能动性的团队成员，让他们试着去承担更多的责任，给予他们足够的信任，锻炼他们在没有Leader的帽子下也能有Leadership（领导力）的能力。

“用人不疑，疑人不用”，当你选出一个你认为合适作为前端开发小组小组长或后端开发小组小组长的时候，请给予他们足够的信任，在不影响交付价值的前提下，可以给他们足够的试错的机会。

留

在任何企业，人才去留其实是一个个人需求满意度问题，本质上是心理问题。按照心流理论人处于心流状态时最幸福，这时人的能动性和创造力都能达到最佳状态，在这种状态下人才的留存率也会达到最高。

因此，尽量减少让团队处于厌烦或焦虑的状态，否则团队就会离分崩离析不远了。而如何减少让团队处于厌烦或者焦虑的状态，这就需要TL花时间思考了。我的做法是：活跃型团队 + 学习型团队。

所谓活跃型团队，就是不定期地在微信群里面聊天和互动（非工作IM），搞搞TB聚餐，在开发工作中能够经常交流和协作，加强反馈能面谈的都面谈，定期开迭代回顾会议放松气氛在划水中复盘不足，整个团队看起来十分充实而又不算很累。

所谓学习型团队，就是在工作之外能够引导大家学习技术和非技术方面的内容，定期分享讨论共同提高。目前我已经组织团队核心成员学习讨论了《商业洞察力30讲》、《五分钟商学院商业篇》（部分）等，组织团队开发成员学习讨论了《企业IT架构转型之道》（中台部分）、DDD实战课（极客时间课程）等等，团队成员都表示学有所获，刷新了自己的认知。如果有条件，还可以创建一个企业的技术团队的公众号，鼓励大家将学习到的心得感受总结成文发布到公众号上面，一来可以帮助大家总结学习成果，二来也可以满足大家的成就感和参与感，最后也可以帮助其他同事了解新的知识和技能，一举三得。