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

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

定義低效：

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

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

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

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

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

低效場景描述：

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

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

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

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

艾賓浩斯記憶曲線

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

多數人的記憶是符合這樣的規律的：

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

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

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

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

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

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

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

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

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

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

2. 需求描述技術化

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

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

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

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

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

3. 確保開發在做的永遠是正確的需求

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

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

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

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

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

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

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

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

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

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

03 額外功能

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

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

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

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

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

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

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