中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

需求評審，產(chǎn)品經(jīng)理們再也熟悉不過的工作，但對于許多產(chǎn)品新人來說，不是一件簡單的事。這是一場和自己的較量，畢竟是否準(zhǔn)備充分，是否能將自己的方案經(jīng)受住其他人的靈魂拷問，歸根結(jié)底，還是產(chǎn)品經(jīng)理自己的事。具體要怎么做，希望本篇文章能給各位帶來幫助。

大家好，本期我們分享的是產(chǎn)品經(jīng)理每天都會做的工作，很熟悉，但是很多產(chǎn)品經(jīng)理也很恐懼，那就是：需求評審。需求評審是產(chǎn)品經(jīng)理的一場考試，其實我覺得更是產(chǎn)品經(jīng)理的一場自我較量，是產(chǎn)品經(jīng)理自己是否準(zhǔn)備充分，是否能將自己的方案經(jīng)受住其他人的靈魂拷問，歸根結(jié)底，還是產(chǎn)品經(jīng)理自己的事。

一、故事引入

小李新入職了一家公司，領(lǐng)導(dǎo)安排小李先熟悉業(yè)務(wù)，給他開通了一個測試賬號，小李就在測試環(huán)境上走流程、看功能，流程都走通了，對業(yè)務(wù)也有了一定的了解。3天后小李找到領(lǐng)導(dǎo)；

小李：領(lǐng)導(dǎo)，我熟悉的差不多了，有什么工作嗎，分給我一個？

領(lǐng)導(dǎo)：正好業(yè)務(wù)方提了一個需求，你來跟進(jìn)下吧。這個需求就是住院的醫(yī)囑計費節(jié)點配置功能（醫(yī)囑是指醫(yī)師在醫(yī)療活動中下達(dá)的醫(yī)學(xué)指令，比如開藥，做一次CT檢查）

小李拿著需求，第二天就畫完了原型，寫完了PRD，約了開發(fā)準(zhǔn)備評審。

評審會上小李慷慨激昂的講完了需求，心里想：等著開發(fā)排期吧。

突然，氣氛有些不對。

開發(fā)老張說：第三方檢查系統(tǒng)要觸發(fā)計費的怎么處理，據(jù)我所知，有的PACS系統(tǒng)是在登記成功的時候要調(diào)用HIS進(jìn)行計費。

小李有些懵，以為所有的計費只需要護(hù)士分解提交就可以計費了呢。

這個故事告訴我們，新人去了公司一定不用急著干活，雖然我們做不到很全面地了解業(yè)務(wù)和功能，但是在接到需求時，一定要了解清楚這幾點：

1.這個需求的背景是什么

也就是說為什么要做這個需求，誰提出的，比如HIS系統(tǒng)里，是護(hù)士提出的，還是醫(yī)生提出的，是在什么場景下提出的？是遇到什么困難了需要系統(tǒng)幫忙解決？

2.這個需求對現(xiàn)有系統(tǒng)有哪些影響

如果做這個需求，對現(xiàn)有系統(tǒng)哪些地方會影響，列出影響當(dāng)前系統(tǒng)的點，這個一定要自己親手去體驗產(chǎn)品，根據(jù)現(xiàn)有的邏輯和交互去考慮，如果不了解現(xiàn)在的功能，那么很容易會遺漏或者方案有沖突。

3.這個需求的分類

需求是否是屬于標(biāo)準(zhǔn)型產(chǎn)品還是個性化產(chǎn)品，思考能否做成通用的產(chǎn)品，如果不能，怎么來平衡對其他客戶對影響，尤其是在to B的業(yè)務(wù)里，是經(jīng)常遇見的，產(chǎn)品經(jīng)理要深入了解業(yè)務(wù)場景，才能判斷好。

4.做最優(yōu)的方案

這個是最難的，也是值得我們最應(yīng)該思考和努力的。

如果有多個解決方案，我們肯定會采取成本最小的方案，但是筆者最近一直在思考一個問題：系統(tǒng)做的功能就是最優(yōu)的方案嗎，我的答案是非也，其實很多時候我們通過管理要求、相關(guān)制度可以解決問題，舉個例子：醫(yī)院放射科的主任說需要限制每天臨床的加急患者，否則加急的插隊多了患者會投訴，但是控制加急的患者靠系統(tǒng)合適嗎，是否需要加急醫(yī)生最有決定權(quán)，系統(tǒng)是完成不了這個事情的，所以不是所有的需求都應(yīng)該通過系統(tǒng)滿足，有時會適得其反。

