—— BEGIN ——

本人作為一枚初入產(chǎn)品領(lǐng)域的小白,，在加入公司后,，有幸參與了一個從 0 到 1 的項目（B 端工單系統(tǒng)，涉及微信 H5 及 PC 管理后臺）,，短短幾個月時間,，對如何做產(chǎn)品有了一點自己的想法以及理解。

了解項目

熟悉業(yè)務(wù)流程及背景

當(dāng)你接手了一個項目時,，先不要去著急了解這個產(chǎn)品的功能,，它的用戶體驗好不好。

首先最重要的是了解這個產(chǎn)品屬于 B 端產(chǎn)品還是 C 端產(chǎn)品,，它的受眾人群是廣大 C 端用戶還是合作公司,？因為二者的本質(zhì)還是有比較大的差別。

使用 B 端產(chǎn)品的用戶,，希望通過這款產(chǎn)品可以將自己內(nèi)部管理混亂的流程標(biāo)準(zhǔn)化,，最最重要的就是可以提高人效。為了提高人效也許不會那么注重用戶體驗,，更不會有一些很炫酷的交互,，正如張小龍大神所說的：用完即走。因為作為 B 端產(chǎn)品不需要對用戶增加什么粘性,。

其次需要熟悉為什么要有這個產(chǎn)品,，打造這個產(chǎn)品的初衷是什么,？為了解決當(dāng)時的什么問題,？有和沒有這個產(chǎn)品對實際業(yè)務(wù)有什么影響？提高人效是否可以量化（如：沒這個產(chǎn)品辦一件事需要1小時,，有了這個產(chǎn)品后,，辦相同的事只需要 1 分鐘）？整個產(chǎn)品的未來規(guī)劃是什么,？

尤其是 B 端產(chǎn)品,，要緊跟公司的戰(zhàn)略發(fā)展，必須熟悉了解公司當(dāng)前的戰(zhàn)略發(fā)展是什么,，最重要的戰(zhàn)略合作伙伴有哪些,，這個產(chǎn)品在公司戰(zhàn)略發(fā)展中起到什么樣的地位。

相信對這個產(chǎn)品有了以上的了解后,，在日后的產(chǎn)品需求優(yōu)先級的判斷,，及產(chǎn)品設(shè)計中會更游刃有余,。

需求收集

通過對以上內(nèi)容對產(chǎn)品的歷史及未來有了一定的了解后，接下來就要進(jìn)入整個產(chǎn)品的初始階段：收集需求,。既然是一款緊隨公司戰(zhàn)略發(fā)展的 B 端產(chǎn)品,，那么高優(yōu)需求一定是來自業(yè)務(wù)部門以及相關(guān)戰(zhàn)略合作公司。

首先收集最高優(yōu)緊急的需求,，也就是與當(dāng)前公司戰(zhàn)略發(fā)展最密切相關(guān)的,，根據(jù)關(guān)鍵需求梳理 MVP 主流程，同時產(chǎn)出流程圖,。然后確認(rèn)該流程圖中所涉及的角色有哪些,，每個角色應(yīng)該有哪些最基本的功能，才能使整個流程不阻塞,，走的通,。

有些 B 端產(chǎn)品不僅涉及到公司內(nèi)部的多個部門，還涉及到公司戰(zhàn)略發(fā)展的合作伙伴,，這時你就會發(fā)現(xiàn)每個部門或合作公司,，都會對這個產(chǎn)品都會提一些自己的需求。

這時最重要的兩個問題出現(xiàn)了:

1. 需求提交流程規(guī)范化

當(dāng)有很多部門或合作公司同時對你所負(fù)責(zé)的產(chǎn)品提需求時,，作為 PM ,，我們是需求的收集方，同時也是需求的過濾方,，更是善于梳理流程的專業(yè)戶,。

可以讓每個部門選出一個負(fù)責(zé)收集該產(chǎn)品需求的負(fù)責(zé)人，每個部門人員的需求統(tǒng)一提交至需求負(fù)責(zé)人處,；同時,，每個部門的需求負(fù)責(zé)人，再選出一個總的需求負(fù)責(zé)人,，由總的需求負(fù)責(zé)人收集所有部門負(fù)責(zé)人的需求,，同時過濾掉一些提交重復(fù)的需求，最后以正式的形式（郵件）交至 PM 手中,。

接到需求后,，PM 線下和各部門需求提交人積極溝通，了解需求背后的邏輯,，需求產(chǎn)生的原因,，自己再過濾一些偽需求。

2. 需求優(yōu)先級判斷要明確

當(dāng)非常多的需求到 PM 手中后,，不可能所有需求都在一個版本做完,，就算 PM 產(chǎn)品設(shè)計能做得完，但是也得問問天天加班加點的程序員哥哥愿不愿意啊～

所以,，要制定重要的需求優(yōu)先級排序,，明確下一個版本要達(dá)成什么目標(biāo),，需要什么功能，在不影響大版本發(fā)版的情況下,，可以對哪些小的功能進(jìn)行優(yōu)化,。

明確了需求優(yōu)先級后，便可以進(jìn)入到下一個環(huán)節(jié)— 產(chǎn)品設(shè)計,。

