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