需求文檔是產(chǎn)品經(jīng)理和其他人對接的一個重要產(chǎn)品，然而由于文字描述的抽象，隨著描述越精準(zhǔn)，可讀性不可避免地會變差，有些人會選擇把抽象的邏輯轉(zhuǎn)換成“更具體”的流程圖。但是，流程圖真的“更具體”了嗎？有什么方式能更清晰地表達你的需求呢？本文作者對此進行了分析，希望能給你帶來一些幫助。

需求文檔是你和其他人對接的一個重要產(chǎn)品，它的核心競爭力是——可讀性強。

如果你接手過一個其他產(chǎn)品負責(zé)的項目，你一定會關(guān)注文檔的可讀性，畢竟，要是寫得難懂，那維護起來著實是一大麻煩。

這就跟程序員看開發(fā)文檔一樣，好的文檔結(jié)構(gòu)清晰，涉及概念時，會有實例說明，而且文檔照顧了人們的閱讀習(xí)慣（簡單說，就是太長不看），讀起來很舒服。

但如果你看到的文檔描述起來是類似這樣的呢？

報告的生成規(guī)則跟隨方案內(nèi)單元的開啟規(guī)則，具體為：

每個方案內(nèi)，每新開啟一個單元且該單元內(nèi)包含訓(xùn)練任務(wù)，對應(yīng)一份報告。

例如，同一天內(nèi)用戶有兩個方案各開啟了一個新單元，且單元內(nèi)包含訓(xùn)練任務(wù)，則當(dāng)天生成兩份訓(xùn)練報告；同一天內(nèi)用戶有一個方案開啟了兩個新單元，一個單元含訓(xùn)練任務(wù)，一個單元不包含訓(xùn)練任務(wù)（比如全是測評任務(wù)），則當(dāng)天生成一份報告；同一天內(nèi)用戶有一個方案開啟了兩個新單元，且都包含訓(xùn)練任務(wù)，則當(dāng)天生成兩份報告。

會不會有一種要硬著頭皮讀下去的感覺。

主要是因為文字太長了，對進行信息分段處理造成了困難。而且，漢字本來就比較模糊，不適合描述復(fù)雜的邏輯。

再加上文字本身就是對事物的一層抽象，而我們用文字描述一種規(guī)則又是另一層抽象。而且隨著描述得越精準(zhǔn)，可讀性不可避免地會變差。

所以人們說：一圖勝千言。

那很自然，大家會選擇把抽象的邏輯轉(zhuǎn)換成“更具體”的流程圖。

但問題是，流程圖真的“更具體”了嗎？

01 使用戰(zhàn)術(shù)而不是天賦，來提高你的文檔可讀性

流程圖面臨許多問題，其中最重要的是，它不是研發(fā)常常看到的語言，這涉及到了一個轉(zhuǎn)化成本。

首先定義一個問題，我們的文檔是給誰看的？

主要是研發(fā)，次要是產(chǎn)品同事。那么研發(fā)看流程圖方便嗎？作為一個前研發(fā)來說，圖大于一長串文字。但是，流程圖彎彎繞繞，各種箭頭指向，確實存在理解和轉(zhuǎn)化的成本。

1. 解決方案是：給偽碼

說到頭，研發(fā)是要用程序語言和電腦進行溝通的，你費力畫成圖，讓研發(fā)理解圖的意思，再從圖轉(zhuǎn)成代碼，不如直接寫給研發(fā)偽碼，這樣也省下了你一個個拖框、填文字的辛苦。

聽到“偽碼”，不用慌張，畢竟我們用的也就是一些條件判斷而已。

比如，最開始給的例子，我們可以這么寫：

if 第X天，用戶在 a1 方案內(nèi)：

開啟了 1個單元 & 單元內(nèi)訓(xùn)練任務(wù)數(shù) >0：

生成1份報告

實例：

第X天，用戶的a1、a2方案：

各開啟了1個新單元 & 單元內(nèi)訓(xùn)練任務(wù)數(shù) >0：

生成 2 份報告

a1方案，新單元_生成1份報告

a2方案，新單元_生成1份報告

會不會清楚很多？

像上面那樣，使用條件判斷（if），and邏輯，把輸入、輸出及中間過程的約束條件，一個個列清楚，同時，用空格來進行文本的分層。

這樣，無論誰來看，都可以很明白地get到你的意思。哪怕時間過了很久，你自己看也看著方便。

寫的時候，可以想象自己在出數(shù)學(xué)題，把邏輯、可能用到的變量都梳理一遍，盡可能地做到“完全窮盡且互相獨立”。

比如，如果天數(shù)是你的約束條件，那就可以寫“if 第X天”，這樣研發(fā)就能關(guān)注到X是一個變量。后面你自己想對天數(shù)做更進一步的處理，只需要再給X加上限制條件，比如 if X≥5，之類的，就可以了。

