產品說想要一個登錄注冊的功能, 你一想, 好說, 不就是用戶名密碼嘛, 然后開發完成

• 產品看到成果后: 我要的是手機驗證碼登錄
• 結果寫好的功能基本廢了

產品又想要一個登錄注冊的功能, 這回你學乖了, 確認了一下, 是手機驗證碼登錄, 沒問題, 然后開發完成

• 產品拿到成果: 怎么沒有驗證碼? 現在登錄注冊哪有不要驗證碼的?

以上情景, 你是否曾經在某個時間點遇到過? 我是經常遇到, 因此我也想過如何來避免這種功能情況.

造成這個局面的原因是什么? 很明顯, 因為你們對登錄注冊這個功能的定義不同. 要想對一個功能達成一個統一的認知, 如何做到呢? 我沒有想到什么好的方法, 只能是將功能進行細化.

功能剖析

還是以登錄注冊功能為例, 可能你接到的需求是: 一個登錄注冊功能. 而在你拿到這個需求之后的第一件事, 不是編碼, 也不是設計, 而是要先化身產品經理, 對這個功能進行剖析, 將相關的內容一一列出. 如:

使用手機號登錄還是用戶名

是否支持郵箱注冊

是否支持微信/QQ/微博等第三方登錄

是否需要驗證碼

對密碼的強度是否有要求

對密碼的長度是否有要求

對用戶名是否有限制

用戶名是否可以重復

用戶名是否支持修改

用戶名不存在時, 如何提示用戶去注冊

是否需要找回密碼功能

在可見的未來, 需求可能會如何演化

等等

注意, 在這個過程中, 你要拋棄你的程序員思維, 不要考慮技術上的問題.

當然, 以上功能可能我們并不是都需要, 但卻是我們需要考慮到的, 只有確認過, 你才能知道是否真的是不需要的功能. 因此, 一個登錄注冊功能, 也必然不會是用戶名+密碼這么簡單的事情.

在對需求進行剖析之后, 你就可以拿著剖析的列表和產品確認需求, 在這個過程中, 可能會有你沒有想到的, 自然也會有產品沒有想到的, 也可能會有你們都沒有想到的, 不過沒關系, 至少你們對功能的認知達到了統一.

一開始, 分析需求的時候, 可能想的并不全面, 畢竟有些違反程序員的思維, 而且產品經理也不是那么簡單的. 只能通過不斷的練習, 將你的產品思維提上來. 有什么好的練習辦法呢? 我不知道, 如果你知道的話希望能夠告訴我. 我在每次分析并開發之后, 還是能碰到當時沒有想到的問題. 感覺這玩意就像創作, 全靠靈感…

功能分析

這個時候, 你對這個功能已經有了一定的認識, 你已經知道想要的是什么了, 接下來就可以恢復你的程序員身份了, 開始著手實現這個功能吧.

而在這之前, 還有一些是需要你以程序員的身份來思考的, 你需要考慮一些技術上的問題, 比如:

如何對用戶的密碼進行保護

如何降低密碼被脫褲后的危害

如何防止腳本注冊

如何對接第三方登錄

估算用戶量, 是否需要增加緩存

設計功能, 并給短期的需求演化留出空間(不要實現!)

等等

至此, 設計編碼之前的準備工作已經完成了. 當然, 這并不能確保你能夠完全規避 對功能的定義不同 這個問題. 但至少在很大程度上降低了這種尷尬情況的概率.

---

以上, 只是我能夠想到的方式. 如果你有更好的方案, 希望能夠不吝賜教.

總結

以上是生活随笔為你收集整理的关于对接需求的思考的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。