本文將以有贊零售產品為例，介紹需求全生命周期的管理實踐，包括：商家的原始需求收集、產品設計與評審、研發(fā)的需求實現(xiàn)、上線后運營反饋、新一輪迭代優(yōu)化，構成了需求全生命周期的反饋回路。

在整個過程中，我們是如何對需求、項目、任務、缺陷、線上質量和功能優(yōu)化進行有效組織和管理的呢？讓我們一起揭開這個神秘面紗吧！

為了讓產品和研發(fā)過程更可控，讓彼此間協(xié)作更順暢，讓共同努力的結果更靠譜，我們設計了“1 個項目 +3 塊看板”模型。

“1 個項目”指有贊零售事業(yè)部只使用 1 個 JIRA 項目管理產品需求、技術需求、技術任務和測試 Bug），“3 塊看板”指：

• 給產品經理提供的“有贊零售產品需求看板”；

• 給研發(fā)過程提供的“有贊零售項目看板”；

• 給測試階段提供的“有贊零售 Bug 看板”

其中，“有贊零售項目看板”是 Scrum Board，而另外兩塊看板是 Kanban Board，它們通過不同的 JIRA 過濾器來實現(xiàn)。由于我們需要對產品需求和技術需求做拆分、估算和迭代規(guī)劃，所以“有贊零售項目看板”設計成 Scrum Board，該看板提供了兩種視圖：整體視圖和局部視圖，我們可以通過該看板的活躍 Sprint 視圖查看當前正在進行中的所有 Sprints（包括項目迭代和日常迭代）的需求和技術任務，同時也支持單個 Sprint 查看視圖。在正式進入“1+3 模型”之前，讓我們先從需求的源頭入手，介紹下商家原始需求的管理方式。

商家反饋的需求主要來源于客滿、商家服務、渠道銷售、用戶研究同學和 BBS 需求帖，BBS 需求帖由產品同學定期處理和反饋，而其他來源的需求會統(tǒng)一提交到共同的 JIRA 看板“客戶服務需求反饋／同步看板”中。

該看板提供多種視角查看各產品線的需求，同時，提供“用戶體驗問題”和“大客戶需求”的專屬泳道。每張需求卡片上會顯示其產品名稱、預處理結果和預計發(fā)布日期。商家反饋的需求為原始需求，無法直接用于生產，由產品經理來跟進處理，所以，該看板不需要技術同學介入。

選擇 JIRA 看板工具做管理的好處是：

1. 通過搜索查詢類似需求是否已被提交，以減少不同來源需求的重復提交；

2. 能捕捉需求經過的每個過程；

3. 郵件通知機制，需求卡片的更新（如：備注、狀態(tài)更新等）會以郵件形式通知到報告人和關注人等需求干系人。

產品經理過濾出與自己相關的需求，如果是新提交的需求，那么會對其進行預處理：

1. 判斷價值很低或肯定不會做的需求，直接將需求卡片拖動到“已完成”列，選擇解決結果“不會被修復”，并備注原因；

2. 判斷有一定價值或需要再分析的需求，將需求卡片拖動到“產品需求池”列，在彈窗中選擇“預處理結果”為需要再分析、可以很快開始或已規(guī)劃到項目。

我們會以報表形式展示多種統(tǒng)計結果，用于管理決策，比如：“產品需求池”列中需求的預處理結果和不同產品線的需求累積流圖。接下來，我們介紹下“已規(guī)劃到項目”中的需求管理方式，該類需求來源于“客戶服務需求反饋／同步看板”，經過產品同學設計后，以“功能”粒度在各事業(yè)部的產品需求看板中以“Story”類型來管理。

產品經理使用產品 PRD 文檔將需求輸出給研發(fā)同學，產品 PRD 的標準模板可在 Confluence 的“創(chuàng)建”右側的“…”中找到。該模板主要包括：需求的基本信息（作者、優(yōu)先級、來源和期望上線時間）、需求的背景、簡介、目標、總體需求（功能列表、業(yè)務流程和業(yè)務規(guī)則）、原型和視覺稿、詳細需求（各功能的詳細說明）、數(shù)據(jù)需求、其他說明和風險。

“總體需求→功能列表”會羅列出需求所涉及的所有產品功能點，這種“將大需求拆分成功能點”的需求管理方式叫需求條目化。通過條目化的功能列表可以讓需求干系人簡要了解到要做的功能，同時，細粒度的功能清單也方便需求在研發(fā)階段的管理。

