開始實(shí)習(xí)已逾一月，在段時間里我也大大小小的經(jīng)歷了數(shù)十個需求。從最初對業(yè)務(wù)一無所知，只了解哪些書本上抽象的概念到后來能夠較為獨(dú)立的負(fù)責(zé)一個需求的生老病死。有許多的成長，也有許多的體會。

通勤

因?yàn)樽饨鸢嘿F等各種原因，實(shí)習(xí)的公司離家很遠(yuǎn)，每天單程的通勤時間超過1個小時，并且一種交通工具是不行的，下了地鐵還要趕到接駁點(diǎn)坐班車。

路上的時間很長，思考的時間也就多了不少。

站在上海嘈雜的地鐵里，人群擁擠的抬不起來手來。左手拎著飯盒，右手扶著扶桿，偶爾累了還要換換手，玩手機(jī)變成了一般人難以完成的高難度動作。于是人群很吵，心卻變得很靜，有許多的時間可以去思考工作中的那些對與錯。

在實(shí)習(xí)之前，我也寫過一些關(guān)于“產(chǎn)品思維”的一些文章，對于好的產(chǎn)品經(jīng)理十分敬仰，覺得思維的廣度與深度令人著迷。當(dāng)然，實(shí)習(xí)之后我也并沒有覺得那些是不重要的，但卻更多了一層腳踏實(shí)地。思維的廣度不能只靠資訊的積累，思維的深度也不能只靠天馬行空的想象與推測。

建立起自己的產(chǎn)品哲學(xué)觀前，先要能夠做好事情，這是產(chǎn)品經(jīng)理的基本功，也是公司對于任職者的基本要求。相對于技術(shù)、設(shè)計(jì)，產(chǎn)品經(jīng)理這一職位學(xué)校并無專業(yè)設(shè)置，也無技能訓(xùn)練，好像人人都能走進(jìn)門，好像人人都能做好事，但其實(shí)并非如此。

一個合格的產(chǎn)品經(jīng)理，你至少要做好兩件事：第一，想清楚；第二：講清楚。

一、想清楚

對于產(chǎn)品er來說，每天打交道最多的不是技術(shù)也不是設(shè)計(jì)，而是“需求”，這些需求可能從別的業(yè)務(wù)方處來，可能從老板處來，也有可能從產(chǎn)品er里的小腦瓜里冒出來。

公司里常常發(fā)生的一種情況是別的業(yè)務(wù)方來了一個需求，產(chǎn)品er覺得“emmm…好像還不錯，正好兩周一更版，加進(jìn)去吧！”結(jié)果做出來的效果可能不盡如人意。

對于產(chǎn)品er來說，需求并不完全由自己控制的，無論是實(shí)現(xiàn)還是舍棄，到面前的需求就需要產(chǎn)品er認(rèn)真對待，去思考：

1. 這個需求解決了什么問題？
2. 它對用戶意味著什么？對公司又意味著什么？
3. 這個需求是否有可以替代的其他的實(shí)現(xiàn)方式？

本人在一個以視頻為核心產(chǎn)品的公司，前兩天直播頻道給我們部門提了個需求，希望我們可以在彈幕上給直播頻道的主播們進(jìn)行引流，所以希望他們能夠?qū)霃椖唬厦嬗兄鞑バ畔⒁约疤D(zhuǎn)到相應(yīng)主播間的button。

在接到這個需求之后，我們首先需要去認(rèn)真的思索這個需求：

（1）這個需求一定要做嗎？它的目的是什么？

這邊我們主要考慮的還是主播頻道那邊的目的：引流，同時希望優(yōu)化用戶體驗(yàn)或至少不對用戶體驗(yàn)造成傷害。

（2）是否有可以替代的方案？

這里我們大概想了三種：

• 主播導(dǎo)入彈幕，點(diǎn)擊彈幕引流（與普通彈幕互斥）；
• 主播導(dǎo)入彈幕，點(diǎn)擊彈幕引流（與普通彈幕不互斥）；
• 主播導(dǎo)入音軌，側(cè)邊欄引流。

最后用了哪個方案這里不透露了，在確定做某一個需求之后，還有許多的事需要想清楚：

