產(chǎn)品經(jīng)理成長(zhǎng)日記-從需求到產(chǎn)品

本篇本來(lái)打算寫(xiě)如何跟技術(shù)進(jìn)行溝通，其實(shí)跟技術(shù)的溝通，是貫穿于整個(gè)從需求文檔到產(chǎn)品上線、產(chǎn)品跟蹤、迭代的過(guò)程之中的。本篇更多的是講作者工作半年來(lái)，從需求文檔到產(chǎn)品上線的過(guò)程，也希望與同行朋友多交流。

需求文檔看不看

當(dāng)你辛辛苦苦寫(xiě)出來(lái)一堆需求文檔，跟UED的同學(xué)定好交互、視覺(jué)、重構(gòu)；滿以為技術(shù)會(huì)認(rèn)真對(duì)待，但是你會(huì)發(fā)現(xiàn)，技術(shù)同學(xué)基本不會(huì)看你準(zhǔn)備的一堆東西，基本是按照自己的理解來(lái)開(kāi)發(fā)，當(dāng)開(kāi)發(fā)不下去，第一時(shí)間也不是看文檔，而是看測(cè)試用例，或者直接跟產(chǎn)品溝通；基本文檔只是QA同學(xué)對(duì)著寫(xiě)用例。

剛剛開(kāi)始工作的時(shí)候，對(duì)于技術(shù)不按照文檔開(kāi)發(fā)，是比較著急上火的，經(jīng)歷一段時(shí)間后，發(fā)現(xiàn)重點(diǎn)就好了。產(chǎn)品的本質(zhì)是保證產(chǎn)品核心功能的質(zhì)量，保障用戶體驗(yàn)，用戶端和商戶端的功能不能含糊；運(yùn)營(yíng)后臺(tái)、客服后臺(tái)之類的，保障功能完整和業(yè)務(wù)流暢的基礎(chǔ)上，可以給技術(shù)適當(dāng)?shù)淖杂砂l(fā)揮；就算是前臺(tái)頁(yè)面，多聽(tīng)聽(tīng)技術(shù)的意見(jiàn)，讓技術(shù)同學(xué)參與進(jìn)來(lái)；開(kāi)發(fā)過(guò)程中，保持溝通，對(duì)于技術(shù)提出的問(wèn)題，最快速度的響應(yīng)。

什么樣的需求要寫(xiě)文檔？對(duì)于功能性、涉及業(yè)務(wù)流轉(zhuǎn)，狀態(tài)切換，邊界條件灰常多的需求，流程圖、交互、PRD一個(gè)都不能少；對(duì)于非功能性的需求，提升用戶體驗(yàn)的部分，文檔可以不準(zhǔn)備，準(zhǔn)備好原型圖，然后在上面標(biāo)注出重點(diǎn)，交付的時(shí)候講清楚。

todolist與優(yōu)先級(jí)

產(chǎn)品在迭代過(guò)程中，不斷有新的需求，不斷有需求被完成，通過(guò)list來(lái)管理這些需求，整理的過(guò)程也是對(duì)產(chǎn)品思考的過(guò)程，不停問(wèn)自己，這個(gè)需求用戶是誰(shuí)，解決什么問(wèn)題，是否必要，以及是否必要現(xiàn)在就做？

list的好處就是，可以盡量多的記錄所有需求，雖然有些天生就是被砍的命，但是list一堆需要完成的事情，對(duì)整個(gè)項(xiàng)目組都會(huì)有緊迫感；一句話講清楚每個(gè)需求，標(biāo)明優(yōu)先級(jí)，負(fù)責(zé)人，對(duì)應(yīng)的開(kāi)發(fā)，開(kāi)始時(shí)間，完成時(shí)間，完成狀態(tài)，讓項(xiàng)目組所有人（包括老板），都知道我們現(xiàn)在有多少事情在做，已完成來(lái)多少，接下來(lái)做什么。

需求永遠(yuǎn)做不完，對(duì)于優(yōu)先級(jí)安排，平時(shí)工作中最常用的就是四象限法，重要又緊急，重要不緊急，緊急不重要，不緊急也不重要，根據(jù)項(xiàng)目實(shí)際來(lái)做判斷。

需求會(huì)議

