編輯導語：產(chǎn)品經(jīng)理在日常工作中會接收到各方遞來的需求，對于這些需求產(chǎn)品經(jīng)理要有判斷以及跟進的能力，對于可實現(xiàn)的需求進行落地方案的跟進；本文作者分享了關(guān)于B端需求的實現(xiàn)之路，我們一起來了解一下。

前面的文章我從自身產(chǎn)品經(jīng)歷的實際工作中描述了一些產(chǎn)品經(jīng)理在做的事，也總結(jié)了一些產(chǎn)品經(jīng)理應該做的事；但都是基于從產(chǎn)品經(jīng)理整體的方向去描述的，針對一些工作過程中的細節(jié)并沒有過多闡述。

這一篇我就分享一下我所經(jīng)歷的一個需求從客戶提出到最后實現(xiàn)的過程，看一下一個需求經(jīng)歷了什么最終成為了產(chǎn)品中的一個功能。

這是我所描述的這個需求從提出到實現(xiàn)的流程圖，下面的文章我們就基于這個流程圖展開：

一、需求提出

我們的新版本手術(shù)室麻醉信息系統(tǒng)在設(shè)計完成之后，某三甲醫(yī)院作為第一個客戶正式上線了我們的系統(tǒng)，我們系統(tǒng)的簡易的標準手術(shù)流程圖如下：

在使用過程中麻醉科主任針對系統(tǒng)的手術(shù)流程提出了一個想法：“希望我們能夠在此標準的手術(shù)流程外，再有一個針對二次手術(shù)功能，并且使其能夠識別和記錄下該患者是二次手術(shù)患者?！?/p>

我們系統(tǒng)之前針對患者的二次手術(shù)的處理做法是重新創(chuàng)建手術(shù)申請，按照一臺新的手術(shù)繼續(xù)操作。系統(tǒng)中會有兩條該患者的手術(shù)記錄，這兩條記錄都以獨立手術(shù)的形式存在，這樣會保證每一個手術(shù)流程都是標準的。

如果二次手術(shù)與第一次手術(shù)進行關(guān)聯(lián)，系統(tǒng)原本的標準手術(shù)流程會被打破，比如一個患者本應該狀態(tài)為手術(shù)結(jié)束，下一個狀態(tài)卻又變?yōu)榱耸中g(shù)開始；這個需求由主任提出之后我們的現(xiàn)場實施人員判定無法在現(xiàn)場使用現(xiàn)有功能解決，就反饋到了我們事業(yè)部。

二、需求分析

事業(yè)部在收到客戶的這個需求之后，將需求發(fā)到了我們產(chǎn)品部門。

我們針對這個需求主要從三個方面進行了分析：

• 該需求是否會影響項目的驗收；
• 該客戶的影響力；
• 該需求的市場情況；

通過需求分析先判定這個需求響不響應以及如果響應是只針對該客戶還是納入產(chǎn)品標準版中。

1. 該需求是否會影響項目的驗收

我們參與了實施團隊與客戶需求溝通的會議，期間提到這個二次手術(shù)需求時，與客戶再次確定了他們醫(yī)院的實際業(yè)務(wù)的確存在該情況，并且她他們主要是想通過此功能加強對手術(shù)室二次手術(shù)的管理規(guī)范。

我們感受到醫(yī)院管理方面在這個需求的態(tài)度還是很在意的，屬于強烈的期望需求，會影響到客戶的滿意度。

2. 該客戶的影響力

該客戶作為某省的三甲醫(yī)院，在一定區(qū)域內(nèi)具有一定影響力，并且與銷售團隊溝通得知，后續(xù)可能會將該醫(yī)院作為該地區(qū)的標桿醫(yī)院，用來向其它客戶展示我們的系統(tǒng)實際現(xiàn)場使用情況。

3. 該需求的市場情況

隨著醫(yī)療體系的不斷完善以及各臨床醫(yī)療信息系統(tǒng)逐漸精進，二次手術(shù)的規(guī)范化管理可能會成為市場上大部分三級醫(yī)院的標準參數(shù)。

綜合以上幾點考慮，我們團隊決定在該項目驗收前滿足客戶的需求，并且將這個需求納入到產(chǎn)品標準版基線中，即以后該功能都將作為產(chǎn)品的標準參數(shù)出廠。

三、需求設(shè)計

確定做該需求之后，就到了需求設(shè)計這一步開始設(shè)計功能的實現(xiàn)了，并且需要通過原型圖的形式將其展現(xiàn)出來。