通過以上行為收集了需求,，并且明確了需求的優(yōu)先級，對下一個版本的迭代目標(biāo)有了更深的理解之外后,，再補充一下需求收集中,。尤其是迭代目標(biāo)需要注意的幾個重點，避免踩坑：

• 無論任何需求傳遞到 PM 手中,，都要與提這個需求的人直接溝通,，而不是層層傳遞，拒絕接收二手需求（如：運營中心市場部門員工A提交需求至本部門需求負(fù)責(zé)人 B 手中,，B 再將需求匯總傳遞至運營中心總需求負(fù)責(zé)人 C 手中,，C 將需求傳遞至 PM，PM 需要對需求進(jìn)行核實了解,，應(yīng)直接找到 A,，而不是 B 或 C）

• 當(dāng) PM 收集了很多需求后，自然要結(jié)合公司發(fā)展戰(zhàn)略,，總結(jié)出下一個版本需迭代的高優(yōu)需求,。既然是公司戰(zhàn)略層面的問題，自然少不了開會,。每次開會,，會議的決策人最好在場，避免以后將本次會上的所達(dá)成的結(jié)論推翻,。需求高優(yōu)不高優(yōu),，有時就是老板一句話的事兒。并且在會議結(jié)束后,，要將會議紀(jì)要同步所有相關(guān)人員,，做到信息一致,。

產(chǎn)品設(shè)計

Axure 是 PM 吃飯的家伙,，你可以不會 PS，不會編程,，但是 Axure 你必須得會,。

我非常享受畫產(chǎn)品原型的時候，因為這個時候,，才是 PM 真正發(fā)揮創(chuàng)造力的時候,。此階段最重要的兩個產(chǎn)物,，是產(chǎn)品原型和 PRD 文檔，產(chǎn)品原型決定了你的產(chǎn)品長什么樣,，而 PRD 文檔決定了你的產(chǎn)品規(guī)則邏輯,。

作為產(chǎn)品小白，剛開始畫產(chǎn)品原型的時候,，面對一大片空白區(qū)域,，真的不知如何下手，這一點我深有體會,。此時不妨去看看別的產(chǎn)品是怎么做的,，競品也好，還是當(dāng)今最流行的產(chǎn)品也罷,，真的會幫助你少踩不少坑,，最好多看幾款產(chǎn)品，取其精華去其糟粕,。

作為一款 B 端產(chǎn)品,，要本著提高人效的心態(tài)去完成這款產(chǎn)品，似乎不需要多么炫酷的交互,。因為這個產(chǎn)品的用戶是上來工作的,，不會因為你一個超炫的視覺效果而愛上這個產(chǎn)品，從而多加加班,。

但是最基本的交互是必須要的,，如什么時候用浮層，什么時候用彈窗,，什么時候打開一個新頁面,，篩選是用下拉還是點擊，完成一件事的操作流程是否足夠簡潔等等,。

界面樣式,，只是這個產(chǎn)品的表現(xiàn)形式，應(yīng)該對任何一個細(xì)小的功能有更多的聯(lián)想,。例如一個工單列表頁,，涉及到很多信息：工單提交人、工單實施人,、提交工單時間,、工單狀態(tài)、工單完成時間,、工單所在地,、工單名稱等等等等。

這里就涉及到信息展示的問題,，要聯(lián)想到誰會用到這個頁面,？可能是管理者要登錄后臺看自己公司的工單信息,，那么他希望看到什么？可能要看看自己哪個員工又簽單了,，什么時候簽的單,，工單的進(jìn)展如何了，并且看到這些信息之后有什么樣的操作,？可能要對已完成的工單操作一下服務(wù)成功,，或者把某一個進(jìn)展不順利的單重新分配給自己其他員工，他希望的達(dá)到怎樣的效果,？

所以要對如此多的信息進(jìn)行篩選,，列出操作此功能的人最關(guān)心的信息，將其不關(guān)心的信息弱化,，或者在工單詳情頁去展示,，并且配上可能出現(xiàn)的場景操作。

在產(chǎn)品設(shè)計中,，一定要注意產(chǎn)品設(shè)計的細(xì)節(jié),，任何細(xì)節(jié)都不可想當(dāng)然。因為研發(fā)會根據(jù)你所有的需求描述去實現(xiàn)產(chǎn)品,，可能會因為一個小細(xì)節(jié)的變動,，牽一發(fā)而多全身，有時只是 PM 的一句話,，但是卻是研發(fā)工作的一整天,。

PRD 文檔的書寫要細(xì)心，盡量要多考慮產(chǎn)品的邊界值,，如：設(shè)置密碼,，密碼的長度控制在多少位，是否需要特殊符號,，大小寫是否有區(qū)分,，對輸入不規(guī)范的報錯形式是怎樣，文案怎么寫能讓用戶知道自己輸錯了等等,。

一些技術(shù)難題,，可以拋給研發(fā)去處理，但是對于產(chǎn)品需求,，一定要自己去構(gòu)思完成,。

產(chǎn)品開發(fā)

