每周总得有点思考。
需求做完了，却没产生什么价值？
最近发现个别需求上线后，负责同学无法明确量化需求带来的业务价值。
需求开发前，似乎业务同学提了很多明确价值点，比如 稳定性提升、减少开销 等，“看起来”很有价值。
但是功能真正上线了，结果发现并无法衡量提升了多少。
这个时候就尴尬了，投入了一段时间和不少开发资源，结果上线的功能无法量化价值，ROI近似为0。
所以，这个需求能不能不做？
问题出在哪里？
在敏捷迭代和项目管理中，我们常常会提到DoD(Definition of Done)基于“随时可向用户发布”的目标制定衡量团队工作是否已完成的标准，是Agile Team的共识。
一般涉及到的是 产品功能交付、需求交付 维度的流程，比如一个常规的需求交付，需要包含 产品文档、交互文档、技术设计&开发、测试、上线等步骤。后面我们称之为「标准DOD」。
严格遵守标准DOD，可以给我们带来标准化、高质量的交付。
但是，对于基础架构团队来说，仅仅只是使用标准DOD来进行研发交付，会存在一些困扰。
高质量交付后呢，带来什么价值？列举几个比较常见的问题：
- 没有事先定义业务价值，功能上线后不知道有什么用，或者根本就没用
- 定义了业务价值，但是功能上线后无法量化价值
- 定义了量化指标，但是上线后并没有达成预期的优化目标
因此，缺少前置量化评估需求价值的环节，是出现这些问题的根本原因。
怎么办呢？
因此，我们尝试探索，是否存在更加适合我们的「广义DOD」，来践行 业务价值导向 与 客户成功。
为了解决上述问题，我们对标准DOD做了扩展，定义了「广义DOD」：
在标准DOD的前后，延伸了对需求价值的定义、客户实践推广、需求价值确认、回顾和提升点 等环节。以 客户需求价值定义 为起点，以 客户实践案例 和 需求价值验证 为关键里程碑，
与标准DOD类似，广义DoD同样需要DOD清单，确保团队按照正确的方法做事：
- 必须有量化价值（上下左右对齐的有价值的，而不是无意义的）
- 必须有user case
- 进入标准DOD流程前，必须先有可量化指标，评估当前情况
- 研发交付标准DOD流程
- 功能交付后（标准DOD完成），必须进行 推广、价值验证、回顾和复盘。
这个需求能不能不做？
结合「广义DOD」的研发流程，未来我们接到一个新的需求后，必须先完成业务价值的量化评估，如果无法量化，或者量化后的价值比较小，原则上不考虑排入迭代。
反之，如果量化后的业务价值非常大，则可以高优先级安排迭代交付。
往期热门笔记合集推荐：
