從0開始學產品策劃⑦：通過人物角色了解用戶期望

簡體傳統

　　通過人物角色了解用戶期望

　　無獨有偶，不僅僅是《生活大爆炸》中人物角色個性鮮明，寧財神的《龍門鏢局》中的人物亦有類似的特征。

陸三金：有點面但是愛說道理。
盛秋月：沖動喜歡，武力解決一切的女性。
白敬祺：愛面子的剛性男。
呂青橙：武功好但是比較單純的女性。
溫良恭：有很多感情故事的男性。
邱纓絡：愛財花癡的女醫生。
蔡八斗：想賺錢的男廚子。

　　大部分時候劇情的推動往往是依據每個人的個性安排矛盾和沖突的。比如，一旦出了事情，蔡八斗永遠是第一個說“出事了！”的人；溫良恭則永遠與前女友糾結不清。這些都是劇本的創作手法，但我認為，也是互聯網產品非常值得學習的地方。

　　在日常互聯網產品的使用過程中，產品經理與用戶之間的距離不能說很近，雖然兩者依靠產品進行連接，但大部分時候用戶不會表達許多想法。因為對于產品經理來說，抱怨功能缺失的用戶A 和吐槽界面設計的用戶B 可能都是模模糊糊的兩個人，似乎屬于用戶的范疇，但實際上兩個人可能在現實生活之中非常不一致，情境也各有各的特點，但這些細節都是產品經理很難去獲得的信息。

　　因此，在一開始產品經理通過用戶調研方法建立了核心人物角色之后，可以按照電視劇的模式描述每個人物的特點，然后根據特點進行頭腦風暴，討論這幾個核心用戶在使用產品的過程中會遇到哪些問題——甚至是會吐槽什么類型的話。我時常看用戶反饋，會發現一些很有意思的句型。

無理由抱怨型：垃圾，真是垃圾！！
有理由的反饋和建議：如果有個xx功能就好了。
恨鐵不成鋼：唉，上次反饋的那個問題，這個版本還是會出現……
語言侮辱和人身攻擊：傻X的xxx和xxx公司！

　　在我剛入職做產品經理的時候，會和用戶在QQ 群里討論產品問題，甚至有些熱心的用戶時常會加好友和我聊產品問題。我發現用戶與用戶之間的確有著不同的背景和期望，有許多類型的用戶。在觀察了各大安卓市場、電商網站的用戶反饋評論之后，更堅定了這一觀點。

　　創立核心人物角色的方法在前面已經有所闡述，相信各位產品經理都希望去試一試這個方法。不過，我建議產品經理一定要多和用戶進行溝通。和用戶溝通不一定必須是關于產品體驗的，可以適當發散一些，聊一聊生活等問題，可以通過這些信息更全面地了解用戶，讓整個人物角色更加飽滿。正如謝爾頓和萊納德都是技術宅，但后者更加了解日常社交的方法；邱纓絡和蔡八斗都愛錢，但一個想要通過傍大款獲得，一個希望自力更生艱苦奮斗獲得。

　　把控用戶體驗是每個產品經理都頭疼的問題，但這也是鍛煉產品經理能力的階段。尤其是剛入門的產品經理在今后遇到的項目都有可能會出現各種用戶體驗問題。別担心，方法可以慢慢摸索，關鍵是始終記得那句話：以用戶為中心。這句話也是產品經理在項目前期和探索需求階段需要特別關注的，別為了做功能而做功能。

　　目標至上——細節和ROI 的故事

　　敏捷迭代和人月神話

　　說完了用戶體驗，讓我們回到項目的真實情況。等產品經理寫完文檔，以為一切都正常進行的時候，發現自己突然陷入一種忙亂的狀態——相關的人一波又一波地過來找你，各種措手不及的事情讓你原本心情很好的早晨變成了一團糟的開端。別太担心這種情況，每個項目啟動后都很容易遇到這樣的情況。這不僅僅是含混性的問題，更因為大部分時候項目規劃都是在理想情況下進行的，而現實是這些理想情況都有可能背道而馳，出現一些意外。

