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

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

需求文檔看不看

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

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

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

todolist與優(yōu)先級

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

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

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

需求會議

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

需求準備要充分

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

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

講好我的故事

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

客服說，這個信息在這里查，那個信息在另外一個頁面，每條記錄處理的時間增加多少分鐘；

最有意思的是商戶端，商戶那邊有簽合同的、店長、負責人、前臺、收銀，會計，每個人都有可能來用我們的后臺，去商戶端做訪談的時候，觀察他們?nèi)绾问褂命c評的產(chǎn)品；

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

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

讓更多的人參與需求討論

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

確定好時間點和相關(guān)責任人

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

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

適當?shù)乜承枨?/span>

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

產(chǎn)品開發(fā)過程中

保持溝通

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

認真對待測試用例

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

需求變更與delay

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

正確處理需求變更

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

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

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

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

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