1、需求分析阶段
需求分析阶段我们过去仓促，没有形成一个形式的文档结构化。
与运营同事沟通，并没有形成会议纪要文档。
需求在不断变更中，每次开会的时候又会涌出新的需求。
2、设计阶段
设计阶段的分工我们没有统一口径，改了哪些东西没有备注。
涉及到的产品形态太多，小程序、微信公众号、微信小店、后台点评 总共算下来4个板块需要跟进；
3、项目跟进阶段
项目跟进，我身为项目的产品负责人，我有义务有权利知道，哪个环节导致项目的风险点，我有能力hold住。
项目的延期并不是能很好的很有效的评估产品能力、设计能力、开发能力。但是，肯定一点就是我们在哪个环节出错了，我们要么是需求变更的问题，要么是UI不能理解你的需求，要么是开发不能很好的评估等你的需求造成的。
4、需求评审阶段
需求评审阶段，需求在评审前期已经发至到相关人员，还请大家仔细的阅读原型交互稿，避免在前端研发开发阶段才发现问题，发现问题既然是好事，比最终上线用户体验更好。但是需求评审阶段就是让大家都周知该项目的业务需求流程以及项目的整个概览情况。
4、反思
1）多方人员协调同步信息的沟通。专业产品经理、UI、研发
举例子，与专业产品经理，以为他们给出的测评题、测评报告都是具备专业性质的。反之他们给出的测评题都是含糊不清，没有业务逻辑在里面。针对类似处理的方式，我的想法，我们需要让专业产品经理了解业务需求，让他们参与需求评审中，测评题的业务逻辑反之推理出测评报告。｛测评报告也是具有专业性质的 ｝
2）产品的业务逻辑线，业务逻辑本身就是产品的核心。如何在确定原型设计中，就将业务逻辑旅顺，需要产品人在设计之初就反复推敲逻辑，并应用不同的业务用户场景。业务逻辑想透再开需求评审，需求评审过后，还有个一个PRD交互稿微调的时间差需要预留出来。产品在经过微调后，大业务方向线就不会再变更了。除去一些微调的，每次变更必将通知项目组所有成员。好多都是信息不沟通所造成的。
3）UI设计稿再变更原型的情况。分2个方面，1个是UI优化、美化。另外1个是业务流程变更，业务流程变更是不允许的。业务流程在设计之初，就已经设定好项目的的总体流程，这是大家都已经评审通过的，是不允许变更的。
