两周的开发任务可以三天完成吗？

背景

在软件开发中，经常会面临如何缩短开发时间的问题。然而，以下情况不在今天的讨论范围内：

1. 增加额外人手或者调用更稀缺的开发资源。
2. 10X程序员，研发能效，架构方面控制墒的维度。

两个场景

假设你遇到了两个不同的场景：

场景A

你接到一个需求，调研后发现，需要使用新的语言和框架来实现一些模块，并将其集成到现有系统中。初步评估后，你需要学习、搭建环境、运行演示、满足需求、进行测试，而且中途可能会出现许多未知问题。在这种情况下，完成这个任务可能需要两周，这已经算是相当迅速的了。

场景B

与场景A不同，你面临了一项紧急任务，线上出现了重大问题，业务受到了严重影响，这就需要尽快实现一个功能来修复问题或减小其影响范围。在这种情况下，同样的功能第一个版本可能就一天，三天可以迭代几个版本把功能都实现了。

高强度

为什么在场景B中的时间可以如此缩短呢？这是因为任务的优先级极高，你可以中断所有其他任务，压缩睡眠、用餐、运动和娱乐等时间，找到安静的、不受干扰的工作环境，想尽一切办法，提高注意力，高强度的执行任务。

高成本

所以，答案显而易见，开发时间当然可以被缩短，而且空间还很大。那么，为什么我们不在日常的开发工作中采用类似场景B的方式，以最快速度完成任务呢？

实际上，采用场景B的工作方式会付出更高的成本。

1. 中断其他任务会增加更多时间投入，因为时间被压缩，后期需要赶工，同理会增加投入成本，而且对于复杂任务，切换成本很高。
2. 高强度工作会耗尽注意力，相当于使用额外的能量槽，而每个人的额外能量槽是有限的，一旦能量槽较低时，开发效率会大打折扣，甚至下不了手，需要时间来恢复。此外，过度消耗注意力实际上是在牺牲未来的时间。
3. 这种方式只适用于短期应急情况，是不可持续的。

因此，在正常的开发工作中，要准备好一些突击时刻，并保持一定的注意力能量槽储备以应对紧急任务，这才是可持续的做法。

如果简单的认为只要压缩了时间，就节省了成本，实际上作用很可能是相反的，进度也可能是伪进度，墒增的速度可能很快，技术债积累的很快，甚至出现失控的情况。

结论

总结，开发时间可以被缩短，有很大空间，但会伴随着成本的大幅增长。要在项目中采用类似场景B的工作方式，需要仔细考虑这些成本和可持续性。