开发者如何面对需求变更？

最近在进行一个产品的开发过程中，碰到下面情况：

短短一周内，产品需求变更3次，开发过程中不断的与产品进行需求反馈与确认，甚至在测试即将完成时，产品的需求也发生了重大变更。不禁反思，开发者在面对这种情况下应该如何应对，才能进可攻退可守，而不至于陷入需求变更的泥潭，而裹足不前，陷入混乱。 下面是个人的一些思考，欢迎大家进行讨论。

1. 面对常规需求

这种需求是最常见的需求，也是最成熟的需求。产品经理会将需求点一一列出，并给出详细的UE供开发人员参考。开发人员也很容易知道需求有1，2，3等到几个点。一次需求宣讲，一篇需求文档，一封邮件确认，开发人员即可进行大家碰头讨论后，拍板下基本需求，开发者就可以回去设计方案，并进行开发了。

2. 面对未成熟的需求

相比于常规需求，产品们的想法暂时也没有成熟，可能觉得一些产品创意好，但是并未想清楚，仍然处在不断的变化中。但是可能面临各种压力，又急于提出。这个时候，往往出现这种情况：开发人员在具体开发过程中，遇到一些不明确的需求点时，需要与产品反复确认，产品可能为考虑到这些需求点，因为这些都在之前的需求宣讲范围之外。这个时候，要么暂不考虑此类需求，要么就是也做了吧。产品是允许试错的，所以开发人员也要硬着头皮将其实现。

3. 面对试验性的产品需求

最好的方法是在最短的时间内，采用最小的代价将其开发出原型，快速上线并得到产品和用户的反馈，产品叫好，可以考虑投入更大的资源进去，不好，下线也不会损失太大。

具体到执行的时候，会在进行方案设计的过程中也要面临抉择：

1. 优雅的设计与工期的矛盾往往在进行方案设计时，开发人员都极力想推崇最优雅的设计，使我们的系统更易维护，更具可拓展性，更健壮。但是工期很紧，产品急于看到原型，这个时候开发人员开始在快速实现与优雅设计之间纠结，因为优雅的设计需要反复推敲，不断改进，工期往往不允许。2. 最佳方案与存储资源的矛盾对于一个业务，最佳的方案往往是单独进行存储，需要各种资源如缓存、DB等，这样的方案通常具有可维护性、易运维等，但是对于一些小业务，不足以让我们为之付出如此高的代价的时候，就要进行权衡。

3. 现有架构与特殊需求的矛盾

一个成熟的系统，其架构往往是针对常规的需求而设计的，然而互联网产品在更新中，不可避免的要加入一些特殊的需求，比如商业化的、个性化的需求。这些特殊需求，采用现有的架构实现起来，要么基本上不可能，要么总是很别扭。推翻重来，对于一个已经稳定运行的线上系统更是不可接受的。开发人员此时又会在新架构与老架构之间踟蹰不前。
针对上面的矛盾，如何抉择呢？有没有统一的原则呢？下面是个人在日常工作中总结的一些办法，这些也是前人们经常使用的，可供参考。