開始實習已逾一月，在段時間裡我也大大小小的經歷了數十個需求。從最初對業務一無所知，只瞭解哪些書本上抽象的概念到後來能夠較為獨立的負責一個需求的生老病死。有許多的成長，也有許多的體會。
通勤
因為租金昂貴等各種原因，實習的公司離家很遠，每天單程的通勤時間超過1個小時，並且一種交通工具是不行的，下了地鐵還要趕到接駁點坐班車。
路上的時間很長，思考的時間也就多了不少。
站在上海嘈雜的地鐵裡，人群擁擠的抬不起來手來。左手拎著飯盒，右手扶著扶杆，偶爾累了還要換換手，玩手機變成了一般人難以完成的高難度動作。於是人群很吵，心卻變得很靜，有許多的時間可以去思考工作中的那些對與錯。
在實習之前，我也寫過一些關於“產品思維”的一些文章，對於好的產品經理十分敬仰，覺得思維的廣度與深度令人著迷。當然，實習之後我也並沒有覺得那些是不重要的，但卻更多了一層腳踏實地。思維的廣度不能只靠資訊的積累，思維的深度也不能只靠天馬行空的想象與推測。
建立起自己的產品哲學觀前，先要能夠做好事情，這是產品經理的基本功，也是公司對於任職者的基本要求。相對於技術、設計，產品經理這一職位學校並無專業設置，也無技能訓練，好像人人都能走進門，好像人人都能做好事，但其實並非如此。
一個合格的產品經理，你至少要做好兩件事：第一，想清楚；第二：講清楚。
一、想清楚
對於產品er來說，每天打交道最多的不是技術也不是設計，而是“需求”，這些需求可能從別的業務方處來，可能從老闆處來，也有可能從產品er裡的小腦瓜裡冒出來。
公司裡常常發生的一種情況是別的業務方來了一個需求，產品er覺得“emmm…好像還不錯，正好兩週一更版，加進去吧！”結果做出來的效果可能不盡如人意。
對於產品er來說，需求並不完全由自己控制的，無論是實現還是捨棄，到面前的需求就需要產品er認真對待，去思考：
- 這個需求解決了什麼問題？
- 它對用戶意味著什麼？對公司又意味著什麼？
- 這個需求是否有可以替代的其他的實現方式？
本人在一個以視頻為核心產品的公司，前兩天直播頻道給我們部門提了個需求，希望我們可以在彈幕上給直播頻道的主播們進行引流，所以希望他們能夠導入彈幕，上面有主播信息以及跳轉到相應主播間的button。
在接到這個需求之後，我們首先需要去認真的思索這個需求：
（1）這個需求一定要做嗎？它的目的是什麼？
這邊我們主要考慮的還是主播頻道那邊的目的：引流，同時希望優化用戶體驗或至少不對用戶體驗造成傷害。
（2）是否有可以替代的方案？
這裡我們大概想了三種：
- 主播導入彈幕，點擊彈幕引流（與普通彈幕互斥）；
- 主播導入彈幕，點擊彈幕引流（與普通彈幕不互斥）；
- 主播導入音軌，側邊欄引流。
最後用了哪個方案這裡不透露了，在確定做某一個需求之後，還有許多的事需要想清楚：
- 需求是否拆解為了最小粒度？
- 需要撰寫多少份prd？（前端？後臺？中臺？）
- 是否需要UE、UI稿的輸出？
- 是否需要數據埋點？
- 是否需要A/B test？
想清楚是講清楚的基礎。
一個需求的實現需要多方的配合，但人之常情的是，通常前端只想知道前端要做什麼，後臺通常只想知道後臺要做什麼，測試也只想知道測試要做什麼。但你產品經理er，你需要知道所有人該幹什麼。
通常我拆解需求的方式是先用Xmind進行邏輯的拆分，再用Feature list進行整理總結。
（大致如上圖，由於保護公司利益有一些處理）
總之，無論是使用什麼樣的工具輔助，最後的結果一定要是你在腦海裡完整、清晰的勾畫出了一個需求的方方面面。
二、講清楚
在腦海中建立起一個需求的每個細節點之後，你還需要把他事無鉅細、毫無歧義的傳達給諸位實現者，通常的渠道有四個：PRD、UE/UI、需求評審會議以及日常聊天軟件。輔助的還包括原型圖、用例圖、流程圖等。
其中的起點就是PRD，一般PRD的組成部分是文檔信息、修訂記錄、目錄及正文內容，正文內容又包括引言、特性所包含的功能、功能性需求等。
由於設計師會按照你所撰寫的PRD去輸出UE和UI稿，所以PRD裡的邏輯必須十分清晰、完整，儘量考慮好所有的邊界情況和邏輯漏洞，同時在PRD中用語需要規範，避免由於對於某一詞語理解不同而導致效率降低的情況。
PRD中的功能入口設置通常需要和UE共同商討，UE在輸出UE稿後需要交給產品經理去統一同步到各位技術手上，為了避免反覆修正和需求變更引起矛盾，產品需要仔細的確認UE稿，防止出現UE稿和PRD矛盾或不同步的情況。
在輸出UE和UI後，會舉行一次需求評審會議，主要是產品經理主講，UE輔助，這是講清楚中最重要的部分，因為語言總是比文字有更強的說服力，在評審會上要明晰各方疑惑的問題並同步到PRD以及UE上。
產品er們也需要去有意識的對文字表達和語言表達能力進行訓練，以便更好的講清楚。
需求評審會議後，開發的老大一般會進行排期，這時候開發和測試童鞋可能會來與你核對或者確認一些需求的細節，這時候你就會明白：一份好的prd是提高工作效率的關鍵，那些prd留下來的坑都是需要產品er後期去填的，千萬不要偷懶~
在溝通時，需要注意當聊天軟件無法講清楚時，一定要積極的去找開發當面交流，以避免矛盾的產生，另外要注意用流程的規範降低交流成本。
比如：你確實需要變更或許補充一個需求，一定要和開發以及測試先事先確認，再進行prd和UE、UI稿的修改，修改後一定要通過郵件或其他方式同步到各方。
變更時的措辭也需要注意，剛實習的時候我就曾因同步時，措辭有歧義並且@錯了人而和開發產生了一點小矛盾。開發、測試、產品實在是太容易相互產生怨懟的職位，各盡其職，不拖後腿，才是解決這個問題的根本辦法。
想清楚+講清楚，我正在努力成為一名合格的產品經理，你呢？
題圖來自Unsplash，基於CC0協議
閱讀更多 人人都是產品經理 的文章
