一.需求评审需求可行性评估关键确认阶段
（一）参会者
产品经理开发团队(前端/后端开发工程师)交互设计师和可视设计师测试工程师（二）筹备
原型图demoPRD （三）内容
逻辑是否合理(责任归属：产品经理)是否能用现有研发能力实现)责任归属：开发者（四）作用：需求的确认，最终方案的敲定
仔细调查
讨论技术上可能出现的详细问题； 可行性评估
评估目前研发团队能否实现或哪些部分难以实现； 达成协议
产品经理和研发人员共同达成的承诺。（五）可能遇到的问题
功能相似
即使现在的需求和以前的某个需求使用路径完全不同，但是在应用场景上高度相似的话，研发人员会觉得重复，对于重复做同样的事情的合作度自然不高。 需求过剩
通常，产品经理管理一组项目日程表(进度看板)，这些日程表用于记录当前正在进行、正在计划和正在计划的项目。 如果已经有很多项目通过审核进入排期，可以由研发团队消化这些需求后再组织新的需求审核。 没有解决实质性问题
在随后的详细审查过程中，如果研发人员发现你的设计没有实质性地解决需要解决的问题，自然会给他们人为地提出更合理的设计方案。 技术的实现很难
虽说不能实现，但也可以选择其他简单的方案。（六）雷点
准备不充分
材料齐了吗？ 文档质量合格吗？ 太妥协了
过度变更需求，忽视截断需求的检验标准
确定验收标准很重要二、用户体验设计(User Experience Design )（一）交互设计师（UE）
改善用户体验
简化操作流程分层结构动态效果设计（二）视觉设计师（UI）
为用户制作静态设计图
（三）沟通
重视背景介绍
什么，为什么，怎么抛弃技术语言
通过在行动层进行说明，引用场景的实例（四）修改流程：不影响完整性及安全性为前提
过程太长了
在考虑需求是否符合使用场景、逻辑是否正确时，不可避免地要将业务流程设计得很长； 通过对长流程进行分层、分类汇总，并丢弃部分操作节点来解决。 多分支过程
通过集约设计解决。 奇怪的潮流
用主流设计解决。 三、技术审查前后端的研发人员在正式开始开发前的重要准备阶段
可能出现的问题：
不关注技术评审中涉及的项目具体实施细节，不了解基础技术逻辑4、项目经理(PMO )区别：
产品经理关注的焦点：
需求的实现(重新审视需求后，项目如何实现) ) )。
预测和在线时间项目经理关注点：
整个进程的进展情况(里程碑)
阶段性报告(多个项目)五、按时发布日常报告
维护一个项目进度看板，注明所有计划完成的项目、相关说明、参与者、人员消耗、计划完成时间等。 KPI绑定
与研发人员同步制定相同的KPI指标，确定预定完成的任务和详细的参与者和在线时间。