如何確保需求文檔完善?

1 評論 4674 瀏覽 54 收藏 8 分鐘

在撰寫需求文檔時,要怎么確保需求文檔的完善性,確保交付的需求文檔是穩當的?這篇文章里,作者梳理了核心流程與相關步驟,一起來看看,或許會對屏幕前的你有所幫助。

一、核心邏輯

1)圍繞主數據展開的系統建設。根據二八法則,我們最重要的是那20%的主數據,主數據也可以理解為我們最重要的業務對象,例如:客戶、支付、訂單、發貨等。

這啟發于《華為數字化轉型之道》以及我平時常看的saas系統寫的說明書,特別是旺店通ERP的說明書,讓我受益匪淺。

2)用“強邏輯”去確保我們每一步都走得很踏實,來確保我們整份需求文檔交出去的時候是穩當的。

二、梳理業務流程,得到核心邏輯

1)詳細地將業務流程刻畫下來,建議主要用圖表來描述,例如:流程圖。這一步主要是讓我們加深對業務的理解。

2)開始總結出核心。用圖表以及一些的文字言簡意賅描繪出整個需求,讓人一目了然。需要寫出必要的固化后業務流程圖、功能流程圖、數據流程圖等。這一步做完,你對需求已經非常理解,能夠簡要地表達給別人。

注意:這里盡量需要能夠從數據底層理解需求。

三、抽象出主數據

主數據也可以理解為我們最重要的業務對象,例如:客戶、產品、支付、訂單、發貨等。對于主數據的認識也依賴我們對于系統的理解深度、廣度,全局觀和前瞻性。

能夠借鑒先進的系統,并立足于自己所在的公司業務,嚴謹地推敲,大膽建設。

四、分析主數據

按照生命周期去分析,得到相關的操作和字段。

我們梳理主數據的時候,通常是從主數據的生命周期去梳理,從一條數據產生到其被廢棄不再使用。

我們以產品為例,簡要地做個示范。事實上一個很完善的系統,將會記錄下產品創建時的狀態、上架時的狀態、下架時的狀態、修改后的狀態。這里真的是很簡單示范,事實上信息遠不止這些。

從數據的角度來說,這樣做才算真正將功能做完整,關鍵操作后該記錄下來的東西都記錄下來了。

這也是更接近于我們說的一個概念“數字孿生”,現實世界上的東西更多地記錄在了系統上。

這也是風控的一種手段,隨時能夠排查出哪里出了問題。

我還記得某次業務問起誰改了產品信息,結果我們沒有日志記錄下這些信息就很尷尬,無法排查問題。我們大多數人做系統,特別是企業內部系統,都沒有這種將關鍵操作記錄下來的習慣,不信你看看你旁邊的同事。

五、分析原型怎么畫

直接開始畫原型,一邊畫原型一邊腦補應該有什么頁面,頁面上有什么?

這很容易讓我們的思維是很發散的,一邊需要兼顧原型的樣式,一邊需要想有什么操作,應該展示什么數據??赡苣銜谀X子里想,應不應該搞個批量操作呢,然后畫了一下,然后又覺得還是不要了,初期版本沒必要。就是這樣的不集中的思考,會消耗你很多的時間,讓你花了更多的時間去畫原型。

本質上,應該是邏輯先行,先從邏輯上大概構建好你的原型。

這里講的是大概,我特別指出,因為我曾經嘗試過將原型的邏輯先構建得非常詳細,發現這很花費時間,其實也沒必要,因為有一些頁面上的字段你在邏輯里概括一下(還有的業務會直接給你表單的字段,這個時候你更沒必要重復在邏輯里寫一遍字段),等到畫原型時直接寫在原型上也省一點事。

工作量與產出要達到一定的平衡,這樣才會有高的ROI。

六、梳理出頁面

根據業務流程圖先梳理出頁面,假設你要做的是一個簡單的商城管理后臺,從業務流程梳理我們可以得到下面的頁面。

當頁面足夠多的時候,我們就需要形成一個菜單,也就是我們說的功能結構。

七、梳理頁面上的字段與操作

參考我們上面梳理的核心邏輯與主數據信息,我們可以很快梳理出頁面上有什么字段、操作。到這里的時候,我們已經將整個原型基本勾畫出來了,接下來就是打開axure開始繪制,這一步自然難不到各位。

八、原型的邏輯怎么寫

這個邏輯已經在我的上一篇文章里寫過了,按照那樣去寫,大概率不會有什么問題,這是多年實踐下來的。

大家一定還是想要一個武功秘籍一樣的東西,那應該就是自檢表。

以下是我總結的一套自檢表。

九、最后

別忘了寫完原型之后,自己按原型走一走核心流程以及各個操作看看有沒有哪里有問題,這不比啥都強嗎!

本文由@Bruce 原創發布于人人都是產品經理,未經作者許可,禁止轉載。

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

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 想加你好友

    來自江蘇 回復