起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識TOB入門與不同需求文檔的應用場景
今天給大家帶來的是幾種產品需求寫作方法，以及它們的優缺點。
一、流程的劃分
隨著C端產品的不斷完善和市場擴充，讓傳統行業看到了互聯網他們的魅力所在，由此如今的TOB行業很火爆，在此很多做TOC的小伙伴在轉行的時候寫需求的話會忽略業務流程的梳理，這也是你快速入行和成為行業專家的第一步，當然最好搭配上5W2H分析發效果更佳哦。
下面拿采購來說明：
從中可以發現哪些問題呢？
- 需要紙質表格填寫，不方便管理；
- 需要當面和負責人對接說明，消息滯后處理不及時；
- 特殊情況，需要協調更多負責人的時間，錯過最佳處理時間；
- 財務需要通過人事統計表格去對賬，不嚴謹有誤差風險。
在你對現有流程比較熟悉之后（當然可以把這一步看作是用戶調研），就可以著手準備優化后的業務流程，以及使用流程去討論了，盡可能的在前期去把風險降到最低。TOB的產品注重與邏輯和業務，所以在這一步大家一定要慎重，不要一上來就直接畫頁面。
我們解決方法：
- 線上化，方便記錄與管理；
- 及時通知，避免時間不對稱的風險；
- 自由添加審核人、抄送人或者后臺管理員編輯，解決消息同步和職責不清晰問題；
- 減少人力成本，財務對賬信息更嚴謹。
下圖為個人申請的一個使用流程，當這個流程被確認，你就可以畫出信息架構圖，去進行詳細的頁面設計。
二.四種需求說明
純文字說明
樣例：
1.1搜索欄：
1.1.1、地區顯示固定為北京，暫不提供基于定位顯示位置信息。
1.1.2、搜索欄搜索內容增加為可搜索場地（默認顯示今天場地，按時間排序）、作家、和作品信息。
1.1.3、搜索界面搜索場地默認顯示今天場地，按時間排序。
優點：
- 簡潔明了，易于閱讀；
- 單區域可觀性強；
- 便于初學者描述需求。
缺點：
- 整體邏輯性不強；
- 模塊描述不清晰；
- 流于細節，不利于整體流程框架通讀。
應用場景：
主要應用于邏輯簡單的小型產品。在最開始開始階段，進行MVP（敏捷）開發的時候，可以使用該功能需求的寫作方法。而對于邏輯復雜的產品線來說就不適用，像OA、CRM等重邏輯的TOB產品相對就不是很適用
模塊描述型
樣例：
優點：
- 突出模塊與效果；
- 功能模塊可觀性強；
- 編寫需要對產品模塊有了解。
缺點：
- 偏向狀態描述；
- 單條篇幅較大；
- 模塊與模塊之間無聯系；
- 編寫需要對產品模塊有了解。
應用場景：
此需求說明主要的功能是去描寫頁面的一些動效和頁面流轉效果，多適用于注重交互的產品。是上一個需求的加強歸納版本。
用戶場景型
樣例：
優點：
- 以業務流程為主，從起始到完結；
- 邏輯清晰，不容易產生遺漏。
缺點：
- 細節描述，有所欠缺；
- 編寫需要對業務流程有理解。
應用場景：
主要應用在有比較完善，有設計規范、UED、資深開發、等已經形成默契的團隊。重點集中在事件流程，前段用戶操作和系統如何處理，方便開發快速閱讀，形成邏輯流轉在腦海當中。
用戶場景細化型
樣例：
優點：
- 以業務流程為主，從起始到完結；
- 邏輯清晰，不容易產生遺漏；
- 主要為異常流（備選事件流）的積累，便于完善產品。
缺點：
- 細節描述，有所欠缺；
- 編寫需要對業務流程有理解；
- 對技術開發、團隊合作需要一定經驗。
應用場景：
與用戶場景型的應用場景一致——被驗證過的成熟產品，不過它的重點是在備選事件流程上。20%時間放在其他描述，80%的時間是放在備選時間流程上，去梳理、準備各種異常情況下，產品應該給用戶一個什么樣的解決辦法。
總結
世界方法千千萬，沒有最好的只有最合適的。方法是讓我們更好、更快去解決問題的途徑。學習各種方法，再去提煉出最適合自己的方法，形成自己的體系，那么你就是下一個大神了。今天就分享到這里了，期待下次與愛智求真的你相見。
本文由 @?大西瓜 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自PEXELS，基于CC0協議
個人申請的使用流程是不是需要進行下優化哈？如果部門經理/高層領導審核未通過應該退回給個人而不是直接結束吧？