程序猿與產品經理溝通需求的分歧點!

0 評論 2528 瀏覽 10 收藏 9 分鐘

在工作中,總是會出現一些兩人之間會出現分歧的情況,產品經理與程序猿之間也不例外,那分歧點都有哪些場景呢?可以看看下面的文章了解哦!

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

一、完全不能理解業務場景

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

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

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

二、需求評審階段的分歧

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

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

如:患者預約掛號流程

(1)第一步:校驗是否已經綁就診人。

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

(3)校驗該用戶綁定就診人是否已超過個數限制,如果已經超過,需要給予對應提示。

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

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

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

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

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

(1)頁面交互需求評審時的談論

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

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

(2)無關痛癢的需求文案分歧

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

它體現不出程序猿的邏輯推理能力,也體現不出一個產品人的用戶思維。所以只要是恰當的文案,就討論一分鐘劃走即可,沒必要花太大力氣在評審會上專門討論。

比如:當用戶想要刪除自己已經取消的歷史訂單時:

(3)需求實現難易程度的分歧

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

三、需求實現階段的分歧

1. 需求優先級

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

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

2. 實現工期節點

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

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

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

比如:

  • 排需求優先級,列舉優先實現的節點,分版本來完成;
  • 申請從其他項目組調人員來支持。
  • 項目組擴招人員(建立在公司的資金與資源的充足性之上)

3. 測試、驗收環節bug問題

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

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

專欄作家

木北的產品成長路,微信公眾號:木北的產品成長路,人人都是產品經理專欄作家,互聯網產品經理,曾擔任醫藥產品經理和電商產品經理,經歷主導過電商平臺的系統整合規劃。

本文原創發布于人人都是產品經理。未經許可,禁止轉載。

題圖來自 Unsplash,基于 CC0 協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!