編輯導讀：在需求文檔撰寫過程中，注意一些小的細節(jié)，能有效提升團隊工作效率。本文作者結合自己的實踐經驗，分享了優(yōu)化需求文檔提升研發(fā)人員工作效率的幾點建議，并對各個環(huán)節(jié)需要注意的問題進行了分析總結，供大家一同參考和學習。

想要提升團隊效率，第一步要做的就是識別出團隊工作過程中的低效場景。

定義低效：

我們先來定義一下什么是低效。效率是和時間、工作成果強相關的。

工作成果或目標確定時，完成該目標用掉的時間越長，效率越低；

工作時間確定時，成果和目標達成度越差，效率越低；

很多時候由于工作本身的復雜性和階段性，很難定義清楚什么是效率低和效率高。

所以本文僅從開發(fā)過程和需求表達的角度，說明可以通過一定科學的手段和工具進行規(guī)避的低效場景；

低效場景描述：

一般在需求評審會上，產品經理會為大家集中呈現原型和產品設計方案。短期內，讓大家記住是沒有問題的。馬上要做的需求和大框架的部分大家會迅速的達成共識。

然而會后一段時間內，研發(fā)人員的時間和精力相對有限，尤其是當需要開發(fā)的功能較多，對需求的吸收程度更加無法保證。時間一長，本來記住的需求也容易忘記或記混 。這時候就需要重復溝通確認，甚至返工重做。那些用在重復確認需求和需求細節(jié)上的時間，就是低效場景。

01 為什么需求會被忘記呢？

上面闡述的，需求記不住，記混，其實都是記憶的問題。結合記憶的相關規(guī)律，我們來分析一下，為什么上述場景中會出現記憶的問題。

艾賓浩斯記憶曲線

艾賓浩斯遺忘曲線由德國心理學家艾賓浩斯(H.Ebbinghaus)研究發(fā)現，描述了人類大腦對新事物遺忘的規(guī)律。是人類大腦對新事物遺忘的循序漸進的直觀描述。

多數人的記憶是符合這樣的規(guī)律的：

根據表格呈現的規(guī)律，大膽猜測一下：開完需求評審會之后，需求點在研發(fā)人員的腦中進行著瘋狂的遺忘。僅僅 20 分鐘，需求就會損失將近一半。所以按正常的開發(fā)進度，他們是永遠記不住接下來要開發(fā)的需求點的。這也就是為什么多數開發(fā)需要一邊問一邊做，因為是真的忘記了。

既然這種情況是符合科學常識和記憶規(guī)律的，我們不應該責怪研發(fā)人員記不住需求。那我們應該采取什么樣的辦法來減少或者避免研發(fā)人員的詢問，進而提升工作效率呢？

讓開發(fā)及時復習，努力記住需求么？

記單詞的時候為了對抗艾賓浩斯遺忘曲線，會為每個單詞區(qū)分 List，按照記憶規(guī)律去安排時間及時復習。不過我們可以思考一下開發(fā)和需求的關系：研發(fā)人員的工作任務是實現需求，而實現需求最快的路徑是清楚需求，實現需求。記住需求本身非但不是開發(fā)實現需求的必須之路，還會花費大量的時間。所以是沒有必要的。

下面我們就來看一下具體什么樣的文檔，從哪些方面能夠提升研發(fā)人員的工作效率。

02 讓研發(fā)人員高效的需求文檔應該具備哪些特點呢？

1. 需求點顆粒度足夠細小

研發(fā)人員對于足夠大和明顯的需求，不太容易忘記，越是細小的需求點，就越容易忘記。沒有這些細節(jié)，產品功能依舊可以說實現了。所以這些小的需求點被忘記大家都察覺不到，但往往這些被忘記的需求就是會被漏做和做錯的需求。就會變成在后續(xù)的使用中不斷發(fā)現的一類“Bug”。

所以這些細小的需求點，需要在文檔中有具體的呈現。讓開發(fā)做之前能夠再記需求細節(jié)，確保細節(jié)被完成。

