比如上次在需求宣讲会上（实例化需求分析会），我作为教练被邀请列席会议快结束时，
我提了两个问题：
问题1：产品同学不要说话，请开发同们讲一下，这次迭代的业务目标和价值是什么？
开发大部分人面面相觑，只有一个人大概讲清楚了上一个迭代的业务目标和价值。
:问题2：刚才在需求讨论过程中有人提出，有上线风险，假如真的完不成这么多需求，谁能说出哪些功能是我们必须保证完成的？
没有人能回答，只是说我们所有任务并行.....
以下是教练针对整个会议过程的观察和反馈：
一、 团队识别到上线风险
教练识别到的风险因素：
1.个别功能要根据工作量来定做不做，业务价值有待考量
2.大部分开发不清楚迭代的业务价值和目标，所有功能并行开发（可能会有在制品浪费）
3.没有人能回答，为保证冒烟测试通过，哪些功能必须第一时间可用（可能提测失败，返工浪费）
团队要解决的问题：上线风险既然已经识别到，需要采取哪些措施来应对？
实例化过程改进点：如何把业务价值和目标传达到团队所有成员?交付价值是核心，而不是功能模块
二、.教练识别风险：开发和产品解决方案不一致，例如，裁图功能做不做，什么时间做？代码为什么写死？航站楼定位方案 等等。
团队要解决的问题：确定并统一最佳解决方案和验证方案
实例化过程改进点：谁负责业务解决方案，谁负责技术解决方案，如何达成一致，如何验证？
三、.团队识别风险：新增和变更内容，开发不清楚在哪
团队要解决的问题：明确变更位置和范围以及验证方案
实例化过程改进点：如何方便开发、测试快速定位变更位置
四、教练识别风险：app前端和后台都可以操作数据，如何保证前后端数据一致性，开发已有解决方案，测试知道么？
团队要解决的问题：确保已经识别的风险解决方案，被真证落实
实例化过程改进点：缺少测试角色帮助识别风险
五、教练识别风险：存在“不知道再问”的需求，可能会导致沟通浪费
团队要明确：是不确定性问题，还是需求过早澄清
实例化过程：鼓励做什么细化什么。如果过早澄清会忘，一旦有变更，修改量大
六 、感觉开发比较着急结束需求会议，回去开工
会后组织小会产生DOR，作为需求会议检查列表
