一、膨胀的团队、膨胀的复杂度

书接上文：新晋总监生存指南开篇之总监二三事

按照之前的逻辑：如果你想创造一个能够维持一定秩序、不会分解的系统，那么这个系统必然是一个开放系统，就需要为他注入能力，并让其在系统中流动以维持这种秩序。管理的动作就是为团队注入能量，能量停止系统就会开始退化，这种持续为组织注入能量的行为，正是领导力的核心。

以上的话比较晦涩，他要表达的意思是：团队一定会出问题。规模越大问题越多，并且问题会越来越愚蠢、越来越不可思议！

如果没有管理动作的介入，团队会变得十分混乱，效率接近为0，根据熵增定律，封闭的系统，最终会由有序变成无序。

这里举个简单的小例子，大家去食堂打饭，没人维护秩序会怎么样；增加规模，变成市民去火车站买票没人维护秩序会怎么样；持续增加规模，变成国庆期间外滩游客如果没人维护秩序会怎么样。

所以管理的核心其实是有效的解决团队的问题，保证他有效的运转，而团队不同的阶段（不同的规模）下他所产生的问题以及对leader的依赖是有所不同的，如图所示：

每个团队在形成初期，沟通往往是单向的，需要一个强有力的leader，成员之间了解度低，对环境乃至公司团队战略不清晰，很容易产生焦虑困惑和不安全感。

比如新同学是非常容易无所适从而导致离职的，这个时期主要需要解决的是两个点：信任与目标，即员工之间的信任问题，和明确团队的目标问题，这个可以由五维能力模型的战略入手。

这个时期的团队一般50人以下（更常见于20人以下），由leader凝聚起来，如果leader足够优秀，团队会非常有凝聚力，适合局部作战，打一些小战役，而随着团队发展，接下来就会进入风暴期。

由于团队规模变大，不可避免的团队和团队之间会产生合作，但是因为各个团队风格各异，冲突会因为文化、理念、利益、工种等问题不断爆发，这个时候我们主要解决团队之间的问题，这里除了机制解决以外，更好的办法是划分赛道，并且确定更大的战略目标。

风暴期的团队已经有一定体量，人数因公司团队情况而有所不同，这个时候的团队冲突往往很难自己解决，因为一旦涉及到所谓团队利益，很多人就会很容易失去冷静，所以这个时候更需要一个好的leader解决一些冲突，把各个团队串联起来，避免团队各自为战，各自埋怨产生内耗，形成效率竖井，事实上风暴期是很多创业公司的送葬场。

团队经历痛苦的磨合，开始进入规范期，这个时候团队之间已经找准自己的定位以及对方的价值，彼此间开启高效的合作模式，之前良好的机制迭代，也形成了统一的文化，所以团队问题变得更可控了（未必变少了），合作共赢、配合执行成为团队主旋律，leader的更多是参与决策，而不是主导决策，只有在一些比较胶着的情况才会推动问 56c 题解决。

团队最终阶段，我这边缺少经历无法建立认知，便不多说了。

分而治之是解决规模过大的良药（正如上图中的team小圆圈），多数公司都会分为事业部，继续将关注点聚焦，技术团队一般是按业务线或者按技术职能线划分（前后终端...）分为几个组。

于是管理整个技术团队变成了管理各个小组，这样虽然会导致“屁股问题”，但管理难度会小很多。这里最核心的问题依然绕不开：CEO不可能承担所有角色（技术、财务），技术负责人也很难精通各个技术栈，那么各个陌生的部门、陌生的领域如何管理？

二、为什么要建立数据指标

实际推进数据指标落地可能非常费力，需要不停的建立共识，了解全貌可以更好实施，所以我们首先介绍团队膨胀到复杂度增加，并最终选择分而治之的方案，至于数据指标是什么，我们以一个案例开始：

因为产研是公共资源，所以会存在业务方抢占产研资源的现象，而限制创造力的内部竞争会导致制度性的内卷，于是某一天老板提出谁使用谁埋单的规则，产研刚以为可以少做一些低价值需求后，来了一句神来之笔：

虽然当时的真实反应是：艹！又要做一堆无效的作业去应付这莫名其妙的疑问。但如果细细思考，这里却触发了本质问题：

技术负责人应该如何评价各个单元组的产出，可以主观的定性，却需要客观科学的定量，于是便需要建立数据指标。

然后在具体实施落地的时候，很多同学不容易理解数据指标是什么，认为“数据指标”在瞎折腾，不能理解这块的用意，内心抵制是不容易做好的，就算做好了也可能只是运气好（蒙对了，反而会埋下更大的坑），这里跟大家强调下，数据指标至少有两个作用：

1 想不出来数据指标，说明是对这块事（团队要做的事）没有一个清晰的认知

2 想得清楚数据指标，却做不出来，说明对整个团队缺少掌控，不能推动落地

