產品經理的初識

想轉「產品」也不是一天兩天的事情了，可是我一直對「產品經理」這個名詞在心裏沒有確切的定義。最近，看看蘇傑的《人人都是產品經理》，

以及和公司從事「產品」的同事的交流。本身心裏對產品已經有個大體的定義。「產品」：「爲解決問題而存在的一種有形或者無形的一種載體」，

無形能夠說是一種服務，好比說：你使用的電話套餐。有形，你能夠拿到一個具體的實物。好比說我今天買了一個筆記本。「產品經理」第一次

起源於保潔內部的故事，想必你們都知道的。「產品經理」，「把每一個產品看做是本身的孩子。產品經理就是那個計劃讓孩子到出生，發展，到死

亡的這個過程的管理者。

1.孕育到出生：需求採集的過程

如今我寫的這些東西都是在紙上談兵，我至今還不曾作過和需求採集相關的工做。可是學習到作事情的方法仍是比較重要的。

需求的奮鬥史，從需求被發現到決定實現的一個過程。

採集需求有幾種方式：

1.1用戶訪談;

對着用戶採用約談的方式，這種方式較爲快捷，能夠及時溝通。可是這個方法的缺點：用戶「說」和「作」不一致；樣本少，以偏概全的問題；

用戶過於強勢，把大家往溝裏帶；大家過於強勢，把用戶往溝裏帶；

1.2調查問卷

而調查問卷一般封閉式問題比較多，適合大用戶量的信息收集，但不夠深刻，通常只能得到某些明確問題的答案，調查問卷不是考試卷，

不適合安排問答題。不管是網上仍是線下，做答時間最好不要超過10分鐘，不然不少人看一眼就被嚇跑了。可是這個方法仍是有問題：

第一，樣本的誤差，即樣本與想了解的目標用戶羣體出現誤差。第二，樣本過少的問題。第三，問卷內容的細節問題。

1.3可用性測試

可用性測試是指經過讓實際用戶使用產品或原型方法來發現界面設計中的可用性問題，一般只能作少數幾個用戶的測試，看他們怎麼作，

屬於典型的定性研究。這樣也有問題：第一，可用性測試是指經過讓實際用戶使用產品或原型方法來發現界面設計中的可用性
問題，一般只能作少數幾個用戶的測試，看他們怎麼作，屬於典型的定性研究。第二，總以爲可用性測試很專業，因此乾脆不作。

第三，明確是測試產品，而不是測試用戶。第四，測試過程當中，組織者該作的和不應作的。

我我的是比較喜歡作可用性測試，不少時候開評審會議的時候，須要開發人員在短期以內作出決策（尤爲是那些不喜歡看PRD文檔的人），

demo更能快速高效的傳遞你的意思。並且，如今AXURE Rp工具也極爲方便。

1.4數據分析

雖然絕大多數狀況下的經驗證實，只要在用戶的選擇上沒犯什麼低級錯誤，他們是「具備表明性的」，或者說接受這種假設是一種性

比很高的廉價解決方案。不過，咱們還有數據分析，一種定量的研究方法，數據來講話，看看用戶究竟是怎麼作的，不管是考察目標用

戶全體、仍是採樣，都徹底可控，所謂「According to the data」是最難被駁倒的。

總結：需求採集可謂是重中之重，記得之前在上軟件工程課中，需求到最後成品簡直沒有半點關係。因此，必須把握好需求這關。

對於本身身邊，批發站的產品，從需求這面着手，我採用約談方式。對於小公司不適合採起成本太高的需求採集方式。對於內部員工約談，應該是最合適的方式。可是有的項目需求存在不肯定的問題，做爲產品，必定要給最後的產品開發留上需求改變的空間。