12年都是一周一次迭代，每周都會(huì)有下次迭代的需求會(huì)議，并不是真正意義上的需求評(píng)審，產(chǎn)品驅(qū)動(dòng)的公司，基本就是需求講解，交付，以及相關(guān)時(shí)間點(diǎn)確認(rèn)

需求準(zhǔn)備要充分

在需求會(huì)議上，面對(duì)技術(shù)和QA，甚至老大們的挑戰(zhàn)，這是正常的，他們會(huì)問(wèn)為啥要這么做，為啥不那么做，甚至直接對(duì)你的需求提出挑戰(zhàn)：這個(gè)東西不靠譜，不可能；拍桌子打板凳的事情也時(shí)有發(fā)生；唯一避免發(fā)生的情況，就是對(duì)于需求的準(zhǔn)備要充分；不管面對(duì)何種挑戰(zhàn)，講清楚數(shù)據(jù)、用戶需要、和競(jìng)爭(zhēng)對(duì)手怎么做的，基本就能說(shuō)服；一般只要保持平和的心態(tài)，不會(huì)有大問(wèn)題。

真有自己無(wú)法立即解答的，快速承認(rèn)錯(cuò)誤：不好意思，這個(gè)是我沒(méi)有準(zhǔn)備好，會(huì)后我再去做詳細(xì)調(diào)研和準(zhǔn)備，快速跳過(guò)這個(gè)問(wèn)題，繼續(xù)下面有把握的內(nèi)容；會(huì)后再去完整論證，并把問(wèn)題描述清楚，郵件給大家；既可以避免沖突，會(huì)后大家平和心態(tài)來(lái)對(duì)待，也便于解決。

講好我的故事

這里應(yīng)該是講好用戶的故事，為啥叫講好我的故事，因?yàn)楫a(chǎn)品需要把自己代入到各個(gè)角色中；做過(guò)幾次用戶訪談，很多用戶描述這樣一個(gè)場(chǎng)景，我快下班了，拿出點(diǎn)評(píng)App搜索附近找吃的；運(yùn)營(yíng)說(shuō)這個(gè)這個(gè)很煩，我需要這么這么做，其實(shí)可以這樣就解決了；

客服說(shuō)，這個(gè)信息在這里查，那個(gè)信息在另外一個(gè)頁(yè)面，每條記錄處理的時(shí)間增加多少分鐘；

最有意思的是商戶端，商戶那邊有簽合同的、店長(zhǎng)、負(fù)責(zé)人、前臺(tái)、收銀，會(huì)計(jì)，每個(gè)人都有可能來(lái)用我們的后臺(tái)，去商戶端做訪談的時(shí)候，觀察他們?nèi)绾问褂命c(diǎn)評(píng)的產(chǎn)品；

講需求的時(shí)候，先描述用戶遇到的困境，繪聲繪色，動(dòng)人心弦；如何做到，代入自己的角色，不要假裝用過(guò)，而是自己真正使用過(guò)程中的痛點(diǎn)，放大再放大，感情方式來(lái)打動(dòng)技術(shù)。

描述痛點(diǎn)只是第一步，可以清楚描述，如果這個(gè)需求做來(lái)，運(yùn)營(yíng)效率可以提升多少，節(jié)約多少成本，最終轉(zhuǎn)化率預(yù)計(jì)提高多少，以及ROI（投入產(chǎn)出比），所有功能點(diǎn)的改進(jìn)，最后都可以結(jié)算為Money，因?yàn)殄X(qián)，會(huì)讓所有人興奮，并集中精力來(lái)解決問(wèn)題。

讓更多的人參與需求討論

需求被挑戰(zhàn)，會(huì)有點(diǎn)不舒服；但是若所有人都表現(xiàn)出對(duì)你的需求漠不關(guān)心，那才是最難受的。如何讓技術(shù)更多的參與需求討論：首先可以挖掘?qū)I(yè)務(wù)有興趣的人，多跟他們聊，他們會(huì)主動(dòng)告知他們的想法。一般工作幾年的技術(shù)比剛剛工作的童鞋更關(guān)心；其次讓技術(shù)有存在感，定時(shí)告知他們相關(guān)的產(chǎn)品數(shù)據(jù)，月用戶數(shù)，月增長(zhǎng)量，收入等，根據(jù)技術(shù)所開(kāi)發(fā)的功能點(diǎn)，細(xì)化到此功能帶來(lái)的數(shù)據(jù)，以及同比環(huán)比數(shù)據(jù)；最后在Scrum中，計(jì)劃撲克能夠讓所有人都參與到需求當(dāng)中，因?yàn)槊總€(gè)人都要評(píng)估task的工作量，目前來(lái)看，效果還不錯(cuò)。

