工程师最害怕的是:动态需求
最近和朋友聊天，发现大家普遍遇到比较多下面一些情况。
- 『这个功能不是已经实现「差不多」了吗，再加个功能很快吧』；
- 『以前做过「类似的」功能，这次项目可以复用以前的模块咯』；
- 『怎么要这么长时间，这个功能以前不是做过的吗』；
- 『都快 deadline 了还没做完啊。再加个人，一定要按时发布』；
- 『我们团队已经这么多人了，怎么还完不成这么简单的功能』；
- ……
遇到上述情况之一，不仅管理者无奈，作为工程师其实也很无奈的。有些事情真的不容易解释清楚，比如：动态需求和动态需求管理。
如果定义我们看到的产品需求是静态需求，那么从一个静态需求向另外一个静态需求迁移的过程，就会产生对应的动态需求。过去工程师们一般会将这种需求称为需求变更，不过这种说法容易导致产品经理的抵触，因为一个产品实际中总是充满各种变化的，不能很好执行需求变更的技术团队不是好的技术团队。为了避免这种误解，我们称呼其为动态需求更好一些。
解释一下为什么通常动态需求会让工程师抓狂，这事儿就好理解了。
一般来讲，完整的项目需求给到工程师，架构师会首先根据项目的需求进行系统架构设计，一方面尽量实现项目的需求，以满足各相关方的利益表达，另外一方面还需要结合项目的发展规划、团队实际情况、现有技术架构等情况，尽可能多地实现非功能性的目标，包括可维护、可扩展、安全性、稳定性、易用性、质量控制、灾备方案，甚至团队构成、成本核算。有句话叫『没有最好的解决方案，只有最适合的』。针对每个具体的场景和需求，一定会有一个相对合适的方案，而这个方案也就是具体到这个场景和需求的，如果简单地把方案挪用到其它场合，就配不上『最优』这个形容词了。
所以，当一个适合某场景的方案产出了成果，我们要直接复用它，拿它为另外一个场景服务，这就是一次从『最优』到『次优』甚至『不优』的迁移。也许这两个场景中一些需求是存在一定程度的重复，因为各个因素的关联性，为了保证迁移之后的方案能相对『较优』，一定是需要额外付出劳动的，而且往往，这种付出对应的工作量还不小，很多迁移本身就是一次大工程。
这也解释了为什么很多工程师往往愿意选择自己重新造轮子，也不愿意使用别人的代码，因为使用别人的代码需要读代码、抠细节、做迁移，当然也包括承担和消化前人遗留下来的谬误。
对于很多创业公司来说，忽视动态需求的危害已经到了能够影响公司自身发展的地步，却很少有人能意识到。最近几年大家对非功能性需求普遍比较重视，因为有人通过技术债的概念将它抽象出来。可惜需求到需求的迁移产生的代价，还在水面之下，不为众人所见。
后面有时间再讲关于如何处理动态需求带来的问题，以及动态需求的管理。