需求改来改去高手和菜鸟究竟有什么不同

　　在产品和开发日常的工作中，需求改来改去是常有的事，但总有一些人能够化解这种恼人的事，这就是高手。那么相比产品的菜鸟，高手究竟在哪些方面表现得更为突出呢？
　　最近开发吐槽说，很多的时候，能不能一开始想好了，需求不要改来改去的。
　　感觉每隔一段的时间，都需要配合改改改，这个真的非常浪费效率。
　　我当时立刻想起：
　　某次跟老板在屋子里面对需求文档。
　　＂哎呀，你这个写得太复杂了，一开始不需要这么复杂的呀，这些这些，还有这些都砍掉。＂
　　某次在会议室里面跟开发拆业务需求。
　　告诉开发同学们，这个地方，先务必使用这个结构，将来方便改，为后续的迭代留好可能性
　　而我们当前的业务结构不需要这么复杂。那个开发同学立刻说
　　＂那你就跟我讲这个版本要做什么就好了，为什么要跟我说那么多，我本来就事情非常多。＂
　　有的时候被其他人催需求。
　　＂一个案子为什么那么难写，大方向不是会议上都订好了么？你都想了这么久了，快点结束，然后把需求提过去，方便开发干活。＂
　　工作中真的这种事情大量发生。
　　真想有的时候想怼回去，可是那样还会引起什么别的东西；很多的时候真的是不想解释，因为真的很累；有那个解释的时间，还不如自己闷头做点有价值的事情。
　　吐槽当然很爽了，但是本文的目的绝对不是吐槽，当然得说说＂如何看出一个人的专业度＂。
　　需求文档的水平，就决定了一个人在理解业务时候的专业度。
　　本文中心思想：
　　一开始就想明白，然后设计出框架感，以方便未来迭代。
　　相比：
　　想到一点是一点，然后根据需求去添加迭代。
　　在专业上，根本就是两个境界。
　　一、从两个案例说起
　　举两个例子吧（不喜欢例子的可以跳过）：
　　1. 游戏行业的礼包码案例
　　我职业生涯里面写得第一个需求是＂礼包码＂的需求文档。非常简单，人人都见过。
　　用户拿到一个几位数的字符串，比如：da3f4ggu6u232f，然后进入到游戏里面，找到一个兑换界面，输入后点击确认，验证通过后，即可拿到事先配置好的游戏道具礼包。
　　除去兑换成功外，还要考虑多少兑换失败的反馈呢（反正很多的人只考虑正常情况，从来不考虑多少异常情况）？
　　礼包码就只有一种用法么？
　　来看看，还有多少种业务场景：
　　发布会的场景，希望现场的5000个用户使用一个礼包，用到5000就作废，如何处理？
　　当我们使用用户召回行为的时候，是否可以限制注册时间仅允许老用户参与？
　　当我们想给新用户发福利的时候，是否可以限制注册时间仅允许新用户参与？
　　当我们跟渠道通过游戏礼包换资源，是否可以做到仅仅A渠道参与，B渠道无法参与？
　　这仅仅是点击兑换回复这一个小的点，这个业务的复杂性，在运营层面也许更多：
　　用户需要输入的礼包码要不要区分大小写？
　　要不要去掉数字1和0，字母L和O（为什么要去掉呢，用过的都懂吧）
　　用户用手输入的礼包码的位数支持多少种排列组合？
　　如果礼包码的位数过多，能不能想到一种方式不用手动填写？
　　用户拿到礼包码之后，能不能准确找到对应的兑换入口？
　　礼包批次激活查询，和客服的单个礼包的查询后台如何构建业务查询字段以及逻辑？
　　如果有人的礼包码被盗异常丢失，被人挂在淘宝上卖，能不能把某个批次的礼包作废掉？
　　……
　　后面的问题我还可以提出20多个。
　　2. 互联网行业的优惠券案例
　　这个业务更好理解了。
　　比如说我们在使用美团的时候，经常会收到各种各样的优惠券；在支付的时候，优惠券会自动抵扣一些金额。
　　仅仅说创建阶段，有多少可以设计的呢？
　　上面的图片，仅仅是配置优惠券的一个功能设计——怎么投放，怎么使用，怎么查询，怎么管理，每个模块都有不同的细节。
　　这两个例子，做得好，被认为是理所当然；做的不好，业务能力需要拓展，就只能发起需求，改来改去咯。
　　想到一点点自然是非常简单，但是每个业务上，实际的颗粒度，是需要考虑得非常细节的。
　　所以：
　　＂一开始就想明白，然后设计出框架感，以方便未来迭代。＂
　　相比
　　＂想到一点是一点，然后根据需求去添加迭代。＂
　　在专业上，根本就是两个境界。
　　二、但是，世界上识货的人有多少呢？
　　如果识货，需要我跟你费力巴拉解释么？
　　你要是懂，有些问题和话术就不会表达。
　　你一张嘴，我就知道你的业务段位。
　　此时此刻来看看本文开始的三段文字。
　　＂哎呀，你这个写得太复杂了，一开始不需要这么复杂的呀，这些这些，还有这些都砍掉。＂
　　＂那你就跟我讲这个版本要做什么就好了，为什么要跟我说那么多，我本来就事情非常多。＂
　　＂一个案子为什么那么难写，大方向不是会议上都订好了么？你都想了这么久了，快点结束，然后把需求提过去，方便开发干活。＂
　　很多时候，产品们受迫于时间的压力，被强行出那种粗糙的需求文档给开发。
　　这种产品，可以拿互联网的金句＂快速迭代，小步快跑＂来安慰自己，可以拿＂MVP（最小化可实施方案）＂来安慰自己——其实就是自己想得非常粗糙。
　　好了，祭出我的又一个发明的业务清单：
　　这张清单，方便各位团队管理者能够看出自己是一个什么水平，能够看出自己的团队是一个什么水平：
　　上面的这张表格，花费的时间，真的非常多非常多，不过在开发的眼里，甚至在很多不识货的老板眼里，或者在很多不明真相的吃瓜群众眼里，甚至本质上，整个开发团队的行为也还是：
　　第一周，某某功能，产品写文档，开发写写写
　　第二周，还是某某功能，产品写文档，开发改改改
　　第三周，依旧还是某某功能，产品写文档，开发改改改
　　……
　　可能一个月过去了，也还是改来改去的。
　　上面的描述，真的仅仅是表象；但是在实际的业务中，产品的境界天差地别。
　　要知道：高手的改来改去和菜鸟的改来改去终究是不一样的。
　　一个是事先声明，全盘控制（有些拿不准的，事先声明自己拿不准），但是上线后，可以通过数据论证，收集到足够多的条件，最后做出修订决策。
　　而另外一个人是在某些领导的压力下，先交付一个版本再说，发现业务表现不行，然后慌不择路，发出亡羊补牢式的需求迭代。
　　真正的了解到业务细节，才能够判断出谁是高手，谁是菜鸟。