這篇文章通過一個具體的故事，揭示了產(chǎn)品需求價值評估的復(fù)雜性和實際操作中的困境。它講述了一個業(yè)務(wù)部門對現(xiàn)有系統(tǒng)效率不滿、提出改進(jìn)需求，到產(chǎn)品經(jīng)理如何評估這個需求的價值，再到需求實施后的實際效果與預(yù)期之間的差距。

業(yè)務(wù)部門覺得現(xiàn)有系統(tǒng)的錄入合同信息功能就是“反人類”！

一個新合同要在ERP、財務(wù)系統(tǒng)、OA審批系統(tǒng)分別錄入，錄完合同然后再錄入收款，假如合同的收款分為多次，那負(fù)責(zé)合同收款的小姑娘就要哭啦。因為合同收款是一線銷售在跟進(jìn)，收款到賬是財務(wù)部進(jìn)行核實，中間是小姑娘向銷售人員要到收款信息后錄入系統(tǒng)，工作流才能串聯(lián)起來。但是，有些合同收款周期太長，銷售忘了提供合同后續(xù)的收款信息（實際已打款），財務(wù)部就多了不少“無頭賬”，小姑娘就得拿著一筆筆銀行轉(zhuǎn)賬，去ERP系統(tǒng)里找哪個合同收的款。因此，小姑娘經(jīng)常加班到深夜9、10點，大好年華都奉獻(xiàn)給了公司。

小姑娘很委屈，就找到部門主管訴苦。業(yè)務(wù)部門主管一聽，覺得有道理，公司的系統(tǒng)是該好好改造一下了，這破系統(tǒng)，簡直就是讓人在給系統(tǒng)打工！于是，業(yè)務(wù)部門給IT部提了一個需求，要求合同信息不用錄入3次。

產(chǎn)品經(jīng)理小吳一聽這需求，簡單?。∽鰝€系統(tǒng)間的數(shù)據(jù)同步不就好了嘛！

產(chǎn)品經(jīng)理老吳會心一笑，別急！咱先來看看業(yè)務(wù)部門在3個系統(tǒng)的功能現(xiàn)況。

接著便發(fā)現(xiàn)：

1. 需要錄入的合同信息主要為十幾個合同字段，還有一些附件材料。
2. 在ERP是在項目簽完紙質(zhì)合同的時候錄入合同，在OA審批是項目合同上報管理層的時候錄入合同，在財務(wù)系統(tǒng)是項目第一次收到付款的時候錄入合同。
3. 在OA審批時要填寫的信息遠(yuǎn)不止合同信息，還有很多線下收集的材料、審批流字段。也就是說，如果做數(shù)據(jù)同步，只能把3次錄入減到2次，并不能減到1次。
4. 更好的辦法是將收集合同信息的錄入工作轉(zhuǎn)移到一線銷售員工身上，因為銷售員工上百名，分?jǐn)偟矫咳瞬贿^0.5個合同，不會給他們造成很大的工作壓力，并且銷售跟進(jìn)自己的合同更上心。
5. 需求的另一個塊——“無頭賬”的解決方案，則同樣將收集收款信息的工作轉(zhuǎn)移到一線銷售員工身上，從而釋放小姑娘的工作壓力。

這么一來，功能應(yīng)該設(shè)計成：在APP新開發(fā)兩個表單收集頁面，在PC后臺新開發(fā)一個管理頁面。

老吳又找到小姑娘細(xì)聊，確認(rèn)完她日?？啾频墓ぷ髦?。問她：每個合同要花多少時間處理？每個月大概有多少個合同？

小姑娘滿眼真誠地說：“每個合同都要花掉她1小時錄入，一個月大概有40個合同。假如合同分多次付款，則還要多花1個小時?！?/p>

老吳腦子里開始盤算：算她一個月大概50小時做這事，一年是600小時，折合下來差不多是3.4個月（720/22/8）。小姑娘的人力成本是10k/月，那么，這個需求的成本是34k。然后，IT部為此投入的產(chǎn)品、開發(fā)、UI、測試的人力成本算1人月吧，研發(fā)的人力成本是30k/月。需求的投產(chǎn)比是114%，雖然是正收益，可價值不是很大。

告別了小姑娘，老吳把分析結(jié)果給小吳講了，小吳驚呼，這需求沒多大價值嘛，一般需求的投產(chǎn)至少要到200%。給它放著，先做價值高的需求吧。

老吳又說：“你還是天真了，我們需求池的里的各個業(yè)務(wù)部提的需求，價值、投產(chǎn)真的有那么高嗎？大家知道投產(chǎn)會影響需求優(yōu)先級，于是業(yè)務(wù)部門報過來的需求價值往往高估，甚至水分十足。這小姑娘不諳世事，說的卻是實際的。另外，這個業(yè)務(wù)部門領(lǐng)導(dǎo)平時在老板面前威望很重，要是拖著人家，人家到老板那邊告我們的狀，我們可要吃不了兜著走?！?/p>

小吳：“這可咋辦？”