5.這個需要的范圍有多大

這個需求僅僅是我們看到的樣子嗎？未必，一個需求有時候會連接好幾個系統(tǒng)都要配合，這個也要考慮到，拿HIS系統(tǒng)舉例，HIS和醫(yī)技系統(tǒng)有很多業(yè)務(wù)接口交互，新增需求很可能會影響到第三方改動。

二、需求評審是為了什么，都有哪些角色參與

我們做產(chǎn)品的，對需求評審的一個共識就是需求評審就是給開發(fā)講我們要做的功能，讓開發(fā)幫我們干，這樣理解沒有問題，但是最重要的是讓我們做的事情，大家達(dá)成一個共識。只有大家達(dá)成了共識，認(rèn)為我們是做一件正確的事，你的需求評審就贏了一半，大家也才會努力的去做，剩下一半就是要把功能怎么講解給項目人員，讓大家對自己要做的部分很清晰。

需求評審時參與的角色：項目經(jīng)理、產(chǎn)品經(jīng)理、前后端開發(fā)，UI，測試等項目人員。

三、需求評審，開發(fā)關(guān)注什么？

俗話說，知己知彼，百戰(zhàn)百勝，很多人之所以評審時被開發(fā)懟或者質(zhì)疑，就是因為不清楚評審的對象他們心里想要的評審是什么樣子。

前后端開發(fā)關(guān)注的點如下：

后端

業(yè)務(wù)邏輯：我們拿線下購物舉例，我們?nèi)コ匈徺I東西需要先加入到購物車，然后收銀臺付款后，商品我們才能帶走，映射到程序里，就是提供搜索、瀏覽商品、加入購物車、提交訂單、支付的功能，在程序里也是有邏輯的，不可能未付款就給發(fā)貨，只有有了邏輯，開發(fā)才可以按照邏輯去寫代碼。

數(shù)據(jù)字典：數(shù)據(jù)字典產(chǎn)品可以理解為我們設(shè)計產(chǎn)品的字段，開發(fā)設(shè)計數(shù)據(jù)庫時，需要表，表里面就是字段，我們提供一份完整的數(shù)據(jù)字典，開發(fā)在設(shè)計表的時候就能填充進(jìn)去字段，數(shù)據(jù)字典一般包括字段名稱、字段的類型、字段的來源、字段的長度等。

實體關(guān)系：實體關(guān)系說經(jīng)過現(xiàn)抽象出來的概念，比如我們?nèi)メt(yī)院看病，患者就是一個實體，醫(yī)生是一個實體，醫(yī)生所在的科室也是一個實體，實體和實體之間是有關(guān)系的，一個科室可以有多個醫(yī)生，一個醫(yī)生屬于一個科室，我們在設(shè)計產(chǎn)品的時候也要把業(yè)務(wù)類的概念抽象出實體，然后梳理實體店關(guān)系

業(yè)務(wù)流程：凡事都有流程，先做什么后做什么，產(chǎn)品設(shè)計也是如此。在評審的時候我們一定要把流程描述清楚，拿購物舉例：用戶瀏覽商品-加入購物車-提交訂單-付款-商家發(fā)貨-商品配送-用戶收貨，可以通過畫流程圖的形式將業(yè)務(wù)的流程表達(dá)出來。

前端

頁面：前端關(guān)注的是頁面的元素是什么，頁面上是否需要表單、下拉框、彈窗等等

交互：交互有頁面之間的跳轉(zhuǎn)關(guān)系，也有特殊要求的動態(tài)效果

總結(jié)：前端一般不參與處理業(yè)務(wù)邏輯和處理數(shù)據(jù)，所以關(guān)注的是交互和頁面上的元素，相反，后端開發(fā)需要處理邏輯處理數(shù)據(jù)，所以前后端關(guān)注的點是不一樣的。

四、需求評審時描述功能要怎么描述

建立場景化的表達(dá)

場景表達(dá)是具體到用戶或者系統(tǒng)的操作場景，這樣參加評審的人員聽起來就不會很懵，建立起來場景，大家的接受情況就會很高，評審效率也會很高

舉例：PACS系統(tǒng)醫(yī)院的登記員給患者在登記時調(diào)用HIS的計費接口，需求評審時候可以說在點擊【登記】按鈕時，調(diào)用計費接口。

