本文作(zuò)者系大(dà)衆點評産品經理(lǐ)@七手八腳裸奔地小(xiǎo)石頭 。

本篇本來(lái)打算(suàn)寫如何跟技(jì)術(shù)進行(xíng)溝通(tōng)，其實跟技(jì)術(shù)的溝通(tōng)，是貫穿于整個(gè)從需求文檔到産品上(shàng)線、産品跟蹤、叠代的過程之中的。本篇更多(duō)的是講作(zuò)者工作(zuò)半年來(lái)，從需求文檔到産品上(shàng)線的過程，也希望與同行(xíng)朋友(yǒu)多(duō)交流。

需求文檔看不看

當你(nǐ)辛辛苦苦寫出來(lái)一堆需求文檔，跟UED的同學定好交互、視(shì)覺、重構;滿以為(wèi)技(jì)術(shù)會(huì)認真對待，但(dàn)是你(nǐ)會(huì)發現，技(jì)術(shù)同學基本不會(huì)看你(nǐ)準備的一堆東西，基本是按照自己的理(lǐ)解來(lái)開(kāi)發，當開(kāi)發不下去，第一時(shí)間(jiān)也不是看文檔，而是看測試用例，或者直接跟産品溝通(tōng);基本文檔隻是QA同學對着寫用例。

剛剛開(kāi)始工作(zuò)的時(shí)候，對于技(jì)術(shù)不按照文檔開(kāi)發，是比較着急上(shàng)火(huǒ)的，經曆一段時(shí)間(jiān)後，發現重點就好了。産品的本質是保證産品核心功能的質量，保障用戶體(tǐ)驗，用戶端和(hé)商戶端的功能不能含糊;運營後台、客服後台之類的，保障功能完整和(hé)業務流暢的基礎上(shàng)，可(kě)以給技(jì)術(shù)适當的自由發揮;就算(suàn)是前台頁面，多(duō)聽(tīng)聽(tīng)技(jì)術(shù)的意見，讓技(jì)術(shù)同學參與進來(lái);開(kāi)發過程中，保持溝通(tōng)，對于技(jì)術(shù)提出的問題，最快速度的響應。

什麽樣的需求要寫文檔?對于功能性、涉及業務流轉，狀态切換，邊界條件灰常多(duō)的需求，流程圖、交互、PRD一個(gè)都不能少(shǎo);對于非功能性的需求，提升用戶體(tǐ)驗的部分，文檔可(kě)以不準備，準備好原型圖，然後在上(shàng)面标注出重點，交付的時(shí)候講清楚。

todolist與優先級

産品在叠代過程中，不斷有(yǒu)新的需求，不斷有(yǒu)需求被完成，通(tōng)過list來(lái)管理(lǐ)這些(xiē)需求，整理(lǐ)的過程也是對産品思考的過程，不停問自己，這個(gè)需求用戶是誰，解決什麽問題，是否必要，以及是否必要現在就做(zuò)?

list的好處就是，可(kě)以盡量多(duō)的記錄所有(yǒu)需求，雖然有(yǒu)些(xiē)天生(shēng)就是被砍的命，但(dàn)是list一堆需要完成的事情，對整個(gè)項目組都會(huì)有(yǒu)緊迫感;一句話(huà)講清楚每個(gè)需求，标明(míng)優先級，負責人(rén)，對應的開(kāi)發，開(kāi)始時(shí)間(jiān)，完成時(shí)間(jiān)，完成狀态，讓項目組所有(yǒu)人(rén)(包括老闆)，都知道(dào)我們現在有(yǒu)多(duō)少(shǎo)事情在做(zuò)，已完成來(lái)多(duō)少(shǎo)，接下來(lái)做(zuò)什麽。

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

需求會(huì)議

12年都是一周一次叠代，每周都會(huì)有(yǒu)下次叠代的需求會(huì)議，并不是真正意義上(shàng)的需求評審，産品驅動的公司，基本就是需求講解，交付，以及相關時(shí)間(jiān)點确認

需求準備要充分

