技术团队：研发中的短跑冲刺和马拉松游戏

hi，我是熵减，见字如面。

对于技术团队来说，开发软件产品，是一项长期的工作。

就如同马拉松一样，要完成这样的游戏，需要的多个迭代周期和很多冲刺的不断地积累。

在游戏的过程中，需要持续的、有节奏的向着目标前进，并在此过程要不断地做出调整和改变。

然而，在现实中，今天有不少的团队，是无法如此有效的开展工作的。

其背后的原因是：团队将冲刺（Sprints）的数量和周期作为了目标。

将短期的冲刺做为团队的目标，就是将开发产品的工作，看为了一项短跑游戏。它的本质上就变成了一种浪费，因为团队会最终陷入一些毫无意义的工作任务之中。

尤其是在今天，在互联网增长神话消失后，唯快不破的方式，已经不能给产品或业务带来太多的意义。

所以，及时的调整团队工作的节奏，对团队和业务的长期发展是更为有价值的。

短跑的“敏捷”

在冲刺（Sprints）的数量和周期成为团队的目标后，整个团队的动作就会悄然发生改变。

现实中，大多数团队都采用一些类似敏捷的方法，在这种方法中，开发工作会在迭代中开展。团队会计划一些 Sprints ，会评估如何完成这些任务，并在完成后进行任务过程的回顾。而对于Sprints的背后的要交付的产品价值，要解决的实际问题，研发团队是很少讨论，也不太愿意去关注的。

同时，为了增加冲刺（Sprints）的数量，或减少完成冲刺（Sprints）的时间投入，团队会做出很多没必要的拆分，从大的数据上来看：所有的事情都在不断的进行，Sprints的完成量和完成时间投入也非常的合理。

但其实呢，产研团队可能在玩一个短跑冲刺的游戏，来迎合管理层的考核目标。在短跑游戏中，团队往往就会偏离了业务价值的交付的目的。

短跑冲刺的伤害

其实，这种空洞的短跑冲刺游戏，会给团队造成多方面的伤害：

首先，团队的稀缺的研发资源被浪费在了很多无意义的冲刺（Sprints）之上。从表面上来看，团队是完成了很多的任务，交付任务的效率也很高，但真正交付的业务价值是多少，是很少有人去关心的。

第二，团队的冲刺（Sprints）回顾，成为了一个形式化的步骤。回顾，更多的只停留在第一层的任务完成的过程上的复盘，而未能在向前推进一步，对于冲刺（Sprints）的业务价值，方向上的问题，团队总是视而不见的。

第三，工程师们逐渐丧失了价值感。工程师们逐渐成为了任务完成的一个终端，而无法真正参与到问题的解决之中，长时间的参与感缺失，就会对工作失去了价值感和意义感，稳定性也就成为了一个问题。

总之，对于技术团队，最稀缺的资源就是工程团队的时间资源，如果我们如此任性将时间浪费在空洞的短跑冲刺游戏上，是非常可惜的。

回归意义

要解决空洞的短跑游戏问题，其办法也是非常简单的：那就是让冲刺（Sprints）有意义。

让团队有全局的视角，找到一个健康的节奏，将有效的时间资源，尽可能的投入到有业务价值的功能交付之上。

具体如下：

首先，在管理上，不只是单一维度的去考核团队的冲刺数量和交付时间周期的指标。

第二，要让产研团队一起去设定每一个“冲刺”的业务价值，让每个人(包括他们自己)都理解朝着这个价值前进的重要性。

第三，团队要能根据实际的情况，动态的调整“冲刺”的重要性和优先级，任务范围的大小、交付周期的计划等，不在追求虚假的指标。

第四，在团队的“冲刺”回顾中，要向上有深挖假设的有效性，譬如，问题是否定位准确，方案设计是否有效，交付的业务价值是否符合预期等。而不只是任务完成过程中的研发效率那一小块东西。

数字产品研发和交付，是一个如同马拉松一样的长跑游戏。

在此过程中，要找到合适的短期目标，控制好整体的节奏，不断做出有意义的回顾和调整，让团队看见真实的意义和价值，是持续发展的关键。

写在最后

软件产品的开发过程，不是一项短跑冲刺的游戏，而是一项持续的马拉松项目。

如果将研发过程简化为只有冲刺数量和交付周期的短期任务，而忽略了团队内人员内在需求，资源的浪费就是必然的事情。

回顾到敏捷和冲刺（Sprints）的本质之上，要让团队将更多的精力和能量，用在交付更有业务价值的迭代之上，才是更有意义的。

好的目标，会带来好的结果，所以小心你的考核目标。

---

阅读，思考，练习，分享，日日不断之功。

嗯，写完了。

新的一天，加油哦 (ง •̀_•́)ง