開發(fā)到底喜歡看怎樣的需求文檔

時(shí)間：2023-05-25 17:06:02 | 來源：網(wǎng)站運(yùn)營

時(shí)間：2023-05-25 17:06:02 來源：網(wǎng)站運(yùn)營

開發(fā)到底喜歡看怎樣的需求文檔：?一份好的需求文檔不僅能提高開發(fā)效率，還能避免需求誤解導(dǎo)致的返工。 開發(fā)喜歡看怎樣的需求文檔？我總結(jié)了以下7點(diǎn)。


目錄

1. 需求文檔必備的基本要素
2. 分工要明細(xì)，避免多人看同一份文檔
3. 邏輯要清晰，避免口口相傳
4. 重點(diǎn)要突出，避免文案臃腫
5. 嚴(yán)謹(jǐn)全面，避免遺漏異常
6. 需求所有地方的描述要保持一致性
7. 相比于文字，開發(fā)更喜歡看圖

1、需求文檔必備的基本要素

需求迭代、需求優(yōu)先級(jí)、需求產(chǎn)品負(fù)責(zé)人、需求開發(fā)人員、需求背景、需求總體描述、需求功能描述是組成一份文檔的基本要素。

如果你們公司使用了需求管理工具，就更好了，比如tapd需求管理工具，以上提到的要素，在這個(gè)管理工具上面都會(huì)要求你填寫，還有狀態(tài)流轉(zhuǎn)、開發(fā)預(yù)計(jì)開始時(shí)間、結(jié)束時(shí)間、需求保密性管理、需求的評論補(bǔ)充等，已經(jīng)結(jié)束的需求如果以后想重構(gòu)功能，查看歸檔文件也很方便。

2、分工要明細(xì)，避免多人看同一份文檔

如果一份需求需要多個(gè)開發(fā)角色來完成，比如數(shù)據(jù)分析師、前端、后臺(tái)。建議把需求拆成1個(gè)父單和3個(gè)子單，父單有需求的總體描述，子單是對應(yīng)到不同角色的需求描述。

子單給到不同的開發(fā)，開發(fā)不僅能快速瀏覽到需求明細(xì)，后續(xù)如果產(chǎn)生需求變更或者需求補(bǔ)充時(shí)也能實(shí)時(shí)反饋到對應(yīng)的需求文檔中。

注：如果使用了需求管理工具，父單和子單可分在不同的鏈接文檔中，如果使用的word文檔，在文檔內(nèi)寫好不同角色的分工模塊即可。

3、邏輯要清晰，避免口口相傳

1）避免一句話需求

舉個(gè)例子：產(chǎn)品想提一個(gè)和已經(jīng)存在功能的類似功能，比如登錄功能。然后把以前的登錄界面截個(gè)圖，再加上一句話：實(shí)現(xiàn)和以前登錄一樣的功能。

在接這個(gè)需求時(shí)好像沒毛病，但是可能做起來全是問題。比如用戶體系是否用的同一套？登錄態(tài)是否要打通？等等。所以邏輯一定要清晰，關(guān)注到細(xì)節(jié)。

2）避免口口相傳

有些邏輯產(chǎn)品經(jīng)理可能一時(shí)沒有顧及到，開發(fā)在讓產(chǎn)品補(bǔ)充時(shí)，建議產(chǎn)品把補(bǔ)充的邏輯都寫在需求文檔中，避免口口相傳。這樣有個(gè)記錄，在后期如果出現(xiàn)需求沒達(dá)到預(yù)期時(shí)，起碼有個(gè)依據(jù)看。

4、重點(diǎn)要突出，避免文案臃腫

文案臃腫是需求文檔常出現(xiàn)的問題，大概率的原因是沒有主次分明，突出重點(diǎn)。所有的細(xì)節(jié)都寫。對于常識(shí)性的細(xì)節(jié)，建議不要寫上，建議寫核心邏輯、關(guān)鍵分支、關(guān)鍵異常就可以了。

舉個(gè)例子：需要新增一個(gè)搜索下拉選擇框。

描述1（bad）: 搜索新增一個(gè)選擇食品的下拉選擇框，當(dāng)選擇食品時(shí)，把食品名稱展示在輸入框中，支持單選搜索。

描述2（good）: 搜索新增一個(gè)選擇食品的下拉選擇框，支持單選。

這個(gè)需求的重點(diǎn)：下拉框選擇食品，僅支持單選。

描述1中有常識(shí)性的描述（把食品名稱展示在輸入框中，然后觸發(fā)搜索），描述2比較簡潔。描述1的做法，當(dāng)需求內(nèi)容多起來時(shí)很容易導(dǎo)致文案臃腫。

5、嚴(yán)謹(jǐn)全面，避免遺漏異常

異常包括：

• 執(zhí)行者輸入異常。比如輸入為空、輸入非法字符、輸入重復(fù)單詞。
• 平臺(tái)業(yè)務(wù)異常。比如異常分支流程，超時(shí)異常
• 第三方異常。比如第三方調(diào)用失敗，第三方請求頻率被限制

6、需求所有地方的描述要保持一致性

一般一份需求會(huì)分為這幾部分：需求總體說明文檔、原形圖、設(shè)計(jì)稿。

• 避免同個(gè)功能邏輯分在多處展示。

目前發(fā)現(xiàn)比較多的需求模式是，需求文檔里面，一個(gè)功能模塊一張?jiān)徒貓D，然后底部寫上具體邏輯。但是發(fā)現(xiàn)有的需求文檔是這樣的：原型圖截圖里面寫著一份邏輯描述，需求文檔也寫著一份邏輯描述。這2處地方的邏輯描述大同小異。 建議把邏輯統(tǒng)一寫在一處地方表示，好處是：一是開發(fā)可以不用來回切換看邏輯，二是以后變更需求時(shí)只要改一處地方就可以了。

• 避免原型圖和設(shè)計(jì)稿描述不一致。

這是我經(jīng)常遇到的需求問題，可能產(chǎn)品和設(shè)計(jì)沒有溝通好，或者變更需求沒有及時(shí)更新，導(dǎo)致原型圖和設(shè)計(jì)稿展示的功能不一致。開發(fā)一般會(huì)在設(shè)計(jì)稿出來之前，按照原型圖做功能，等待設(shè)計(jì)稿出來后再繼續(xù)完善，如果兩個(gè)地方不一致容易讓開發(fā)誤解。所以在設(shè)計(jì)稿出來后，建議產(chǎn)品要做好設(shè)計(jì)走查，保持一致。

7、相比于文字，開發(fā)更喜歡看圖

能用圖展示的需求，盡量不要用文字。俗話說：一圖勝千言。 舉個(gè)例子：比如一個(gè)填寫的表單，描述輸入異常

用文字描述（bad）：

• 活動(dòng)名稱為空時(shí)：提示請輸入活動(dòng)名稱
• 活動(dòng)區(qū)域?yàn)榭諘r(shí)：提示請選擇活動(dòng)區(qū)域
• 活動(dòng)性質(zhì)為空時(shí)：提示請至少選擇一個(gè)活動(dòng)性質(zhì)

用圖描述（good）：




更多好文歡迎關(guān)注公眾號(hào)：產(chǎn)品的技術(shù)小課