我們可以看到上圖中 Excel 的需求文檔，對功能的每個需求點和邏輯都進行了描述。當研發(fā)人員做到這個功能的時候，僅需找到該功能模塊，再細看后面的需求點，就能夠清楚自己開發(fā)的功能模塊具體有多少個需求點需要做。有效避免因為忘記而造成的功能開發(fā)不完善的情況。

2. 需求描述技術化

當我們我們認識到了需求會被自然遺忘，就能夠理解研發(fā)人員看文檔最主要的功能。針對接下來要開發(fā)的需求點進行確認和回憶。

一個功能開發(fā)完成，或開發(fā)到一半時，研發(fā)人員需要對照文檔去看功能的實現情況是否滿足需求。如果文檔中全是描述性的語言，就需要他們花費一定的時間去重新理解并且和產品再次確認需求。

world 類型需求文檔的特點就是需求描述很細致，很多，像論文一樣。但如此多的描述型語言，不僅需要二次確認，而且大量的文字也會讓人望而生畏。

好文檔的另一個功能就是能夠減少研發(fā)人員確認需求的時間。Excel 文檔語言的特點，就是簡潔和技術化。

需求經過產品經理轉化后被安排在表格的每一行。像極了代碼，很多時候每一行的需求點的描述，就代表著一種或者一個代碼邏輯。不需要花費多余時間進行理解和消化，進而提升了工作效率。

3. 確保開發(fā)在做的永遠是正確的需求

研發(fā)人員在開發(fā)過程中高頻的確認需求還有一個原因：他們不記得到底哪些需求被更改過，那些需求是否還會更改。開發(fā)的工作需要被認可，已經開發(fā)過需求點就是開發(fā)的工作成果。為了產品更加細膩，需求變更不可避免。然而由于需求變更造成的重復開發(fā)和資源浪費。因為沒有記錄需求變更，使得研發(fā)人員工作成果不被認可就不應該了。

默默的調整文檔，不做變更記錄，就會導致開發(fā)的工作量得不到認可，工作沒有成就感。項目進行中，文檔更新不及時，更新沒有記錄，也成為了研發(fā)人員的痛。這種就痛促使著他們在做之前不斷的去確認需求。

能夠清晰的記錄被更改過、刪除過、延期過的需求點，的文檔會為開發(fā)帶來安全感。

上圖中的文檔，灰色是取消的需求，紅色是新增的需求。用取消和新增來代替修改。既保證了需求的準確性，又讓開發(fā)過需求能夠清晰的溯源。會讓開發(fā)對文檔充滿了信任，進而減少提問和確認需求。

4. 提高團隊獲取對應需求的效率

IT 產品不管需求多么花哨強大。最終研發(fā)人員能夠實現的產品需求都需要落到功能上。換句話說，產品經理輸出的需求高效的被團隊理解、實現，產品才會真正的有變化。

下圖我截取了，工作中和學習中見到的 excel 類型的需求文檔的表頭；我們來看一下它的特點。

首先就是所有的需求點，都歸屬于具體的功能模塊，功能模塊歸屬于需求模塊。大家有了具體需求模塊和功能模塊的基本認知，再到對應的需求點。使得研發(fā)人員對每個需求點都能清晰的對應上具體的功能模塊。

其次，所有需求點共用一個表頭，表頭陳列的需求點的不同方面，形成了團隊通用的語言框架溝通模式。研發(fā)人員通過文檔自檢當前功能模塊和需求的需求點是否有漏做的情況；UI 和測試也可以直接在文檔中找到工作需要的，信息展示的字段、相關的說明。很好的銜接自己的工作。

團隊有了通用的語言框架，彼此的信息的傳達一定是更加明確和暢快的。所以當團隊的人都適應的文檔以后，整個流程的效率一定會有所提升；

03 額外功能

Excel 的需求文檔，能對需求和功能進行量化，進而粗略的清晰產品和開發(fā)的工作量；記錄每個版本的需求數量和效果，那些需求是不夠明確？

過程中取消和新增了多少需求？

那些需求難度較大出現了返工或者開發(fā)亮點？

客觀的總結過去，才能更好的向前前進。

作者：臺燈少女；公眾號：產品人的結構化思考

本文由 @臺燈少女 原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協(xié)議。