我們使用 JIRA 來管理產品功能列表，需求根據(jù)大小可以分為兩類：a）史詩級需求、大需求或產品特性使用 JIRA 問題類型 Epic（史詩）；b）產品功能點、用戶故事或日常需求使用 Story（故事），它們使用如下統(tǒng)一的 JIRA 工作流。該工作流看起來有點復雜，其實它主要由兩個階段組成：a）產品階段：需求池【Open】 → 設計中 【Product-In Design】→ 評審中【In Review】 → 待開發(fā)【Product-Waiting for Development】 ···> b）研發(fā)階段：···> 開發(fā)中【In Progress】 → 已完成【Resolved|Closed】。

為了讓需求的過程管理更直觀，我們使用“產品需求看板”來管理功能 Story（如下圖所示）。一個 Story 既可以表示產品 PRD 中的一個功能，也可以表示一個線上待優(yōu)化的功能。前者將規(guī)劃到某個項目中完成，而后者將規(guī)劃到日常需求周迭代中完成。

由于有贊零售產品包含了多條業(yè)務線，我們使用 JIRA“模塊”來區(qū)分來自不同業(yè)務線的 Story，跨多個業(yè)務線的 Story 需要標記為多個模塊，通過“業(yè)務模塊快速過濾器”查看僅該模塊的需求。需求看板上每張 Story 卡片可以顯示 Story 的描述信息、所屬史詩名和被規(guī)劃到的發(fā)布版本名。

我們通常直接從 PRD 文檔中批量創(chuàng)建產品功能點 Story 到產品需求看板中，方法是：在功能列表中點擊三次某個功能名稱，會彈出 2 個“快捷菜單”，右側那個為“創(chuàng)建 JIRA 問題”菜單（如下圖所示） → 點擊“Create JIRA issue'后進入”創(chuàng)建問題“彈框 → 選擇“從表格創(chuàng)建多個問題” → 選擇相應項目和問題類型：Story → 選擇“總結”（JIRA 主題）為：功能列表的“名稱”列，描述（JIRA 描述）為：功能列表的“說明”列 → 點擊“創(chuàng)建”即可完成“從 PRD 文檔批量創(chuàng)建產品需求到 JIRA”。

在每個功能名稱右側插入了“JIRA 鏈接及狀態(tài)”，以后 Story 狀態(tài)的任何更新都會在產品 PRD 中同步更新，JIRA 中也自動添加了產品 PRD 的鏈接，實現(xiàn)了 JIRA 與 Confluence 之間的數(shù)據(jù)互通。我們在“有贊零售產品需求看板”的“需求池”列將顯示這 2 個 Stories。

在每個月月末，有贊會召開月度規(guī)劃會，主要由各產品線的產品負責人和技術負責人參加，旨在就需要下一個月做的需求的優(yōu)先級順序達成一致。

當產品 PRD 文檔通過了產品內部的方案評審后，產品經理會給研發(fā)同學做產品需求宣講。待 UI 設計和交互稿完成后，設計師還會給產品經理和前端同學做 UI 設計評審，以確保傳遞的信息有效性和完整性，避免后期產生不必要的溝通浪費。

像 PHP 轉 Java 這種技術改造型需求，不會對線上產品功能產生影響，我們簡稱為“技術需求”。為了與功能型需求 Story 區(qū)分開，我們使用 JIRA 問題類型 Feature 表示技術型需求（注：官方對 Feature 的解釋為產品特性，也屬于功能型需求）。其工作流比較簡單：待辦【To Do】|【Reopened】→ 進行中（開發(fā) / 測試中）【In Progress】→ 已完成【Resolved】|【Closed】（掛起【On Hold】暫時沒使用），如下圖所示：

為了簡化研發(fā)同學的使用姿勢，技術需求的管理與產品需求使用同樣的數(shù)據(jù)存儲結構，即：Epic → Feature → Technical Task（產品需求為：Epic → Story → Technical Task）。創(chuàng)建好的技術需求 Feature 會直接顯示在 Scrum Board 的 Backlog 中，而創(chuàng)建好的產品需求 Story 必須流轉到研發(fā)階段（即：待開發(fā)或之后的狀態(tài)）才會顯示在 Backlog 中。

我們在系統(tǒng)分析階段會使用統(tǒng)一的技術方案模板進行技術評審，包括不同系統(tǒng)之間的依賴分析、業(yè)務流程分析和系統(tǒng)接口約定等。

技術任務的工作流與技術需求的工作流類似，不管是產品需求（包括產品日常需求），還是技術需求（包括技術優(yōu)化）在開發(fā)前將被拆分為可分配給單個研發(fā)同學執(zhí)行的技術任務，且每個任務的原預估時間為 8H 左右（最多不超過 16H），技術任務的類型包括前端、后端、數(shù)據(jù)、Android、iOS、小程序、開發(fā)自測、用例編寫和用例執(zhí)行等。