這個功能的復雜點并不在于簡單的單個患者的手術(shù)狀態(tài)變更，而是在整個系統(tǒng)中很多功能都關(guān)聯(lián)著患者的狀態(tài)信息，如：患者轉(zhuǎn)運、病理標本、安全核查等，這些功能的操作都與患者的手術(shù)狀態(tài)進行關(guān)聯(lián)。

患者增加了二次手術(shù)狀態(tài)后其它功能模塊關(guān)于手術(shù)狀態(tài)的判斷需要進行怎樣的變動，這些都要從系統(tǒng)全局角度出發(fā)考慮的，所以這個功能是牽一發(fā)而動全身。

當時初步構(gòu)思了兩個方向的設(shè)計方案，第一個是合，即二次手術(shù)的操作基于第一次手術(shù)的信息和記錄上進行操作；第二個是分，即二次手術(shù)的操作與第一次手術(shù)保持記錄關(guān)聯(lián)但操作分開。和同事初期溝通了之后，我認為合的情況不會對系統(tǒng)的頁面顯示造成影響，就按照第一種合的方式進行了設(shè)計，出了原型圖。

我的習慣是評審通過前只出原型圖，因為我個人認為在需求設(shè)計未評審通過之前，可以通過原型圖的方式讓大家快速了解我的想法，也方便我后續(xù)進行快速更改和迭代。

有的同事在設(shè)計好原型圖之后就把需求文檔寫好然后去評審，結(jié)果需求設(shè)計被駁回時再做更改，之前的文檔工作量就浪費了，后續(xù)文檔的更改工作量有時還不如直接寫一篇新的。

四、需求評審

在需求設(shè)計完成后，就邀請了產(chǎn)品、研發(fā)、測試的同事以及相關(guān)領(lǐng)導進行需求的評審。

評審的時候尤其是研發(fā)提出，這種合的方式對頁面的改動的確較??；但是會對其它依靠手術(shù)流程節(jié)點做判斷的功能模塊來說，后臺需要改動太多，而且無法預估出可能會造成影響的功能bug，所以第一次的評審沒有通過這個合的方案。

下來之后從頁面改動與牽扯到的其它功能模塊一起考慮，我又重新設(shè)計了分的方案，這種方案，在點擊進行再次手術(shù)功能時會獨立產(chǎn)生一條二次手術(shù)記錄，這樣手術(shù)信息與第一次手術(shù)關(guān)聯(lián)，但是手術(shù)流程節(jié)點在頁面中跟著第二次手術(shù)走。

這種方案雖然會在所有患者信息顯示的頁面進行改動新增一條患者的二次手術(shù)記錄，但是對其它關(guān)聯(lián)功能模塊對手術(shù)流程的節(jié)點判斷影響較?。挥谑怯终偌诙涡枨笤u審，在第二次需求評審中通過了該設(shè)計方案。

其實第一次需求評審沒過，決定全部推翻而要設(shè)計新的方案時，我同事說“這么可惜，那之前的設(shè)計豈不是白做了?！逼鋵嵨也贿@么認為，因為知道怎么做固然是一種成長，但是知道為什么不那么做何嘗不也是一種成長呢？

另外還有一點，我也作為參與者參加過別人的評審會，我發(fā)現(xiàn)我在參加別人評審會時會下意識帶有一種想反駁的感覺。

我們的評審會也是很多時候提的需求或者設(shè)計會被反駁砍掉一部分，不會被完整的通過；所以我們在準備評審的時候，可以適當?shù)脑谧约簻蕚涞膬?nèi)容之上補充一些一定會被砍掉的設(shè)計即滿足了別人反駁的欲望又保護了自己真正想做的設(shè)計。

五、需求實現(xiàn)

評審通過后，就要確定需求的開發(fā)人員與開發(fā)時間了，我們使用的是線上的項目管理工具，在線上管理工具里錄入需求的各種相關(guān)信息并且補充上需求的word文檔；畢竟為了速度原型圖只是對頁面和功能進行大概展示，具體的細節(jié)還是要在需求文檔中描述清楚的。

研發(fā)人員開發(fā)完成后，測試人員也測試通過后，我們還要再對功能進行核驗，因為很多時候測試雖然能測出來功能上的bug，但是一些頁面展示以及交互的改進我們還是要產(chǎn)品經(jīng)理自己再去看一看是否滿足我們的要求。

上述步驟全部完成之后這個需求就算是蛻變成了產(chǎn)品中的具體功能了，這個時刻往往也是作為產(chǎn)品經(jīng)理最有成就感的時刻！

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

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