【周末瞎想】这个需求能不能不做？

需求做完了，却没产生什么价值？

最近发现个别需求上线后，负责同学无法明确量化需求带来的业务价值。

需求开发前，似乎业务同学提了很多明确价值点，比如 稳定性提升、减少开销 等，“看起来”很有价值。

但是功能真正上线了，结果发现并无法衡量提升了多少。

这个时候就尴尬了，投入了一段时间和不少开发资源，结果上线的功能无法量化价值，ROI近似为0。

所以，这个需求能不能不做？

问题出在哪里？

在敏捷迭代和项目管理中，我们常常会提到DoD(Definition of Done)基于“随时可向用户发布”的目标制定衡量团队工作是否已完成的标准，是Agile Team的共识。

一般涉及到的是 产品功能交付、需求交付 维度的流程，比如一个常规的需求交付，需要包含 产品文档、交互文档、技术设计&开发、测试、上线等步骤。后面我们称之为「标准DOD」。

严格遵守标准DOD，可以给我们带来标准化、高质量的交付。

但是，对于基础架构团队来说，仅仅只是使用标准DOD来进行研发交付，会存在一些困扰。

高质量交付后呢，带来什么价值？列举几个比较常见的问题：

• 没有事先定义业务价值，功能上线后不知道有什么用，或者根本就没用
• 定义了业务价值，但是功能上线后无法量化价值
• 定义了量化指标，但是上线后并没有达成预期的优化目标

因此，缺少前置量化评估需求价值的环节，是出现这些问题的根本原因。

怎么办呢？

因此，我们尝试探索，是否存在更加适合我们的「广义DOD」，来践行 业务价值导向 与 客户成功。

为了解决上述问题，我们对标准DOD做了扩展，定义了「广义DOD」：

在标准DOD的前后，延伸了对需求价值的定义、客户实践推广、需求价值确认、回顾和提升点 等环节。以 客户需求价值定义 为起点，以 客户实践案例 和 需求价值验证 为关键里程碑，

与标准DOD类似，广义DoD同样需要DOD清单，确保团队按照正确的方法做事：

• 必须有量化价值（上下左右对齐的有价值的，而不是无意义的）
• 必须有user case
• 进入标准DOD流程前，必须先有可量化指标，评估当前情况
• 研发交付标准DOD流程
• 功能交付后（标准DOD完成），必须进行 推广、价值验证、回顾和复盘。

这个需求能不能不做？

结合「广义DOD」的研发流程，未来我们接到一个新的需求后，必须先完成业务价值的量化评估，如果无法量化，或者量化后的价值比较小，原则上不考虑排入迭代。

反之，如果量化后的业务价值非常大，则可以高优先级安排迭代交付。

往期热门笔记合集推荐：

• HBase原理与实战笔记合集
• MySQL实战笔记合集
• Canal/Otter源码与实战笔记合集
• Java实战技巧笔记合集

原创：阿丸笔记，欢迎 分享，转载请保留出处。