在需求會(huì)議上(shàng)，面對技(jì)術(shù)和(hé)QA，甚至老大(dà)們的挑戰，這是正常的，他們會(huì)問為(wèi)啥要這麽做(zuò)，為(wèi)啥不那(nà)麽做(zuò)，甚至直接對你(nǐ)的需求提出挑戰：這個(gè)東西不靠譜，不可(kě)能;拍桌子打闆凳的事情也時(shí)有(yǒu)發生(shēng);唯一避免發生(shēng)的情況，就是對于需求的準備要充分;不管面對何種挑戰，講清楚數(shù)據、用戶需要、和(hé)競争對手怎麽做(zuò)的，基本就能說服;一般隻要保持平和(hé)的心态，不會(huì)有(yǒu)大(dà)問題。

真有(yǒu)自己無法立即解答(dá)的，快速承認錯誤：不好意思，這個(gè)是我沒有(yǒu)準備好，會(huì)後我再去做(zuò)詳細調研和(hé)準備，快速跳(tiào)過這個(gè)問題，繼續下面有(yǒu)把握的內(nèi)容;會(huì)後再去完整論證，并把問題描述清楚，郵件給大(dà)家(jiā);既可(kě)以避免沖突，會(huì)後大(dà)家(jiā)平和(hé)心态來(lái)對待，也便于解決。

講好我的故事

這裏應該是講好用戶的故事，為(wèi)啥叫講好我的故事，因為(wèi)産品需要把自己代入到各個(gè)角色中;做(zuò)過幾次用戶訪談，很(hěn)多(duō)用戶描述這樣一個(gè)場(chǎng)景，我快下班了，拿(ná)出點評App搜索附近找吃(chī)的;運營說這個(gè)這個(gè)很(hěn)煩，我需要這麽這麽做(zuò)，其實可(kě)以這樣就解決了;

客服說，這個(gè)信息在這裏查，那(nà)個(gè)信息在另外一個(gè)頁面，每條記錄處理(lǐ)的時(shí)間(jiān)增加多(duō)少(shǎo)分鍾;

最有(yǒu)意思的是商戶端，商戶那(nà)邊有(yǒu)簽合同的、店(diàn)長、負責人(rén)、前台、收銀，會(huì)計(jì)，每個(gè)人(rén)都有(yǒu)可(kě)能來(lái)用我們的後台，去商戶端做(zuò)訪談的時(shí)候，觀察他們如何使用點評的産品;

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

描述痛點隻是第一步，可(kě)以清楚描述，如果這個(gè)需求做(zuò)來(lái)，運營效率可(kě)以提升多(duō)少(shǎo)，節約多(duō)少(shǎo)成本，最終轉化率預計(jì)提高(gāo)多(duō)少(shǎo)，以及ROI(投入産出比)，所有(yǒu)功能點的改進，最後都可(kě)以結算(suàn)為(wèi)Money，因為(wèi)錢(qián)，會(huì)讓所有(yǒu)人(rén)興奮，并集中精力來(lái)解決問題。

讓更多(duō)的人(rén)參與需求討(tǎo)論

需求被挑戰，會(huì)有(yǒu)點不舒服;但(dàn)是若所有(yǒu)人(rén)都表現出對你(nǐ)的需求漠不關心，那(nà)才是最難受的。如何讓技(jì)術(shù)更多(duō)的參與需求討(tǎo)論：首先可(kě)以挖掘對業務有(yǒu)興趣的人(rén)，多(duō)跟他們聊，他們會(huì)主動告知他們的想法。一般工作(zuò)幾年的技(jì)術(shù)比剛剛工作(zuò)的童鞋更關心;其次讓技(jì)術(shù)有(yǒu)存在感，定時(shí)告知他們相關的産品數(shù)據，月用戶數(shù)，月增長量，收入等，根據技(jì)術(shù)所開(kāi)發的功能點，細化到此功能帶來(lái)的數(shù)據，以及同比環比數(shù)據;最後在Scrum中，計(jì)劃撲克能夠讓所有(yǒu)人(rén)都參與到需求當中，因為(wèi)每個(gè)人(rén)都要評估task的工作(zuò)量，目前來(lái)看，效果還(hái)不錯。

确定好時(shí)間(jiān)點和(hé)相關責任人(rén)

Scrum确實是一個(gè)好的方式，能夠估算(suàn)出工作(zuò)量，并且技(jì)術(shù)自發領取任務，直至每個(gè)人(rén)工作(zuò)內(nèi)容都填充滿整個(gè)sprint。

在未開(kāi)始Scrum之前，每周一次需求會(huì)議，隻是交付好相關需求，由開(kāi)發主管來(lái)指派任務，并定好工作(zuò)計(jì)劃表，然後QA同學補充相關測試安排，最後敲定上(shàng)線時(shí)間(jiān)。