這個說法看上去沒有問題，但是如果通過場景化來表達(dá)，就會特別清晰。

• 非預(yù)約登記：點擊登記按鈕時調(diào)用計費接口
• 預(yù)約登記（非簽到）：點擊登記按鈕時調(diào)用計費接口
• 預(yù)約登記，需要簽到：點擊簽到按鈕時調(diào)用計費接口

2.描述要準(zhǔn)確

在需求評審時描述盡量用可以量化的詞進(jìn)行，盡量少用名詞，或者描述不準(zhǔn)備的詞匯

舉例：比如訂單金額必須大于0才能提交，有的產(chǎn)品經(jīng)理可能會描述成訂單金額不為空、必須有訂單金額才能提交。很明顯，第一種的描述開發(fā)是特別清晰怎么去做的。

3.規(guī)則要定義好

現(xiàn)在技術(shù)發(fā)展迅速，基本沒有實現(xiàn)不了的功能，我們在評審的時候一定要想好我們的業(yè)務(wù)規(guī)則，業(yè)務(wù)規(guī)則清晰，開發(fā)就能按照規(guī)則去開發(fā)。

舉例：醫(yī)生開立醫(yī)囑后，護(hù)士要執(zhí)行，有的醫(yī)院藥房周六日休息，護(hù)士會提前領(lǐng)?。ㄖ芪澹⒅苋盏乃幤罚I(lǐng)取藥品后就意味著給患者計費了，但是醫(yī)生在周六突然停止醫(yī)囑了，周日的藥不再給患者吃了，那么周日的藥就要退掉，系統(tǒng)要做自動給護(hù)士創(chuàng)建一個退藥的申請，那么，這個是評審的時候就需要設(shè)計到退藥申請的規(guī)則問題。

那么，我們在設(shè)計產(chǎn)品時，這個規(guī)則一定要考慮清楚，就執(zhí)行單計劃時間（護(hù)士給患者服藥的時間）晚于醫(yī)囑停止時間的才允許自動創(chuàng)建退藥申請，不然沒有這個規(guī)則，都退藥的話，就把不該退的藥也給退了。

五、評審時需要注意的地方

1. 評審時切忌說模棱兩可的話，會讓大家對你失去信任。我們知道，程序員的世界很簡單，要么對，要么錯，如果我們說一些可能、也行、大概的話，會遭致評審人的反感，逐漸對產(chǎn)品經(jīng)理失去信任，產(chǎn)品經(jīng)理是要給參加評審的人一個主心骨的，如果自己都做不到，那么別人可想而知了。

2. 產(chǎn)品經(jīng)理在需求評審前和過程中，一定要自信，只有心里充滿自信，才能在評審過程中有條理的回答別人的疑問，不要怕被質(zhì)疑，產(chǎn)品經(jīng)理注定是在不斷的質(zhì)疑中成長起來的。

3. 評審過程中，遇到邏輯錯誤、遺漏的時候，也不要慌，畢竟人無完人，可以先回答說我下去確認(rèn)下或者我再思考下，盡量不要直接給出方案，因為當(dāng)場給出的方案，基本都是我們沒有仔細(xì)思考的，容易掉坑里。

4. 如果有需要調(diào)整方案或者補(bǔ)充的內(nèi)容，產(chǎn)品經(jīng)理會后要及時的完成，否則容易遺忘，丟掉關(guān)鍵信息。

5. 評審前，產(chǎn)品經(jīng)理可以找好的開發(fā)同事幫忙看看大的邏輯是否存在問題，技術(shù)實現(xiàn)是否可行？同時在評審前，將要評審的內(nèi)容提前發(fā)出來，評審時候大家就會比較有針對性的提問，提高評審效率。

6. 評審結(jié)束，要和相關(guān)角色討論排期，如果不要排期，后面很可能會進(jìn)度失控，不能如期上線，產(chǎn)品經(jīng)理可能就要背鍋了，其實產(chǎn)品經(jīng)理某種程度上也在做項目經(jīng)理的一部分事情。

六、結(jié)尾

需求評審是每個產(chǎn)品經(jīng)理必經(jīng)的過程，從被開發(fā)懟，到自己應(yīng)付好多人的拷問都是需要一個過程的，除了對業(yè)務(wù)本身精通外，還需要多總結(jié)經(jīng)驗，多和開發(fā)、測試溝通，多聽取優(yōu)秀的產(chǎn)品經(jīng)理的評審，需求評審會越來越順利。