確定好時(shí)間點(diǎn)和相關(guān)責(zé)任人

Scrum確實(shí)是一個(gè)好的方式，能夠估算出工作量，并且技術(shù)自發(fā)領(lǐng)取任務(wù)，直至每個(gè)人工作內(nèi)容都填充滿整個(gè)sprint。
在未開(kāi)始Scrum之前，每周一次需求會(huì)議，只是交付好相關(guān)需求，由開(kāi)發(fā)主管來(lái)指派任務(wù)，并定好工作計(jì)劃表，然后QA同學(xué)補(bǔ)充相關(guān)測(cè)試安排，最后敲定上線時(shí)間。

其實(shí)不管何種方式，最終的結(jié)果導(dǎo)向就是，產(chǎn)品盡快上線，且以最有效、風(fēng)險(xiǎn)最小的方式。

適當(dāng)?shù)乜承枨?/span>

產(chǎn)品是不需要懂技術(shù)，但是如果能根據(jù)需求大致預(yù)估工作量，排期更簡(jiǎn)單；每次我都會(huì)提前多準(zhǔn)備一些，連交互和重構(gòu)都準(zhǔn)備好，擺出一副不做此需求是誓不罷休的架勢(shì)；資源充分時(shí)，技術(shù)童鞋會(huì)主動(dòng)領(lǐng)取需求的，但是當(dāng)工作都排的比較滿的時(shí)候，就很難了；所以需求評(píng)審時(shí)，每個(gè)需求的優(yōu)先級(jí)都排的高高的，將用戶痛點(diǎn)描述的栩栩如生，如果技術(shù)實(shí)在抱怨太多，那就象征性地砍掉部分，前提是保證核心必須完成，其實(shí)當(dāng)砍掉一部分，不會(huì)一直砍下去，而且心里也會(huì)有滿足感；其次給技術(shù)緊迫感，趕緊完成，后面還有一堆事情呢，即使這次迭代不做，下次迭代也需要完成

產(chǎn)品開(kāi)發(fā)過(guò)程中

保持溝通

在產(chǎn)品開(kāi)發(fā)過(guò)程中，技術(shù)都是非常有責(zé)任心的，會(huì)幫你考慮邊界條件，作為產(chǎn)品積極響應(yīng)技術(shù)提出來(lái)的各種疑問(wèn)，是維系技術(shù)與產(chǎn)品之間很有效的方式。雖然有一些問(wèn)題，可能是技術(shù)對(duì)需求的理解并沒(méi)有產(chǎn)品那么深刻，講清楚就好了，沒(méi)有必要上綱上線，因?yàn)樽罱K大家的目的都是為了產(chǎn)品，另外公司開(kāi)始實(shí)踐的Scrum也對(duì)整個(gè)團(tuán)隊(duì)保持溝通，既是要求，更要成為一種習(xí)慣。

認(rèn)真對(duì)待測(cè)試用例

測(cè)試用例，又是一個(gè)保證產(chǎn)品質(zhì)量的利器；剛開(kāi)始工作的時(shí)候，認(rèn)為測(cè)試用例只是QA同學(xué)的工作，第一版本App上線做UAT的時(shí)候，發(fā)現(xiàn)對(duì)著需求文檔并不能完整驗(yàn)證完所有需求，但是對(duì)著測(cè)試用例，所有的主流程，輔助流程，邊界條件，非功能性需求，清晰明了，感覺(jué)太有用了。所以每次都提前完成需求文檔交付QA，QA在技術(shù)正式進(jìn)入研發(fā)完成用例文檔；在過(guò)測(cè)試用例時(shí)，產(chǎn)品同時(shí)參與，避免一些需求理解上的偏差，此外技術(shù)同學(xué)對(duì)著case開(kāi)發(fā)，比需求文檔描述更清晰，另外技術(shù)同學(xué)可以參與部分自測(cè)；UAT的時(shí)候，也是產(chǎn)品的參考。

