在中臺產(chǎn)品經(jīng)理的日常工作中，獨立負(fù)責(zé)一個模塊的優(yōu)化與迭代是一項極具挑戰(zhàn)性的任務(wù)。本文通過一個實際案例，詳細(xì)拆解了從接手 CRM 系統(tǒng)中的“線索模塊”到完成方案落地的全過程。

作為一名中臺產(chǎn)品經(jīng)理，我們不僅要主動提出需求，分析業(yè)務(wù)邏輯是否有可重構(gòu)/降本增效的節(jié)點，還要不斷調(diào)整產(chǎn)品更新計劃，滿足用戶日益變化的需求。但事實上，需求更多來自老板、業(yè)務(wù)部門甚至其他團(tuán)隊。當(dāng)面對不熟悉的業(yè)務(wù)領(lǐng)域和復(fù)雜的內(nèi)部訴求時，如何開展有效調(diào)研，設(shè)計出讓各方認(rèn)可的方案？筆者將結(jié)合在某東方文旅實際從0-1接手CRM系統(tǒng)中“線索模塊”的實際案例，拆解從接到陌生需求到完成方案落地的全過程。希望能給同樣是中臺產(chǎn)品的朋友提供參考思路。

需求背景和需求范圍

首先一個很重要的事情是，需要和業(yè)務(wù)一起確定需求的背景和需求的范圍，定義好最基礎(chǔ)的共識信息。確定了這一點，相當(dāng)于有了一個各方明確的北極星目標(biāo)，在這個過程中，最重要的目標(biāo)拆解是，新增/迭代/修改這個功能的目的是什么？

很常見的情況是，業(yè)務(wù)方提出的需求只是表層的需求，如果完全按照業(yè)務(wù)方的需求內(nèi)容去做，會出現(xiàn)：

1. 需求范圍過小，影響業(yè)務(wù)的正常使用
2. 需求范圍過大，造成了功能的過度堆砌，產(chǎn)研的壓力過大。

因此我們需要對需求的目標(biāo)進(jìn)行深度發(fā)掘。以我接到線索這個模塊為例，在敲定需求背景和需求范圍的階段，有以下幾個思考和推進(jìn)的過程

1）和業(yè)務(wù)方溝通幾個問題

-為什么要做這個模塊，原來的系統(tǒng)不滿足銷售/運營部門的需求了嗎？

-當(dāng)前系統(tǒng)使用過程中遇到了什么困難？

-對于新系統(tǒng)/功能你最希望能滿足什么需求？

2）定義并明確基礎(chǔ)共識信息

-線索：尚未明確意向的用戶聯(lián)系資源，量級大，輕跟進(jìn)，對應(yīng)TMK（呼叫中心）?色

-商機(jī)：已確認(rèn)有意向的用戶聯(lián)系資源，量級小，重維護(hù)，對應(yīng)銷售/顧問?色

3）根據(jù)和業(yè)務(wù)方溝通的內(nèi)容，得出當(dāng)前業(yè)務(wù)存在的問題：

-系統(tǒng)層面目前沒有線索和商機(jī)的明確區(qū)分，部分分/子公司會在商機(jī)池內(nèi)導(dǎo)入未明確意向線索，影響銷售工作效率，同時污染原商機(jī)維度數(shù)據(jù)

-目前部分意向篩選過程需要通過其他系統(tǒng)來進(jìn)行，該環(huán)節(jié)過程數(shù)據(jù)未能落實到文旅CRM，缺少過程數(shù)據(jù)監(jiān)控

-由于文旅業(yè)務(wù)及分/子公司架構(gòu)特殊性，以及商機(jī)錄入的唯一性，需要線索池支持分/子公司沉淀所有已獲取到的線索資源