其實不管何種方式，最終的結果導向就是，産品盡快上(shàng)線，且以最有(yǒu)效、風險最小(xiǎo)的方式。

适當地砍需求

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

産品開(kāi)發過程中

保持溝通(tōng)

在産品開(kāi)發過程中，技(jì)術(shù)都是非常有(yǒu)責任心的，會(huì)幫你(nǐ)考慮邊界條件，作(zuò)為(wèi)産品積極響應技(jì)術(shù)提出來(lái)的各種疑問，是維系技(jì)術(shù)與産品之間(jiān)很(hěn)有(yǒu)效的方式。雖然有(yǒu)一些(xiē)問題，可(kě)能是技(jì)術(shù)對需求的理(lǐ)解并沒有(yǒu)産品那(nà)麽深刻，講清楚就好了，沒有(yǒu)必要上(shàng)綱上(shàng)線，因為(wèi)最終大(dà)家(jiā)的目的都是為(wèi)了産品，另外公司開(kāi)始實踐的Scrum也對整個(gè)團隊保持溝通(tōng)，既是要求，更要成為(wèi)一種習慣。

認真對待測試用例

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

需求變更與delay

需求變更是永恒的話(huà)題，Scrum中一般是不接受需求變更，其實不允許變更的本質不是需求定闆不動，而是對産品提出了更好的要求，從需求調研、準備、設計(jì)、交付每一步都需要考慮周全和(hé)清楚;即使在要求嚴格的Scrum中，需求真的不能變更麽?如果臨時(shí)線上(shàng)bug造成用戶無法訪問，技(jì)術(shù)同學是不是要停下手中工作(zuò)，來(lái)排查線上(shàng)故障呢。作(zuò)為(wèi)一個(gè)産品，不是神，盡量保證所有(yǒu)的需求都是合理(lǐ)且必要，并且将所有(yǒu)的需求準備工作(zuò)做(zuò)到位;如果還(hái)不能避免，就要影(yǐng)響甚至說服整個(gè)團隊來(lái)擁抱變化。

正确處理(lǐ)需求變更

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

若是因為(wèi)行(xíng)業或者市場(chǎng)變動，産品轉型等原因，直接向團隊傳達變更的原因，以及接下來(lái)的産品規劃，讓所有(yǒu)人(rén)都看到一個(gè)清晰明(míng)确的目标，技(jì)術(shù)會(huì)有(yǒu)疑問和(hé)挑戰，耐心解答(dá)，通(tōng)過行(xíng)業數(shù)據、競品等角度去闡述;遇到老闆變更需求，那(nà)比較簡單，因為(wèi)老闆的需求優先級永遠是最高(gāo)的，但(dàn)是作(zuò)為(wèi)跟技(jì)術(shù)直接溝通(tōng)的産品，要認真對待老闆變更的部分，若老闆頻繁變更需求，煩的是技(jì)術(shù)，會(huì)不會(huì)以後合作(zuò)留下影(yǐng)響呢。

關于産品delay

不管産品還(hái)是技(jì)術(shù)，沒有(yǒu)人(rén)願意看到delay的;面對delay，怎麽處理(lǐ)?換個(gè)思路：就算(suàn)delay了，隻要用戶還(hái)能用，服務照樣跑，地球還(hái)照樣轉。如果真的導緻用戶不能訪問，整個(gè)技(jì)術(shù)團隊肯定加班加點，不吃(chī)不喝(hē)也會(huì)搞好的。一旦出現delay，整個(gè)團隊一起來(lái)排查delay原因，是需求變更，還(hái)是資源沒到位，還(hái)是項目之間(jiān)的耦合關系，前面小(xiǎo)的改動，導緻後面項目的延期，做(zuò)好每次的總結會(huì)議，并在下一個(gè)叠代中避免此問題。

目前團隊中正慢慢引入Scrum敏捷開(kāi)發，而本篇總結，大(dà)部分是基于小(xiǎo)瀑布模式的叠代;需要學習的還(hái)有(yǒu)很(hěn)多(duō)，一轉眼又過了兩個(gè)月，正式工作(zuò)已經八個(gè)月，需要走的路還(hái)有(yǒu)很(hěn)多(duō)，跟随整個(gè)team一起成長。