下载掌阅APP，畅读海量书库
立即打开
有时候，资源有限未必是坏事，因为它也是倒逼创新的最好方式。但是从短期视角来看软件研发，这个观点似乎并不明智。
最常见的错误方式是采用DDD（Deadline Driven Development，期限驱动开发），用Deadline来倒逼研发团队交付业务功能。但大量的实践经验告诉我们，软件研发就是在需求范围、软件质量、时间进度这个三角中寻求平衡的，如图1-6所示。
图1-6 软件研发的三角平衡
短期来看，研发团队可以通过更多的加班来赶项目进度，但如果这个时间限制过于苛刻，那么必然就要牺牲需求范围和软件质量。当需求范围不可裁剪的时候，唯一可以被牺牲的就是软件质量了，这实际上就意味着在很短的时间内往软件系统中倾泻大量的随机复杂度。
而且，上述做法从表面上看可以更快地取得进展，快速摘取成功的果实，但是经过一段时间之后（一般是6～18个月），负面效果就会凸显出来，会显著降低研发的速度和质量。而且这种负面效果是滞后的，等问题能够被感知到的时候，往往已经形成一段时间，软件架构的腐化就是这样在不知不觉中形成的。
以上这种急功近利的做法，本质上是将长期利益让位于短期利益，过度追求短期交付效率，最终的结果只能是“欲速则不达”。
正确战略方向下的“慢”，远远好过错误方向下的“快”。作为技术管理者必须学会两者之间的平衡之道，并为此长期承担后果。
当然，如果你是在创业项目前期，则可以暂且不关注这些，毕竟几个月后你的项目是不是还活着都是一个问题，但如果创业项目熬过了这段时间，还继续这么做就会很危险。那么，你可能会问创业项目的代码在前期积累了大量的随机复杂度，后续该怎么办？笔者的答案是，在适当的时候另起“炉灶”，在用户无感知的情况下完成后台服务的替换，这个适当的时候往往就是项目的商业模式完全走通的时间点。正确的技术战略需要能够在宏观层面上帮助系统控制复杂度。
记得在一次行业交流的时候，有一位朋友说到一个观点：“乱七八糟的生机勃勃，好过井井有条的死气沉沉”，乍一听这个观点还是挺有道理的，但是笔者觉得对于软件工程来讲，这个观点是完全不适用的。这个观点对于需要创意的工作是成立的，创意工作一般是单次博弈（前后两次掷骰子没有关联性），而软件工程是工程，属于连续博弈（前面的行为对后面的有影响），所以笔者认为上面的观点不成立。
另一种常见的错误方式是试图通过招聘或借调更多的人来解决软件项目的进度问题。随着项目参与的人越来越多，分工越来越细，人和人之间需要的沟通量也呈指数增长。很快你就会发现，沟通花费的时间渐渐地比分工省下来的工作时间还要多。简单说，过了一个临界点，不是人越多越帮忙，而是人越多越添乱。一个人3个月能完成的事，3个人1个月不一定就能完成，甚至3个月也未必能完成，更何况加入的新人还需要填上认知负荷的“坑”，这些都需要时间成本。