今天第一次去开需求评审会议，感觉比我想象中的要温和一些，虽然有争论，但是没有发生比较严重的吵架这种情况，但是根据从书上看到的和今天感受到的，还是有一些想法。
1.需求在之前最好自己就梳理清楚其目的和带来的流程变化。对于需求，产品一定要做到心里有数，不能自己对与某些概念就不清不楚的，尤其是涉及到多个部门要交接的那种，对于需求提出方，一定要搞清楚需求提出的“目的“”是什么，希望能够达到什么效果，有没有可以从其他渠道实现的可能性，最终反馈的结果会是什么。也就是说，产品要把这个需求的流程搞清楚，明白这个需求改变之后带来的流程上的优化在哪里。
2.需求在评审之前最好把其引起的逻辑上的变化搞清楚。因为我涉及的产品是对于金融逻辑卡的比较严的，前端某一个数据获取的变化会引起后端逻辑的变化很多。所以不要仅仅看到页面上加了一个输入框，与其相关联的接口、页面、逻辑都要搞清楚。
前面都是废话，关于我需要做的：
1.前期在处理需求的时候一定要沟通清楚。和需求提出方弄清楚他a.希望我们做成什么样子 b.做成这个样子的目的是什么、达到什么结果 c.对于这个目的，至少做成什么样子。
2.和开发沟通的时候一定要搞清楚技术边界。也就是说要清楚a.我们这个需求要做成什么样子，目的是达到什么效果，最低要求是什么，也就是吧需求方提出的需求清晰的反馈回去 b.让开发理解我们这个过程，同时听取开发的意见，了解技术上的限制是什么，获取能否实现、实现的限制，同时为开发理清逻辑，共同思考。简而言之，就是给开发讲懂我们要做个什么东西。
3.关于个人最好在会前能够多多沟通。在会前最好把上述信息都和开发还有需求方沟通清楚，对于双方的意见做好很好的反馈，有机会的话让两个主要负责的人面谈，如果不能实现，就做好沟通工作，如果实在沟通不妥，备注，在会议上由各方讨论能否实现。
事情的沟通提前做！！！
不要都等到需求评审的时候做！！！
所有的问题一定要确认！！！
任何问题，注意是任！何！问！题！都不要我觉得怎样，一定要沟通清楚，哪怕在细小的问题都要沟通，因为你的理解和业务还有开发的理解是不一样的！！！
自己的责任自己承担，但一定不能背锅！！！
最终的决策权要请教一下产品的总负责人！！！
