同樣是改需求，高手和菜鳥究竟有什麼不同？

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

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

1.我當時立刻想起

某次跟老闆在屋子裡面對需求文件。

“哎呀，你這個寫得太複雜了，一開始不需要這麼複雜的呀，這些這些，還有這些都砍掉。”

2.我當時立刻想起

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

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

而我們當前的業務結構不需要這麼複雜。

那個開發同學立刻說

“那你就跟我講這個版本要做什麼就好了，為什麼要跟我說那麼多，我本來就事情非常多。”

3.我當時立刻想起

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

“一個案子為什麼那麼難寫，大方向不是會議上都訂好了麼？你都想了這麼久了，快點結束，然後把需求提過去，方便開發幹活。”

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

真想有的時候想懟回去，可是那樣還會引起什麼別的東西

很多的時候真的是不想解釋，因為真的很累。

有那個解釋的時間，還不如自己悶頭做點有價值的事情。

01

吐槽當然很爽了。但是本文的目的絕對不是吐槽。

當然得說說如何看出一個人的專業度。

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

本文中心思想：

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

相比：

想到一點是一點，然後根據需求去新增迭代。

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

舉兩個例子吧。

禮包碼案例——來自遊戲行業

（不喜歡例子的可以跳過）

我職業生涯裡面寫得第一個需求是“禮包碼”的需求文件。

非常簡單，人人都見過。

使用者拿到一個幾位數的字串，比如，da3f4ggu6u232f，然後進入到遊戲裡面，找到一個兌換介面，輸入後點選確認，驗證通過後。即可拿到事先配置好的遊戲道具禮包。


除去兌換成功外，還要考慮多少兌換失敗的反饋呢？

（反正很多的人只考慮正常情況，從來不考慮多少異常情況）


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

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

1.釋出會的場景，希望現場的5000個使用者使用一個禮包，用到5000就作廢，如何處理？

2.當我們使用使用者召回行為的時候，是否可以限制註冊時間僅允許老使用者參與？

3.當我們想給新使用者發福利的時候，是否可以限制註冊時間僅允許新使用者參與？

4.當我們跟渠道通過遊戲禮包換資源，是否可以做到僅僅A渠道參與，B渠道無法參與？


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

1.使用者需要輸入的禮包碼要不要區分大小寫？

2.要不要去掉數字1和0，字母L和O（為什麼要去掉呢，用過的都懂吧）

3.使用者用手輸入的禮包碼的位數支援多少種排列組合？

4.如果禮包碼的位數過多，能不能想到一種方式不用手動填寫？

5.使用者拿到禮包碼之後，能不能準確找到對應的兌換入口？

6.禮包批次啟用查詢，和客服的單個禮包的查詢後臺如何構建業務查詢欄位以及邏輯？

7.如果有人的禮包碼被盜異常丟失，被人掛在淘寶上賣，能不能把某個批次的禮包作廢掉？

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

優惠券案例——來自網際網路行業

（不喜歡例子的可以跳過）

這個業務更好理解了。

比如說我們在使用美團的時候，經常會收到各種各樣的優惠券。

在支付的時候，優惠券會自動抵扣一些金額。

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



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

這兩個例子，做得好，被認為是理所當然.

做的不好，業務能力需要擴充，就只能發起需求，改來改去咯。

02

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

所以

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

相比

“想到一點是一點，然後根據需求去新增迭代。”

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

但是世界上識貨的人有多少呢？

如果識貨，需要我跟你費力巴拉解釋麼？

你要是懂，有些問題和話術就不會表達。

你一張嘴，我就知道你的業務段位。

此時此刻來看看本文開始的三段文字。

1.“哎呀，你這個寫得太複雜了，一開始不需要這麼複雜的呀，這些這些，還有這些都砍掉。”

2.“那你就跟我講這個版本要做什麼就好了，為什麼要跟我說那麼多，我本來就事情非常多。”

3.“一個案子為什麼那麼難寫，大方向不是會議上都訂好了麼？你都想了這麼久了，快點結束，然後把需求提過去，方便開發幹活。”

很多時候，產品們受迫於時間的壓力，被強行出那種粗糙的需求文件給開發。

這種產品，可以拿網際網路的金句“快速迭代，小步快跑”來安慰自己。

可以拿“MVP（最小化可實施方案）”來安慰自己。

其實就是自己想得非常粗糙。

好了，祭出我的又一個發明的業務清單

這張清單，方便各位團隊管理者能夠看出自己是一個什麼水平

能夠看出自己的團隊是一個什麼水平


上面的這張表格，花費的時間，真的非常多非常多。

不過在開發的眼裡，甚至在很多不識貨的老闆眼裡。

或者在很多不明真相的吃瓜群眾眼裡。

本質上，整個開發團隊的行為也還是：

第一週，某某功能，產品寫文件，開發寫寫寫

第二週，還是某某功能，產品寫文件，開發改改改

第三週，依舊還是某某功能，產品寫文件，開發改改改

……

可能一個月過去了，也還是改來改去的。

上面的描述，真的僅僅是表象。

但是在實際的業務中，產品的境界天差地別。

要知道，高手的改來改去和菜鳥的改來改去終究是不一樣的呀。

一個是事先宣告，全盤控制，（有些拿不準的，事先宣告自己拿不準），但是上線後，可以通過資料論證，收集到足夠多的條件，最後做出修訂決策。

而另外一個人是在某些領導的壓力下，先交付一個版本再說，發現業務表現不行，然後慌不擇路，發出亡羊補牢式的需求迭代。

真正的瞭解到業務細節，才能夠判斷出誰是高手，誰是菜鳥呀。


來源：飯大官人
原地址：https://mp.weixin.qq.com/s/D6BQ3Dqzs3rB-BwQuqhIGQ