終于到了將自己的構(gòu)思實現(xiàn)出來的重要一步，交付研發(fā),。其中自然少不了評（si）審（bi）,，我們現(xiàn)階段的產(chǎn)品評審流程為：組內(nèi)評審—設(shè)計評審—和業(yè)務(wù)部門評審—研發(fā)評審—項目啟動。

如果想著研發(fā)哥哥會按照自己的產(chǎn)品原型和需求文檔,，任勞任怨的實現(xiàn)出來,，那你就大錯特錯了。

正式啟動研發(fā)后,，還會發(fā)現(xiàn)之前評審沒有發(fā)現(xiàn)的種種問題,。項目正式啟動研發(fā)后，有以下幾點總結(jié)：

• 每天最好以站會的形式和大家同步彼此的工作進(jìn)展,，因為有些研發(fā)會有多項目并行的情況,，如果有影響上線時間的情況出現(xiàn)，那么也好做出調(diào)整,，而不是后知后覺,。

• 需求和研發(fā)成本如何取舍，根據(jù)當(dāng)前項目緊迫程度做好評估,。如某一個需求,，研發(fā)成本比較高，那此時需判斷此需求是否影響主流程,，是否屬于 MVP 功能,，如果會影響主流程，非做不可,，但是做了會影響上線時間,，那么就要及時協(xié)調(diào)研發(fā)資源，如果又沒有多余的研發(fā)資源可供協(xié)調(diào),，那么就要考慮變更需求或聽取研發(fā)的其他建議了,。如果不是影響主流程的需求，那么就要根據(jù)當(dāng)前項目緊迫程度做好評估,，是否可以將此需求延遲至下一個版本,。

• 如有延期上線風(fēng)險，合理調(diào)動研發(fā)資源,。

• 盡量考慮周全所能遇到的場景,，以便研發(fā)設(shè)計技術(shù)框架。

• 我所用到的項目管理工具是 jira,，會在每一次的項目啟動后建立相關(guān)的用戶故事和任務(wù),，任務(wù)分配給各自負(fù)責(zé)的研發(fā)就好，用戶故事可以存放原型和 PRD 文檔,。

測試環(huán)節(jié)

辛苦的程序猿哥哥通過加班加點的寫代碼,，終于通過了聯(lián)調(diào)，將自己的代碼部署到了測試環(huán)境,，那么就該測試和 PM 上場了,。

測試評審盡量叫上相關(guān)研發(fā)人員，可以作為產(chǎn)品實現(xiàn)是否正確的二次確認(rèn)。并且評審要細(xì)致,，將各個功能的不同操作所導(dǎo)致的結(jié)果考慮情況全面,，歸根結(jié)底還是 PRD 文檔要書寫全面，因為測試同學(xué)會根據(jù) PRD 文檔來寫測試 case,。沒錯,，一切都是產(chǎn)品的鍋。

每一次新版本的迭代,，不僅要測試新增加的功能是否有 bug,，還是測試產(chǎn)品的主流程是否受到本次迭代的影響。

關(guān)于 bug,，我認(rèn)為兩種非常緊急且重要：

1. 阻塞性 bug

2. 影響業(yè)務(wù)的 bug

阻塞性的 bug 自然不用多說,，例如你用微信聊天，信息發(fā)不出去,；用攜程買機票,，沒法兒出票。

而影響業(yè)務(wù)的 bug 是指：用攜程買機票,，本來機票 1000 塊,，但是用戶 1 塊就買到了，這個 bug 不屬于阻塞性,，但是卻影響重大,。

產(chǎn)品上線

我們產(chǎn)品上線的流程為：研發(fā)提交上線申請 — 測試回復(fù)測試通過并且展示 bug 處理情況—產(chǎn)品驗證是否通過—產(chǎn)品上線—產(chǎn)品發(fā) release 郵件周知老板們及項目成員。

產(chǎn)品上線意味著兩件事：

1. 可以進(jìn)入到下一個版本迭代的工作當(dāng)中了,。

2. 對本次上線的產(chǎn)品功能負(fù)責(zé),。

在此主要整理一下產(chǎn)品上線后的注意事項：

• 尤其是一款 B 端產(chǎn)品，一定要在產(chǎn)品上線前幾天,，對公司內(nèi)部用到該產(chǎn)品的所有部門進(jìn)行相關(guān)培訓(xùn),，并且編寫產(chǎn)品功能使用手冊及時同步大家。

• 線上回歸測試,，收集 bug,，嚴(yán)重 bug 緊急修復(fù)；影響不大的 bug 可以考慮到下一個版本迭代修復(fù),。

• 收集用戶的使用反饋,，對體驗不好的功能進(jìn)行優(yōu)化。

• 數(shù)據(jù)監(jiān)測,，最好通過線上數(shù)據(jù),，可以給業(yè)務(wù)部門一些指導(dǎo)性的建議。

我每天都會自己寫日報,，記錄項目的的進(jìn)展,，以及某些會議達(dá)成的重要結(jié)論,。并且也會記錄自己在工作中認(rèn)為重要的產(chǎn)品體會，每天沒事兒看一看,，相信看的多了會有更深的領(lǐng)悟,。