—— BEGIN ——
本人作為一枚初入產(chǎn)品領(lǐng)域的小白，在加入公司后，有幸參與了一個從 0 到 1 的項目（B 端工單系統(tǒng)，涉及微信 H5 及 PC 管理后臺），短短幾個月時間，對如何做產(chǎn)品有了一點自己的想法以及理解。
當(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)有了更深的理解之外后，再補(bǔ)充一下需求收集中。尤其是迭代目標(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)人員，做到信息一致。
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)思完成。
終于到了將自己的構(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 文檔。
辛苦的程序猿哥哥通過加班加點的寫代碼，終于通過了聯(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)為兩種非常緊急且重要：
阻塞性 bug
影響業(yè)務(wù)的 bug
阻塞性的 bug 自然不用多說，例如你用微信聊天，信息發(fā)不出去；用攜程買機(jī)票，沒法兒出票。
而影響業(yè)務(wù)的 bug 是指：用攜程買機(jī)票，本來機(jī)票 1000 塊，但是用戶 1 塊就買到了，這個 bug 不屬于阻塞性，但是卻影響重大。
我們產(chǎn)品上線的流程為：研發(fā)提交上線申請 — 測試回復(fù)測試通過并且展示 bug 處理情況—產(chǎn)品驗證是否通過—產(chǎn)品上線—產(chǎn)品發(fā) release 郵件周知老板們及項目成員。
產(chǎn)品上線意味著兩件事：
可以進(jìn)入到下一個版本迭代的工作當(dāng)中了。
對本次上線的產(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)悟。
聯(lián)系客服
