編輯導語：當已經掌握了根據用戶未來旅程和把握住的“核心場景”轉換出來的需求，要怎麼樣将需求進行系統的規劃呢？怎樣将他們串聯起來，成為一個可以交付給到用戶的東西？本文作者分享了需求策劃的幾個方法，希望能給你帶來幫助。

我之前在集團組織裡做效率工具産品，對于管理視角出發的工具如何從發現需求到規劃落地，總結了系列文章，現在想跟大家聊聊幾個策劃需求的辦法，碰撞思考。

概要：

1）敏捷疊代

2）産品規劃4方法

1. 排序聚合分類
2. 回歸和因果關系，事件發生邏輯
3. 金字塔原理，結論論點論據
4. 嚴謹的【五步法】

3）兩個确保

日程系列一裡（ 日程系列（一）如何用兩套工具找準需求 ），指南針主要解決了where的問題，把範圍框定在一群用戶的主要痛點裡。地圖主要解決了what的問題，今天講“怎麼做”how的問題。

當手上已經握住了用戶的反饋，根據用戶未來旅程和把握住的“核心場景”，轉換出來的需求，怎麼樣将需求進行系統的規劃呢？怎麼将他們串聯起來，成為一個可以交付給到用戶的東西。

産品誕生前期在實際工作中其實占大頭的就是貼近用戶和産品規劃。先來介紹一個敏捷概念。

01 敏捷疊代

按照敏捷的開發方式，要足夠快，小步快跑做疊代，才可以快速滿足用戶的需求（我在這一點上做的還不夠好）。

所以一般是1-2周做一次疊代，好幾個疊代一起做一次對用戶有感知的版本發布。

（圖侵删）

1. Story： 故事

指的是一個完整的用戶故事（功能點），如果是按照事件流程就可以是一個用戶參與日程的全環節，例如日程中，我要做一個“群組日曆”。讓超過兩個人以上的團隊可以共享一個工作時間面闆。那故事的細節至少會包含：

1）前期

至少管理員角色和成員角色參與進來，管理者作為發起方，成員角色可以參與日程發生。

管理員可以增删改查成員，可以管理、創建、删除、修改該群組面闆下的日程。

成員用戶可以自己選擇是否讓群組日曆顯示在自己的面闆裡。

2）日程事件發生時

成員需要知道面闆下的日程，什麼時候和誰會在哪裡發生什麼主題的會議。

日程發生前，告知即将有什麼會議發生，做提前提醒。

日程發生時，可以及時提醒到他們。在正确的地方出現和正确的人開會讨論具體的事情。

3）日程發生後

成員看到這個事件已經發生過，并記錄一些曆史附件，甚至可以形成待辦事項。

故事完整，可以讓一個用戶在這裡“完成”“一件事”。

2. Feature：有價值的特性

如果要讓用戶有感知，我們起碼會解決一些問題，實現一些用戶提過很想要的點。拿日程舉例子：

1. 我們給用戶上了“集團工作日曆”讓各個BGBU可以用來發布需要共同關注的大事件
2. 我們還将之前的周期重複日程，不能設置截止時間的點做了完善
3. 解決了隻能同步自己的日程，不能同步别人共享給我的日程到手機的問題
4. 解決了若幹個控件操作問題
5. 重新梳理會議室的組織結構，預定的時候選擇組織更清晰

這裡面包含了新的需求功能點、包含了缺陷修複、交互問題的整改、信息結構的優化。合成一個2.3.6版本。

如果是story，我更推薦你用1、2的規劃方法：排序分類、因果邏輯；如果是大版本Epic或者一整個立項，我就更推薦你用3、4的方法：金字塔、五步法。

02 産品規劃4方法

1. 排序聚合分類

思維導圖是個排序分類的好工具。

還是拿集團工作日曆舉例子，它首先跟用戶、用戶的時間看闆、日程本身、擴展内容有關。所以可以把它分為這幾類。

每一個分類都可以往下延伸：

• 用戶：包含管理員和成員
• 用戶的時間看闆：包含自己的日曆、别人共享給他的日曆、群組的日曆
• 日程本身：包含增删改查必要的字段，什麼時候在哪裡跟誰開什麼會
• 擴展内容：能不能是一個周期重複會議，開會的時候需要的附件，同時開線上會議的鍊接，什麼時候提醒到參與人，要不要同步到手機系統日曆

2. 因果關系，事件邏輯

有人在特定的日曆中，建立了一個事件，裡面包含了時間地點人物事件，一群人在特定的地方可以随時看到（應用裡、手機上），并且app在特定的時間能提前告訴（提醒）即将到來的事件在什麼時候發生，以便讓這群人提前知會，及時參會；如果過程中會議有任何修改取消，他們也可以第一時間知情。

因果和事件邏輯一般可以用魚骨圖來描述。

在工作日曆中，一連串的事情環環相扣，相繼發生，上下協同，左右對齊，時間安排合理有序。從最簡單的主流程裡，我們還可以分化出來基于具體場景的因果分支。

從管理者角色看：

• 分支一：因為集團高層需要讓員工知道公司的大節點，但是不方便透露太多細節，所以通過集團工作日曆，讓大家知情。
• 分支二：因為集團高層沒有太多精力安排自己的事項，所以通過共享給秘書完成日程安排。

