中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

本文重點(diǎn)描述產(chǎn)品從需求收集到上線過(guò)程中注意事項(xiàng)，如何避免踩坑類似的經(jīng)驗(yàn)總結(jié)，以下內(nèi)容以B端產(chǎn)品為例，獻(xiàn)給同樣是小白的你。

了解項(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)樽鳛锽端產(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ù)部門以及相關(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è)部門，還涉及到公司戰(zhàn)略發(fā)展的合作伙伴，這時(shí)你就會(huì)發(fā)現(xiàn)每個(gè)部門或合作公司，都會(huì)對(duì)這個(gè)產(chǎn)品都會(huì)提一些自己的需求。

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

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

當(dāng)有很多部門或合作公司同時(shí)對(duì)你所負(fù)責(zé)的產(chǎn)品提需求時(shí)，作為PM，我們是需求的收集方，同時(shí)也是需求的過(guò)濾方，更是善于梳理流程的專業(yè)戶?？梢宰屆總€(gè)部門選出一個(gè)負(fù)責(zé)收集該產(chǎn)品需求的負(fù)責(zé)人，每個(gè)部門人員的需求統(tǒng)一提交至需求負(fù)責(zé)人處；同時(shí)，每個(gè)部門的需求負(fù)責(zé)人，再選出一個(gè)總的需求負(fù)責(zé)人，由總的需求負(fù)責(zé)人收集所有部門負(fù)責(zé)人的需求，同時(shí)過(guò)濾掉一些提交重復(fù)的需求，最后以正式的形式（郵件）交至pm手中。接到需求后，pm線下和各部門需求提交人積極溝通，了解需求背后的邏輯，需求產(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)部門員工A提交需求至本部門需求負(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)題，自然少不了開會(huì)。每次開會(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ì)。我非常享受畫產(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)品小白，剛開始畫產(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í)候打開一個(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文檔的書寫要細(xì)心，盡量要多考慮產(chǎn)品的邊界值，如：設(shè)置密碼，密碼的長(zhǎng)度控制在多少位，是否需要特殊符號(hào)，大小寫是否有區(qū)分，對(duì)輸入不規(guī)范的報(bào)錯(cuò)形式是怎樣，文案怎么寫能讓用戶知道自己輸錯(cuò)了等等。一些技術(shù)難題，可以拋給研發(fā)去處理，但是對(duì)于產(chǎn)品需求，一定要自己去構(gòu)思完成。

產(chǎn)品開發(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ù)部門評(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)，那么就要考慮變更需求或聽取研發(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)的寫代碼，終于通過(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文檔要書寫全面，因?yàn)闇y(cè)試同學(xué)會(huì)根據(jù)prd文檔來(lái)寫測(cè)試case。沒(méi)錯(cuò)，一切都是產(chǎn)品的鍋。

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

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

1. 阻塞性bug
2. 影響業(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)品上線意味著兩件事：

1. 可以進(jìn)入到下一個(gè)版本迭代的工作當(dāng)中了。
2. 對(duì)本次上線的產(chǎn)品功能負(fù)責(zé)。

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

• 尤其是一款B端產(chǎn)品，一定要在產(chǎn)品上線前幾天，對(duì)公司內(nèi)部用到該產(chǎn)品的所有部門進(jìn)行相關(guān)培訓(xùn)，并且編寫產(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ù)部門一些指導(dǎo)性的建議。

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

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