每當接到一個使用者需求，産品經理頭疼的事情之一，可能就是如何把使用者需求轉化成研發需求。怎麼了解二者的差別，并成功地将需求轉化呢？這篇文章裡，作者做了分享與總結，一起來看一下。
産品經理與研發人員的博弈是産品界永恒的話題，産品經理說研發人員不懂業務，研發人員說産品經理不懂技術，但沖突的是，每一次接到一個使用者需求的時候，産品經理都需要絞盡腦汁把它轉成研發需求，以便于研發人員能夠知道如何将該需求正确實作出來。
一、使用者需求和研發需求的差別
使用者需求是研發需求的結果，研發需求是使用者需求的過程；使用者需求的本質是“做什麼”，研發需求的本質是“怎麼做”。然而有時候“做什麼”和“怎麼做”之間是沒有必然聯系的。
比如，使用者需求是：設計一個功能，使使用者可以将目前賬号綁定的手機号更換成新的手機号。
在未經過細緻分析的情況下，我們大緻可以将該需求轉化為以下研發需求：
- 對舊手機号通過驗證碼形式進行驗證，驗證通過後輸入新手機号
- 驗證新手機号與舊手機号不同且未被其他賬号綁定後，向新手機号發送驗證碼
- 對新手機号通過驗證碼形式進行驗證，驗證通過後将賬号綁定的舊手機号更改為新手機号
在以上研發需求中可以發現，如果你不看到最後一步，根本不知道這些需求是為了實作什麼功能，而這隻是一個很簡單的功能，對于複雜的業務功能，尤其是多人分工研發的功能，很多研發人員做完了也不知道這個功能是幹什麼用的，因為在研發需求中，有時會牽涉一些功能需求；
比如上文提到的對新舊手機号進行驗證，或者涉及一些設計限制，比如上文提到的判斷新手機号是否綁定其他賬号，防止重複綁定，而這些功能需求和設計限制，都是為了最終能夠正确實作“更換手機号”的使用者需求，但其本質跟使用者需求是沒有直接關系的。
關于功能需求和設計限制的定義，感興趣的讀者可參考之前的文章《從10大管理看産品經理的日常工作——産品整體管理》。
二、為什麼需要轉化需求
之是以需要将使用者需求轉化成研發需求，是因為産品經理和研發人員的思維有着相當大的差别。
産品經理由于經常接觸業務，是以在産品經理腦海中，每次想到的都是需求的解決方案；而研發人員，在日常研發工作中，很多隻是負責某幾個接口或某幾個頁面的編寫，大多數的研發人員對業務形态沒有一個完整的概念，是以他們更關注的是需要他們做什麼東西，隻要研發需求寫得足夠詳細，他們就能在不完全清楚業務形态的情況下将功能開發出來。
還是以上文“變更手機号”的需求為例，如果産品經理給開發的需求這樣描述：由于在實際業務中，使用者有可能需要更換綁定的手機号，是以需要開發一個這樣的功能。那麼從開發的角度，他會認為這個功能是這樣實作的：給已登陸的使用者提供一個頁面，使用者輸入手機号，點選确定後，将該使用者賬号綁定的手機号修改為新手機号。
如果你問他，為什麼不做手機号驗證，為什麼沒有判斷手機号重複綁定，他們會說：“産品就是這麼設計的。”
這就是産品思維和研發思維的差別，經過多年與研發打交道，我對他們的工作方式總結了一句話，就是：盡量不少做，絕對不多做，不保證不做錯，出錯就是産品經理的鍋。
之是以會形成這樣的工作方式，是因為有可能産品經理需求描述中簡單的一句話，研發就需要好幾個人幹好幾天才能做完，在這樣的工作環境中，他們沒有太多的時間去考慮業務層面的東西，是以要求産品經理将需要做的事情寫得非常詳細，以減少研發人員在研發過程中的思考時間。
三、如何轉化需求
将一個使用者需求拆解成多個研發需求時，每個需求都可以從使用者、權限、驗證中的一個或多個次元去考慮，接下來我還是以上文的“變更手機号”需求為例，簡單分析一下如何将這個使用者需求轉化為研發需求。
所謂“使用者”，即是“人”，我們可以分析一下什麼人有變更手機号的訴求以及原因：
- 賬号所有人，變更原因：更換手機号
- 非賬号所有人，如盜号的人，變更原因：通過變更手機号，将賬号據為己有
從以上分析可以看到，這個需求的真正的使用者應該是前者，而非後者，是以這裡就涉及到“權限”的問題，如果不做權限的限制，讓後者可以很輕松地變更手機号，那麼将可能對前者造成不可估量的損失，關鍵的問題是，如何明确使用者有權限進行手機号變更呢，這就需要通過“驗證”來确認權限，我們可以再來分析一下，哪些驗證可以用來明确使用者的權限：
以上3種驗證方式都可以在某種程度上驗證使用者的身份，在這樣的情況下，應該選擇哪一種驗證方式呢，這就需要做取舍了，我們可以這樣分析：
通過以上對比表格，我們可以發現，“賬号密碼驗證”是最先排除掉的，剩下的兩種驗證方式中，我們可以發現“人臉識别驗證”的結果是最準确的，造假成本也是最高的，但同時操作門檻也是最高的，且隻能在手機上操作，而相對而言，手機号更加友善快捷，是以大多數的産品會選擇通過手機号來進行驗證。
但我們會發現，無論是哪一種驗證方式，都存在造假的可能，沒法百分百保證驗證結果的準确性，是以在這個需求中，也可以考慮雙重驗證，比如通過手機号+人臉識别來驗證使用者身份，但這未免太過繁瑣，那麼就可以考慮使用者進行手機号驗證時，判斷使用者目前的 IP 屬地與經常登入的 IP 屬地是否一緻，如果不一緻，再考慮讓使用者進行人臉識别，如果屬地一緻，則驗證手機号即可。
當然，無論怎麼防範，無非是提高了造假的成本，并不能完全杜絕作假的行為，是以，針對一些安全性更高的資訊和操作，應該再上一把“鎖”，比如支付應用會要求使用者單獨設定一個支付密碼，用來區分登入操作和支付操作，以此來增加安全性。
除了對“權限”的驗證，即将綁定的新手機号也需要“驗證”，主要驗證幾點：
- 新手機号與舊手機号不同
- 新手機号未被其他賬号綁定
- 新手機号是正确的
是以，通過以上分析，我們可以嘗試将這個使用者需求轉換成以下研發需求：
- 使用者點選“修改手機号”時，進入“驗證舊手機号”頁面，使用者發送驗證碼并進行驗證碼驗證
- 舊手機号驗證不通過時，通過系統向使用者展示錯誤提示；驗證通過時，判斷目前操作的 IP 屬地與使用者經常登入的 IP 屬地是否相同，如果相同，則進入“驗證新手機号”頁面；如果不相同，需判斷使用者目前通路頁面的裝置，如為 PC 裝置，則展示二維碼，使用者通過手機掃碼進入“人臉識别頁面”，如為移動裝置，則直接進入“人臉識别頁面”
- 如需進行人臉識别，在人臉識别驗證通過後，進入“驗證新手機号”頁面
- 使用者在“驗證新手機号”頁面輸入新手機号，驗證新手機号與舊手機号不同且新手機号未綁定其他賬号後，向新手機号發送驗證碼
- 使用者輸入新手機号驗證碼點選送出，同時驗證新舊手機号不同、新手機号未綁定其他賬号、新手機号驗證碼正确通過後，将該賬号的綁定手機号更新為新手機号
第5個需求你可能會覺得很奇怪，為什麼第4個需求已經驗證過一次，還要再驗證一次，因為使用者可能發送了驗證碼之後，又将手機号改了，是以綁定前，一定要再次驗證新手機号的合格性再綁定上去。
寫在最後
講到這裡，本文的核心内容已經講完了，最後我想講的是，很多時候産品經理志得意滿，覺得自己已經把一個使用者需求的研發需求梳理得清清楚楚，但是到了評審的時候還是容易挨怼，一方面，太多的文字容易讓人覺得找不到重點，另外，中國文化博大精深，同一時間不同的人對同一句話可能有不同的了解，甚至同一個人在不同時間對同一句話都有可能産生不同的了解。
在這樣的情況下，除了盡可能精簡一些不必要的文字之外，有時候一個簡單的流程圖就能夠把一個看似複雜的邏輯講清楚，比如你不妨試試把上面的研發需求換成一個流程圖，你會發現比上面那堆文字直覺得多，對于研發而言，他們希望産品經理能夠直擊重點，而不是把需求寫得跟小說一樣。
如果你對繪制流程圖的要點感興趣，可參考之前的文章《為什麼你畫的流程圖開發總說看不懂？》
以上便是本文的全部内容，感謝閱讀！
專欄作家
産品錦李，公衆号：産品錦李（ID：IMPM996），人人都是産品經理專欄作家。不務正業的産品經理和他的産品設計。
本文原創釋出于人人都是産品經理，未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協定。
該文觀點僅代表作者本人，人人都是産品經理平台僅提供資訊存儲空間服務。