　　我有時候會和其他產品經理討論這種現象：究竟是什么原因使得每個項目在過程中會出現這樣的情形？我的一個朋友說，首先你的預期就不應該是整個項目都按照理想狀態進行，這顯然是不現實的。對于一個項目來說，沒開始做之前永遠不知道會遇到什么問題。所以在項目進行中，應該帶著問題不斷前進，推動問題解決和項目進度，這才是產品經理需要關注的事情。另一個產品經理則提到，很多時候產品經理無法控制所有的細節，而這些細節會隨著項目而產生。

　　那么，如何將這樣的意外控制在有限的范圍呢？互聯網公司現在流行講敏捷迭代，實際上有多少公司真正做到了敏捷？假設百米跑是項目經理常說的敏捷迭代，那么跨欄跑則是真實狀態下的項目：既要敏捷，又要解決難題。這才是大部分項目的真相，也是產品經理不得不面對的真相。

　　如果把寫作本書看成是一個個人項目，我深刻地理解了敏捷迭代是多么重要。因為還需要進行日常的工作，所以我每天都是利用下班之后的時間進行寫作，尤其是周末時間。按照理想狀態，我應該每天寫2000 字左右。但事實上，我大部分的寫作時間都來自周末。不如來看看我的“項目計劃”：

工作日每天輸出2000字，每個月爭取輸出40000字以上，周末用來修改文字和查找案例。
每個月輸出一章內容讓朋友提一提意見。看起來似乎挺可行的，每天2000 字對于我來說不算太難——畢竟我日常也有寫博客的習慣；文字質量我對自己有信心，因為平時寫的文章都有一些業內的朋友關注，他們覺得挺不錯的。那么，我就把這種理想狀態的計劃看成是我后續寫作的原則。但事實呢？
工作日基本每天的輸出都達不到2000字，甚至大部分時候都沒有輸出；而周末因為在星巴克待兩個下午，可以勉強完成10000字；幾乎沒有修改時間。
每個月輸出的章節基本都欠缺一些關鍵內容，時常會出現“待補充”的字樣，不忍心讓朋友們閱讀。這就是寫作項目中的大風險——我很有可能無法保證在約定時間內寫出對應的字數和有觀點有價值的內容。按照計劃，我現在應該每天輕輕松松地坐在電腦前，敲出2000 字，然后起身投入到生活中。但自從寫作之后，我發現自己大量的時間花費在了寫作之外：
加班。最直接的因素，常常會影響到下班后的狀態。
社交活動。人天生就是社交動物。
呆坐在電腦前。我時常打開文本編輯器，然后一臉茫然地看著發光的顯示屏，從亮到暗到關閉，然后一敲回車鍵，屏幕從關閉到亮。我在電腦前想：為什么繆斯女神總喜歡在我坐下的時候就離我而去呢？
排解沒有靈感的痛苦，進行“勞逸結合”的活動。大部分呆坐著的時間非常痛苦。因此，我常常選擇起來運動一下，或者是看看微博、刷刷豆瓣……然后就陷入了現代人常有的拖延癥狀態，將時間花費在刷各種資訊上。
日常的運動健身。為了保持高強度的大腦活動，我從寫作開始就保持長跑，希望向村上春樹的《當我跑步時，我談些什么》一書致敬，并希望像他一樣在跑步中感悟到一些思路，通過釋放壓力更好地獲取靈感。還有一些日常的零零碎碎的事情，于是我的寫作計劃基本破產。按照阿瑟•布洛赫在《墨菲定律》一書中的闡述，我顯然被墨菲定律纏身：事情如果有變壞的可能，不管這種可能性有多小，它總會發生（Anything that can go wrong will gowrong）。于是在一個月之后，我推倒了這個計劃，重新寫了一份我能接受的計劃：
周末寫作10000字，工作日寫1000字。完成一章之后再進行編輯工作。
保證內容都可以連貫閱讀，然后就給朋友們看最新章節。