當然不斷完善的過程，也需要把異常情況、極端情況考慮進去，不斷補充細節和現實中的各種情況分支。

3. 金字塔原理

結構化分析問題，可以用金字塔結構（寫ppt的時候最常用）。可以選擇自上而下，也可以選擇自下而上。

1. 确定主題
2. 設想疑問
3. 給出答案
4. 檢查背景和沖突是否引發讀者提出疑問
5. 證實答案
6. 填寫關鍵句要點

這裡引入一個概念：“價值矩陣”的概念。它有兩條軸構成：議題度和解答質。“議題度”是指“在目前的情況下，找出該問題答案的必要性有多高”；“解答質”是指“對于該議題度，目前可以提供明确答案的程度”。

金字塔原理裡面，找到真正應該去解決的問題很重要。

1）界定問題

為什麼要做集團工作日曆，是辦公用戶非常想要知道集團正在發生什麼大事嗎？還是為了滿足管理者上傳下達的需要？顯然是後者。

2）存在問題的領域

之前的集團或者區域的大會小會，都是通過一封郵件，傳遞給所有人。

• 信息的内容：在過去用郵件的方式給全集團的人同步信息，信息結構是很簡單的，标題、正文，沒了。作為一個内容，它很完整，但是作為一個事件（時間地點人物主題）就不夠了。
• 信息的傳達方式：如果作為郵件，一種非即時的信息是不關心你是不是第一時間知情的，你在一段時間内看都可以，郵件躺在列表裡隻會按照收發的時間線排列，跟你的個人時間無關，這就沒有把人作為中心。應該讓“事件”在你的時間線裡“有序發生”。

3）問題可能産生的原因

1. 大會需要有“公文”“公告”的嚴肅性質。郵件常用來發紅頭文件、通告，有慣性。
2. 用法錯了，日程過去用的場景很少，大部分人隻會用在會議室“實體空間”的預定，但是對于“時間安排”沒有過多運用，不過這也很正常，單位時間價值越高的人，才越會細緻管理自己的時間，例如集團越高職位的領導日程越多。
3. 記錄時間安排，也需要花時間精力，額外增加工作量。所以其實一次錄入可以關聯很多人，規模上來了性價比更高。重要大會、培訓、例會、活動、節日都屬于這種。

4）收集信息，證實

進行實際的走訪，需要大量的調研求證。用戶問卷調研，用戶實地走訪和深度訪談等等。

5）最後給出對應界定問題的解決方法，并不斷證實

框定要解決的業務流程，不斷思考從流程上有沒有更好的辦法優化，然後才是功能架構和實現本身。

4. 五步法

1）目的：想清楚為什麼做這件事情

事情有什麼樣的背景，解決的是誰的需求或者問題，如果事情沒有想清楚那就不應該一上來就開始幹。

例如做日程：很多員工不知道公司在經曆什麼，大部分的用戶不主動記日程但是他們都會接收日程提醒（因為他們會開會），我們要幫助的是時間單價更高，對時間要求更嚴的那群人，解決的是他們在管理上的問題，組織管理和個人管理。

2）目标：想清楚做這件事情究竟要解決什麼問題

集團工作日曆就是解決信息的上傳下達和對齊問題，大事通知的适時觸達問題。

讓員工有更多參與感，當然這也是從管理視角出發的。

3）診斷：想清楚現在做這件事情有什麼痛點和不足

現階段要解決的問題，現狀是如何的。如果我們知道了現象，怎麼去挖掘背後的原因更加重要。這個問題一開始發生的時候是怎麼解決的，方案結果又如何。痛點是用戶自己描述的痛點嗎？他反應的痛點是否真實，都是需要探讨和推敲的。

例如：郵件同步重大消息，在過去是很常用的，但是過去養成的習慣，還能不能适用未來，現在看郵件的都是誰，他們習慣怎麼樣，郵件裡都充滿了什麼内容，還是不是一個好的渠道。

4）方案：形成具體的方案

如果經過了上面的幾步，一般方案就經得起推敲。

方案上可以大緻分為：指标确定、業務流程、功能架構。方案的環節，會專門抽一篇來講講。

5）後遺症：方案可能帶來的不利影響

方案過程當中，一定會有取舍，如何做取舍呢？ 我們還要關注這個次優方案下，取和舍了哪部分，對未來會不會有什麼影響，未來還有沒有可能補足。

如果拿工作日曆來說的話，工作組有大有小，我們一開始考慮放開的組織層級，就需要有一定的取舍。

工作中五步法對我來說是一個需求分析和規劃落地的思考框架，隻有在實踐中不斷運用，才有實際作用。感興趣的話，後面會用專門的“突發信息報送”案例詳細講。

03 兩個确保

用了以上的方法， 别忘了兩件重要的事情呀。

• 一定要牢牢記住産品定位，它能讓你明确什麼做什麼不做，框定範圍，有所取舍，決策的能力對産品經理很重要。思考的時候，常想産品定位。
• 一定要時時刻刻跟用戶呆在一起，隻有經常跟他們聊天，把自己融入用戶，做起産品來才會更加有底氣的。閑暇的時候，常翻翻微信列表裡的用戶。

想要培養好的習慣，可以在一個原有的舊流程中，加入一個新環節，慢慢地就可以養成持續的習慣，讓新環節“發生”很重要。

本文由 @俊宇 原創發布于人人都是産品經理，未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部