起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識如何標準化需求文檔提升團隊效率和質量？
當我們在說標準需求文檔時，到底在說什么？與網上已有的標準模板不同，其實每一個團隊，都有最適合自己的一版，可以說是千團千面，那么如何針對自己的團隊通過標準化打磨一份最優文檔呢？
下面我將按照背景、問題、方案、價值的順序，來說明標準化需求文檔的方法論，并明確其適用場景，最后試圖進一步思考標準化的方法論和邊界。
標準化的背景
首先要明確目的，為什么要標準化文檔？我們都知道項目管理是典型的標準化方法論，良好的項目管理可以有效地確保質量（一定范圍），并增效減本。其中，需求文檔作為執行環節中傳閱最高頻的文件，同樣也承載了項目管理的價值。
一般來說，需要標準化的場景，就是原有的文檔未形成標準化，這意味著文檔可能有錯誤或有遺漏，甚至可能因為一次疏忽造成蝴蝶效應般的風險導致重做。那么根據墨菲定律，只要有可能，就一定會發生。所以，標準化文檔，是從根本上解決效率和質量問題的有效方法。
如何識別問題？
通常來說，文檔未標準化的問題會出現在2個方面，首先是過程，比如文檔已經足夠詳細，可同事還是頻繁地找PM確認，這屬于效率問題；其次是結果，比如在測試階段，發現效果質量與文檔描述差距較大，這屬于質量問題，如果要返工就同屬于效率問題。
說到這里需要強調的是，問題要根據實際情況來判斷，也不是所有情況，都要按照相同的質量和效率完成。
接下來我會通過一個具體案例來進一步闡述：
- 問題背景：團隊因與甲方深度合作，需要長期駐扎在異地辦公，在此之前沒有遠程工作的經驗，歷經幾次項目后發現，不是延期就是趕著上線，質量也得不到一定的保障。
不難看出，案例中的主要問題是延期和質量，雖然這2點也與“人”相關，比如團隊成員的工作態度和能力各有差異，但本文僅從“物”的角度分析，也就是客觀事物來看，將其中的核心“文檔”抽離出來，下面先分析延期的問題：
（1）延期原因之一，發布前頻繁更改
改需求或是開發出結果再改，前者可能來自甲方的需求變化，或者是PM考慮不周；后者則是文檔閱讀者的理解與PM不一致，或者是描述中有錯誤、歧義等，這里總結的原因是：
- 來自源頭，文檔有遺漏或有錯誤，導致需要PM做后續的彌補，不僅浪費時間，也有重做的風險；
- 來自結果，閱讀者與PM理解不一致，導致PM需要做協調，這樣也會帶來不必要的工作量；
- 以及，不同PM的流程設計，語義等內容未統一，產生歧義等等，造成了結果有差異。
將這3點綜合來看，如果能有這樣一份文檔：沒有遺漏或錯誤，沒有理解不匹配的內容，沒有不同的描述方式，PM后續編寫時以該文檔作為參照物，就能解決問題了。下面再來看質量問題：
（2）開發后的效果質量差距較大
我們都知道運動員的狀態有起伏，職場人也一樣，對應的產出質量有高低，這就不可避免地會給輸出物帶來一定的影響，這里總結的原因是：
- 不同PM的文檔質量差距較大，文檔中對效果的標準沒有明確定義，不得不依賴后續的溝通來確認，因此開發產出的質量會參差不齊。
- 工時評估的精確性較差，導致砍需求或者壓縮時間來交付（這個問題用其它方案解決，本文不作展開）。
綜上，我的結論是，當團隊的工作方式發生變化時，可以視為一種“新場景”，比如集中變遠程，非敏捷變敏捷，舊領域變新領域，在新場景下最有可能出現問題，因為舊標準或舊模式與新場景不匹配，需要團隊經過一段時間去磨合迭代出新標準。
立足于核心的方案
方案并不唯一，但核心是不變的，正確的做法是根據具體情況來做選擇，解決未標準化文檔帶來的問題自然是標準化文檔，另外作為補充，可以輔以更便捷的溝通方式來解決理解的問題。
- 核心方案：內容標準，質量標準
- 解決方案：標準化需求文檔
- 輔助方案：在線協作文檔，語音在線辦公
那么具體如何落地呢？很簡單，分為2步，重新分類和完善規則。規則通常是既定的，只做小修改就行，所以我重點說分類，可以從2個角度來分，一個是人，另一個是物。
先從人的角度來分，是指按不同角色來分類，如程序員、設計師、動畫師、測試等等。
舉個例子，程序員的需求是邏輯，流程，優先級等信息，所以用表格形式描述更合適；動畫師的需求比較抽象難以描述，所以如果有類似的視頻或動圖輔以文字描述更合適。
再來從物的角度分，是指按相同規律分類，可以不斷簡化描述，并避免歧義。
善用不同的顏色、數字、符號來給打“標記”，來表示權重高低或是你想強調的重點，或者定義某個新符號來代替篇幅過長的內容，將這部分內容單獨放到一個頁面，這就好比程序里的“封裝”，不必每個人都要清楚文檔的全貌，這樣做可以使某一類角色迅速聚焦到他需要看的部分，這樣就能用最少的內容表達最豐富的信息，使文檔達到極簡。
最后說規則，就是團隊對文檔共同約定并遵守的管理方法，包括命名，備份，變更等等，概括一下有兩點通用規則，一是關于權責劃分，二是關于文件管理。
真正的價值
標準文檔一般需要歷經1-2個項目來打磨，形成模板后，PM只需以最少的思考撰寫，后續將整理完成的需求填寫即可，團隊成員的理解會逐漸與PM接近一致，質量標準也已設立，后續執行作參考，這樣效率和質量就得到了提升和保障。
整體來看，一份標準需求文檔發價值是提升開發效率和質量，降低溝通成本，新人學習成本，重做延期的風險。
但是如果想量化價值，是既不可取也不現實的。有2點原因，首先，在本文背景已經提到，另一核心因素關乎于“人”，所以單獨抽出文檔來證明價值，并不準確；其次，如果要計算，提升的價值應乘以未來文檔的數量或工時，這種未知值也很難估量。
最后再回過頭看項目管理三角，除去成本，只看效率和質量，其實這二者在本質上是一對矛盾指標，所以標準化文檔真正的核心價值在于：在客觀事物的層面，平衡效率和質量的最優解。
適用場景
在本文的背景已經提過，適用場景的核心是未形成標準化，同理，不適用的場景就是已形成標準化。
這里需要額外指出，不適用的場景還存在一種陷阱：
如果一個團隊，彼此之間非常熟悉，那么這種人與人之間大量的交流也會形成某種標準化的習慣，也就是所謂的“默契”，在這種情況下標準化雖然對當前沒有多少價值，但是對新同事而言就不同了，可能他很難融入這種默契，無法通過文檔來迅速上手工作。
回到正題，什么是已形成標準化的場景？這里我只舉幾個例子參考，并不唯一。
- 大公司，因為大公司自有一套成熟的標準化文檔體系。
- 中小團隊，如果工作場景未發生顯著變化，那么原有的標準已接近最優解。
- 敏捷模式，敏捷文檔已足夠極簡，是通用的標準化。
關于標準化的思考
相比需求文檔，我們更常見的問題是如何將一個產品標準化，或者制度標準化，所以我想探討一下標準化方法論和邊界。
支撐方法論的底層是思維，標準化屬于工程思維的核心，從歷史來看是從工業革命開始后廣為流傳，但如果將時間尺度放大到最遠，我們會發現倉頡造字到現代文字，也是一場漫長的文字標準化，其中的甲骨文、象形文字等等已經被淘汰了，而國外則演變出了不同的文字，從這里可以看出2點特征：
- 沒有一勞永逸的標準，標準化是持續的狀態，只有階段性的標準，所以標準具有時間屬性。
- 不同標準是基于不同人的共識而建立的，所以任何標準都有一定的適用范圍，比如英語在世界通用，方言則在不同地域通暢，表情包顏文字則廣泛適用于不同的社交關系。
標準化的結果是取代舊標準，還伴隨著舊標準下系統或產品的逐漸衰落，比如智能手機與諾基亞就是最典型的例子，那么如果標準化涉及到關于人或組織，會發生什么？
來回答制度的問題，我們知道，在某些場景下，遠程辦公比集中辦公效率更高，或者OKR比KPI更好等等，然而問題的關鍵在于，支撐方法論的是思維，如果推行某個新標準，就意味著持有舊標準的人或者組織會受到挑戰，要打破他們思維里的墻，甚至還會遭受利益上的損失。所以，如果想試圖改變某個人或組織原有的思維，要格外小心，很可能走不通。
所以，標準化對人來說是反人性的，影響的人越多，角色越多樣，阻力也越大，這是標準化的邊界。
再來回答產品標準的問題，要先想清楚什么是標準？直接去市場尋找一個標準，看它存在的時間，越久就說明越穩定，比如需要深度研究某一個競品，就選歷史最久的那個。
另外隨著時間的推移，市場競爭更加激烈，還會產生標準化的對立面——非標準化，對應產品的特征就是個性化，定制化，價值差異化等等，那么這二者如何選擇呢？
答案還是看時間，已形成的標準做復制，在此基礎上做非標準化來滿足市場需求，以此循環往復，沒有終點，對產品來說，標準與非標是永恒的主題。
本文由 @布藍 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
干貨