　　或許有人會說這是朝三暮四的故事——不，我想稱之為項目管理。我曾經戲謔地和我的朋友說，我這個才叫敏捷開發：先做再調整計劃，小步快跑，隨時根據自己的現狀進行調整，但不影響整個項目周期，甚至還能取得更好的效果。

　　事實上，敏捷迭代并非只是簡單的一套方法論，更像是一種理念，貫穿整個項目的始終。

　　Scrum 是一種迭代式增量軟件開發過程，通常用于敏捷軟件開發。騰訊目前在使用的項目迭代應該就是基于這種迭代方法的。最具標志性的產品就是內部使用的TAPD 系統。通過這個系統，項目相關人員可以很方便地看到各自想要的信息：需求單、開發進度、bug 單等。對于項目經理來說，通過TAPD 可以有效地統計整個項目迭代周期中出現的情況，并及時發現問題。

　　除此之外，騰訊內部流行在開發中后期舉行定期的例會，比如每天上班之后的晨會，會上需要每個人闡述三個問題：

昨天做了什么？
今天打算做什么？
完成昨天的任務時遇到了什么樣的困難，需要什么樣的支持？

　　通過簡單的信息同步之后，負責人就可以盡快聯系對應的人員，溝通對應的難題。一般來說，這些問題大部分都是信息不同步造成的，產品經理通過參加這樣的簡短會議，可以快速找到問題要害，及時召集對應的人員給予支持。敏捷還體現在整個項目迭代中，會有許多參與角色，比如產品經理、開發工程師、測試工程師等。每個人有每個人的迭代階段，比如：

需求收集階段。
需求設計階段/需求輸出階段。
開發技術預研及框架構建。
功能開發階段。
功能測試階段。
系統測試階段。

　　上述粗略的階段劃分主要是想說明，每個階段其實都不是堆棧式的，而是當有了部分輸出之后，下一個階段就會馬上同步進行，通過多次迭代實現整個版本需求。

　　通過持續集成等環境，版本質量在不斷提高。與此同時，測試人員在進行測試，開發人員在進行開發，產品經理則可以通過持續集成的版本，進行體驗優化。當整個項目接近尾聲時，則可以通過灰度測試的方式論證用戶對于新產品功能的認可度。

　　這就是騰訊比較有特色的敏捷迭代方式，對于一些小團隊也非常受用。在我寫作的過程中，雖然只有我一個角色，但依然需要給自己不斷規劃迭代周期，并按照任務數進行排期實現。雖然說敏捷迭代相比傳統的瀑布式開發會更加沒有節奏感，但實際上，敏捷也需要良好的規劃時間和任務，不然一環連一環可能引起更多的問題。

　　對于產品經理來說，了解基本的敏捷迭代方法非常有必要。大部分時候，產品經理的執行力其實就在于如何規劃功能并引導相關成員把功能實現。敏捷迭代方法是一種成本低、速度快的方式，也是提高執行力的方法之一。通過細分任務，每天定時匯報，產品經理及時體驗，可以在短時間內把功能做得比較完善。

　　在敏捷方法中，對于產品經理最關鍵的啟示就是：目標導向。在日常需求討論的過程中，時常會遇到這樣一種情況：

　　這個功能符合用戶場景，而且做得很炫。

　　產品經理時常會遇上這樣一種情況：用戶提出了一個反饋，產品經理需要考慮如何去滿足；或者是有一個功能可以做得很炫，但對用戶不一定有太大的價值。

　　按照常規，這些需求理所應當地被剔除，或者是延緩實現。但有一種情況就很尷尬：有價值但成本較高的功能。在《用戶故事與敏捷方法》一書中展示了一個排列優先級的方法——莫斯科（MoSCoW）規則：

必須有（Must have）
應該有（Should have）
可以有（Could have）
這次不會有（Won’t have this time）

　　大部分尷尬的情況都源自于“可以有”的需求。這種需求優先級不高也不低，對于用戶來說，是具有使用價值的，但在項目中并非是一個最緊急的需求，時常會被前兩個需求擠掉。畢竟項目的周期和成本是關鍵因素，任何時候資源都需要用在“刀刃上”。因此會出現這樣一種情況：每一個項目迭代周期都會有許多的高優先級需求（Must have 和Should have），于是每一期的Feature List 上都會有一些“可以有”的需求排不上隊，一期又一期都沒有進入迭代計劃。

