運營提需求，說加上支付寶支付吧，好像看起來很簡單，但其實卻沒那麼簡單。這也是我寫這篇文章的緣由，下面就來詳細說一下。
一、問題描述
我們項目裡有付費產品，目前只接入了微信支付，突然有一天，運營提了一個需求，要增加支付寶支付，對，就是這麼一句話需求，然後就推給了產品部門。
產品經理正好很忙，我就幫著想這個需求，然後我就發現幾個問題：
- 為什麼要加這個需求？
- 支付的場景是什麼？
- 需求量很大嗎？
- 加了之後會導致流程變化嗎？
跟需求方溝通之後發現，我瞭解了以上問題：
- 首先加這個需求是因為有的人不用微信支付，或者說微信裡沒錢；
- 支付的場景是在微信群內發一個折扣商品鏈接，用戶訪問鏈接就可以進行購買；
- 需求量不大，目前只有三個；
- 增加支付寶之後之後，整個登陸的流程要變。
所以，增加一個支付寶支付，遠不是一句話的問題，背後涉及到的變動還是很大的，由於開發的排期很緊張，而且這個需求量很小，所以暫時不進行開發，如果遇到個別這樣的支付問題，運營人員線下收款，然後技術協助修改訂單狀態。
二、整理需求
由於上面的問題，我想到了產品整理需求時的流程和注意事項。
- 瞭解需求提出的原因
- 瞭解需求的場景
- 統計需求量
- 評估需求變動對其他部分的影響
下面我就以上面那個支付的問題為例，一點一點進行闡述。
首先是需求提出的原因，就是有的人不用微信支付，或者微信裡沒錢，其實這個很容易跟第三點聯繫到一起，這個年代了，有幾個人微信沒錢呢？
其次是需求的場景，上面也說到，支付的場景是在微信群內，微信群裡面你打得開支付寶支付嗎？所以這個問題不止是增加支付寶支付那麼簡單，還要引導用戶在微信外瀏覽器打開頁面，這也涉及到第四點，登陸的流程會有變化。
需求量剛才也談到了，就三個人，佔整體支付訂單的比例很小，基本可以忽略。
最後就是該需求對其他部分的影響，首先就是要引導用戶在微信外瀏覽器打開購買鏈接，然後還需要修改登錄的流程，之前可能是微信授權登陸，在微信外只能使用手機號登陸了。
經過層層分析，就會發現，要做一個需求，不是一句話就能說清楚的，要考慮使用場景，要考慮值不值得做，還要考慮開發成本，等等。一句話的需求，往往都沒那麼簡單。
還有，我們要挖掘表象之下的真實需求，就好像沒有造出飛機的時候，人們只想到要汽車的速度更快，但造出飛機才能解決速度問題。
三、需求評審
需求整理之後，產品還要進行需求評審，主要有以下幾種評審：
- 業務評審
- 功能評審
- 設計評審
- 技術評審
業務評審是產品整理好需求之後，跟需求方核對整個業務的流程是否符合需求方的預期。
功能評審是在產品出了原型之後，跟需求方確認原型裡的功能是否符合需求方的要求。
設計評審是設計部門將核心頁面設計完成之後，與產品部門進行核對，看是否符合準確還原了產品原型。
技術評審的時候，產品要多從技術的角度去解釋，方便技術理解，有機會再詳細寫下我自己在技術評審中的感悟，說白了就是產品應該怎麼講需求。另外，也推薦大家聽一下極客時間裡邱嶽的專欄「邱嶽的產品手記」。
以上就是我對產品需求的一些看法，可能考慮的並不全面，但是確實是在真實項目裡的感受，歡迎溝通交流產品心得。
閱讀更多 掘墓人的小鏟子 的文章
