【周末瞎想】這個需求能不能不做?
每周總得有點思考。
需求做完了，卻沒產(chǎn)生什么價值？
最近發(fā)現(xiàn)個別需求上線后，負責同學無法明確量化需求帶來的業(yè)務價值。
需求開發(fā)前，似乎業(yè)務同學提了很多明確價值點，比如 穩(wěn)定性提升、減少開銷 等，“看起來”很有價值。
但是功能真正上線了，結(jié)果發(fā)現(xiàn)并無法衡量提升了多少。
這個時候就尷尬了，投入了一段時間和不少開發(fā)資源，結(jié)果上線的功能無法量化價值，ROI近似為0。
所以，這個需求能不能不做？
問題出在哪里？
在敏捷迭代和項目管理中，我們常常會提到DoD(Definition of Done)基于“隨時可向用戶發(fā)布”的目標制定衡量團隊工作是否已完成的標準，是Agile Team的共識。
一般涉及到的是 產(chǎn)品功能交付、需求交付 維度的流程，比如一個常規(guī)的需求交付，需要包含 產(chǎn)品文檔、交互文檔、技術(shù)設計&開發(fā)、測試、上線等步驟。后面我們稱之為「標準DOD」。
嚴格遵守標準DOD，可以給我們帶來標準化、高質(zhì)量的交付。
但是，對于基礎架構(gòu)團隊來說，僅僅只是使用標準DOD來進行研發(fā)交付，會存在一些困擾。
高質(zhì)量交付后呢，帶來什么價值？列舉幾個比較常見的問題：
-
沒有事先定義業(yè)務價值，功能上線后不知道有什么用，或者根本就沒用
-
定義了業(yè)務價值，但是功能上線后無法量化價值
-
定義了量化指標，但是上線后并沒有達成預期的優(yōu)化目標
因此，缺少前置量化評估需求價值的環(huán)節(jié)，是出現(xiàn)這些問題的根本原因。
怎么辦呢？
因此，我們嘗試探索，是否存在更加適合我們的「廣義DOD」，來踐行 業(yè)務價值導向 與 客戶成功。
為了解決上述問題，我們對標準DOD做了擴展，定義了「廣義DOD」：
在標準DOD的前后，延伸了對需求價值的定義、客戶實踐推廣、需求價值確認、回顧和提升點 等環(huán)節(jié)。以 客戶需求價值定義 為起點，以 客戶實踐案例 和 需求價值驗證 為關鍵里程碑，
與標準DOD類似，廣義DoD同樣需要DOD清單，確保團隊按照正確的方法做事：
-
必須有量化價值（上下左右對齊的有價值的，而不是無意義的）
-
必須有user case
-
進入標準DOD流程前，必須先有可量化指標，評估當前情況
-
研發(fā)交付標準DOD流程
-
功能交付后（標準DOD完成），必須進行 推廣、價值驗證、回顧和復盤。
這個需求能不能不做？
結(jié)合「廣義DOD」的研發(fā)流程，未來我們接到一個新的需求后，必須先完成業(yè)務價值的量化評估，如果無法量化，或者量化后的價值比較小，原則上不考慮排入迭代。
反之，如果量化后的業(yè)務價值非常大，則可以高優(yōu)先級安排迭代交付。
往期熱門筆記合集推薦：
原創(chuàng)：阿丸筆記（微信公眾號：aone_note），歡迎 分享 ，轉(zhuǎn)載請保留出處。
沒有留言功能的悲傷，掃描下方二維碼「加我」聊些有的沒的吧～
覺得不錯，就點個 再看 吧??