需求變更與delay

需求變更是永恒的話題，Scrum中一般是不接受需求變更，其實(shí)不允許變更的本質(zhì)不是需求定板不動(dòng)，而是對(duì)產(chǎn)品提出了更好的要求，從需求調(diào)研、準(zhǔn)備、設(shè)計(jì)、交付每一步都需要考慮周全和清楚；即使在要求嚴(yán)格的Scrum中，需求真的不能變更么？如果臨時(shí)線上bug造成用戶無(wú)法訪問(wèn)，技術(shù)同學(xué)是不是要停下手中工作，來(lái)排查線上故障呢。作為一個(gè)產(chǎn)品，不是神，盡量保證所有的需求都是合理且必要，并且將所有的需求準(zhǔn)備工作做到位；如果還不能避免，就要影響甚至說(shuō)服整個(gè)團(tuán)隊(duì)來(lái)?yè)肀ё兓?/span>

正確處理需求變更

需求變更已經(jīng)發(fā)生，那就趕緊處理吧。如果是產(chǎn)品沒(méi)考慮清楚，用戶調(diào)研或者數(shù)據(jù)支持出錯(cuò)，果斷向團(tuán)隊(duì)承認(rèn)自己的錯(cuò)誤，沒(méi)有人會(huì)責(zé)怪一個(gè)真心誠(chéng)意道歉的人；并在第一時(shí)間交付變更后的需求文檔、交互、視覺(jué)、重構(gòu)等，并跟技術(shù)溝通如何以最小的代價(jià)，完成此次實(shí)現(xiàn)；若技術(shù)的工作在本次迭代已經(jīng)安排很滿，那考慮需求的緊急程度，適當(dāng)情況下，可以放到下個(gè)迭代去完成。

若是因?yàn)樾袠I(yè)或者市場(chǎng)變動(dòng)，產(chǎn)品轉(zhuǎn)型等原因，直接向團(tuán)隊(duì)傳達(dá)變更的原因，以及接下來(lái)的產(chǎn)品規(guī)劃，讓所有人都看到一個(gè)清晰明確的目標(biāo)，技術(shù)會(huì)有疑問(wèn)和挑戰(zhàn)，耐心解答，通過(guò)行業(yè)數(shù)據(jù)、競(jìng)品等角度去闡述；遇到老板變更需求，那比較簡(jiǎn)單，因?yàn)槔习宓男枨髢?yōu)先級(jí)永遠(yuǎn)是最高的，但是作為跟技術(shù)直接溝通的產(chǎn)品，要認(rèn)真對(duì)待老板變更的部分，若老板頻繁變更需求，煩的是技術(shù)，會(huì)不會(huì)以后合作留下影響呢。

關(guān)于產(chǎn)品delay

不管產(chǎn)品還是技術(shù)，沒(méi)有人愿意看到delay的；面對(duì)delay，怎么處理？換個(gè)思路：就算delay了，只要用戶還能用，服務(wù)照樣跑，地球還照樣轉(zhuǎn)。如果真的導(dǎo)致用戶不能訪問(wèn)，整個(gè)技術(shù)團(tuán)隊(duì)肯定加班加點(diǎn)，不吃不喝也會(huì)搞好的。一旦出現(xiàn)delay，整個(gè)團(tuán)隊(duì)一起來(lái)排查delay原因，是需求變更，還是資源沒(méi)到位，還是項(xiàng)目之間的耦合關(guān)系，前面小的改動(dòng)，導(dǎo)致后面項(xiàng)目的延期，做好每次的總結(jié)會(huì)議，并在下一個(gè)迭代中避免此問(wèn)題。

目前團(tuán)隊(duì)中正慢慢引入Scrum敏捷開(kāi)發(fā)，而本篇總結(jié)，大部分是基于小瀑布模式的迭代；需要學(xué)習(xí)的還有很多，一轉(zhuǎn)眼又過(guò)了兩個(gè)月，正式工作已經(jīng)八個(gè)月，需要走的路還有很多，跟隨整個(gè)team一起成長(zhǎng)。