編輯導(dǎo)語：每個產(chǎn)品都是需要一系列需求的慢慢搭建，并且需求對于一個產(chǎn)品來說是非常重要的；我們對需求進(jìn)行分配以及執(zhí)行，需要一整個團(tuán)隊的配合以及執(zhí)行，才可以最終達(dá)到一個好的效果；本文作者分享了關(guān)于產(chǎn)品是從需求開始的，以及怎么落地的做法，我們一起來看一下。

項目一般是由一系列的需求組成的，需求來源于業(yè)務(wù)，業(yè)務(wù)需要通過一系列的流程串聯(lián)起來，按照某種規(guī)則和規(guī)范循環(huán)執(zhí)行；而在電商企業(yè)中的這些協(xié)作是通過對外或?qū)?nèi)提供的一些軟件產(chǎn)品和服務(wù)體現(xiàn)的。

產(chǎn)品技術(shù)部的工作就是不斷打磨這些產(chǎn)品和服務(wù)，讓其與競品形成差異化，在效率提升和成本控制上產(chǎn)生優(yōu)勢，所有的這些都源于我們對需求的把握與控制。

無論企業(yè)愿景多大，業(yè)務(wù)戰(zhàn)略與IT戰(zhàn)略方向如何，都應(yīng)該始于需求（用戶、行業(yè)、市場、業(yè)務(wù)等），而終于需求的最終落地。

一、需求的發(fā)現(xiàn)與獲取

有些需求是通過業(yè)務(wù)或產(chǎn)品提出來的，有些需求是自行創(chuàng)新整理出來的，需求的發(fā)現(xiàn)與獲取通常采用以下幾種方式：

1. 訪談

訪談顧名思義，就是通過交談的方式獲取需求；在電商企業(yè)中，產(chǎn)品經(jīng)理需要不定期的與相關(guān)人員接觸，深入了解業(yè)務(wù)狀況以及即將開展的工作內(nèi)容，并結(jié)合當(dāng)前的產(chǎn)品及服務(wù)收集一些迫切解決的問題和痛點。

訪談分為內(nèi)部和外部，對于外部訪談主要是針對一些重要客戶或有代表性的關(guān)鍵用戶（2B型產(chǎn)品采用的比較多）。

我們在訪談前要準(zhǔn)備好提綱，在訪談過程中應(yīng)該帶有一定的目的性，集中一些流程或工作節(jié)點進(jìn)行，不要過分的擴(kuò)散，訪談后要進(jìn)行梳理總結(jié)。

2. 需求調(diào)研會

需求調(diào)研會主要是針對談過程中涉及的某些重大問題或企業(yè)確定的一個項目所進(jìn)行的前期準(zhǔn)備工作；在這個過程中，我們要確定重要的干系人（熟悉業(yè)務(wù)流程且可以確定一些流程及細(xì)節(jié)的人員），可以分別調(diào)研，必要時也可以將這些人組織在一起集中討論。

如果以會議的形式，需要我們要有較強(qiáng)的會議組織和掌控能力，而且要提前準(zhǔn)備好會議議題、確定會議時間與地點，在會上要能夠按照既定的議程進(jìn)行。

調(diào)研會的溝通效率及結(jié)果非常關(guān)鍵，充分、詳實的會前準(zhǔn)備工作是調(diào)研會成功的必要條件，正確的與會干系人選擇是影響溝通成果的重要因素。

3. 競品分析

我們都知道市場相似產(chǎn)品多如牛毛，很多產(chǎn)品都是抄來抄去的，但大部分都是形似而神不似；我們在做競品分析時應(yīng)該注重差異化，如何結(jié)合企業(yè)內(nèi)部的資源做出區(qū)別于競品的產(chǎn)品，為用戶提供更優(yōu)質(zhì)的服務(wù)才是一個正確的選擇。