老吳：“這樣，你私下里跟那個小姑娘說一聲，告訴她正式提交需求給IT部門的時候，不要把價值評估的范圍局限于她自己一人，把財務(wù)同事、銷售人員花的時間，以及她和相干人頻繁交接所花的時間都算進(jìn)去?！?/p>

小吳：“高還是你高！不僅瞬間提升了需求價值，還TMD賊合理?！?/p>

小姑娘聽了豁然開朗。不過，她還是很謹(jǐn)慎，把這事告訴了部門主管，主管一聽，當(dāng)機立斷：“這必須得把價值提升上去?。　眱?nèi)心嘀咕：我只管提升我們部門的工作效率。心里默默地夸獎老吳、小吳：這兩個IT部的員工，很懂得做事嘛。

于是，小姑娘在正式需求單里把每個合同的耗時從1小時改為了3小時，一個月大概150小時，一年是1800小時，需求成本約合10萬，投產(chǎn)比暴增至333%。需求優(yōu)先級大大提高，順利排上期。

一個月后，需求上線。

小姑娘卻發(fā)現(xiàn)新功能上線后，并沒有給她省下很多的時間，因為銷售人員還是習(xí)慣性的把付款材料傳給她，還有些銷售抱怨要自己傳資料很麻煩，不如之前線下的流程來的方便。小姑娘反而變成了一個輔導(dǎo)員，每天教銷售人員如何填寫合同信息、如何提交付款記錄。

過了不久，公司企劃部抽查IT部的工作成果，正好選中了這個“合同信息”的需求，于是，便去詢問需求提出人——小姑娘——實際使用效果如何？以及“有沒有為業(yè)務(wù)部門每個月節(jié)約150小時？”

小姑娘猶如被雷劈了一下——怎么還有檢查啊！現(xiàn)在要暴露了，咋辦咋辦？一時之間不知如何開口，只好支支吾吾的說：“那個……確實有所幫助，那個…….實際節(jié)約的時長，我……我……再回去問下我們領(lǐng)導(dǎo)?！?/p>

慌慌張張的小姑娘跟領(lǐng)導(dǎo)說了檢查的事，領(lǐng)導(dǎo)一聽，眉頭微微一皺：被抽到確實有點倒霉，但兵來將擋水來土淹，總能應(yīng)付的。要是現(xiàn)在事實求是匯報使用現(xiàn)況的話，就會說我們部門虛報需求價值，估計IT部兩位產(chǎn)品經(jīng)理也要被批評需求管理不當(dāng)——不行！我們把效果說的好一點，這樣才能證明我們部門是認(rèn)真做事、積極向上。

領(lǐng)導(dǎo)把小姑娘拉過來，跟她說：“你這么…這么…寫，這樣…這樣…說，明白了嗎？”

有過上次點撥的經(jīng)驗，小姑娘立馬心領(lǐng)神會，回去“啪啪啪”敲鍵盤，給企劃部回復(fù)到：合同信息需求不僅幫助業(yè)務(wù)部門員工節(jié)約了150小時/月的合同收錄時間，相關(guān)員工還做了更多工作，尤其是輔導(dǎo)銷售人員這一塊，培養(yǎng)了我們的銷售隊伍線上化作業(yè)的能力，使我們整個銷售流程更加合規(guī)、更高效。在此，非常感謝IT部的支持和相關(guān)產(chǎn)品經(jīng)理的出謀劃策，幫助業(yè)務(wù)部門降本增效。

企劃部收到回復(fù)表示滿意：業(yè)務(wù)部認(rèn)可需求價值，并且邏輯也說的通。此外，因為“流程線上化”是當(dāng)年公司創(chuàng)新主題，企劃部還將該需求標(biāo)記為“有價值案例”。

至此，這個需求的故事收獲了一個各方“皆大歡喜”的結(jié)局。

可是，這個結(jié)局似乎也不盡如人意。需求價值虛報的，需求產(chǎn)出蒙混過關(guān)，小姑娘也沒因需求省心多少，銷售還在吐苦水。

這就是一個普通的關(guān)于需求價值的故事，或許，也是很多產(chǎn)品經(jīng)理經(jīng)歷過的事兒。如果也曾感到無奈，這里有三條建議給到分享：

1. 做好需求調(diào)研、分析。業(yè)務(wù)夸大需求價值不可避免，產(chǎn)品經(jīng)理收到需求時不可盲目輕信之，多思考，多去體驗用戶的場景、流程，從而避免被業(yè)務(wù)忽悠，做了低價值的需求。
2. 做好用戶陪伴、追蹤上線效果。新功能需要一個試用期和學(xué)習(xí)培訓(xùn)階段，需求價值不能馬上體現(xiàn)，保持耐心，比如過一個月再看需求效果，如果解決了主要問題解決了，那么需求基本沒太大問題，還有些小問題一點點優(yōu)化就好。假如主要問題沒解決，那就說明這需求最初的分析判斷有誤。
3. 保持清醒的認(rèn)知。有些時候有些需求價值不高，但也“必須做、必須上”，產(chǎn)品經(jīng)理人輕言微，那就內(nèi)心明白這個需求本質(zhì)是什么就好，做好原型、文檔等本職工作，其他的就讓他隨風(fēng)去吧，別因此精神內(nèi)耗。