描述：有時候看似笨拙而浪費時間的撰寫需求方法，反而是最省力的。正所謂“磨刀不誤砍柴工”。

很多初級產品經理往往會產生這樣一個錯覺，這個需求已經很明確了，甚至都是常識性的一些東西，不需要逐字逐句的將每個按鈕的具體含義、數據來源、交互邏輯、權限控制邏輯寫在需求中了?；蛘邽榱怂^的敏捷開發，只需要口頭跟所有的研發和測試說清即可。短期內看似提高了效率，而下文將列舉幾種場景是會導致這樣做出的需求是在降低團隊整體的效能。

場景一：需求之間穿插需求

當我們在做一個需求時，是需要保持很高的專注度和思維敏感度的。而此時，倘若在插入一或多個需求進來，將如何處理？我們可以按照緊急程度和重要程度將需求歸類（重要且緊急、重要不緊急、緊急不重要、不重要不緊急），并且進行優先級排序。

但是此時我們的思維其實是已經碎片化，當一天內大腦進行“多線程”工作時，我們就需要把每個版本的需求盡可能詳盡的寫出來，以防止被打斷思路后需要很多的回想時間。

場景二：多次反復修改需求

無論是初級產品經理還是資深產品經理，需求大多數情況下不會一次性盡善盡美。都是需要在和產品團隊其他成員、研發部門、測試部門、業務部門進行多次的溝通，輸出符合當前業務需求最合理的方案。即使需求寫的“盡善盡美”，在開發過程中，也可能會因為一些未知因素導致需求的變更。

這個時候，不僅是需求中的每個細節都要詳細描述，最好是有較為清晰的變更記錄，包括變更內容，變更原因等。不然很可能發生這個需求改過后一段時間，就忘記了當初為什么要這樣改（尷尬臉）。

場景三：團隊中增加新人

這個應該是最好理解的一個場景。需要注意的是，團隊中增加新人包括常見的招聘新人、其他部門轉移過來的人，還有本來不在項目中的人（沒有聽過評審）新加入這個項目。為了新人能快速上手工作，需求當然是要以寫給“白癡”的標準來。

下面是兩個反面的例子，我在做需求時，已經盡力以“白癡”的標準去描述需求，但還是會有一些意想不到的小插曲。

案例A：在做一個積分商城后臺需求的時候，由于需求反復改了幾次，和業務部門溝通以前有些寫好的需求在此版本中不做了。按照我的習慣會用一個灰色遮罩將不需要的功能遮住而不是直接刪除，因為這樣可以記錄下來這個需求演變的過程，再次啟用的時候也方便查找。我沒有對灰色遮罩的含義進行說明，就對研發和測試人員造成了困擾，這個在我的認知中屬于“常識性”的規則，現在已經被打破了。所以在之后的需求版本中，我會做一個全局說明，特別標明一些標注的含義。

案例B：在進行一個需求描述的時候，涉及到兩類商品的金額，我的需求描述中是顯示“A類商品的金額+B類商品的金額”，我想表達的含義是顯示兩個金額中間用+分隔，但是研發將兩個金額相加顯示。這個案例給了我一個經驗，寫的需求的時候自己要多讀，看看是否有歧義句的可能，并且在寫完規則后有一個舉例，就會降低歧義的可能性。

凡事無絕對，如果有一些特殊情況，也不用執著于“白癡”般的需求。方法不是目的，結果才是目的。能夠快速高質量的將需求完成上線才是最終目的。只是別忘了在上線后，將產品文檔補充完整，也是對自己需求的嚴謹性做的再一次檢驗。

本文由 @芝士肉松包 原創發布于人人都是產品經理。未經許可，禁止轉載。