今天偶然想到在之前公司商城上有近百元的禮品卡未使用，于是乎想用掉，發(fā)現(xiàn)原商城地址、小程序、APP都已經(jīng)下線了（與某生鮮合并了），有點莫名的感覺。

回顧之前做的一些項目，似乎一直在跟著某些競品屁股后面跑（到店到家、社區(qū)團(tuán)購、鮮花、禮贈、牛奶周期配、旗艦店的堂食等），做的很早但沒有優(yōu)勢，又缺乏運營與堅持，這也是企業(yè)最終不斷的失去競爭力的原因之一。

競品分析要運用SWOT進(jìn)行優(yōu)勢、劣勢、機(jī)會與威脅的分析，找出差異化，做自己的特色產(chǎn)品，拼DD的成功值得我們借鑒。

競品分析需要了解行業(yè)，這里推薦一個小程序「報告查一查」，可以獲取一些行業(yè)報告。

4. 用戶反饋

對于APP和小程序等前端用戶產(chǎn)品，企業(yè)要實時關(guān)注用戶的行為與評論反饋；前端需求相較于后端生產(chǎn)的需求更多的是來自于用戶，大的公司都會有用研部門，專門負(fù)責(zé)研究用戶。

通過調(diào)查問卷或用戶評價來收集一些需求時，一定要注意問題的質(zhì)量，可以通過招募體驗官的方式進(jìn)行（要給予優(yōu)惠酬金等），注重UGC的內(nèi)容與影響。

此外，在用戶反饋后，我們要根據(jù)結(jié)果進(jìn)行分析（問題多數(shù)是選擇性的），但前提是參與的用戶數(shù)要達(dá)到一定的量才有代表性，否則很容易以偏概全。

5. 數(shù)據(jù)驅(qū)動型需求

數(shù)據(jù)的獲取一方面是對于面向用戶的前端產(chǎn)品通過埋點數(shù)據(jù)，形成分析報表，可以找出問題產(chǎn)生的原因。后端同樣也可以通過操作頻率、系統(tǒng)日志來分析系統(tǒng)使用狀況和服務(wù)性能，從而形成整改的需求。

另一方面，對于有些項目或產(chǎn)品，還要針對生產(chǎn)過程中的各種數(shù)據(jù)進(jìn)行分析，如缺貨分析、履單效率分析、商品報損率、GMV等。

通過數(shù)據(jù)去驅(qū)動一些流程的優(yōu)化，從而使業(yè)務(wù)運營得到改善。

以上都是正常的需求獲取方法，在互聯(lián)網(wǎng)公司呆的久了，我們都體驗過“快”和“變”的酸爽；很多老板的需求一般都是最急迫的，如果老板對于電商行業(yè)與玩法判斷不準(zhǔn)，通常都是一個失敗的項目。

如果為了職場發(fā)展，那么首先就要伺候好老板，老板爽了，你就會有莫大的好處，這在有些公司還是比較常見的，所以需求的獲取莫要遺漏”時刻琢磨老板想法”這個途徑。

二、需求篩選與分類

需求有了，多且雜。

首先，我們可以按照重要性和緊急程度先進(jìn)行區(qū)分，這就是四象限法。

其次，對需求進(jìn)行打標(biāo)（分類）。分類的方式有很多種，比如按照前端產(chǎn)品與后端產(chǎn)品，按照問題BUG、現(xiàn)有業(yè)務(wù)流程優(yōu)化、新項目等，也可以按照業(yè)務(wù)影響范圍分為大、中、小等。

在需求分類時，我們也可以利用KANO模型進(jìn)行劃分；KANO模型把需求分為基本需求、期望需求、魅力需求、無差異需求、反向需求。

通過分類，我們可以將一些相似的需求進(jìn)行合并，也可以去除一些不緊急不重要的需求，以便于更好的調(diào)整資源，也是為后續(xù)的需求優(yōu)先級確定做準(zhǔn)備。

三、需求識別與梳理