至此，我們形成了需求拆分的三層模型，即：史詩 Epic->功能 Story/ 技術需求 Feature → 技術任務 Technical Task。產品經理只需關注業(yè)務需求 Story，而研發(fā)同學除了要關注 Story，還需要關注技術需求 Feature。我們配置了 Backlog 的卡片布局，顯示了三個擴展字段：Σ 原預估時間、Σ 進度和到期日，可以很容易看到需求的預估工作量、當前完成進度以及完成日期，如下圖的項目看板 Backlog 所示。

當?shù)?Sprint 啟動后，我們可以在項目看板的“活躍 Sprint”中跟蹤技術任務的執(zhí)行，常用操作有：a）通過拖動任務卡片來更新狀態(tài)；b）給被阻塞的任務卡片增加 Flag（右鍵點擊卡片→增加 flag），提醒項目成員注意。待風險解除后再刪除標識；c）將任務卡片分配給自己，選中卡片，然后點擊鍵盤”I”鍵；d）每日登記工作日志或在將任務拖到“已完成'列時記錄工作日志。

我們使用 Sprint 燃盡圖和定期站會對 Sprint 整體進度進行評估和風險識別，在實踐中，我們需要了解到每個人在該 Sprint 中的進度情況。為了滿足這個需求，我們設計了 Sprint Task Completion by Assignee 報表，展示每個人的原預估時間、實際花費時間、任務的完成率和時間的消耗率等信息。

在 Sprint 完成后，我們會使用“海星圖”、“KISS”或“做的不錯的／應該做的更好的”方法進行復盤，復盤的改進措施會被錄入到“有贊零售復盤 Action 跟進看板”，每個 Action 必須是可執(zhí)行的具體措施，且有一個主要負責人（JIRA 經辦人）和完成日期（JIRA 到期日）。

迭代 Sprint 測試階段發(fā)現(xiàn)的 Bug 提交到“Bug 看板”中，其工作流與技術需求 / 任務的工作流類似。但是，Bug 看板的列名與活躍沖刺看板的列名差別較大，主要是：增加了“測試中”（Resolved）和“掛起中“（On Hold）。當 Bug 暫時不需要修復時，我們可以將其拖到“掛起中”列，掛起的時候需要在 JIRA 備注中說明原因。

提交測試 Bug 的彈窗會提示報告人按“Bug 描述標準模板”（包括：重新步驟、實際結果、期待結果和抓包數(shù)據(jù)）來填寫，此外，測試 Bug 必須關聯(lián)到 JIRA 模塊、影響版本和解決版本。這樣，我們將 Story、Feature 和 Bug 都關聯(lián)到了 JIRA 版本后，就可以在發(fā)布版本中按照“版本”查看已發(fā)布、未發(fā)布和歸檔版本信息。我們可以根據(jù)“模塊”和“經辦人”來統(tǒng)計某個版本中遺留的測試 Bug 存量分布，如下圖所示：

我們不僅要管理研發(fā)過程中的測試 Bug，還要管理需求上線后運營階段產生的問題和故障。線上問題一般是對業(yè)務影響很小的缺陷、任務和查詢，而線上故障指提供給客戶使用的 IT 服務全部或部分不可用，包括服務性能的降低（詳見：“有贊 coder”公眾號 2016 年 11 月的技術博客《有贊線上故障管理實踐》）。

由于兩者的嚴重程度和影響面不一樣，所以我們使用不同的流程進行管理，當前線上問題處理流程如下圖所示，使用 JIRA 看板來輔助流程的管理（流程圖中的紅色為 JIRA 狀態(tài)）。依然針對線上問題的跟進，我們每天都會在產品和研發(fā)群發(fā)布“線上問題日報”，以報表形式展示每個業(yè)務團隊的問題存量，以及這些問題的持續(xù)時長。

在新功能上線后，商家會將使用過程中遇到的問題和建議反饋給我們，比如：對功能的改進建議或相關的新需求。這些需求會被提交到“客戶服務需求反饋 / 同步看板”中，有價值的小需求會在各事業(yè)部內部以日常迭代方式快速反饋給客戶，而有價值的新需求一般會項目制方式處理。不管采用哪種方式，有贊零售事業(yè)部會以功能 Story 方式在零售產品需求看板中管理，待產品方案設計完成并通過評審后，進入研發(fā)階段，然后以 JIRA 迭代 Sprint 方式來管理整個研發(fā)過程。

日常需求周迭代 Sprint 周期固定，從周五啟動到下周四晚上結束（如下圖所示），未完成的產品或技術需求會被移至 Backlog 或下周 Sprint 中。而以項目制方式管理的 Sprint 的周期不固定，項目排期排到什么時候，Sprint 就到什么時候結束，還可能存在延期情況。

