2023 年的今天，软件研发团队一个比一个大。
研发一款软件到底需要多少人？
60 年代末，年仅 26 岁的 Ken Thompson 一个人，一个月，完成了无懈可击的 Unix 操作系统雏形；
80年代求伯君一个人能写出整个wps；
90年代张小龙一个人完整写出foxmail；
即便到2006年，我一个人，在全新的WinCE平台上从 0开发出一套完整的QQ，独自码了全部软件的近 70% 的代码，当时的团队全员也才2.5个人；
一直到2011年，诞生微信 1.0的研发团队全员，只需要一个小黑屋就能全部装下；... ...
然而
再往后，互联网公司却变得越来越大，随随便便开发一款软件，刚刚起步，用户都还是 0，就上百人的产研退伍砸进来了。才刚发布 1.0 版本，就会开始着急的继续扩大，仿佛人手已经严重不足了，不快点招聘，团队就要累死了。几乎个个如此。以至于头部互联网企业陆续都超过 10W 级的员工人数，研发效率，似乎再难上巅峰。我自己身处其中，很难不去思考这个问题，Why?
是因为牛人都生活在过去吗？这个答案显示不合理
我入职腾讯那年，全公司 2k 多人。部门经理讲话说：“我们是一个 70 人的大部门，太多人了，我都记不住你们的名字”。然而实际上，当时 2k 多人的腾讯已经维护着好几十款不同的产品了，去掉客服行政等非产研角色，真正的研发团队并不多。其中很多产品的产研队伍都是几个人，或者十几个人的规模，几十人做一款产品就已经是最大规模的研发团队了。我当时所在的那个 70 人的部门要研发并发布的产品就有好几个。而我负责研发的平台，客户端部分总共2.5 个人，由于当时的跨平台技术的不足，没有其他平台的代码可以复用，整个平台的 QQ 是从 0 开始一行行的敲，我一个人一年敲了 10W行代码，完成了该平台下整个 QQ 1.0 基础版本 2/3的功能编码。却由于该平台用户量级不大，被产品总监吐槽说我们这 2.5 个人的人力投入太大。那时候的腾讯没有今天这样的高度，当时还并没有能力吸引大把的清北毕业生来应聘。要说人才的平均水准，或许是不如今天的。但为何当时的研发团队，能普遍能做到精兵的能力？
这其中的原因绝不会是某一个单点造成的，如果是个单点问题，那一定早就会有人能解决掉了。实际上，在有着数百产款品并行研发的腾讯，截止目前我也只能看到微信、企业微信这样极少团队能相对较好的克服这个问题，却也只能算是相对不错。
本文，我把我能看到的部分背后成因，分享出来。至于克服的方法，我会在后续文章再展开。
一、 软件之间的内卷
2011年之前，一款通常的移动端App，如果希望尽量覆盖主流平台，那么你需要开发symbian、kJava、MTK、Windows Mobile、iOS、Android 这至少6个不同平台的版本。每个平台需要3到5人，再加上后台以及官网前端等等研发，这就是一只几十人的队伍了。由于每个平台的特性差异巨大，对测试和产品人员也都有不同的要求，很多时候并不能完全复用,每个平台都还会有对应的人口配比。算上这些关联的人口，我们统称产研团队，按上述的计算，整个产研团队很容易就会达到或接近50人的规模。
演化到今天，移动端的App，我们需要开发的平台只剩下iOS和Andriod了，其他的移动端平台都已埋入历史的尘埃。但是，奇怪的是。今天，各家大厂的成熟型App，需要的人数相比2011年没有更少，反而更多。如果依然还是只有不到50人的产研团队规模，那绝对是非常精英的团队了，会非常难得。这样的团队往往在国外还能见到。例如whats app，例如 slack 等等。国内已经基本匿迹了。当然，这不包括那些作坊式的用户量极小的不知名软件。
随着互联网领域前些年白热化的技术竞争，大量的新增技术工作类型，就像军备竞赛一样被层层叠高。也就是我们平时所说的内卷。这些都会继续推高基础研发团队的投入需求。
就拿 crash 率分析工具来说，2010 年之前，能自己分析并独立的做好这套工具，就足够支撑一个研发人员在腾讯内部晋升 T3.1 或 T3.2（约等于今天的 T9 或 T10 级）。但是今天，如果你讲这个，晋级的面委同事可能会很鄙视的看着你：“这不是很基础的，每一个研发人员都要掌握的东西么？讲这个做什么？”
现实就是如此残酷，软件研发的工具、技巧方法、新平台、新语言、新框架、新模式、新流程... ... 层出不穷。尤其是最近这 10 年多，好像寒武纪的生命大爆发，突然就变得千姿百态了。其实这些东西当中的很多如过眼云烟，快速出现又快速消失，这部分倒不是什么问题，比如 symbian 系统、比如 svn... ... 消失了就消失了，就不需要后来者再了解或掌握了。可怕的是，出现后，就一直存在的，那些生命力顽强的东西，它们就像生命演化过程中被稳定保留的新性征，可能无法消除了。
下面这段描述了这些专业化膨胀的一些技术概要，非专业读者建议跳过该段落：
1、 包括可动态运营的统计分析模块：
越来越强大的统计分析系统，包括各类自动化的报表系统，甚至统计打点都能一定程度上做到云端控制
2、 包括增强网络或者io等基础能力稳定性的专业打磨过的底层模块的维护：
多套备用的域名/ip 混合动态部署、长短连接并存、类似 quic，双链路等各类健壮性策略深度耦合等等，大家都在 4 个 9 之后的维度上竞争。你差那么一丝策略，可能就会比竞品的健壮低上 0.01）
3、 包括crash分析、卡顿分析、操作流分析、远程调试 … … 等等一大串的高级质量运维维护套装的开发：
这些都是效率工具，都是为了节省人力与时间而诞生，但同时也是需要人力去开发和维护的效率工具。只是，有些团队忘了初心，把这些工具作为自己炫技的舞台而不是为产品去服务
4、 包括广告、基础音视频处理、运用于特效动画的3D引擎等各类增香调色却巨大无比的周边润色模块的开发维护：
不搞技术的人，看到这里也能明白怎么回事，类似于无所不见的开屏广告，越来越多的出现在各类 app，它们的每一次出现，都在述说着背后那些冗余的产品经理与研发们，为了在公司里继续待下去而不得不绞尽脑汁的创造点击来源的强烈诉求
5、 包括防黑产、防破解、保护隐私与数据的各类加固、反注入、层层加码的加密技术等等：
这是一个无奈的系列，只要产品做到足够大了，你将不得不面对它们
6、 包括研发团队扩张后，内部数据安全的保障工具，流程管理工具，信息协同工具，权限管理工具的外部引入或者自研等技术管理工作；
7、 包括为了维护上述这么多工具套装要进行的管理协调工作，再开发的管理工具的工具：
这是个死循环，因为上述的种种原因，导致团队变大后而产生的管理问题，也是需要软件过程与软件工具的
8、 包括上述这些 工具 与 管理工具的工具 之后，带来的管理和质量成本问题，而再引入的高级研发过程质量控制技术… …上述这些只是互联网软件研发军备竞赛的后果之一，冰山一角，技术工作之多，垒如高山，远非中国的软件行业之初的那份单纯了，一切都进入到高精尖的复杂工程领域。
一位在诺基亚工作过多年的前同事和我吐槽说“我在腾讯一个星期干的活，比在诺基亚半年干的都多”。或许他说的有些夸张了，但趋势确实是这么个趋势。
国内的大型App背后的团队，近些年来在不断膨胀。某些知名App的背后维护和研发团队规模甚至可达几千人，甚至近万人之巨，这几千人就仅仅服务于一款软件。甚至还没有包括大公司内部对这些软件做支撑的云平台等公线服务的人力投入。
为了对抗无限的成本膨胀，研发效率的升级 也是企业微信从立项之初就持续不断在摸索的关键工作，牵涉的方方面面甚多，包括管理、人才、技术工具、研发模式… … 每一项都是考验。等有时间，我在后续文章继续展开应对的细节
二、低效的分工模式
首先思考一个问题：软件研发是一个创造性工作，还是一个流水线工作？
我对这个问题的看法是，要视我们想如何对待软件研发而定。
传统的软件研发领域的 CMMI (Capability Maturity Model Integration，即能力成熟度模型集成) ，一共 5 级，层层递进，就是把软件研发过程当做了一个流水线工作，真正的把软件的研发，工业化的变成为了“软件工程”。我自己就是学这个专业毕业的，但我本身对这种理论方向并不喜欢。
我更倾向于，认为软件研发是一个创造性工作。当一个软件研发团队的分工细致到，一线研发几乎完全不知道整体是如何工作与实现的，而只清楚自己手上的螺丝钉是如何打的，那这样的研发团队注定无法生产出优秀的软件产品。尤其是对于腾讯这样的，以创造性的软件产品为生存之道的企业。不是外包企业，也不是纯实施团队，而是期望创造出出色的产品去解决人们的所需，创造普通人想象之外的境界。就非常不适宜是推行类似于 CMMI 这类的机械化工业化的工作模式。
如果我们错误的基于工业化的思路去工作，那我们在进行软件模块分工的时候。会和流水生产线一样，按“技能”的品类进行切分。例如负责处理数据存储的同事，专项负责存储层，负责处理协议的同事就专项负责协议网络层，以此类推，有负责 UI 的，有负责视频的，还有负责加解密等基础工具类的。这些是不是像极了当年福特汽车创造的全世界第一条工业化生产线，装轮胎的工人永远在装轮胎，装玻璃的工人永远在装玻璃... ...这样的弊端非常明显，技能固化，没有全局观，同时，产业工人们对产品也没有感情可言。何谈创造与突破？这不能怪工人，是设计分工模式的人导致的。
回到软件领域，我们继续分析这个问题：
按技能差异进行的模块切分，带来的是技能单一化。举一个真实的例子，我曾经和某团队进行过一次合作，暂且就叫做 X 团队。合作的是一个非常紧迫，时间要求很高的任务。在合作的过程中，我会不断的调集合适的人力来加快进度。
例如 填补时间评估的误差、例如有人突然休假、例如突然的需求变更带来的额外工作量 等等风险。我会把其他优先级低于该任务的资源灵活调度进来，确保把这些坑都填上，而实现进度不延迟。 但是，我发现对方团队却始终人力紧缺，难以对齐进度。所以我就和对方去深入地探讨这个问题，看有没有去加快的一个方法。比如从对方团队的其他组去协调更多的人力资源来进行支持，因为在进行人力盘点的过程中，我通过代码提交量和频率会发 X团队内其实有很多人是处于一个比较空闲的状态，那么，有空闲的人力为什么不能调过来支持？然而实际上，发现是不行的，这些比较空闲的员工长期都负责另外一个模块，虽然这个模块当前没有什么紧要的工作。他们对别的模块非常不熟悉，而且 X 团队也从来没有横跨不同技术模块，去支援研发的先例，他们不能够调过来支持。最终不得不通过加班或牺牲功能的完整程度来确保项目的交付。有资源，却用不上，形成很大的浪费。
上面这个例子来看，虽然有问题，但好像还不是很大的问题。延期一点就好了嘛。但实际上，这背后隐藏着大问题。因为 X 团队的工作模式并不是一个特殊的工作模式，而是很多大公司内非常常见的普通工作模式。在这种工作模式下，某个模块建设之初由于工作量很大，会投入很多人。而一旦该模块进入到平台期，没有太多需要改进的点了，例如登录模块，已经很完善了，不需要再做什么的时候。这些模块的维护人，会本能的维护自己的工作价值，会去深挖登录失败率从 0.01% 升级到 0.001% 的努力，会让一部分管理者觉得他们依然很忙，而且还很上进！都是好同志！这有价值吗？当然有。但是，这个团队有可能有一个急需快速完成的决定生死的功能模块正处于没有人的状态，这个情况下，团队内部无法按优先级对人员排布进行重新分布。再佐以一些在技术上喜欢和稀泥的管理者，最终只会变成不断去招聘新人做新模块，旧人则不断加固旧模块的工作模式。（这一点在我另外一篇文件的第3点有相关展开：软件研发的实用主义思考）
互联网产品的演变是如此之快，每个几个月都有旧模块进入到平台期，而又有新的模块要诞生。就需要总是在招聘新的人，这就像肿瘤，总是在吸取新的身体营养，但是却不会有新陈代谢能让之前的肿瘤死去。
总结一下这一节的内容：
1、 按功能类别的分工模式，形成的螺丝钉化是非常严重的。这种工作模式下，期望基层员工去产生创造力，是非常难的。他们都不清楚整个软件是如何工作的，没有知识背景的前提下，要如何去创造与当前产品有益的东西。
2、如果团队内部，没有按当前全部事情优先级，去随时重新排布人力的能力，那么团队必然会走向不断臃肿而无法瘦身的状态，除非业务不再发展。
建议的解决方案：
关于该问题，我更倾向于纵向分工的模式，让一个研发同事从一个业务功能的 UI 到数据到网络，一竿子捅到底。更接近创业者团队研发人员工作模式，能了解从上到下的软件工作原理，从而可以更快速的去熟悉并接管另外一个功能。当每一个人都参与过足够多的业务模块后，他们会形成整体的认知，有利于全局的优化思路的诞生。同时，由于不同模块之间的开发人员的互相流动，模块之间的不理解与隔阂被轻易打破，这很重要，甚至能减少很多模块之间由于不信任而去建设的隔离工作与维护解释成本工作。这种模式一旦跑顺，你会发现，在需要多个模块深度配合的复杂新功能开发的时候，根本不需要无休止的开会协调与拉通，因为大家互相之间早已深度理解对方的状态。
当然，读者朋友可能会疑惑，这么好 又 看起来简单的方法，怎么可能只有你发现？实际上，这个方法确实好，但是并不简单。除了技术管理者本身对技术业务理解的深度和参与度的要求高以外，对人才招聘的要求也很高，不是随便任何人都可以轻易的做到快速熟悉有差异化的技术类别，从而快速上手他人的功能模块的。腾讯 WXG 的招聘的严格，业界应该也有传闻，关于招聘技巧这里，后续我也可以继续写文章分享。
三、人才战斗力的螺旋式下滑
我深度合作过的技术团队很多，我也深度了解过同体量友商公司的一些研发团队的状态，从中不难发现一个规律。就是某团队的软件产品，其技术创始人如果还在一线或者准一线奋斗着，那么在研发的部署与效率上，会明显高于那些没有技术创始人在编码的团队。
在大部分的团队里，优秀的技术员工是容易获得提拔的，而往往又在提拔后快速的脱离技术一线。带来的是后续技术人员的脱节。研发能力会开始出现断崖式的下降。这里的问题根源不一定是后续的人才能力下降，而是对业务熟悉度不足，对历史代码上的坑不够了解带来。
当然，如果工程的前期架构足够好，可维护性与可读性够好，能适度缓解这个问题，但不能解决这个问题。因为当工程大到一定程度，技术能力差异不大的后来者，在没有先前的过程经验的情况下，是无法copy原有程序员的熟练度的。这是必然的。如果后来者在好不容易达到原有代码作者70~80%熟练度的时候，也会获得提拔而脱离一线，第三任接班者的熟练度会继续下降，逐步递归… ... 最终研发效率会螺旋式下降。
而领导层往往不容易发现这背后的真实的原因。因为程序员的老毛病，是永远瞧不上前任的代码。他们会告诉管理者，前任的代码都是垃圾，全靠自己的重构才挽大厦于将倾。而且大家的说法几乎一致，没有在一线深入的领导要如何辨别真假？只会觉得他们说得挺对，毕竟他们还能举出不少看起来合理的例子，但是又会觉得哪里不对劲，因为研发效率一直在下降。于是，不得不加大招聘，期望通过 10 个孕妇，实现 1 月怀胎的奇迹。然而，他们并不知道，曾经能实现 1 月怀胎的是另外一个物种罢了。当然，在成熟的大公司，大家会通过不断的重构，来塑造新新的架构初创者，将这个工程维护能力熵增的过程大大的延缓。但同时，牺牲的是效率，动不动的大重构对业务的持续性 以及 迭代效率是有很大影响的。这些人力与时间，本可以实现更多商业化的功能，但是却要用来做重构。
对于该问题的解决思路，恐怕是最难的。因为优秀的技术创始人如果不能获得提拔升任管理的话，在中国这个环境下，恐怕也是死局。只能寄希望于随着时间的发展，会有更多的企业察觉到优秀的资深技术一线工作者并非都在 35 岁之后变得没用，只是其中有用的那部分人早就没有在编码了而已。
争取能持续分享一些互联网领域的经验与知识，欢迎大家加个关注！ |
