一個B端需求的實(shí)現(xiàn)之路

8 評論 8318 瀏覽 31 收藏 11 分鐘

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

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

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

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

一、需求提出

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

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

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

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

二、需求分析

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

我們針對這個需求主要從三個方面進(jìn)行了分析:

  • 該需求是否會影響項(xiàng)目的驗(yàn)收;
  • 該客戶的影響力;
  • 該需求的市場情況;

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

1. 該需求是否會影響項(xiàng)目的驗(yàn)收

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

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

2. 該客戶的影響力

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

3. 該需求的市場情況

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

綜合以上幾點(diǎn)考慮,我們團(tuán)隊(duì)決定在該項(xiàng)目驗(yàn)收前滿足客戶的需求,并且將這個需求納入到產(chǎn)品標(biāo)準(zhǔn)版基線中,即以后該功能都將作為產(chǎn)品的標(biāo)準(zhǔn)參數(shù)出廠。

三、需求設(shè)計(jì)

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

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

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

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

我的習(xí)慣是評審?fù)ㄟ^前只出原型圖,因?yàn)槲覀€人認(rèn)為在需求設(shè)計(jì)未評審?fù)ㄟ^之前,可以通過原型圖的方式讓大家快速了解我的想法,也方便我后續(xù)進(jìn)行快速更改和迭代。

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

四、需求評審

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

評審的時候尤其是研發(fā)提出,這種合的方式對頁面的改動的確較?。坏菚ζ渌揽渴中g(shù)流程節(jié)點(diǎn)做判斷的功能模塊來說,后臺需要改動太多,而且無法預(yù)估出可能會造成影響的功能bug,所以第一次的評審沒有通過這個合的方案。

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

這種方案雖然會在所有患者信息顯示的頁面進(jìn)行改動新增一條患者的二次手術(shù)記錄,但是對其它關(guān)聯(lián)功能模塊對手術(shù)流程的節(jié)點(diǎn)判斷影響較小;于是又召集第二次需求評審,在第二次需求評審中通過了該設(shè)計(jì)方案。

其實(shí)第一次需求評審沒過,決定全部推翻而要設(shè)計(jì)新的方案時,我同事說“這么可惜,那之前的設(shè)計(jì)豈不是白做了?!逼鋵?shí)我不這么認(rèn)為,因?yàn)橹涝趺醋龉倘皇且环N成長,但是知道為什么不那么做何嘗不也是一種成長呢?

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

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

五、需求實(shí)現(xiàn)

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

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

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

 

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

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

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 拜讀了所有的文章,寫的很好~學(xué)習(xí)了~~~

    來自上海 回復(fù)
    1. 棒!

      來自湖南 回復(fù)
  2. 我覺得作者你說的需求評審應(yīng)該方案評審,所謂需求評審是組內(nèi)開會,從需求的業(yè)務(wù)價(jià)值方面決定需求做還是不做的問題。需求的業(yè)務(wù)價(jià)值肯定之后,才會進(jìn)行方案設(shè)計(jì),設(shè)計(jì)完之后才是和研發(fā)、測試一起進(jìn)行方案評審。

    來自湖北 回復(fù)
  3. 其實(shí)產(chǎn)品的呈現(xiàn)和功能上不管是分還是合,對后臺技術(shù)的實(shí)現(xiàn)都是分。手術(shù)的過程信息是系統(tǒng)的核心,第二次手術(shù)跟第一次手術(shù)在手術(shù)過程信息上就是平等的新增信息。對于產(chǎn)品的呈現(xiàn)上,需要合按用戶的唯一身份作為關(guān)聯(lián)即可,需要分就是2條不同的手術(shù)。所以從產(chǎn)品上討論分合的意義不大,技術(shù)上的分合區(qū)別就大了。

    來自北京 回復(fù)
    1. 沒錯,所以技術(shù)同事駁回了我第一次只從產(chǎn)品頁面呈現(xiàn)上考慮的設(shè)計(jì)

      來自上海 回復(fù)
    2. 那你這咋沒說服他呢

      來自湖北 回復(fù)
  4. 增加炮灰需求當(dāng)然是聰明之舉,但是評審的意義不就是對真正的需求進(jìn)行評審么~

    來自四川 回復(fù)
    1. 需求被對懟回來就像兒子被人打了一樣hh,這樣盡量避免真正的需求被研發(fā)懟掉/(ㄒoㄒ)/~~

      來自上海 回復(fù)