編輯導語：B端產(chǎn)品經(jīng)理在工作過程中，需要注意哪些事情呢？多多學習前輩的經(jīng)驗可以幫助我們在工作上少踩一些雷，進步的更快。本文作者結合自己一年半的工作經(jīng)驗，從成長點以及工作習慣兩方面為我們做出了回答，希望對你有所幫助。

從踏入產(chǎn)品經(jīng)理至今，已經(jīng)有1年半的時間了，本篇文章會總結一下我能感受到的自己成長點；其次，跟大家分享一下產(chǎn)品日常工作中需要注意的關鍵點。

一、成長點

考慮需求更加全面，提前告知業(yè)務風險點。

對于B端產(chǎn)品經(jīng)理，很多需求來源于我們的業(yè)務方，他們會天馬行空地跟我們說出很多需求。這個時候，我們需要快速地思考如下方面的問題：

1. 明確需求的合理性

這個問題需要回答的是要不要做的問題。

首先：引導業(yè)務明確地闡述為什么要做這個需求，如果業(yè)務只說結果，我們很難洞察到背后的原因。因此需要讓業(yè)務描述出在什么場景下，遇到了什么問題，期望得到的結果是什么。通過了解背后的原因，可以探討需求的本質。

其次：產(chǎn)品同學可以結合目前產(chǎn)品本身的功能，看是否有本身已經(jīng)有的功能可以解決問題。如果沒有，則分析一下需求的價值及合理性，很多業(yè)務提出的需求是偽需求，或者是在原本錯誤的邏輯上提出的解決方案，這種需求就不建議做。

2. 需求的優(yōu)先級

這個問題需要回答的是該不該現(xiàn)在做的問題，很多需求是合理且有意義的，但不代表就要立馬做，產(chǎn)品需要梳理本次需求的方向與產(chǎn)品的大方向是否吻合，產(chǎn)品本身是有自己的發(fā)展路徑的，比如目前產(chǎn)品處于起步階段，需要做到更多的是系統(tǒng)能力的搭建。

如果這時，業(yè)務提出比較大的活動引流玩法，在系統(tǒng)不夠成熟的情況下，很容易造成系統(tǒng)崩潰，用戶體驗差，引流來的用戶無法在持續(xù)地在系統(tǒng)上留存。這個時候，產(chǎn)品經(jīng)理需要結合產(chǎn)品發(fā)展階段給出需求在此階段開發(fā)的合理性。

除此之外，在需求評估的時候，即使需求合理，也需要考慮使用的場景的頻率和用戶的使用范圍，如果該需求無法成為后續(xù)可推廣性的功能，那可以適當?shù)匕研枨蟮膬?yōu)先級降低。

3. 是否有什么風險

在明確需求該做，且比較迫切時。這個時候，就需要發(fā)揮產(chǎn)品經(jīng)理的洞察風險的能力，這也是資深產(chǎn)品和萌新產(chǎn)品經(jīng)理很重要的區(qū)別點。

風險點一般出現(xiàn)在哪些方面呢？

• 提出需求的人，和真正的用戶并非是同一類型的用戶。提出需求的人，大多情況是站在管理者，平臺方的角度。所以，站在他們的視角需求可能是合理的，但是站在真正使用者的角度，存在很多不合理或者體驗不好的地方。這種情況，需要提出這樣的風險點，避免需求上線后，真正的使用者不買賬的情況；
• 需求要在哪個平臺或者頁面做，是否有權限的問題。這也是很多初級產(chǎn)品經(jīng)理容易忽略的問題-權限問題，需要跟業(yè)務方明確，是允許哪種角色的人使用該功能。如本身系統(tǒng)無法滿足該權限類別，這也是需求的工作量；
• 數(shù)據(jù)覆蓋同步和覆蓋問題，一旦涉及到數(shù)據(jù)問題，就需要系統(tǒng)之前的數(shù)據(jù)傳遞，需要提前告知業(yè)務，是實時同步，還是T+1同步，還是幾個小時的延時同步，最好可以在后臺系統(tǒng)上標明同步時間，避免用戶產(chǎn)生歧義；
• 所有環(huán)節(jié)查看的數(shù)據(jù)是實時信息還是快照信息，一旦涉及到數(shù)據(jù)的修改，尤其是用戶端已完成的數(shù)據(jù)，查看的是實時數(shù)據(jù)還是快照數(shù)據(jù)。這些都需要在方案階段進行梳理，不同的決定方案，可能會影響后續(xù)的數(shù)據(jù)處理和存儲方式；
• 重要行為用戶行為操作記錄，如商品的價格修改，上下架等業(yè)務認為重要的行為是否需要記錄，并展示出來，這個也可以在需求溝通中明確要記錄的用戶關鍵動作，形成操作日志。

