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

2023/09/23 10:59
阅读数 22


每周总得有点思考。

需求做完了,却没产生什么价值?

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

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

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

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

所以,这个需求能不能不做?

问题出在哪里?

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

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

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

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

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

  • 没有事先定义业务价值,功能上线后不知道有什么用,或者根本就没用

  • 定义了业务价值,但是功能上线后无法量化价值

  • 定义了量化指标,但是上线后并没有达成预期的优化目标

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

怎么办呢?

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

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

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

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

  • 必须有量化价值(上下左右对齐的有价值的,而不是无意义的)

  • 必须有user case

  • 进入标准DOD流程前,必须先有可量化指标,评估当前情况

  • 研发交付标准DOD流程

  • 功能交付后(标准DOD完成),必须进行 推广、价值验证、回顾和复盘。

这个需求能不能不做?

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

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



往期热门笔记合集推荐:


原创:阿丸笔记(微信公众号:aone_note),欢迎 分享,转载请保留出处。

没有留言功能的悲伤,扫描下方二维码「加我」聊些有的没的吧~

                                                                              觉得不错,就点个  再看 吧👇



本文分享自微信公众号 - 阿丸笔记(aone_note)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部