to b 行業解決方案需要思考的内容?今天給大家帶來的是幾種産品需求寫作方法，以及它們的優缺點，我來為大家科普一下關于to b 行業解決方案需要思考的内容?以下内容希望對你有幫助!

to b 行業解決方案需要思考的内容

今天給大家帶來的是幾種産品需求寫作方法，以及它們的優缺點。

一、流程的劃分

随着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協議

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