B test、細節評審、做減法）技术頭條網

上一文講到的“Kano模型”因為許多小夥伴並不瞭解所以我單獨開了一篇文章進行講述。

這篇文章我將會一次性講述完其餘的3種需求分析法。

A/B test

“A/B test”許多人也被叫做“A/B測試”，簡單的理解就是在同一需求與目標下難以抉擇優劣時需要制定出兩套不同的方案，將用戶也劃分為A、B兩部分，選擇一部分用戶去體驗A方案，其餘一部分用戶則體驗B方案，並且根據用戶反饋來對方案進行最終確定。

某公司想在自己的資訊平臺植入廣告功能，他們最終確定出兩套方案，A：廣告信息植入在信息流中；B：廣告信息植入在詳情頁面中。兩種方案的最終需求都是為了讓用戶看到廣告，現將A、B方案投放給不同的兩撥用戶，他們在APP中所看到的界面是不一樣的，一段時間後數據顯示A方案用戶點擊廣告的概率要比B方案高，並且也沒有產生用戶流失，所以最終這家公司選擇了A方案給所有用戶。

這時候應該會有人困惑，A/B test最多隻能進行兩種方案的測試麼？其實，A/B test只是一種便於理解的叫法，你大可以策劃出多種方案進行測試，但是隨之增加的也會是一定的成本。所以個人建議最好是經過多輪篩查選擇出最難以定奪的方案進行“A/B test”。

進行A/B test需要注意的地方：

方案具備可實施性：定製方案時需確保方案的可實施性，避免投入市場後毫無反饋；
合理區分用戶群體：劃分出功能對用戶群體的影響性，避免造成不必要的用戶流失；
統一需求點：方案定製的最終需求點必須為同一需求點，否則將無法考察出實際數據；
保證功能同時性：保證功能在同一時間內投入市場，避免今天A功能，明天B功能的情況影響數據。
保證群體同質性：確保用戶群體的性別、年齡、消費水平等在統一層級。
做好數據埋點：A/B test投入市場前需要做好數據埋點，以及時獲取數據信息，避免出現遺漏。

總結：其實A/B test並不是一個廣泛的需求定義法，這類方法因為考慮到成本問題許多初創型公司並不會採取，但是如果遇到真正難以抉擇或拗不過老闆的時候可以進行嘗試。但是這類方法還是具備侷限性，需要結合其他需求分析方法層層篩選後才可以使用。

細節評審

細節性需求評審大家都不陌生了，我也就不浪費大家的時間去說是什麼了。

這裡我分享一些可以高效完成需求評審的方法。

需求評審前：做好充足的“功課”

在會議開始前提前找到此項目對應的技術負責人，認真的和他們溝通你的方案和想法；
自己多跑幾遍業務邏輯，避免在會議中出現卡殼無法進行或浪費過多時間去解決問題；
將產品的發展方向或迭代目的明確的告訴研發人員，讓大家更好的融入產品思路中，提出可參考意見。
撰寫出需求大綱，讓大家簡介明瞭的知道功能點從而思考實現的時間。

需求評審中：思路清晰，掌握節奏，控制情緒

在需求會開始的時候一定要時刻保持自己的思路，因為在會議中總會有人打亂話題，這時候如果你被他帶跑偏了，那這場會議註定是回不到主題了，所以一定要將自己的思路控制的穩穩地，像事先預想的那樣講述自己的需求點。
需求評審會的時間切記不要太長，不然在需求探討的過程中提到的問題也會因為長時間出於演講和干擾狀態遺忘，有時候就算做了筆記也會遺忘。
說句實話，許多需求會的時候總會有人“雞蛋裡挑骨頭”，也有人可能會因為一個小小的邏輯事物去教你怎麼做產品，但是這些情況是很容易出現的，這個時候你千萬不要因為害羞或者憤怒去印象接下來的發揮，控制好自己的情緒也是讓會議持續下去的核心。

需求評審後：立即調整，持續跟進