在项目开发过程中，项目经理拿到客户需求待办事项后，架构人员开始针对客户功能做架构设计，产品人员针对需求列表做产品原型设计，开发人员根据架构和原型开始做系统概要设计，详细等等设计，测试人员需要写测试用例，开发、提交测试、验收......
(一) 需求确认阶段
在上述任何一个环节出现问题都可能引起需求变更，我们往往倾向于在项目经理跟客户沟通或者产品原型设计中出现需求变更，因为需求变更越靠前，成本越低。往往项目经理和产品人员为我们提供的原型或者产品设计说明书大多都是代表客户的意思。这个时候开发人员会对着产品和项目经理原型说明进行评审和设计，中间过程可能会出现问题，开发人员可能会对产品人员甚至客户提出质疑，这个时候产品人员要认真思考客户实际使用场景，不能直接拒绝，也不能盲目听从。因为开发人员大多都是从开发角度去看待问题（产品会说：你不能因为复杂而不做，这大概就是产品和开发经常撕逼的原因吧），但是开发人员大多不能考虑到用户体验，但是有一点往往是正确的，就是产品的开发和可维护成本，产品人员虽然不需要写代码以及后期维护，但是产品都是有迭代、有生命周期的，如果开发不当就会造成产品生命周期变短，可迭代性降低。故需要站在用户使用场景和开发成本几个方面综合考虑，如果实在不好拿捏，可以通过思维导图工具列举出来。
为什么产品需要这样做？
这样做能够带来什么价值？
开发人员为什么不能这样做？
不能这样做的具体原因是什么？
是不是有可以解决的办法？
是不是技术问题（如果是可以通过专家委员会评审决定）？
..........
（二）开发设计阶段
开发人员永远要牢记开发之前的原则，开发之前一定要有设计，有人可能抬扛说我做的东西很简单，拍大腿都能知道怎么做，那你就可以先通过拍大腿做出设计和大概流程，当然这是个玩笑，意思就是项目简单，那么我们就来一个简单的概要设计，复杂的情况下我们不仅需要概要设计还需要详细设计，完成设计之后一定要评审，而且需要约上项目所有相关人员，这个过程其实就相当于是需求反串讲的过程，看看你的理解和产品人员的理解时候一致，如果出现不一致的情况，那么恭喜你，你的设计奏效了，这个时候可能是需求问题，可能是你的理解问题，也很可能出现需求变更，但是没问题啊，code还没有下锅。（不至于程序都编完了，产品人员还在需求变更）。这个时候如果产品人员提出需要变更，那就确认完成后走变更流程，产品人员要敢于改变，因为产品不能凑合，如果现在不改后期，成本更高。开发人员的前期设计不仅能够能够带来这些好处，提前做好复杂功能的流程设计，数据流向设计，以及复杂功能的流程图、时序图。以及内外部接口设计，通过这些设计就可以让我们理解功能需求快速完成编码，并且足够指导其他开发人员开发，但是这些东西会增加我们前期的沟通成本, 人月神话告诉我们沟通永远都会占据我们大量的时间，我们实际编码的时间其实占到我们总时间的1/10左右，所以我们不要沉溺于写代码，不要拿到需求之后立马完成，一个产品的完成是团队共同努力的过程，写代码只是一个水到渠成的过程。
（三）开发阶段
如果团队测试人员充足的话，最好在编写代码之前，先阅读测试人员的测试用例，如果不能跟测试人员达成一致，那么说明对需求的理解存在不一致，那么不好意思，要么你后期加班改bug，要么测试人员需要重新编写测试用例，所以测试人员最好在开发人员编码之前做完测试用例并要求开发人员认真评审，开发人员也一定要认真阅读，因为这是你开发之前的最后一个保障，测试用例能够从一定程度上保证你开发出来的功能大致是正确的，不至于让你研发一个冰箱，最后你做了个水箱。这个时候如果出现需求变更，确认完成后，该变就得变，不能凑合。
这个时间段，产品人员不要以为万事大吉，开发人员赶快加班干吧，现实中很多产品人员都是这样，对于开发出来的功能不闻不问。如果碰到喜欢沟通和发现问题的开发人员还好，但是大多开发人员都不太喜欢说话，有时候很可能不是开发人员的问题，而是当开发人员在开发过程中碰到某个细节问题，但是这个细节问题在需求中并没有体现，想想吧，开发人员大多会按照自己的想象力去做，因为产品并没有指导他怎么做。然后开发加班到深夜，不以为然的完成了，第二天就把这种细节问题给忘了，这些就是后期为啥为经常出现产品和开发或者测试撕逼的原因。但是如果在开发人员开发的过程中产品人员密切关注，当开发出来的还是半成品时就开始试用，发现问题立马改进，如果需要变更需求就提出来，确认无误后走变更流程，可能对于后期的产品验收效率能够起到很大作用。
（四）测试验收阶段
这时候已经通过开发人员自测，提交到专业测试部门进行最后质量把关，这个时候测试人员会站在用户的角度对细节和整体使用进行回归测试，开发人员和产品人员以及其它相关的干系人最好都要参与进来，开发人员不仅需要修改测试人员提出的bug，而且需要对bug进行分析，为什么会出现bug？ 产品和其它的相关人员则要整体试用，尽快发现问题，提出问题，修改问题。