需求是來源于業(yè)務(wù)的，在些階段應(yīng)該站在業(yè)務(wù)架構(gòu)的角度來識別與梳理這些已經(jīng)篩選過且分類的需求；此時，我們要遵循如下圖所示的幾個原則：

需求是要滿足業(yè)務(wù)的，業(yè)務(wù)則要滿足企業(yè)的戰(zhàn)略規(guī)劃（業(yè)務(wù)戰(zhàn)略與IT戰(zhàn)略），每個需求的實現(xiàn)時流程可能會受到影響；我們不能固步自封，要敢于打破舊的流程，通過優(yōu)化重構(gòu)來尋求最好的解決方法；但前提是要保證業(yè)務(wù)連續(xù)性，不能出現(xiàn)“孤島”現(xiàn)象，最終適得其反。

最后，要從企業(yè)規(guī)范、財務(wù)原則、信息安全等角度保證需求方案的合規(guī)性。

當(dāng)然這些對于原則2、4，我們在后續(xù)需求設(shè)計時會重點考慮，在此階段，如果需求沒有脫離業(yè)務(wù)戰(zhàn)略，主要是工作通過識別這些需求，將一些需求串起來，盡可能的使其連續(xù)（通過分類或歸屬）。

經(jīng)過此過程，需求會更加清晰，相關(guān)的需求或相互有影響的需求都會識別出來，有些需求可以作為一些需求的子需求而存在，使其形成一個構(gòu)建塊；這些構(gòu)建塊可以形成一個或多個項目，便于后期的需求實現(xiàn)。

四、需求優(yōu)先級

面對上述已經(jīng)識別和梳理的需求先做哪個是非常棘手的問題；此時，我們通常會排優(yōu)先級來確定，但根據(jù)工作經(jīng)驗，這種優(yōu)先級很多時候都是拍腦袋決定的，沖突矛盾依然會存在。

作為產(chǎn)品負(fù)責(zé)人應(yīng)該尋找一種合適的方法去規(guī)劃協(xié)調(diào)需求與資源，通過合理的需求優(yōu)先級定義，可以保證協(xié)調(diào)項目與IT資源的正常協(xié)作，解決公司內(nèi)部的沖突，能夠創(chuàng)造最大的業(yè)務(wù)價值，更快的響應(yīng)業(yè)務(wù)變化，同時也可以對需求進(jìn)行取舍或分期實現(xiàn)。

但這些需要企業(yè)內(nèi)部相關(guān)人員能夠從全局的角度去看待需求，以企業(yè)戰(zhàn)略為愿景，業(yè)務(wù)戰(zhàn)略為主，IT戰(zhàn)略為輔去規(guī)劃、設(shè)計、實現(xiàn)。

五、VCR方法

下面介紹的VCR方法，是本人應(yīng)用實踐過的，可以參考。

VCR估算法是基于價值（Value)、成本費用（Cost)、風(fēng)險（Risk)的優(yōu)先級評定的過程與方法。這里的價值是由提出需求的業(yè)務(wù)方進(jìn)行評價，產(chǎn)品技術(shù)部進(jìn)行費用與風(fēng)險的評價。

在VCR方法中，采用9標(biāo)度的評分標(biāo)準(zhǔn)，具體過程簡單介紹如下：

1. 列出所有的需求（項目）

我們可以利用EXCEL列出要設(shè)定優(yōu)先級的所有需求、項目或使用實例（這里以項目為例）。

這里要注意，所有的項目都必須在同一抽象級別上，不要把個人項目與公司級的產(chǎn)品項目混合在一起；如果某些項目有邏輯上的聯(lián)系（例如，只有包括項目A的情況下才能實現(xiàn)項目B）那么在分析表中只要列出驅(qū)動項目就可以了。

在這個模型中根據(jù)其有效的范圍或時間可以容納很多不同類型的項目，但前提是要把相關(guān)的項目歸成一類，便于分析與優(yōu)先級的排序（參看前面介紹）。

