在工作中，總是會(huì)出現(xiàn)一些兩人之間會(huì)出現(xiàn)分歧的情況，產(chǎn)品經(jīng)理與程序猿之間也不例外，那分歧點(diǎn)都有哪些場(chǎng)景呢？可以看看下面的文章了解哦！

做產(chǎn)品也有些年頭了，在工作中也時(shí)常會(huì)遇到和程序猿溝通需求而產(chǎn)生分歧；那這些分歧有一些是可以調(diào)和的，而有一些是真的需要各自調(diào)整心態(tài)后重新討論的?？梢钥偨Y(jié)為以下幾種場(chǎng)景：

一、完全不能理解業(yè)務(wù)場(chǎng)景

和程序猿同事評(píng)審需求前，是需要先簡(jiǎn)單介紹場(chǎng)景的。

就像是一個(gè)故事，你是需要用簡(jiǎn)單易懂的語(yǔ)言，給大家去簡(jiǎn)述這個(gè)需求的背景、發(fā)展和之后的一些藍(lán)圖規(guī)劃的。也可以說(shuō)是對(duì)需求的一個(gè)全局觀了解，否則在評(píng)審中途，你會(huì)有被無(wú)數(shù)次打斷的可能！

比如醫(yī)療行業(yè)，在開(kāi)場(chǎng)前去鋪墊一些故事場(chǎng)景，醫(yī)學(xué)知識(shí)，可能會(huì)對(duì)之后架構(gòu)、庫(kù)表關(guān)系的建設(shè)上有一定的幫助。

二、需求評(píng)審階段的分歧

1. 產(chǎn)品考慮的流程中有明顯的邏輯漏洞的

給程序猿呈現(xiàn)需求的業(yè)務(wù)、功能流程，他們能在細(xì)微的流程變化中幫助產(chǎn)品發(fā)現(xiàn)漏洞。比如我之前做的一個(gè)項(xiàng)目中，就一個(gè)掛號(hào)預(yù)約流程，資深的程序猿總是能在細(xì)微的變化中，問(wèn)你一些異常情況的處理方案。

如：患者預(yù)約掛號(hào)流程

（1）第一步：校驗(yàn)是否已經(jīng)綁就診人。

（2）如果就診人未綁，添加就診人信息時(shí)需要校驗(yàn)是否已經(jīng)被其他用戶綁定，如果已綁定，需要處理解綁后再綁定的新的用戶下（這一步驟的校驗(yàn)，可根據(jù)實(shí)際情況來(lái)添加）。

B 端产品经理如何快速成长？

产品与业务架构主要是将整个业务工作流进行分层，梳理，然后抽象出一个个需求，将业务需求与产品合情合理的映射起来，最终使业务数据在产品中流动，执行，记录，使用。

查看详情 >

（3）校驗(yàn)該用戶綁定就診人是否已超過(guò)個(gè)數(shù)限制，如果已經(jīng)超過(guò)，需要給予對(duì)應(yīng)提示。

（4）否則提交成功后才可以真正進(jìn)入掛號(hào)預(yù)約流程。

這個(gè)流程中的第二步校驗(yàn)，就是評(píng)審過(guò)程中他們所提出來(lái)的，足以看出他們對(duì)整個(gè)流程的嚴(yán)謹(jǐn)！

2. 需求功能邊界的范圍劃分

其實(shí)這一點(diǎn)，是需要大家真正去明確的，所有的需求功能點(diǎn)在規(guī)劃初期可能會(huì)全部列舉出來(lái)，但是在本次評(píng)審的范圍內(nèi)，一定需要?jiǎng)澐殖龉δ苓吔绶秶?。否則很容易讓程序猿們和測(cè)試同事產(chǎn)生混亂和誤解。

一般會(huì)用兩種方式，一種是直接在PRD中標(biāo)注本次版本范圍并標(biāo)注出優(yōu)先級(jí)，另外一種則是拆分本次版本內(nèi)容，單獨(dú)提供出PRD，這兩種方式各有優(yōu)缺點(diǎn)，主要還是看團(tuán)隊(duì)以往的協(xié)作風(fēng)格和溝通方式！

（1）頁(yè)面交互需求評(píng)審時(shí)的談?wù)?/p>

這點(diǎn)分歧，大多存在于C端產(chǎn)品的評(píng)審環(huán)節(jié)中；評(píng)審一般大多是和大家來(lái)宣講某一版本的流程、實(shí)現(xiàn)范圍和涵蓋的大致內(nèi)容，而頁(yè)面交互，產(chǎn)品經(jīng)理在評(píng)審會(huì)議中會(huì)酌情提到，但是并不會(huì)就每個(gè)元素的交互都來(lái)講一遍，只會(huì)過(guò)大的功能流程交互點(diǎn)。

