2021-05-11 产品需求DOR产生过程

比如上次在需求宣讲会上（实例化需求分析会），我作为教练被邀请列席会议快结束时，

我提了两个问题：

问题1：产品同学不要说话，请开发同们讲一下，这次迭代的业务目标和价值是什么？

开发大部分人面面相觑，只有一个人大概讲清楚了上一个迭代的业务目标和价值。

:问题2：刚才在需求讨论过程中有人提出，有上线风险，假如真的完不成这么多需求，谁能说出哪些功能是我们必须保证完成的？

没有人能回答，只是说我们所有任务并行.....

以下是教练针对整个会议过程的观察和反馈：

一、 团队识别到上线风险

    教练识别到的风险因素：

     1.个别功能要根据工作量来定做不做，业务价值有待考量

     2.大部分开发不清楚迭代的业务价值和目标，所有功能并行开发（可能会有在制品浪费）

     3.没有人能回答，为保证冒烟测试通过，哪些功能必须第一时间可用（可能提测失败，返工浪费）

    团队要解决的问题：上线风险既然已经识别到，需要采取哪些措施来应对？

    实例化过程改进点：如何把业务价值和目标传达到团队所有成员?交付价值是核心，而不是功能模块

二、.教练识别风险：开发和产品解决方案不一致，例如，裁图功能做不做，什么时间做？代码为什么写死？航站楼定位方案 等等。

        团队要解决的问题：确定并统一最佳解决方案和验证方案

        实例化过程改进点：谁负责业务解决方案，谁负责技术解决方案，如何达成一致，如何验证？

三、.团队识别风险：新增和变更内容，开发不清楚在哪

        团队要解决的问题：明确变更位置和范围以及验证方案

        实例化过程改进点：如何方便开发、测试快速定位变更位置

四、教练识别风险：app前端和后台都可以操作数据，如何保证前后端数据一致性，开发已有解决方案，测试知道么？

        团队要解决的问题：确保已经识别的风险解决方案，被真证落实

        实例化过程改进点：缺少测试角色帮助识别风险

五、教练识别风险：存在“不知道再问”的需求，可能会导致沟通浪费

        团队要明确：是不确定性问题，还是需求过早澄清

        实例化过程：鼓励做什么细化什么。如果过早澄清会忘，一旦有变更，修改量大

六 、感觉开发比较着急结束需求会议，回去开工

会后组织小会产生DOR，作为需求会议检查列表