以下情况根据个人经历以及团队故事总结一下，如有误导请指出。
当一个产品蓝图规划好后，就可以开始安排开发、测试、运维、设计、等人员配合产品经理一起开战了（当然运营和市场是后话了）。产品蓝图的规划主要包括：商业转化、市场前景、产品功能和底层架构这4个方面。
这4个方面的产出是基于各个领导和部门之间的相互协调和讨论最终结果，也就是我们常说的立项，立项基本上可以明确产品的初始定位和第一期的开发进度。
实际上，在第一期开发的过程中，往往会出现开发需要根据产品提出的需求进行多次修改，甚至反复修改。为什么会遇到这样的问题？我们应该如何规避这些问题？
为什么会遇到这样的问题？
1.产品的锅
产品对于之前的需求定义不够清晰，考虑的细节不到位，导致开发过程中反复修改原需求，甚至出现改了2、3次还是回到最初的需求。
而这也表明了产品的定力不足，被开发的技术逻辑牵着走导致产品逻辑反复改。
2.开发的锅
产品需求的可行性和产品实现的技术逻辑开发必须明确自己并不是一个“依照画葫芦”的开发，而是有想法的。（当然如果开发没有想法那只能说明他过于忠诚了）
这里明确指出的是开发在面对新需求的时候，要质疑（当然是出于友善怀疑的态度）产品的需求是否可行，是否颠覆现有的行业标准。
遇到这样的问题，不可能是单方面的责任。更多的是团队的默契不合导致的。那么我们如何解决呢？
我们应该如何规避这些问题？
1.产品侧
a.不断思考：在需求的提出前需要不断思考如何用自己的产品逻辑简单化的告诉开发，最好的方法是：自己讲一遍，开发听后再复讲一遍；
b.完善需求：在需求提出后，按照正常来走是不应该修改需求的。但是出于某些需求在提出后需要和开发商量讨论，这个时候得出来的是最后的确定的需求就是完善需求；
c.遵从主线需求原则：需求已经处于开发阶段再出现新的需求，必须是以主线需求衍生的，否则新需求将替代旧的需求。浪费了很多的开发精力和时间；
d.反复求证：另一个角度来说，就是自己对于需求的把握不准，能力问题）另外可以在确定需求的同时反复向技术求证是否存在违背技术原理的。（一般情况都不可能是技术实现不了的，更多的是实现的方式和表现的方式）。
2.开发侧
a.换位思考：从开发角度出发，需求完成后会出现各种bug，这个时候和产品提出的新需求同样。大家应该互相体谅，换位思考也是一种避免产生不和谐的方法之一（但是治标不治本额）；
b.预估开发用时：更多的时候开发在面对需求的时候需要谨慎判断需求的可行性以及多和产品进行沟通确保需求能够如期完成，避免在开发过程中反复修改需求；
c.适当排期：在某些衍生需求的时候，开发可以按照目前的进度进行排期开发，并不影响主线的需求。
总结：以上只是根据产品和开发侧来分析，当然可能是基于需求的本身是否二手需求，但归根结底还是需要人为进行调控，达成一致的看法才能如期进行。