所以頁(yè)面交互一直建議是大點(diǎn)彈框講到，PRD寫(xiě)清楚，再過(guò)細(xì)碎的就實(shí)現(xiàn)過(guò)程中溝通討論，可能對(duì)評(píng)審效率的提升有很大幫助。

（2）無(wú)關(guān)痛癢的需求文案分歧

文案的提示分歧，其實(shí)在產(chǎn)品評(píng)審過(guò)程中經(jīng)常會(huì)有，畢竟仁者見(jiàn)仁智者見(jiàn)智，可是像這種放在評(píng)審會(huì)上討論，很容易讓人產(chǎn)生一種無(wú)力感。文案沒(méi)有好壞之分，只有場(chǎng)景合適性的考量。

它體現(xiàn)不出程序猿的邏輯推理能力，也體現(xiàn)不出一個(gè)產(chǎn)品人的用戶思維。所以只要是恰當(dāng)?shù)奈陌福陀懻撘环昼妱澴呒纯?，沒(méi)必要花太大力氣在評(píng)審會(huì)上專門(mén)討論。

比如：當(dāng)用戶想要?jiǎng)h除自己已經(jīng)取消的歷史訂單時(shí):

（3）需求實(shí)現(xiàn)難易程度的分歧

需求實(shí)現(xiàn)難易程度，我覺(jué)得這個(gè)可以放在技術(shù)方案討論會(huì)上說(shuō)，如果放在需求評(píng)審會(huì)上，不太恰當(dāng)。畢竟需求評(píng)審會(huì)，大多時(shí)候是需求訴求的闡述和想要實(shí)現(xiàn)的方案。而實(shí)現(xiàn)方案，短時(shí)間內(nèi)會(huì)上討論只會(huì)顯得有些倉(cāng)促，通過(guò)充分調(diào)研給予合理的方案的建議才是解決事情的王道。

三、需求實(shí)現(xiàn)階段的分歧

1. 需求優(yōu)先級(jí)

需求優(yōu)先級(jí)的問(wèn)題大多出現(xiàn)在多項(xiàng)目并行的情況下，而出現(xiàn)這種問(wèn)題時(shí)，穿插于多項(xiàng)目中的程序猿，就會(huì)有一些迷茫和排斥。遇到這種分歧，大多情況可提出現(xiàn)狀和困難點(diǎn)，由產(chǎn)品經(jīng)理（兼項(xiàng)目經(jīng)理）OR項(xiàng)目經(jīng)理協(xié)調(diào)，明確優(yōu)先級(jí)和排期沖突時(shí)間的調(diào)整，以便后續(xù)工作的正常開(kāi)展。而遇到真正不能解決的，可能就需要上升到更高的管理層去協(xié)調(diào)溝通解決。

當(dāng)一個(gè)公司業(yè)務(wù)量上升期，需求與產(chǎn)品規(guī)劃都比較緊張，繁雜。所以需求池的管理，需求分析、排期都是需要相關(guān)人員知曉和合理安排的。

2. 實(shí)現(xiàn)工期節(jié)點(diǎn)

之前在實(shí)現(xiàn)階段還遇到過(guò)實(shí)現(xiàn)工期的分歧問(wèn)題，很多時(shí)候一個(gè)大項(xiàng)目的時(shí)間節(jié)點(diǎn)，都是建立在可預(yù)期和充足人員支撐的情況下。

一個(gè)項(xiàng)目預(yù)期上線時(shí)間和技術(shù)評(píng)估時(shí)間的問(wèn)題，大致分兩類：

1. 工期節(jié)點(diǎn)相差小的，加班是常有的事。
2. 工期節(jié)點(diǎn)相差太大的，那就得通過(guò)一些其他方式解決了。

比如：

• 排需求優(yōu)先級(jí)，列舉優(yōu)先實(shí)現(xiàn)的節(jié)點(diǎn)，分版本來(lái)完成；
• 申請(qǐng)從其他項(xiàng)目組調(diào)人員來(lái)支持。
• 項(xiàng)目組擴(kuò)招人員（建立在公司的資金與資源的充足性之上）

3. 測(cè)試、驗(yàn)收環(huán)節(jié)bug問(wèn)題

不影響主流程的bug，一般都需要在版本節(jié)點(diǎn)范圍內(nèi)解決處理，而對(duì)于一些未考慮的細(xì)節(jié)優(yōu)化點(diǎn)，非主流程的漏洞點(diǎn)完全可以記錄下來(lái)，在下一個(gè)版本中快速迭代處理。最忌諱的是在開(kāi)發(fā)中途修改主流程需求和增加新的功能點(diǎn)，戰(zhàn)線太長(zhǎng)不說(shuō)，還會(huì)影響整體的項(xiàng)目進(jìn)度和人員情緒。

以上就是自己工作中一些小小的總結(jié)，歡迎大家指正和補(bǔ)充！