中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

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

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

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

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

報告的生成規則跟隨方案內單元的開啟規則，具體為：

每個方案內，每新開啟一個單元且該單元內包含訓練任務，對應一份報告。

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

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

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

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

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

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

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

01 使用戰術而不是天賦，來提高你的文檔可讀性

流程圖面臨許多問題，其中最重要的是，它不是研發常?？吹降恼Z言，這涉及到了一個轉化成本。

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

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

1. 解決方案是：給偽碼

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

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

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

if 第X天，用戶在 a1 方案內：

開啟了 1個單元 & 單元內訓練任務數 >0：

生成1份報告

實例：

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

各開啟了1個新單元 & 單元內訓練任務數 >0：

生成 2 份報告

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

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

會不會清楚很多？

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

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

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

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

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

當然，你也可以直接詢問chatGPT，讓它給你答案。

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

02 授人以魚，不如？

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

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

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

1. 先寫研發邏輯（Controller），“怎么運行”
2. 再寫數據結構或者具體例子（Model），“是個啥”
3. 最后寫視覺需求（View），“長啥樣”

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

1. 什么是MVC

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

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

這三個組件分別負責應用程序的不同功能，協同工作以實現應用程序的有效管理和高效運行。

模型（Model）：負責處理應用程序的數據和業務邏輯。它表示應用程序中的數據結構、數據庫的操作、數據的處理和計算等。模型不關心數據如何展示或者如何與用戶進行交互，只負責處理數據的存取和處理邏輯的實現。

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

控制器（Controller）：負責接收用戶的輸入，并根據輸入來更新模型和視圖。它負責用戶輸入的處理、業務邏輯的調度以及模型和視圖之間的協調?？刂破鹘邮沼脩舻妮斎牒螅履Ｐ偷臄祿?，并通知視圖進行界面的更新。

2. 它有什么好處

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

MVC的核心在于將產品進行了分離，分離成了：

1. 模型，Model，即數據結構，也就是“是個啥”
2. 控制器，Controller，即運行邏輯，也就是“怎么跑”
3. 視圖展現，View，也就是“長啥樣”

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

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

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

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

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

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

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

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

3）數據部分，即數據需求，MVC中的M，Model。

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

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