本文將以有贊零售產品爲例，介紹需求全生命週期的管理實踐，包括：商家的原始需求收集、產品設計與評審、研發的需求實現、上線後運營反饋、新一輪迭代優化，構成了需求全生命週期的反饋迴路。
在整個過程中，我們是如何對需求、項目、任務、缺陷、線上質量和功能優化進行有效組織和管理的呢？讓我們一起揭開這個神祕面紗吧！
“1 個項目 +3 塊看板”模型
爲了讓產品和研發過程更可控，讓彼此間協作更順暢，讓共同努力的結果更靠譜，我們設計了“1 個項目 +3 塊看板”模型。
“1 個項目”指有贊零售事業部只使用 1 個 JIRA 項目管理產品需求、技術需求、技術任務和測試 Bug），“3 塊看板”指：
- 給產品經理提供的“有贊零售產品需求看板”；
- 給研發過程提供的“有贊零售項目看板”；
- 給測試階段提供的“有贊零售 Bug 看板”
其中，“有贊零售項目看板”是 Scrum Board，而另外兩塊看板是 Kanban Board，它們通過不同的 JIRA 過濾器來實現。由於我們需要對產品需求和技術需求做拆分、估算和迭代規劃，所以“有贊零售項目看板”設計成 Scrum Board，該看板提供了兩種視圖：整體視圖和局部視圖，我們可以通過該看板的活躍 Sprint 視圖查看當前正在進行中的所有 Sprints（包括項目迭代和日常迭代）的需求和技術任務，同時也支持單個 Sprint 查看視圖。在正式進入“1+3 模型”之前，讓我們先從需求的源頭入手，介紹下商家原始需求的管理方式。
商家原始需求管理
商家反饋的需求主要來源於客滿、商家服務、渠道銷售、用戶研究同學和 BBS 需求帖，BBS 需求帖由產品同學定期處理和反饋，而其他來源的需求會統一提交到共同的 JIRA 看板“客戶服務需求反饋／同步看板”中。
該看板提供多種視角查看各產品線的需求，同時，提供“用戶體驗問題”和“大客戶需求”的專屬泳道。每張需求卡片上會顯示其產品名稱、預處理結果和預計發佈日期。商家反饋的需求爲原始需求，無法直接用於生產，由產品經理來跟進處理，所以，該看板不需要技術同學介入。
選擇 JIRA 看板工具做管理的好處是：
- 通過搜索查詢類似需求是否已被提交，以減少不同來源需求的重複提交；
- 能捕捉需求經過的每個過程；
- 郵件通知機制，需求卡片的更新（如：備註、狀態更新等）會以郵件形式通知到報告人和關注人等需求干係人。
產品經理過濾出與自己相關的需求，如果是新提交的需求，那麼會對其進行預處理：
- 判斷價值很低或肯定不會做的需求，直接將需求卡片拖動到“已完成”列，選擇解決結果“不會被修復”，並備註原因；
- 判斷有一定價值或需要再分析的需求，將需求卡片拖動到“產品需求池”列，在彈窗中選擇“預處理結果”爲需要再分析、可以很快開始或已規劃到項目。
我們會以報表形式展示多種統計結果，用於管理決策，比如：“產品需求池”列中需求的預處理結果和不同產品線的需求累積流圖。接下來，我們介紹下“已規劃到項目”中的需求管理方式，該類需求來源於“客戶服務需求反饋／同步看板”，經過產品同學設計後，以“功能”粒度在各事業部的產品需求看板中以“Story”類型來管理。
產品需求管理
產品經理使用產品 PRD 文檔將需求輸出給研發同學，產品 PRD 的標準模板可在 Confluence 的“創建”右側的“…”中找到。該模板主要包括：需求的基本信息（作者、優先級、來源和期望上線時間）、需求的背景、簡介、目標、總體需求（功能列表、業務流程和業務規則）、原型和視覺稿、詳細需求（各功能的詳細說明）、數據需求、其他說明和風險。
“總體需求→功能列表”會羅列出需求所涉及的所有產品功能點，這種“將大需求拆分成功能點”的需求管理方式叫需求條目化。通過條目化的功能列表可以讓需求干係人簡要瞭解到要做的功能，同時，細粒度的功能清單也方便需求在研發階段的管理。
我們使用 JIRA 來管理產品功能列表，需求根據大小可以分爲兩類：a）史詩級需求、大需求或產品特性使用 JIRA 問題類型 Epic（史詩）；b）產品功能點、用戶故事或日常需求使用 Story（故事），它們使用如下統一的 JIRA 工作流。該工作流看起來有點複雜，其實它主要由兩個階段組成：a）產品階段：需求池【Open】 → 設計中 【Product-In Design】→ 評審中【In Review】 → 待開發【Product-Waiting for Development】 ···> b）研發階段：···> 開發中【In Progress】 → 已完成【Resolved|Closed】。
爲了讓需求的過程管理更直觀，我們使用“產品需求看板”來管理功能 Story（如下圖所示）。一個 Story 既可以表示產品 PRD 中的一個功能，也可以表示一個線上待優化的功能。前者將規劃到某個項目中完成，而後者將規劃到日常需求周迭代中完成。
由於有贊零售產品包含了多條業務線，我們使用 JIRA“模塊”來區分來自不同業務線的 Story，跨多個業務線的 Story 需要標記爲多個模塊，通過“業務模塊快速過濾器”查看僅該模塊的需求。需求看板上每張 Story 卡片可以顯示 Story 的描述信息、所屬史詩名和被規劃到的發佈版本名。
我們通常直接從 PRD 文檔中批量創建產品功能點 Story 到產品需求看板中，方法是：在功能列表中點擊三次某個功能名稱，會彈出 2 個“快捷菜單”，右側那個爲“創建 JIRA 問題”菜單（如下圖所示） → 點擊“Create JIRA issue"後進入”創建問題“彈框 → 選擇“從表格創建多個問題” → 選擇相應項目和問題類型：Story → 選擇“總結”（JIRA 主題）爲：功能列表的“名稱”列，描述（JIRA 描述）爲：功能列表的“說明”列 → 點擊“創建”即可完成“從 PRD 文檔批量創建產品需求到 JIRA”。
在每個功能名稱右側插入了“JIRA 鏈接及狀態”，以後 Story 狀態的任何更新都會在產品 PRD 中同步更新，JIRA 中也自動添加了產品 PRD 的鏈接，實現了 JIRA 與 Confluence 之間的數據互通。我們在“有贊零售產品需求看板”的“需求池”列將顯示這 2 個 Stories。
在每個月月末，有贊會召開月度規劃會，主要由各產品線的產品負責人和技術負責人蔘加，旨在就需要下一個月做的需求的優先級順序達成一致。
當產品 PRD 文檔通過了產品內部的方案評審後，產品經理會給研發同學做產品需求宣講。待 UI 設計和交互稿完成後，設計師還會給產品經理和前端同學做 UI 設計評審，以確保傳遞的信息有效性和完整性，避免後期產生不必要的溝通浪費。
技術需求管理
像 PHP 轉 Java 這種技術改造型需求，不會對線上產品功能產生影響，我們簡稱爲“技術需求”。爲了與功能型需求 Story 區分開，我們使用 JIRA 問題類型 Feature 表示技術型需求（注：官方對 Feature 的解釋爲產品特性，也屬於功能型需求）。其工作流比較簡單：待辦【To Do】|【Reopened】→ 進行中（開發 / 測試中）【In Progress】→ 已完成【Resolved】|【Closed】（掛起【On Hold】暫時沒使用），如下圖所示：
爲了簡化研發同學的使用姿勢，技術需求的管理與產品需求使用同樣的數據存儲結構，即：Epic → Feature → Technical Task（產品需求爲：Epic → Story → Technical Task）。創建好的技術需求 Feature 會直接顯示在 Scrum Board 的 Backlog 中，而創建好的產品需求 Story 必須流轉到研發階段（即：待開發或之後的狀態）纔會顯示在 Backlog 中。
我們在系統分析階段會使用統一的技術方案模板進行技術評審，包括不同系統之間的依賴分析、業務流程分析和系統接口約定等。
技術任務管理
技術任務的工作流與技術需求的工作流類似，不管是產品需求（包括產品日常需求），還是技術需求（包括技術優化）在開發前將被拆分爲可分配給單個研發同學執行的技術任務，且每個任務的原預估時間爲 8H 左右（最多不超過 16H），技術任務的類型包括前端、後端、數據、Android、iOS、小程序、開發自測、用例編寫和用例執行等。
至此，我們形成了需求拆分的三層模型，即：史詩 Epic->功能 Story/ 技術需求 Feature → 技術任務 Technical Task。產品經理只需關注業務需求 Story，而研發同學除了要關注 Story，還需要關注技術需求 Feature。我們配置了 Backlog 的卡片佈局，顯示了三個擴展字段：Σ 原預估時間、Σ 進度和到期日，可以很容易看到需求的預估工作量、當前完成進度以及完成日期，如下圖的項目看板 Backlog 所示。
當迭代 Sprint 啓動後，我們可以在項目看板的“活躍 Sprint”中跟蹤技術任務的執行，常用操作有：a）通過拖動任務卡片來更新狀態；b）給被阻塞的任務卡片增加 Flag（右鍵點擊卡片→增加 flag），提醒項目成員注意。待風險解除後再刪除標識；c）將任務卡片分配給自己，選中卡片，然後點擊鍵盤”I”鍵；d）每日登記工作日誌或在將任務拖到“已完成"列時記錄工作日誌。
我們使用 Sprint 燃盡圖和定期站會對 Sprint 整體進度進行評估和風險識別，在實踐中，我們需要瞭解到每個人在該 Sprint 中的進度情況。爲了滿足這個需求，我們設計了 Sprint Task Completion by Assignee 報表，展示每個人的原預估時間、實際花費時間、任務的完成率和時間的消耗率等信息。
在 Sprint 完成後，我們會使用“海星圖”、“KISS”或“做的不錯的／應該做的更好的”方法進行復盤，覆盤的改進措施會被錄入到“有贊零售覆盤 Action 跟進看板”，每個 Action 必須是可執行的具體措施，且有一個主要負責人（JIRA 經辦人）和完成日期（JIRA 到期日）。
測試 Bug 管理
迭代 Sprint 測試階段發現的 Bug 提交到“Bug 看板”中，其工作流與技術需求 / 任務的工作流類似。但是，Bug 看板的列名與活躍衝刺看板的列名差別較大，主要是：增加了“測試中”（Resolved）和“掛起中“（On Hold）。當 Bug 暫時不需要修復時，我們可以將其拖到“掛起中”列，掛起的時候需要在 JIRA 備註中說明原因。
提交測試 Bug 的彈窗會提示報告人按“Bug 描述標準模板”（包括：重新步驟、實際結果、期待結果和抓包數據）來填寫，此外，測試 Bug 必須關聯到 JIRA 模塊、影響版本和解決版本。這樣，我們將 Story、Feature 和 Bug 都關聯到了 JIRA 版本後，就可以在發佈版本中按照“版本”查看已發佈、未發佈和歸檔版本信息。我們可以根據“模塊”和“經辦人”來統計某個版本中遺留的測試 Bug 存量分佈，如下圖所示：
線上問題與故障管理
我們不僅要管理研發過程中的測試 Bug，還要管理需求上線後運營階段產生的問題和故障。線上問題一般是對業務影響很小的缺陷、任務和查詢，而線上故障指提供給客戶使用的 IT 服務全部或部分不可用，包括服務性能的降低（詳見：“有贊 coder”公衆號 2016 年 11 月的技術博客《有贊線上故障管理實踐》）。
由於兩者的嚴重程度和影響面不一樣，所以我們使用不同的流程進行管理，當前線上問題處理流程如下圖所示，使用 JIRA 看板來輔助流程的管理（流程圖中的紅色爲 JIRA 狀態）。依然針對線上問題的跟進，我們每天都會在產品和研發羣發佈“線上問題日報”，以報表形式展示每個業務團隊的問題存量，以及這些問題的持續時長。
線上功能改進迭代
在新功能上線後，商家會將使用過程中遇到的問題和建議反饋給我們，比如：對功能的改進建議或相關的新需求。這些需求會被提交到“客戶服務需求反饋 / 同步看板”中，有價值的小需求會在各事業部內部以日常迭代方式快速反饋給客戶，而有價值的新需求一般會項目制方式處理。不管採用哪種方式，有贊零售事業部會以功能 Story 方式在零售產品需求看板中管理，待產品方案設計完成並通過評審後，進入研發階段，然後以 JIRA 迭代 Sprint 方式來管理整個研發過程。
日常需求周迭代 Sprint 週期固定，從週五啓動到下週四晚上結束（如下圖所示），未完成的產品或技術需求會被移至 Backlog 或下週 Sprint 中。而以項目制方式管理的 Sprint 的週期不固定，項目排期排到什麼時候，Sprint 就到什麼時候結束，還可能存在延期情況。
有的事業部或產品線使用獨立的事業部日常需求池（JIRA Kanban Board）中管理日常需求，產品負責人會定期拉上需求方產品經理和相關研發同學一起對待辦需求列表進行優先級排序，選擇出最有價值的需求作爲下一階段的目標，這樣可以很好地增進上下游之間的協作關係。
遇到的困難與對策
任何新流程的推行都會遇到很多阻礙，從 2016 年下半年將 JIRA 系統導入有贊零售項目以來，我一直在努力引導大家按規範流程來執行，但是又不適合強推，比如：對實際花費時間的登記，在任務跟進過程中，只能靠經常提醒大家。當採集了一些項目過程數據後，我會使用 EazyBI 工具製作各種數據報表，當大家對數據報表有感覺後，他們對流程執行的配合程度也會提高，比如：統計某個 Sprint 的測試 Bug 存量，經常公開同步這個報表，可以有效促使開發同學更新 JIRA 狀態。
另外，我們還可以藉助“下游拉動上游”之力來推動流程的落地，比如：在測試 Bug 看板中，只有開發同學修復了 Bug 後且更新了 JIRA 狀態爲 Resolved 才能到“測試中”列，這時測試同學纔會繼續驗收是否已修復，測試同學也會提醒開發同學修復好的 Bug 要及時更新狀態，否則他們不會驗收。我們要記住：任何流程或工具都不是完美的，適合當下纔是最重要的。隨着業務要求的變化和團隊規模的擴張，這些流程需要與時俱進，團隊“涌現”出來的改進建議可能讓流程更貼近業務和貼近團隊所需，會讓管理成本更低。
小結
“需求的全生命週期管理”是個很大的課題，本文僅介紹了有贊零售產品的一些實踐方法：
- 使用統一的看板管理來自不同反饋渠道的商家原始需求；
- 使用“1+3”模型管理產品需求條目化和研發過程；
- 使用線上問題和故障流程管理需求發佈後的線上運營質量；
- 使用日常需求看板快速迭代商家反饋的功能優化建議。
但是，我們仍存在很多需要改進的地方：
- 從“需求收集完”到“產品開始設計”之間缺乏市場需求分析（輸出：MRD 文檔），前期對需求的價值評估不夠；
- 需求發佈前對市場、客滿和服務同學的信息同步或培訓不夠，降低了服務響應水平；
- 需求發佈後的線上運營數據分析不夠，無法有效評估需求的 ROI；
- 有讚的業務敏捷性仍有提升空間，目前 1 個月內發佈的需求佔比僅 40% 左右。
此外，JIRA 無法滿足整個公司對項目集或項目的運營訴求，在使用 JIRA 和 Confluence 系統的同時，我們還在自主研發“有贊效率平臺”，目前對需求月度規劃會和項目制管理方式有很好的支撐。
該平臺的願景是：賦能團隊，通過助力團隊協作來管理“產品全生命週期”，提升公司生產效率。2018 年有贊將“需求生命週期”提高到公司戰略高度，我所在的“研發效率”團隊目前還需要更多優秀的小夥伴加入。
最後，非常感謝田瑩、酈斌、秦陽、白月月、廉恆睿和崔等有贊小夥伴對本文提供審覈和支持！
備註：
- JIRA Feature（特性）用作表示：相對於產品需求的“技術需求”，該用法不夠專業，實際含義指：產品特性，粒度要比 Story 大，比 Epic 小；
- JIRA Sprint（衝刺）用作表示：一個獨立項目、一個大項目的多個迭代或一個日常需求周迭代等，爲了達到某個 Sprint 目標，將與該目標相關的 Story 和 Feature 規劃到一個 Sprint 中；
- JIRA Version 用作表示：從產品路線圖角度，需求的一次發佈，每次發佈會包含一到多個產品新功能或功能優化及技術優化，它與 JIRA Sprint 無直接關係，但是一個 Version 中的需求可能被放在多個不同的 Sprints 中完成；
- 通常，我們將 JIRA Scrum Board 簡稱爲敏捷看板，將 JIRA Kanban Board 簡稱爲普通看板（無“規劃”特性）；
- JIRA 看板的每列對應一到多個 JIRA 狀態，每一列都可以配置“在製品數量限制”（WIP），目前只有極少數團隊在使用 WIP；
原文：
http://www.infoq.com/cn/articles/requirement-lifecycle-management-based-on-jira
