面对需求变化，首先，我们要摆正自己的心态：

　　1. 不要一上来发火，要分析为什么会有这个需求，新需求的核心点是什么？

　　2. 对比一下旧的实现，这个新需求用旧的框能不能简单改改可以间接实现？

　　3. 从心态上，把需求变化当作是一种项目常态，但是，要学会控制这种需求变化的趋势，不能任其发展。

　　除了以上相关的心态准备外，在团队内部，还需要建立一种能快速适应需求变化的组织结构，我把这种结构，概括为：一人负责制+小团队协作+信息共享。

　　也是说，在我们所有开发的系统中，针对于其中每一个具体的系统，都只有一个负责人，不会有两个或者两个以上的负责人，这样便可以大限度的加快项目决策本身所耗费的时间，有利于快速决策和快速实施。

　　小团队协作，是指，一个具体的系统，从开发到测试到实施，涉及的人尽可能少，两三个人，四五个人，好。因为，一个系统，从设计，开发，编码，到测试与交付，其中可能会涉及到诸多环节，并不是由程序员作完编码整件事完了，产品可不可用，终还是要由客户说了算，所以，应该想办法尽可能提高产品从编码到交付乃至到用户反馈这样一个完整流程的效率，涉及到这个系统的所有人员的反应速度决定了整个产品对于用户需求的响应速度。

　　团队协作，主要的两点：分工明确+信息分享。分工明确，是说哪一些人负责作哪一些事，有明确说明，但除此之外，我们比较提倡的一点，是：每一个人，其终，都是对产品负责，并不能只关注自己所作的那一块工作，把属于自己作的工作作好，只是一个基本前提，具备完整产品思想的人，才能谈得上合格。而信息分享，是指通过IM群、邮件、小会等多种方式把需求变化的信息尽可能快的通知到所有涉及到的人员，以让这些人员更好的进行协同。

　　除了组织架构，我们还需要提高团队成员个体应对需求变化的相应能力，这些能力包括：提高代码架构本身的灵活性，提高编程人员本身的应变能力。因为代码终都是由单个具体的开发者实施的，他们的能力大小决定了他们的痛苦程度。

　　代码的灵活，可以在一定程度上适应需求变化。但是，这并不是解决需求变化的灵药。因为，在实际的操作中，我们经常会因为无法把握“灵活的程度”而把代码本身写得过于复杂，从而甚至让代码本身丧失易维护性，这是我们所无法接受的。我们认为，代码灵活性的底限，是不能破坏代码的可读和易维护，如果到达这个底限，我们宁愿丢弃灵活性，宁愿将代码写得笨一点。

　　我这里所说的这种方法，对人员也是有一定要求的，比如，这个负责人，必须是能独当一面的，要有比较成熟的作事方式、方法和态度，知道如何在高压力和短时间内开展有效的协作。

　　很多互联网产品，可能都会遇到一种情况：一个产品的新版本刚刚发布了，但是，在引入大用户量测试时，却突然发现出现严重的问题，这时，特别考验负责人的应变能力，这种情况往往都是比较紧急的，成千上万的用户可能在网上排着队用你的东西，你需要在一小时、半小时甚至十几分钟内作出有效修改，这种感觉，已经类似于打仗，虽然很刺激，但确实需要相当大的处变能力。

　　每个团队，刚开始的时候，可能都不会这么完美，有这么多能独当一面的人，但万事总要有个开头，团队的成熟并不是靠读一两本书，看一两篇博文能实现的，它需要你和你的团队在具体实践中不断的磨合、提高、总结。