根據(jù)業(yè)務(wù)存在的問題，得出1.0線索池優(yōu)化的核心需求是解決線索質(zhì)量/規(guī)范商機(jī)轉(zhuǎn)化流程/實現(xiàn)線索管理的問題，產(chǎn)研側(cè)最重要的是做線索分發(fā)/流轉(zhuǎn)/回收策略，以及支持該功能對應(yīng)的線索分配/線索回流相關(guān)的流程。

知道了需求范圍是第一步，接下來需要思考如何解決問題。

深入了解業(yè)務(wù)流程和目前系統(tǒng)邏輯

對于不了解的業(yè)務(wù)場景，起初很難厘清業(yè)務(wù)都有哪些流程、節(jié)點，以及整個龐大的系統(tǒng)是如何運轉(zhuǎn)的。即使是做了大量的競品調(diào)研，對標(biāo)去做一個功能，也很可能不適合公司內(nèi)的實際業(yè)務(wù)訴求，這就是所謂的閉門造車。因此，多和業(yè)務(wù)方進(jìn)行溝通，詢問一線人員的期望，甚至做一些用戶訪談（對內(nèi)的CRM/SCRM系統(tǒng)的用戶就是業(yè)務(wù)方）都是有必要的。

對業(yè)務(wù)方進(jìn)行訪談的一些開放式問題

-線索來源哪些渠道？

-線索的生命周期是怎樣的？

-為什么線索會觸發(fā)回收？

-銷售沒及時跟進(jìn)線索，會有懲罰措施嗎？

請注意，和業(yè)務(wù)方進(jìn)行訪談的目的是為了更明確業(yè)務(wù)流程，避免需求設(shè)計不落地。實際過程中，還需要注意目前的系統(tǒng)邏輯。需要針對業(yè)務(wù)場景，了解相關(guān)上下游系統(tǒng)的作用，避免僅改造單一系統(tǒng)，導(dǎo)致產(chǎn)品邏輯出現(xiàn)問題。這個時候可以使用流程圖進(jìn)行輔助工作。

以我接到的線索模塊為例，這是根據(jù)和業(yè)務(wù)方進(jìn)行訪談、調(diào)研完成后的系統(tǒng)邏輯流程圖

需求跟進(jìn)和需求評審

當(dāng)我們完成所有的前置流程后，就需要進(jìn)行需求內(nèi)容的書寫。在此之前，請務(wù)必拉上業(yè)務(wù)和研發(fā)一起，將V1.0.0版本的需求文檔過一遍，這樣做的目的是：

1. 和業(yè)務(wù)確認(rèn)，你的設(shè)計滿足業(yè)務(wù)方的需求
2. 和研發(fā)確認(rèn)，目前的研發(fā)能力能夠支持你的設(shè)計，以及上線時間滿足業(yè)務(wù)方的需求

如果業(yè)務(wù)和研發(fā)都沒有問題之后，就可以詳細(xì)的對需求進(jìn)行描述了。就我的成果物而言，需要產(chǎn)出研發(fā)能讀懂的“需求文檔”，而需求文檔離不開：需求背景、目標(biāo)、流程圖、功能清單、原型等元素。

以我接到的線索模塊為例，內(nèi)容太多我就只簡化了一個線索分配模塊的需求描述放進(jìn)來了

當(dāng)完成需求文檔之后，我們一般會在每周四組織一次需求評審，首先確定產(chǎn)研團(tuán)隊上周需求的跟進(jìn)進(jìn)度，然后對產(chǎn)研團(tuán)隊的本周的需求進(jìn)行評審，評估研發(fā)成本和周期，是否需要調(diào)整需求內(nèi)容，最后給出合理的需求排期，這樣一個需求就交到了研發(fā)的手里。

接下來就是跟進(jìn)該需求的研發(fā)，組織測試并完成上線。如果是較小的功能模塊，可以通過郵件或者周報的形式進(jìn)行交付，如果是較大的功能模塊，尤其是涉及到系統(tǒng)邏輯和業(yè)務(wù)邏輯的調(diào)整，可能還需要進(jìn)行系統(tǒng)實施培訓(xùn)。