　　而隨著項目迭代幾次之后，越來越多的新功能轉移了用戶的注意，之前提到的“可以有”的功能只剩下零星的幾個用戶在反饋了。項目依然在前進，而新功能依然層出不窮，需求變更依然不停地被加塞到項目中。慢慢地，那些“可以有”的功能被邊緣化了。直到有一天，產品經理發現用戶重新關注起了這個功能。

　　這個時候應該怎么辦？做還是不做，這不是一個簡簡單單的需求問題，而是涉及整個項目的問題。我第一次遇到這種情況時，急急忙忙地找交互人員討論交互方案，找開發人員確認開發難度及工作量，找測試人員溝通測試工作量，然后還需要和項目經理溝通協調。當得知工作量比較大的時候，這個需求似乎又需要延期了。這類“搭車”需求并非是偶然出現，大部分時候是項目的常客。但作為產品經理，是否應該重新思考一下：這個需求之所以沒有實現，是真的因為成本，還是因為其他原因？產品的目標是什么，我們為什么要做這些功能？無獨有偶，在每個產品團隊內部可能都會有這樣的討論：xxx 功能是否可以加上？往往最后大家的爭論都變成了這樣的對話：

這對用戶來說是有場景有需求需要被滿足的！
但是這對產品來說價值有那么大嗎？
是否是所有的需求都需要被滿足，還是產品經理應該只關注有價值的需求？有的時候，產品經理時常忘記兩件事情：
用戶的需求是源源不斷的，而且有優先級。
每個版本、每個功能都有對應的目標。

　　在項目進展過程中，時常出現產品經理在討論細節問題的情況，但很多細節的討論純屬沒有目的的扯皮——例如按鈕放左邊還是放右邊比較符合規范和用戶習慣。這個事情可以直接做一個內部調研或者運用灰度測試的機會測試用戶的選擇，而沒有必要爭論各自的觀點，變成了兩個人為了維護自己的立場進行的爭辯——況且他們擁有的是同一個目標。目標很重要。

　　除了日常時常出現的爭論，項目時常出現“可以有”的需求往往還有另一個原因：優先級問題。優先級意味著有一個目標，而所有的需求都應該向這個目標看齊，然后一個一個進行排隊。優先級是如何安排的呢？按照A～Z 的順序排列嗎？或者是根據產品經理喜好進行排列嗎？這個問題并沒有準確的答案，如果需要有一個答案，那就是：權衡用戶的需求和產品的價值。

　　事實上我們會發現，用戶每天都大聲嚷嚷的需求在經歷了一個迭代之后，用戶并沒有欣喜：提供這個“缺失”的功能是應該的。如果這個功能還有bug，那么第二天迎接你的又將是一大波反饋。反而，產品推出了一個用戶未曾想到的功能，即使問題多多，用戶依然會喜歡并忍受一些缺陷。這真的是一個很有趣的現象。

　　既然如此，產品經理應該如何抉擇呢？把主要精力投入到新功能開發，還是修復bug？相信每個人都有自己的答案，但我的答案是選擇做新功能。產品需要前進，需要有前進的動力。

　　正是因為用戶預期與產品功能有著微妙的關系，所以“可以有”的需求大部分時候都隱隱于市，被新功能遮蓋了。項目的目標一開始就確立，主打新功能的開發，減少成本在修修補補的工作上，除非是特別緊急的工作。在上一章曾談到把控用戶期望，這也是一種方式，即通過新功能的方式推動產品前進。讓用戶感到“意外之喜”。不過往往這樣進行得越久，用戶的期望會越高，而老版本的問題依然存在，最后還是會爆發。所以這并非是一個可行之策。

　　正是考慮到種種現狀，我們才說產品的目標尤為重要——我們有了產品原則，有了優先級，就應該朝著目標前進。用戶的需求不外乎三種：