編輯導語：產品經理在日常工作中會接收到各方遞來的需求，對於這些需求產品經理要有判斷以及跟進的能力，對於可實現的需求進行落地方案的跟進；本文作者分享了關於B端需求的實現之路，我們一起來了解一下。
前面的文章我從自身產品經歷的實際工作中描述了一些產品經理在做的事，也總結了一些產品經理應該做的事；但都是基於從產品經理整體的方向去描述的，針對一些工作過程中的細節並沒有過多闡述。
這一篇我就分享一下我所經歷的一個需求從客户提出到最後實現的過程，看一下一個需求經歷了什麼最終成為了產品中的一個功能。
這是我所描述的這個需求從提出到實現的流程圖，下面的文章我們就基於這個流程圖展開：
一、需求提出我們的新版本手術室麻醉信息系統在設計完成之後，某三甲醫院作為第一個客户正式上線了我們的系統，我們系統的簡易的標準手術流程圖如下：
在使用過程中麻醉科主任針對系統的手術流程提出了一個想法：“希望我們能夠在此標準的手術流程外，再有一個針對二次手術功能，並且使其能夠識別和記錄下該患者是二次手術患者。“
我們系統之前針對患者的二次手術的處理做法是重新創建手術申請，按照一台新的手術繼續操作。系統中會有兩條該患者的手術記錄，這兩條記錄都以獨立手術的形式存在，這樣會保證每一個手術流程都是標準的。
如果二次手術與第一次手術進行關聯，系統原本的標準手術流程會被打破，比如一個患者本應該狀態為手術結束，下一個狀態卻又變為了手術開始；這個需求由主任提出之後我們的現場實施人員判定無法在現場使用現有功能解決，就反饋到了我們事業部。
二、需求分析事業部在收到客户的這個需求之後，將需求發到了我們產品部門。
我們針對這個需求主要從三個方面進行了分析：
- 該需求是否會影響項目的驗收；
- 該客户的影響力；
- 該需求的市場情況；
通過需求分析先判定這個需求響不響應以及如果響應是隻針對該客户還是納入產品標準版中。
1. 該需求是否會影響項目的驗收我們參與了實施團隊與客户需求溝通的會議，期間提到這個二次手術需求時，與客户再次確定了他們醫院的實際業務的確存在該情況，並且她他們主要是想通過此功能加強對手術室二次手術的管理規範。
我們感受到醫院管理方面在這個需求的態度還是很在意的，屬於強烈的期望需求，會影響到客户的滿意度。
2. 該客户的影響力該客户作為某省的三甲醫院，在一定區域內具有一定影響力，並且與銷售團隊溝通得知，後續可能會將該醫院作為該地區的標杆醫院，用來向其它客户展示我們的系統實際現場使用情況。
3. 該需求的市場情況隨着醫療體系的不斷完善以及各臨牀醫療信息系統逐漸精進，二次手術的規範化管理可能會成為市場上大部分三級醫院的標準參數。
綜合以上幾點考慮，我們團隊決定在該項目驗收前滿足客户的需求，並且將這個需求納入到產品標準版基線中，即以後該功能都將作為產品的標準參數出廠。
三、需求設計確定做該需求之後，就到了需求設計這一步開始設計功能的實現了，並且需要通過原型圖的形式將其展現出來。
這個功能的複雜點並不在於簡單的單個患者的手術狀態變更，而是在整個系統中很多功能都關聯着患者的狀態信息，如：患者轉運、病理標本、安全核查等，這些功能的操作都與患者的手術狀態進行關聯。
患者增加了二次手術狀態後其它功能模塊關於手術狀態的判斷需要進行怎樣的變動，這些都要從系統全局角度出發考慮的，所以這個功能是牽一髮而動全身。
當時初步構思了兩個方向的設計方案，第一個是合，即二次手術的操作基於第一次手術的信息和記錄上進行操作；第二個是分，即二次手術的操作與第一次手術保持記錄關聯但操作分開。和同事初期溝通了之後，我認為合的情況不會對系統的頁面顯示造成影響，就按照第一種合的方式進行了設計，出了原型圖。
我的習慣是評審通過前只出原型圖，因為我個人認為在需求設計未評審通過之前，可以通過原型圖的方式讓大家快速瞭解我的想法，也方便我後續進行快速更改和迭代。
有的同事在設計好原型圖之後就把需求文檔寫好然後去評審，結果需求設計被駁回時再做更改，之前的文檔工作量就浪費了，後續文檔的更改工作量有時還不如直接寫一篇新的。
四、需求評審在需求設計完成後，就邀請了產品、研發、測試的同事以及相關領導進行需求的評審。
評審的時候尤其是研發提出，這種合的方式對頁面的改動的確較小；但是會對其它依靠手術流程節點做判斷的功能模塊來説，後台需要改動太多，而且無法預估出可能會造成影響的功能bug，所以第一次的評審沒有通過這個合的方案。
下來之後從頁面改動與牽扯到的其它功能模塊一起考慮，我又重新設計了分的方案，這種方案，在點擊進行再次手術功能時會獨立產生一條二次手術記錄，這樣手術信息與第一次手術關聯，但是手術流程節點在頁面中跟着第二次手術走。
這種方案雖然會在所有患者信息顯示的頁面進行改動新增一條患者的二次手術記錄，但是對其它關聯功能模塊對手術流程的節點判斷影響較小；於是又召集第二次需求評審，在第二次需求評審中通過了該設計方案。
其實第一次需求評審沒過，決定全部推翻而要設計新的方案時，我同事説“這麼可惜，那之前的設計豈不是白做了。”其實我不這麼認為，因為知道怎麼做固然是一種成長，但是知道為什麼不那麼做何嘗不也是一種成長呢？
另外還有一點，我也作為參與者參加過別人的評審會，我發現我在參加別人評審會時會下意識帶有一種想反駁的感覺。
我們的評審會也是很多時候提的需求或者設計會被反駁砍掉一部分，不會被完整的通過；所以我們在準備評審的時候，可以適當的在自己準備的內容之上補充一些一定會被砍掉的設計即滿足了別人反駁的慾望又保護了自己真正想做的設計。
五、需求實現評審通過後，就要確定需求的開發人員與開發時間了，我們使用的是線上的項目管理工具，在線上管理工具裏錄入需求的各種相關信息並且補充上需求的word文檔；畢竟為了速度原型圖只是對頁面和功能進行大概展示，具體的細節還是要在需求文檔中描述清楚的。
研發人員開發完成後，測試人員也測試通過後，我們還要再對功能進行核驗，因為很多時候測試雖然能測出來功能上的bug，但是一些頁面展示以及交互的改進我們還是要產品經理自己再去看一看是否滿足我們的要求。
上述步驟全部完成之後這個需求就算是蜕變成了產品中的具體功能了，這個時刻往往也是作為產品經理最有成就感的時刻！
本文由@小遊不會游泳 原創發佈於人人都是產品經理，未經許可，禁止轉載。
題圖來自Unsplash，基於CC0協議