做为一名产品经理，你是否有把需求提交研发后，还要修改或补充界面、需求说明甚至功能点？
做为一名对自己有高要求的产品经理，你是否在修改需求时自责于自己当初怎么没想到还有这些情况？
做为一名要对产品质量和产品开发进度负责的产品经理，经常改需求不仅会让自己的专业度和威信力下降，也会影响开发进度和上线时间，甚至会延误战机；
当然，导致需求改动的原因有很多，不同的原因也有不同的应对方法。
客观变动：
有时候公司业务发展侧重点变了，产品在做需求的时候也要根据公司的业务发展方向而变动，这点可以看成是不可抗因素。这时候要做的就是安抚好开发的情绪，跟他们讲清楚状况；
在说需求变动原因的时候，说的最多的就是老板要求的，需求方要求的；如何应对老板和需求方经常改需求也是个很大的命题，有很多文章也讲过这个话题，这就不再累述了。
主观变动：
我现在想讲的更多的是因主观原因而导致的需求变更，这主观原因主要就是自己“没考虑到”。没考虑到特殊场景、没考虑到错误分支……当研发或测试问及的时候才发现，对呢，还有这种情况！
之前看过一遍文章说做需求时没有考虑特殊场景，实现功能没有考虑错误分支的情况大多是1-2年经验的产品经理犯的错，可能是这个阶段的产品经常更多的是在执行，没能全盘考虑，没有深入思考。所以针对这种情况，这个阶段的产品经理要打造冥想的能力即思辨大于执行。
有人会因为迭代周期短、功能多，觉得没时间考虑周全，为了早日完成任务，接到需求就立马动手画原型了；有人是没有冥想的概念，不知道要从哪些方面去想，觉得主流程走通了，形成闭环了就可以了。然后在研发做的过程中，一边发现问题，一边改需求或补充逻辑，以致项目周期拖延。这种情况多了，轻则引发研发的怨声载道，重则引发老板的问责；
如何打造冥想的能力？
先想再做，有人说牛人的思维 是接到需求时先思考：结构思考力、马斯洛需求层次、5W1H分析法、金字塔原理、AARRR模型……各种原理、各种支撑；
按科学的设计流程，一步一步梳理需求：比如先定业务方向、然后回归现实梳理现状、再找对照物看竞品趋势，最终制定设计策略。有了既定的方向和设计策略，方向不会错，即使后期要改动也不会是大的业务方向上的改动。然后再把各种异常情况和错误分支罗列出来，一一列出对应的解决方案。有主力军和后备军，进可攻，退可守，再也不用担心需求评审时被各种问啦。