2. 估計相對利潤

以1~9劃分等級（1代表可忽略的利益，9代表最大的價值)

這些利益等級表明了與產(chǎn)品的業(yè)務(wù)項目的一致性。業(yè)務(wù)人員（提出需求者）是判斷這些利益的最佳人選。

在缺省情況下，利潤和損失的權(quán)值是相等的，作為一種精化，我們可以更改這兩個因素的相對權(quán)值。

3. 估計相對損失

估計出如果沒有把應(yīng)該實現(xiàn)的項目包括到產(chǎn)品中，將會給客戶和業(yè)務(wù)上帶來的損失。

同樣使用1~9劃分等級，這里1代表基本沒有損失，9代表嚴(yán)重?fù)p失。

4. 計算總價值及價值占比

總價值=相對利潤+相對損失

價值%= 總價值/總計價值 * 100%

5. 估計相對費用

根據(jù)項目的復(fù)雜度，根據(jù)需求的用戶界面實際情況、重用當(dāng)前代碼的潛在能力以及所需要的測試量和文檔等；產(chǎn)品技術(shù)可以估算出費用，使用1（低級）~9（高級）劃分等級，同時計算每一個項目的費用占比。

6. 風(fēng)險估計

產(chǎn)品技術(shù)要估計出每個項目相關(guān)的技術(shù)或風(fēng)險相對程度，并利用1~9劃分等級。

1級表示你可以輕而易舉地實現(xiàn)編碼，而9級表示需要極大地關(guān)注其可行性、缺乏具有專門知識的人員，或者使用不成熟或不熟悉的工具和技術(shù)。

相對風(fēng)險估算完成后，計算風(fēng)險百分比；在缺省情況下，利潤損失、費用和風(fēng)險的權(quán)值是相等的，可以自行設(shè)置；例如無需考慮風(fēng)險，就可以把風(fēng)險的權(quán)值設(shè)置為0。

7. 優(yōu)先級計算

優(yōu)先級=價值% / （（費用% * 費用權(quán)值） + （風(fēng)險% * 風(fēng)險權(quán)值））

六、成本金額估算法

如果我們是對外提供技術(shù)服務(wù)的企業(yè)，需求優(yōu)先級的判定，在保證業(yè)務(wù)連續(xù)性的和相互最小影響的前提下，也可以采用成本金額估算法。

在評估項目費用成本時，一般情況下都是以IT資源進(jìn)行的，其中人工成本占據(jù)很大的部分。通常我們是將一個項目評估為“人天”，然后分配不同級別的技術(shù)人員，按外包項目的方式進(jìn)行估算。

這樣確定優(yōu)先級主要是考慮企業(yè)的最大利潤，這在一些集團(tuán)型公司（某一子公司為其他子公司提供技術(shù)服務(wù)，財務(wù)上是獨立核算的）比較常見。

當(dāng)然這些需求優(yōu)先級的確認(rèn)是需要甲乙雙方溝通談判的，不適用于企業(yè)自研團(tuán)隊。

對于需求優(yōu)先級的確定，將需求進(jìn)行分類非常重要，有些需求可以整合在一個項目中完成，有的需求則需要依賴于其它需求建設(shè)完成后才能開始，這些都可以通過整合采用循序漸進(jìn)的建設(shè)方式。

同時，我們還要考慮業(yè)務(wù)的期望程度、建設(shè)時間以及經(jīng)費資源，對于期望度高、時間要求短、資源少時，必須盡早確定出所待建設(shè)項目中最重要的項目組合，這個有點類似于關(guān)鍵路徑法。

需求優(yōu)先級的判定可以結(jié)合企業(yè)自身的特點來制定，以上也僅是參考，鞋合不合適，只有腳知道。

七、需求文檔

一個項目（需求）可能會涉及到不同的產(chǎn)品及系統(tǒng)服務(wù),需求文檔的重要性不言而喻，它的詳細(xì)程度與完整度會影響到很多方面。

