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

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

一、完全不能理解業(yè)務場景

和程序猿同事評審需求前，是需要先簡單介紹場景的。

就像是一個故事，你是需要用簡單易懂的語言，給大家去簡述這個需求的背景、發(fā)展和之后的一些藍圖規(guī)劃的。也可以說是對需求的一個全局觀了解，否則在評審中途，你會有被無數(shù)次打斷的可能！

比如醫(yī)療行業(yè)，在開場前去鋪墊一些故事場景，醫(yī)學知識，可能會對之后架構、庫表關系的建設上有一定的幫助。

二、需求評審階段的分歧

1. 產品考慮的流程中有明顯的邏輯漏洞的

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

如：患者預約掛號流程

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

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

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

（4）否則提交成功后才可以真正進入掛號預約流程。

這個流程中的第二步校驗，就是評審過程中他們所提出來的，足以看出他們對整個流程的嚴謹！

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

其實這一點，是需要大家真正去明確的，所有的需求功能點在規(guī)劃初期可能會全部列舉出來，但是在本次評審的范圍內，一定需要劃分出功能邊界范圍。否則很容易讓程序猿們和測試同事產生混亂和誤解。

一般會用兩種方式，一種是直接在PRD中標注本次版本范圍并標注出優(yōu)先級，另外一種則是拆分本次版本內容，單獨提供出PRD，這兩種方式各有優(yōu)缺點，主要還是看團隊以往的協(xié)作風格和溝通方式！

（1）頁面交互需求評審時的談論

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

所以頁面交互一直建議是大點彈框講到，PRD寫清楚，再過細碎的就實現(xiàn)過程中溝通討論，可能對評審效率的提升有很大幫助。

（2）無關痛癢的需求文案分歧

文案的提示分歧，其實在產品評審過程中經(jīng)常會有，畢竟仁者見仁智者見智，可是像這種放在評審會上討論，很容易讓人產生一種無力感。文案沒有好壞之分，只有場景合適性的考量。

它體現(xiàn)不出程序猿的邏輯推理能力，也體現(xiàn)不出一個產品人的用戶思維。所以只要是恰當?shù)奈陌?，就討論一分鐘劃走即可，沒必要花太大力氣在評審會上專門討論。

比如：當用戶想要刪除自己已經(jīng)取消的歷史訂單時:

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

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

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

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

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

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

2. 實現(xiàn)工期節(jié)點

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

一個項目預期上線時間和技術評估時間的問題，大致分兩類：

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

比如：

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

3. 測試、驗收環(huán)節(jié)bug問題

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

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