作為B端產(chǎn)品經(jīng)理，系統(tǒng)的主要使用對象為企業(yè)中各部門的使用人群，其需求收集等方式與C端有所不同。其次，各企業(yè)對產(chǎn)品需求的管理方法也各有特色。本文作者結(jié)合自己公司的具體情況，對管理產(chǎn)品需求進(jìn)行了闡述。

我司使用SAT和禪道對產(chǎn)品需求進(jìn)行管理，接下來結(jié)合需求的流轉(zhuǎn)過程進(jìn)行介紹：

一、需求收集

首先是要進(jìn)行需求的收集。收集方式一方面為產(chǎn)品人員自己分析系統(tǒng)情況、市場調(diào)研等方式，整理出的需求，另一方面，由用戶根據(jù)實際的業(yè)務(wù)情況，對系統(tǒng)提優(yōu)化、新增功能等。

一般來說，需要直屬領(lǐng)導(dǎo)審核需求，通過后方可流轉(zhuǎn)至IT部。接著，產(chǎn)品經(jīng)理和IT相關(guān)人員會定期對需求池的需求進(jìn)行評審處理。

為了減少需求溝通的效率，故需要求用戶在需求提出時，附上相關(guān)附件，以下是在需求收集階段我們會設(shè)置的一些關(guān)鍵屬性：

1. 需求描述

對于2B的產(chǎn)品需求，要描述需求名稱、需求的部門、崗位、涉及的菜單、使用的頻次、責(zé)任人等，最重要的是要寫上預(yù)計使用日期和期望交期。

2. 核心價值

針對核心價值，需要業(yè)務(wù)員根據(jù)想要實現(xiàn)的功能，整理出來預(yù)計后期產(chǎn)生的價值，以及具體的明細(xì)，包括：是否可提效、降本等；

3. 需求類型

描述功能是線下轉(zhuǎn)線上（即新功能）、頁面優(yōu)化、BUG修復(fù)、報表等，根據(jù)不同的需求類型，后期評定技術(shù)上花費(fèi)的預(yù)計時長，安排需求交期或需求的優(yōu)先級；

4. 功能描述以及流程圖

需求提出人需描述清楚待實現(xiàn)的功能，以及相關(guān)的邏輯，涉及的菜單，若含跨部門的，需要需求提出人提前和相關(guān)部門負(fù)責(zé)人溝通，待溝通通過后，畫出相應(yīng)的流程圖，涉及審批流的，需要明確審批節(jié)點名稱和審批人；

二、需求評審

我司設(shè)立業(yè)務(wù)IT一職位，在需求收集之后，由業(yè)務(wù)IT相關(guān)人員組織，設(shè)立每迭代的需求評審小組，根據(jù)迭代交付日期，提前評審需求。

在每次需求評審時，需產(chǎn)品、開發(fā)、設(shè)計師，需求提出人共同參加，需求提出人對功能進(jìn)行大致描述，由IT相關(guān)人員安排需求優(yōu)先級、預(yù)計開發(fā)時間等

在需求評審結(jié)束后，要包含以下3個字段：

1. 需求合理性：合理需求、待定、需求不明確、不合理需求；
2. 優(yōu)先級（評估為合理的需求，我們會根據(jù)重要程度標(biāo)記優(yōu)先級）；
3. 異常處理結(jié)果（對于不明確的需求，或者不合理的需求，通過異常處理結(jié)果進(jìn)行闡述，也可以用評論代替）；

因此，在需求評審后，將下迭代要做的需求引入禪道，便于后期拆分方案、開發(fā)、測試任務(wù)，并對每階段的任務(wù)情況進(jìn)行跟進(jìn)。引入禪道的優(yōu)先級為已計劃、已立項、研發(fā)中、研發(fā)完畢、測試中、測試完畢、已發(fā)布、關(guān)閉。

三、引入禪道，安排計劃

產(chǎn)品經(jīng)理會將決定要做的需求，引入禪道，在禪道建迭代的項目和計劃，并將決定做的需求引入到具體的禪道中，之后將需求指派給相應(yīng)的人員，拆分任務(wù)，并安排整個迭代需交付需求的計劃、交期；

需求的方案任務(wù)拆分后，需進(jìn)行方案評審，評審?fù)ㄟ^后安排研發(fā)周期，由研發(fā)工程師指派給開發(fā)人員。

四、產(chǎn)品研發(fā)

迭代規(guī)劃之后，需求方案也確定已經(jīng)編寫、評審?fù)戤?，則正式進(jìn)入研發(fā)階段，這個時候需要產(chǎn)品經(jīng)理每天跟進(jìn)研發(fā)的工作開展情況，研發(fā)負(fù)責(zé)人和產(chǎn)品經(jīng)理可隨時在禪道上關(guān)注迭代中每個需求的開發(fā)的=進(jìn)度，并在每日站會中溝通進(jìn)展。

這里還需要特別提醒一下，在迭代結(jié)束前2天左右，研發(fā)、產(chǎn)品相關(guān)人員會一起演示迭代的產(chǎn)出。并對每個功能進(jìn)行驗證，演示時，會根據(jù)演示情況在對應(yīng)的需求下創(chuàng)建相關(guān)的缺陷，待演示結(jié)束后進(jìn)行修復(fù)。

演示中出現(xiàn)的bug修復(fù)后，由產(chǎn)品經(jīng)理進(jìn)行最終驗收，并決定是否可以上線。

五、準(zhǔn)備發(fā)布

在迭代交付日期之前，需要開上線發(fā)布準(zhǔn)備會，由產(chǎn)品、設(shè)計、開發(fā)人員，整理需求發(fā)布清單，比如新功能，需要給某部門的人開通菜單權(quán)限等，不同的情況由相應(yīng)的人員管理。

項目組由產(chǎn)品負(fù)責(zé)人整體上線功能清單，共同評審，評審?fù)ㄟ^后，由研發(fā)經(jīng)理在發(fā)布完成后，各需求負(fù)責(zé)人對實現(xiàn)功能進(jìn)行驗證，若過程中出現(xiàn)問題，對應(yīng)的研發(fā)人員查找原因，進(jìn)行更改。

六、總結(jié)

以上是我司用SAT、禪道管理一個需求從提交到上線的完整過程。不同企業(yè)的文化、業(yè)務(wù)不同，對應(yīng)的需求管理方式也不同，同時，隨著用戶及需求的增加，需要不斷對需求管理工具進(jìn)行優(yōu)化，最終目的是為了簡化流程提高效率。

這里只分享一種思路，至于使用什么系統(tǒng)，需要結(jié)合公司或企業(yè)的實際情況而定，最后，希望能給大家?guī)硪恍椭?，同時也歡迎各位大神指導(dǎo)。

本文由@珂遇不可求 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議