有的事業(yè)部或產品線使用獨立的事業(yè)部日常需求池（JIRA Kanban Board）中管理日常需求，產品負責人會定期拉上需求方產品經理和相關研發(fā)同學一起對待辦需求列表進行優(yōu)先級排序，選擇出最有價值的需求作為下一階段的目標，這樣可以很好地增進上下游之間的協(xié)作關系。

任何新流程的推行都會遇到很多阻礙，從 2016 年下半年將 JIRA 系統(tǒng)導入有贊零售項目以來，我一直在努力引導大家按規(guī)范流程來執(zhí)行，但是又不適合強推，比如：對實際花費時間的登記，在任務跟進過程中，只能靠經常提醒大家。當采集了一些項目過程數(shù)據(jù)后，我會使用 EazyBI 工具制作各種數(shù)據(jù)報表，當大家對數(shù)據(jù)報表有感覺后，他們對流程執(zhí)行的配合程度也會提高，比如：統(tǒng)計某個 Sprint 的測試 Bug 存量，經常公開同步這個報表，可以有效促使開發(fā)同學更新 JIRA 狀態(tài)。

另外，我們還可以借助“下游拉動上游”之力來推動流程的落地，比如：在測試 Bug 看板中，只有開發(fā)同學修復了 Bug 后且更新了 JIRA 狀態(tài)為 Resolved 才能到“測試中”列，這時測試同學才會繼續(xù)驗收是否已修復，測試同學也會提醒開發(fā)同學修復好的 Bug 要及時更新狀態(tài)，否則他們不會驗收。我們要記?。喝魏瘟鞒袒蚬ぞ叨疾皇峭昝赖?，適合當下才是最重要的。隨著業(yè)務要求的變化和團隊規(guī)模的擴張，這些流程需要與時俱進，團隊“涌現(xiàn)”出來的改進建議可能讓流程更貼近業(yè)務和貼近團隊所需，會讓管理成本更低。

“需求的全生命周期管理”是個很大的課題，本文僅介紹了有贊零售產品的一些實踐方法：

1. 使用統(tǒng)一的看板管理來自不同反饋渠道的商家原始需求；

2. 使用“1+3”模型管理產品需求條目化和研發(fā)過程；

3. 使用線上問題和故障流程管理需求發(fā)布后的線上運營質量；

4. 使用日常需求看板快速迭代商家反饋的功能優(yōu)化建議。

但是，我們仍存在很多需要改進的地方：

1. 從“需求收集完”到“產品開始設計”之間缺乏市場需求分析（輸出：MRD 文檔），前期對需求的價值評估不夠；

2. 需求發(fā)布前對市場、客滿和服務同學的信息同步或培訓不夠，降低了服務響應水平；

3. 需求發(fā)布后的線上運營數(shù)據(jù)分析不夠，無法有效評估需求的 ROI；

4. 有贊的業(yè)務敏捷性仍有提升空間，目前 1 個月內發(fā)布的需求占比僅 40% 左右。

此外，JIRA 無法滿足整個公司對項目集或項目的運營訴求，在使用 JIRA 和 Confluence 系統(tǒng)的同時，我們還在自主研發(fā)“有贊效率平臺”，目前對需求月度規(guī)劃會和項目制管理方式有很好的支撐。

該平臺的愿景是：賦能團隊，通過助力團隊協(xié)作來管理“產品全生命周期”，提升公司生產效率。2018 年有贊將“需求生命周期”提高到公司戰(zhàn)略高度，我所在的“研發(fā)效率”團隊目前還需要更多優(yōu)秀的小伙伴加入。

最后，非常感謝田瑩、酈斌、秦陽、白月月、廉恒睿和崔等有贊小伙伴對本文提供審核和支持！

備注：

1. JIRA Feature（特性）用作表示：相對于產品需求的“技術需求”，該用法不夠專業(yè)，實際含義指：產品特性，粒度要比 Story 大，比 Epic ??；

2. JIRA Sprint（沖刺）用作表示：一個獨立項目、一個大項目的多個迭代或一個日常需求周迭代等，為了達到某個 Sprint 目標，將與該目標相關的 Story 和 Feature 規(guī)劃到一個 Sprint 中；

3. JIRA Version 用作表示：從產品路線圖角度，需求的一次發(fā)布，每次發(fā)布會包含一到多個產品新功能或功能優(yōu)化及技術優(yōu)化，它與 JIRA Sprint 無直接關系，但是一個 Version 中的需求可能被放在多個不同的 Sprints 中完成；

4. 通常，我們將 JIRA Scrum Board 簡稱為敏捷看板，將 JIRA Kanban Board 簡稱為普通看板（無“規(guī)劃”特性）；

5. JIRA 看板的每列對應一到多個 JIRA 狀態(tài)，每一列都可以配置“在制品數(shù)量限制”（WIP），目前只有極少數(shù)團隊在使用 WIP；