二、工作習慣

產(chǎn)品經(jīng)理是一個信息的匯集地，每天需要輸入，并輸出大量的信息。在工作上多反思，每天給自己“長個記性”會讓工作更加高效。

1. 數(shù)據(jù)的處理

很多產(chǎn)品經(jīng)理在做需求時，只能考慮到此時，此刻的數(shù)據(jù)狀態(tài)和現(xiàn)實情況，很容易忽略掉數(shù)據(jù)的動態(tài)變化過程。

比如，歷史的數(shù)據(jù)該怎么處理？數(shù)據(jù)后續(xù)更改屬性后，數(shù)據(jù)該怎么同步？數(shù)據(jù)刪除后，該數(shù)據(jù)是否在前端顯示，如果顯示，用戶端點擊后，該怎么提示？A獲取B的信息，B變動之后，A的同步機制是什么？

每次涉及到數(shù)據(jù)的處理，請默念【增】、【刪】、【改】、【查】，每次條理清晰地把數(shù)據(jù)的狀態(tài)分場景羅列清楚，開發(fā)和測試同時會愛上你的需求文檔~~

2. 多思考異常情況

近期在設計優(yōu)惠券在用戶界面的展示邏輯，在設計這個需求的過程中，就需要產(chǎn)品經(jīng)理結合運營訴求定義優(yōu)惠券展示的排列規(guī)則。在定義好未領取的優(yōu)惠券排序高于已領取的優(yōu)惠券之后（目的：提高優(yōu)惠券的領取率），就需要再對每一個類別的優(yōu)惠券再次進行排序。

• 未領取優(yōu)惠券中，新最發(fā)布的位置最高，發(fā)布時間以后臺時間為準；
• 異常場景：發(fā)布時間按照后臺記錄的ms級進行記錄，如果時間相同，隨機取一個優(yōu)惠券優(yōu)先排列；
• 已領取優(yōu)惠券中，最后領取的位置最高，以用戶領取時間為準；
• 異常場景：當用戶領取時間相同時（一鍵領取多張時會觸發(fā)同時領?。樞蛞詢?yōu)惠券的截止時間進行排序，距離結束時間越近的（即馬上要到期的）順序放在上方。

這些異常場景都需要產(chǎn)品在撰寫需求文檔的時候就要考慮清楚。每次在寫需求文檔的時候，多問自己問題，就會避免開發(fā)和測試同學來問你問題，也會讓他們在讀你需求文檔的時候，覺得產(chǎn)品的思維是縝密的。

3. 可測試的場景

前幾天開發(fā)問我，**需求的第3個場景在什么情況下發(fā)生？

這時候，我才發(fā)現(xiàn)我的場景3是針對于幾個月后市場部推廣成功后才會應用到的場景，因此，這種在開發(fā)和測試眼中就是“不可測試”場景。

這件事情也給我上了一課，產(chǎn)品經(jīng)理可以把梳理的思路寫到需求文檔，但給到開發(fā)和測試溝通的文檔一定是清晰、明確、可測試的。必要的情況下，可以提供如何達到這種場景的前置條件，方便開發(fā)了解場景的前因后果，也方便測試準備對應的數(shù)據(jù)。

三、小結

希望自己可以每天對工作進行反思，多總結，多歸納。不斷磨練自己的思維。而且有一點點小的感悟就一定要記下來，這樣每次寫需求之前多看看自己的感悟，就可以規(guī)避很多問題，久而久之，能力就會提升一大截。

本文由@黑心老巫婆 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉載。

題圖來自Unsplash，基于CC0協(xié)議