1. 需求是否拆解為了最小粒度？
2. 需要撰寫多少份prd？（前端？后臺？中臺？）
3. 是否需要UE、UI稿的輸出？
4. 是否需要數(shù)據(jù)埋點(diǎn)？
5. 是否需要A/B test？

想清楚是講清楚的基礎(chǔ)。

一個需求的實(shí)現(xiàn)需要多方的配合，但人之常情的是，通常前端只想知道前端要做什么，后臺通常只想知道后臺要做什么，測試也只想知道測試要做什么。但你產(chǎn)品經(jīng)理er，你需要知道所有人該干什么。

通常我拆解需求的方式是先用Xmind進(jìn)行邏輯的拆分，再用Feature list進(jìn)行整理總結(jié)。

（大致如上圖，由于保護(hù)公司利益有一些處理）

總之，無論是使用什么樣的工具輔助，最后的結(jié)果一定要是你在腦海里完整、清晰的勾畫出了一個需求的方方面面。

二、講清楚

在腦海中建立起一個需求的每個細(xì)節(jié)點(diǎn)之后，你還需要把他事無巨細(xì)、毫無歧義的傳達(dá)給諸位實(shí)現(xiàn)者，通常的渠道有四個：PRD、UE/UI、需求評審會議以及日常聊天軟件。輔助的還包括原型圖、用例圖、流程圖等。

其中的起點(diǎn)就是PRD，一般PRD的組成部分是文檔信息、修訂記錄、目錄及正文內(nèi)容，正文內(nèi)容又包括引言、特性所包含的功能、功能性需求等。

由于設(shè)計(jì)師會按照你所撰寫的PRD去輸出UE和UI稿，所以PRD里的邏輯必須十分清晰、完整，盡量考慮好所有的邊界情況和邏輯漏洞，同時在PRD中用語需要規(guī)范，避免由于對于某一詞語理解不同而導(dǎo)致效率降低的情況。

PRD中的功能入口設(shè)置通常需要和UE共同商討，UE在輸出UE稿后需要交給產(chǎn)品經(jīng)理去統(tǒng)一同步到各位技術(shù)手上，為了避免反復(fù)修正和需求變更引起矛盾，產(chǎn)品需要仔細(xì)的確認(rèn)UE稿，防止出現(xiàn)UE稿和PRD矛盾或不同步的情況。

在輸出UE和UI后，會舉行一次需求評審會議，主要是產(chǎn)品經(jīng)理主講，UE輔助，這是講清楚中最重要的部分，因?yàn)檎Z言總是比文字有更強(qiáng)的說服力，在評審會上要明晰各方疑惑的問題并同步到PRD以及UE上。

產(chǎn)品er們也需要去有意識的對文字表達(dá)和語言表達(dá)能力進(jìn)行訓(xùn)練，以便更好的講清楚。

需求評審會議后，開發(fā)的老大一般會進(jìn)行排期，這時候開發(fā)和測試童鞋可能會來與你核對或者確認(rèn)一些需求的細(xì)節(jié)，這時候你就會明白：一份好的prd是提高工作效率的關(guān)鍵，那些prd留下來的坑都是需要產(chǎn)品er后期去填的，千萬不要偷懶~

在溝通時，需要注意當(dāng)聊天軟件無法講清楚時，一定要積極的去找開發(fā)當(dāng)面交流，以避免矛盾的產(chǎn)生，另外要注意用流程的規(guī)范降低交流成本。

比如：你確實(shí)需要變更或許補(bǔ)充一個需求，一定要和開發(fā)以及測試先事先確認(rèn)，再進(jìn)行prd和UE、UI稿的修改，修改后一定要通過郵件或其他方式同步到各方。

變更時的措辭也需要注意，剛實(shí)習(xí)的時候我就曾因同步時，措辭有歧義并且@錯了人而和開發(fā)產(chǎn)生了一點(diǎn)小矛盾。開發(fā)、測試、產(chǎn)品實(shí)在是太容易相互產(chǎn)生怨懟的職位，各盡其職，不拖后腿，才是解決這個問題的根本辦法。

想清楚+講清楚，我正在努力成為一名合格的產(chǎn)品經(jīng)理，你呢？

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

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