不能建立数据指标，根本没法做数据驱动，看似简单的数据指标把团队是否在裸奔指了出来，是因为惯性还是被动向前跑，一目了然。

综上，数据指标其实是想真实反应我们的团队是什么状态，我们做的事是什么状态的一个指向标。究其原因，组织执行力、产品健康度需要某种程度的量化，数据指标的作用从更宏观的角度看是这样的：

数据指标提供了航行方向，北极星的作用，这里再来一张图，看看数据指标在全局中的角色：

其中牵引指标就对应我们的业务数据指标，牵引指标不健康的时候可以预警是不是团队方向跟目标走偏了，leader要考虑调整目标还是修正团队方向。

三、研发数据指标

3.1 比价模型

先回答上面的灵魂一击：你的研发与外包团队有什么区别？

一般来说研发团队的工作是“做项目”，其工作产出物是“代码”，作为偏执行团队的评价指标一般是三个：

1 成本指标

2 过程指标，执行效率

3 结果指标，交付质量

粗粒度的表格可以是这样的：

在数据准确的情况下，上述评价模型基本是可用的（只不过大概率拿不到，所以老板的问题大概率还是瞎扯淡......）

3.2 质效指标

事实上比价模型被作为一个作业交差了，但其中的质效相关指标作为了衡量整个研发团队的指标被保留下来，持续迭代后变成了这个样子：

实际执行效果如图：

上述是周常规指标，每周周会我们会过这个数据，除此之外我们还有一个项目维度的指标，大概是这样的：

这个表格用于每个项目结束后复盘的重要参考材料。

3.3 其他指标

上述是比较通用的质效指标，各个业务团队皆需要遵守，是兜底的存在。

具体到前端团队的数据指标、后端团队的数据指标、NA团队的数据指标，又会有很大的差异，端更倾向于体验指标、后端更倾向于稳定性指标。

而业务团队的数据指标提取就“奇妙”了，除了通用的质效指标需要遵守，还需要侵入业务，而这个数据指标又不能是诸如订单量之类的业务指标，所以纯业务团队的研发数据指标，很长一段时间我也没想明白，后来回归本质，我认为依旧需要在效率和质量上做文章。

其中效率可以具体细化为很多组件化工具的建设，技术升级，这里最终会反馈到整体的效率指标提升，但如果单项的工具建设，由于耗费人力，可能还会在某个时间段降低效率，这里取舍需要leader自己判断，比如测试环境治理要不要做，需要付出什么成本，能达到什么效果，这些都需要决策。

业务质量部分可以更多的考虑业务埋点，比如P0页面乃至接口的监控，这里要达到的效果是，大流量场景下，一旦某个用户触发了边界场景，这个是有预警的。

最后，数据团队、工程团队、产品团队的指标各有不同，大家可以自由补充。

四、数据的使用

建立数据指标，才能存储正确的数据，随后数据便可以产生价值了，我们这里的数据使用依旧是聚焦到研发领域：

1）周常规数据，比如我们每次周会都会过上一周质效周报，里面数据一旦有波动，就一定是某个团队出了问题，这里首先暴露了该团队这个周期内可能的问题，我们可以继续深入这个团队，看他这个周期是什么因素导致了指标不达标，再协助做整改即可。

某些程度来说，数据指标有“紧箍咒”的作用，没有团队想在会议上被人“复盘”，于是平时就会刻意的做建设，那么团队整体的产出就有基础的保障。

这里要注意的是，大家都可能出问题，万不可以某个团队指标不合理大做文章，成为喷子。< ad8 /p> 2）项目维度指标，我们记录了项目维度的执行指标（如上图），在对“问题”项目、“典型”项目复盘的时候，我们发现这次项目过程中，产品与研发的合作十分糟糕，battle不断，对比数据一看，发现需求更改10次，于是便更需要产品同学做复盘；我们发现技术侧耗时远远超出平均项目时间，跟进去一看发现原来测试环境泳道出了问题，项目的执行测试环境，不断的被其他团队修改，那么就该在测试环境治理一块做工作......

诸如此类

3）周期内某业务线整体质量复盘，大概是这样的：

四、结语

无论个体、单元组、团队都需要切实了解自身状态如何，为了更具象的描述这种“状态”，我们要求每个单位需要提出自己的衡量指标，这个就是我们所谓的数据指标。这里要注意一个点：

建立数据指标——>数据开始有指导作用——>数据可说话——>数据驱动，这是每个团队都想要达到的状态，他需要每个“山头”的leader都对自己的领域有足够的认知，提得出相关指标，还需要切实的落地指标记录，到最后的应用指标，这个要求其实比较高，那么有没有相对简单的办法可以更好的建立指标呢，事实上可能还真有：

所以下次，我们一起学习下OKR工具的使用，关于数据指标一块的浅薄的认识就到此，希望大家多多讨论。