入門級產品經理如何把握好產品的需求?
剛開始做產品的時候,總是拿到需求就開始著手畫原型,遇到卡殼的地方就去參考競品,看看別人是怎么做的,接著再繼續畫原型……,幾個產品做下來,對于產品的了解仍然是微乎其微,對于如何做產品仍然是一知半解。后來通過閱讀一些書籍以及產品設計的一些文章,不斷總結了一些經驗,不敢說現在做的就有多好,因為即使是現在每次做新的項目時也總會發現一些比較好的優化需求表達的方式。簡單分享下自己的心得和經驗,大家一起學習。
很多剛接觸產品的同學都覺得會畫圖,會做原型,就是會做產品了。其實,這只是做產品的第一階段。要想把產品做好,對業務需求的理解和表達是非常重要的(去抄抄競品,東拼西湊做出的東西是不可能成功的)。那么,如何把握好產品的需求呢?
一.深入挖掘客戶需求
- 首先向客戶了解清楚產品的目標人群、使用場景、核心業務以及想要達到的目標,總之要詳細了解清楚產品所涉及的業務,而只有深入了解了業務本身,才有助于發現使用場景,并為之提供解決方案,讓用戶用得爽。
- 盡可能讓客戶全面細致的描述產品要達到的目的和業務流程。在汽車還沒有發明的年代,如果你問用戶想要什么,他會回答想要一匹更快的馬。永遠記?。鹤尶蛻舯M可能全面細致地描述產品的目標以及實際業務流程,而不要讓客戶提供解決方案。由于客戶經驗和認知的局限,他所描述的只能是他能想到的符合業務需求但未必是最優的方案。
- 需求不明確的地方及時和客戶溝通。一般我們拿到一個項目,從開始了解需求到輸出需求文檔之間的時間是很短的,遇到需求不合理或者不明確的地方一定要及時和客戶溝通。不然,如果按照自己的理解或者YY出來的東西最終很大可能是不符合客戶的需求的,最后提交給客戶后還需要重新返工,費時費力。
二.確定原型架構
需求了解清楚了,相信這時候很多童鞋已經摩拳擦掌、躍躍欲試想要開始畫原型了。先別急著畫原型,過早的進入原型設計階段只會讓自己陷入細節設計的困擾中不能自拔,從而難以把握產品的大框架及方向,那么你前面所做的需求挖掘及分析在原型表現上將大打折扣。
原型架構的梳理與確定才是需求分析完成后的重中之重。
- 競品分析。基本需求了解了,那么去看看同類型的產品,尤其是市場中優秀的產品。了解下別人的產品架構(當然也了解下同類型業務的處理方式,為后面的業務分析以及原型設計做準備)。
- 按業務需求劃分功能模塊,主要是按照商務整理出的功能需求清單以及和客戶的溝通結果來進行模塊劃分。
- 細分每個大模塊下的小功能模塊。盡可能細化每個模塊下的所有功能,如果可以的話涵蓋所有功能。如:社交類應用,細致到對好友動態的點贊功能。這樣做的好處是在開始畫原型的時候便于檢查是否有遺漏缺失的功能。另外,當你在構思原型架構的時候其實也是一個打腹稿的過程,架構圖涵蓋的越詳細越便于后期的工作。
三.畫業務流程圖
架構圖完成了是否可以開始畫原型了呢?先別急。再梳理一遍業務邏輯,并用流程圖的方式輸出。一來這樣可以檢查自己之前的想法是否正確,二來在梳理流程圖的過程中你有可能發現更優的處理方式。當然最重要的是需求做出來是要給到開發看的,業務流程圖可以更好的幫助開發了解整個產品。
1.不同業務模塊分別畫流程圖
每個產品都不止涉及一個業務流程。如借款的產品涉及的業務就包括:發布借款流程、投資流程、還款流程、提現流程等。當然,多個流程之間可能出現業務交叉的現象,但是盡量分開。這樣做的好處是:一個主流程比較清晰,多個流程交叉在一起會降低可讀性。如下圖所示的流程圖把整個產品的業務流程放在一起,就讓人不明所以
2.文字簡要介紹業務
在流程圖旁邊附上文字說明,簡要說明業務流程。如借款產品:用戶可以以游客模式瀏覽別人發布的借款,但是如果自己發布借款或投資就必須登錄。因為有些規則不適合用流程圖來表示,這個時候簡單的一句話就可以表達的更清楚。
四.做好業務規則說明
很多產品中都會有例如積分、會員等級等激勵用戶活躍性的方式,而對于積分的獲取和使用規則、等級的升級規則做好說明,則可以將需求確定清楚并做好限定。另外,有些規則在初期可能沒有考慮清楚,有可能是不合理的。及早做好說明并在需求評審時和大家討論清楚,能盡早發現問題并找到可替代方案。我曾經做過一個項目就是在初期沒有將規則說明清楚,導致開發到最后才發現這個問題。
這個項目有一個充值優惠功能,當時我提出的方案是:按百分比的方式優惠,如優惠3%,充值100則優惠3元,提現的時候相應的減去優惠的百分比。但是該產品還涉及支付寶支付,如用戶支付寶購買了100元的產品,但是又取消了訂單,退款是直接退到該產品的賬戶余額的,這個時候就相當于我充值了100塊,賬戶余額中英按充值優惠比例增加100/0.97=103.0927835052元。好吧,出問題了。因為我們之前定的規則是保留2位小數的。
所以,如果所做的產品有一些特殊的業務規則,請一定做清楚說明并和大家討論是否合理,不然后期出錯會造成更大的損失。
五.記錄變更日志
需求做完之后不可能一次都不修改,每次改動后都會有開發問變更了哪些部分,于是我們只能一一回答改了哪些。但是很多時候只是大概回答改了哪個模塊,有些小的改動還是被開發給遺漏了。那么每次變動后如何確保將所有的變更都告知開發呢?
在原型文件中直接附上變更日志,注明變更模塊、變更原因及日期,以確保所有人都可以一眼看明白哪些地方做了變更,方便大家的工作又避免忽略一些變更。如下圖所示:
以上都是個人的工作總結,還在持續改進中。有不妥之處,還請指正。
該文章主要針對外包項目而寫。
本文由 @1KB的洋洋?原創發布于人人都是產品經理?,未經許可,禁止轉載。
請問:原型圖是用Word畫的么?
Axure