除了 deadline，我们还能用什么驱动开发？

Q：我们希望通过系统的方式进行度量，其中也包含了一些基本的理念就是聚焦在具体的问题上，有没有什么构建因果回路的好的方式或案例呢？

A：可以用一个通俗的例子解释如何通过系统思考的方法对当下的情景进行分析。比如，我们现在很多软件企业都面临的一个场景叫 DDD，不是领域驱动设计的 DDD（Domain Driven Design），而是 Deadline 驱动开发（Deadline Driven Development），一开始就把 Deadline 定好了，在这种模式下面，从管理的角度来看，大家就以为只要我把 Deadline 定好了那么基本所有的任务就都能完成。所以很多产品开发还在采用这种 Deadline 驱动模式，貌似每次都很有效果，但实际上通过系统思考的方式去想的话可能不是这样。 

一般软件工程需要解决如下几个问题：功能、效率、质量，如果是 Deadline 驱动的，当我们把时间点定好以后，功能又不能砍，牺牲的只能是质量，但表面质量又不能降低，惟一能降低就是内在质量。在这种情况下，工程师确实能完成规定的任务，但他一定会采用战术性编程的方式，即不考虑以后的可扩展、不考虑需求变更后可能需要进行的改动、也不进行领域建模，而仅仅是把代码从头写到底，任务目标虽然完成了，但从系统上来看，这种代码为以后的开发管理工作留下了很多技术债务，会让以后的开发变得更慢。

而且这种模式只考虑了业务，从长远来看，这个系统的可扩展性是很差的，一般 6-12 月以后系统的业务交付就会变得越来越困难。 这件事的回路是这样的：Deadline 驱动交付——战术性编程——技术债务——整体效率变低——更要 Deadline 驱动，团队就陷入一个无止境的恶性循环里了，很难再拔出来。

所以如果我们能通过这种视角看问题的话，就能发现其实 Deadline 驱动 是一个非常不好的模式，那从哪个环节去打破它呢？可以从度量的角度做一些事情，从代码当中的技术债务做度量，比如度量一些重复代码度、代码注释率、代码的测试情况、代码的联动修改等，可以通过这些指标看是否存在上述情况。

作者：茹炳晟

本篇内容来自由思码逸联合各效能专家共同出品的《研发效能100问》，点击可下载全部内容