了解項(xiàng)目，熟悉業(yè)務(wù)流程及背景

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

首先最重要的是了解這個(gè)產(chǎn)品屬于 B 端產(chǎn)品還是 C 端產(chǎn)品，它的受眾人群是廣大 C 端用戶還是合作公司？因?yàn)槎叩谋举|(zhì)還是有比較大的差別。

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

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

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

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

需求收集

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

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

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

這時(shí)最重要的兩個(gè)問(wèn)題出現(xiàn)了:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

作為一款 B 端產(chǎn)品，要本著提高人效的心態(tài)去完成這款產(chǎn)品，似乎不需要多么炫酷的交互。因?yàn)檫@個(gè)產(chǎn)品的用戶是上來(lái)工作的，不會(huì)因?yàn)槟阋粋€(gè)超炫的視覺(jué)效果而愛(ài)上這個(gè)產(chǎn)品，從而多加加班。

但是最基本的交互是必須要的，如什么時(shí)候用浮層，什么時(shí)候用彈窗，什么時(shí)候打開(kāi)一個(gè)新頁(yè)面，篩選是用下拉還是點(diǎn)擊，完成一件事的操作流程是否足夠簡(jiǎn)潔等等。

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

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

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

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

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

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

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

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

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

正式啟動(dòng)研發(fā)后，還會(huì)發(fā)現(xiàn)之前評(píng)審沒(méi)有發(fā)現(xiàn)的種種問(wèn)題。項(xiàng)目正式啟動(dòng)研發(fā)后，有以下幾點(diǎn)總結(jié)：

每天最好以站會(huì)的形式和大家同步彼此的工作進(jìn)展，因?yàn)橛行┭邪l(fā)會(huì)有多項(xiàng)目并行的情況，如果有影響上線時(shí)間的情況出現(xiàn)，那么也好做出調(diào)整，而不是后知后覺(jué)。

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

如有延期上線風(fēng)險(xiǎn)，合理調(diào)動(dòng)研發(fā)資源。

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

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

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

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

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

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

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

阻塞性 bug

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

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

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

產(chǎn)品上線

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

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

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

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

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

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

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

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

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