在產品和開發日常的工作中，需求改來改去是常有的事，但總有一些人能夠化解這種惱人的事，這就是高手。那么相比產品的菜鳥，高手究竟在哪些方面表現得更為突出呢？

最近開發吐槽說，很多的時候，能不能一開始想好了，需求不要改來改去的。

感覺每隔一段的時間，都需要配合改改改，這個真的非常浪費效率。

我當時立刻想起：

某次跟老板在屋子里面對需求文檔。

“哎呀，你這個寫得太復雜了，一開始不需要這么復雜的呀，這些這些，還有這些都砍掉?！?/p>

某次在會議室里面跟開發拆業務需求。

告訴開發同學們，這個地方，先務必使用這個結構，將來方便改，為后續的迭代留好可能性

而我們當前的業務結構不需要這么復雜。那個開發同學立刻說

“那你就跟我講這個版本要做什么就好了，為什么要跟我說那么多，我本來就事情非常多?！?/p>

有的時候被其他人催需求。

“一個案子為什么那么難寫，大方向不是會議上都訂好了么？你都想了這么久了，快點結束，然后把需求提過去，方便開發干活?！?/p>

工作中真的這種事情大量發生。

真想有的時候想懟回去，可是那樣還會引起什么別的東西；很多的時候真的是不想解釋，因為真的很累；有那個解釋的時間，還不如自己悶頭做點有價值的事情。

吐槽當然很爽了，但是本文的目的絕對不是吐槽，當然得說說“如何看出一個人的專業度”。

需求文檔的水平，就決定了一個人在理解業務時候的專業度。

本文中心思想：

一開始就想明白，然后設計出框架感，以方便未來迭代。

相比：

想到一點是一點，然后根據需求去添加迭代。

在專業上，根本就是兩個境界。

一、從兩個案例說起

舉兩個例子吧（不喜歡例子的可以跳過）：

1. 游戲行業的禮包碼案例

我職業生涯里面寫得第一個需求是“禮包碼”的需求文檔。非常簡單，人人都見過。

用戶拿到一個幾位數的字符串，比如：da3f4ggu6u232f，然后進入到游戲里面，找到一個兌換界面，輸入后點擊確認，驗證通過后，即可拿到事先配置好的游戲道具禮包。

除去兌換成功外，還要考慮多少兌換失敗的反饋呢（反正很多的人只考慮正常情況，從來不考慮多少異常情況）？

禮包碼就只有一種用法么？

來看看，還有多少種業務場景：

1. 發布會的場景，希望現場的5000個用戶使用一個禮包，用到5000就作廢，如何處理？
2. 當我們使用用戶召回行為的時候，是否可以限制注冊時間僅允許老用戶參與？
3. 當我們想給新用戶發福利的時候，是否可以限制注冊時間僅允許新用戶參與？
4. 當我們跟渠道通過游戲禮包換資源，是否可以做到僅僅A渠道參與，B渠道無法參與？

這僅僅是點擊兌換回復這一個小的點，這個業務的復雜性，在運營層面也許更多：

1. 用戶需要輸入的禮包碼要不要區分大小寫？
2. 要不要去掉數字1和0，字母L和O（為什么要去掉呢，用過的都懂吧）
3. 用戶用手輸入的禮包碼的位數支持多少種排列組合？
4. 如果禮包碼的位數過多，能不能想到一種方式不用手動填寫？
5. 用戶拿到禮包碼之后，能不能準確找到對應的兌換入口？
6. 禮包批次激活查詢，和客服的單個禮包的查詢后臺如何構建業務查詢字段以及邏輯？
7. 如果有人的禮包碼被盜異常丟失，被人掛在淘寶上賣，能不能把某個批次的禮包作廢掉？

……

后面的問題我還可以提出20多個。

2. 互聯網行業的優惠券案例

這個業務更好理解了。

比如說我們在使用美團的時候，經常會收到各種各樣的優惠券；在支付的時候，優惠券會自動抵扣一些金額。

僅僅說創建階段，有多少可以設計的呢？

上面的圖片，僅僅是配置優惠券的一個功能設計——怎么投放，怎么使用，怎么查詢，怎么管理，每個模塊都有不同的細節。

這兩個例子，做得好，被認為是理所當然；做的不好，業務能力需要拓展，就只能發起需求，改來改去咯。

想到一點點自然是非常簡單，但是每個業務上，實際的顆粒度，是需要考慮得非常細節的。

所以：

“一開始就想明白，然后設計出框架感，以方便未來迭代?！?/strong>