同時，要記住不僅是你會因為太長不看，其他人也是一樣的懶，所以盡可能一句話寫得短小一些，減少他人對信息的處理量。

當(dāng)然，你也可以直接詢問chatGPT，讓它給你答案。

不過我感覺不太符合我的需求，過于研發(fā)化了，但這也是個思路，可以幫助我們進行優(yōu)化，大家可以看情況進行處理。

02 授人以魚，不如？

這樣寫文檔，確實讓研發(fā)在對需求時非常明確，讓我們的溝通更加便捷。但我這么寫的底層邏輯是什么呢？

下面部分會科普一些研發(fā)知識，慢慢來吧。

其實，我遵循的邏輯就是：

1. 先寫研發(fā)邏輯（Controller），“怎么運行”
2. 再寫數(shù)據(jù)結(jié)構(gòu)或者具體例子（Model），“是個啥”
3. 最后寫視覺需求（View），“長啥樣”

當(dāng)然，寫作順序可以隨你喜歡。這里的重點是，我用到了開發(fā)中一個經(jīng)典模式：MVC。

1. 什么是MVC

以下是一段什么是MVC的科普，嫌長可以直接跳過不看。

MVC是一種常用于軟件開發(fā)的設(shè)計模式，它包括三個組件：Model（模型）、View（視圖）和Controller（控制器）。

這三個組件分別負責(zé)應(yīng)用程序的不同功能，協(xié)同工作以實現(xiàn)應(yīng)用程序的有效管理和高效運行。

模型（Model）：負責(zé)處理應(yīng)用程序的數(shù)據(jù)和業(yè)務(wù)邏輯。它表示應(yīng)用程序中的數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)庫的操作、數(shù)據(jù)的處理和計算等。模型不關(guān)心數(shù)據(jù)如何展示或者如何與用戶進行交互，只負責(zé)處理數(shù)據(jù)的存取和處理邏輯的實現(xiàn)。

視圖（View）：負責(zé)展示模型中的數(shù)據(jù)給用戶。它負責(zé)應(yīng)用程序的用戶界面，包括用戶界面的布局、樣式、展示邏輯等。視圖根據(jù)模型的數(shù)據(jù)來生成用戶界面，但它不直接處理用戶的輸入或者修改數(shù)據(jù)。

控制器（Controller）：負責(zé)接收用戶的輸入，并根據(jù)輸入來更新模型和視圖。它負責(zé)用戶輸入的處理、業(yè)務(wù)邏輯的調(diào)度以及模型和視圖之間的協(xié)調(diào)。控制器接收用戶的輸入后，更新模型的數(shù)據(jù)，并通知視圖進行界面的更新。

2. 它有什么好處

了解了MVC是什么，那使用它的好處也就呼之欲出了。

MVC的核心在于將產(chǎn)品進行了分離，分離成了：

1. 模型，Model，即數(shù)據(jù)結(jié)構(gòu)，也就是“是個啥”
2. 控制器，Controller，即運行邏輯，也就是“怎么跑”
3. 視圖展現(xiàn)，View，也就是“長啥樣”

這3個部分下面我們做更詳細的解讀。

試著把自己的需求切片，想像成：

1）邏輯部分，即文檔中，常見的流程圖&說明功能部分

它是MVC中的C，Controller，這部分我們一般會對接：后端同學(xué)。

寫需求時，我們可以將邏輯&例子分開寫，這樣的好處是進行了解耦。說人話就是：邏輯和例子不會攪成一團漿糊，比較有節(jié)奏&之后自己刪改會比較方便。

2）視圖部分，即交互需求、UI需求部分

它是MVC中的V，View，對接的是：前端、UI同學(xué)。

有的項目可能會需要我們提出數(shù)據(jù)需求，那么就會有第3點：

3）數(shù)據(jù)部分，即數(shù)據(jù)需求，MVC中的M，Model。

數(shù)據(jù)需求或者說數(shù)據(jù)結(jié)構(gòu)，你可以把它想象成我們需求中的一個個例子，有的例子里是幾段文本，有的會帶些數(shù)字。對接這部分時，掌握一些基礎(chǔ)的數(shù)據(jù)結(jié)構(gòu)對我們會有幫助。這部分內(nèi)容挺多的，但對我們這次的主題沒有影響，先挖個坑，之后再講

總之，使用MVC模塊就能夠幫助我們拆分需求的運行邏輯、數(shù)據(jù)結(jié)構(gòu)、視圖展現(xiàn)這3個方面，而這3個方面就包含了軟件開發(fā)的所有部分。所有之后提需求，可以試著用這種方式拆分自己的邏輯，特定需求對特定的人，會變得更加清楚。