PRD文檔，是各種溝通的媒介，所以我們要做到以下幾個部分。

• 規(guī)范及完整性是對需求文檔的基本要求。
• 變更要及時通知相關(guān)干系人，包括視覺設(shè)計師、交互設(shè)計師、測試和研發(fā)以及相關(guān)人。
• 必要的流程圖不可少，相對于紛繁的文字，清晰的流程圖可以加快溝通的速度和內(nèi)容的理解。
• 要注意非功能性需求的影響和體現(xiàn)。功能性的需求很多時候只是冰山一角，產(chǎn)品和系統(tǒng)的復(fù)雜度多數(shù)來源于非功能及后端隱藏的實現(xiàn)過程。
• 需求涉及多個產(chǎn)品協(xié)作時，要保證統(tǒng)一性原則，即流程統(tǒng)一，名字定義統(tǒng)一，業(yè)務(wù)目標(biāo)統(tǒng)一，時間統(tǒng)一等。

在此階段要謹(jǐn)防前期配合緊密，后期疏于溝通協(xié)調(diào)的場景發(fā)生，要充分利用實時在線工具，如原型等可以利用墨刀、需求可以利用共享文檔，避免各種變化產(chǎn)生的影響。

八、需求執(zhí)行

對于一個需求有了明確的目標(biāo)，了解其明確的約束以及明確的責(zé)任后，接下來我們就是制定計劃，跟蹤執(zhí)行。

目前對于需求的管理都是通過WEB管理平臺實行的條目化管理，通過配置最小化權(quán)限來保證需求的執(zhí)行。常見的工具有禪道、Readmine、Jira等。

以JIRA為例，通常產(chǎn)品經(jīng)理會先創(chuàng)建用戶需求（業(yè)務(wù)需求或項目），然后分別由研發(fā)負(fù)責(zé)人創(chuàng)建系統(tǒng)需求，再根據(jù)系統(tǒng)需求創(chuàng)建開發(fā)任務(wù)，具體的需求及任務(wù)關(guān)系如下圖。

詳細(xì)的執(zhí)行過程參考下圖，此流程是原公司結(jié)合產(chǎn)品技術(shù)內(nèi)部實際需求設(shè)計的，個人覺得比較繁瑣，還可以再簡化一下：

在需求執(zhí)行管理過程中，要保證每個需求都要進(jìn)入到JIRA中并分配好相關(guān)人員的角色權(quán)限，相關(guān)人員要及時的更新狀態(tài)。

后續(xù)我們可以根據(jù)JIRA中的數(shù)據(jù)進(jìn)行需求管理的數(shù)據(jù)分析，知曉需求達(dá)成率、掛起率、延期時間等指標(biāo)，以助于優(yōu)化管理。

九、寫在最后

本篇對需求的管理進(jìn)行了簡單的整理，源頭管理好了后續(xù)的工作會輕松一些，但這都依賴于規(guī)范與制度；這些需求從領(lǐng)導(dǎo)到員工，從上到下嚴(yán)格執(zhí)行才能達(dá)到效果。

在實際的工作中，很多制度似乎都是要求干活的人遵守的，這是需求管理過程中的大忌，只有上下、內(nèi)外都保持一致，才能更好的滿足企業(yè)業(yè)務(wù)。

最后感謝您的閱讀！

#專欄作家#

倔強(qiáng)的大蘿卜，公眾號：倔強(qiáng)的大蘿卜，人人都是產(chǎn)品經(jīng)理專欄作家。較早的互聯(lián)網(wǎng)電商行業(yè)從業(yè)者，有過多家電商公司的工作經(jīng)驗；擼過代碼，10年以上的團(tuán)隊管理經(jīng)驗，目前的學(xué)習(xí)方向是供應(yīng)鏈及業(yè)務(wù)構(gòu)架等。

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

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