关于Jeff：传统保险行业电子商务需求分析师，原ERP咨询顾问。得益于其在ERP行业的工作经验，其对需求引导、企业流程梳理有着较为独到的认识，也致力于在需求分析领域进一步深耕。
十年的工作经验，可以是用同样的方法将工作重复十遍，也可以是在每一次工作中有不同的收获。其中的区别就在于——是否有不断的思考和总结。
Jeff的需求分析札记，素材都取自于Jeff的真实工作经历。每一篇总结包含了：一个需求的故事，以及Jeff的复盘。Jeff希望通过对工作细节的整理，帮助自己更清晰的认识需求分析。并且在分享的同时，Jeff也期待得到志同道合者的反馈。
8月14日上午11:00@办公室
“小J，抽时间聊一下一个新的需求吧，我们希望玩一种新的营销模式”
“OK，胜哥，目前手上还有几个事情要处理，下午2点可以吗？”
“行”
拿起桌边的铁观音狠狠喝上一口。不知道为什么，一听到有好玩的新需求就浑身来劲。
这茶看起来味道不错。它还是周末和妹子参加茶道活动主持人送的，嗯，妹子其实也不错……想多了，先继续干活。
8月14日下午14:00@会谈室
“我们想在系统里面实现优惠卡的功能，用户输入一个密码就能在APP内领取一张优惠券。”
还以为有什么高大上的功能，不就是优惠券的发放功能么，这似乎很简单吧。小J在心里盘算着。
有过技术背景的小J已经默默将需求转化为了具体方案：
ü在系统中生成随机卡密并存储
ü卡密生成后导出供印制实体卡
ü在APP输入卡密并和数据库匹配
虽然优惠券的业务规则还没谈到，但领取卡券的总体框架似乎早就尽在掌握了，这个点就先过吧。小J心里想。
于是，他们沿着业务思路继续谈论卡券的领取规则，使用规则。半个小时，小J记录了慢慢2页A4纸。
“今天就先聊到这里吧，如果有疑问我们再找时间聊。”好大的需求啊，如果将所有内容细化一下又该忙上一阵了。
8月20日下午15:30@部门周例会
“领导，我们部门为了进行会员用户激活，所以针对性的做了一个优惠卡券的功能。下面就让小J来介绍一下具体方案吧。”
小J接过递给他的VGA信号线，顺手从包里拿出HDMI转接头。
一边调试设备，小J一边在低估。“VGA在现代的笔记本中早就差不多淘汰了，但办公室投影设备还都是VGA接口，什么时候才能看到直接基于HDMI甚至Wifi的投影仪在公司普遍使用呢？
这时，随着信号接通，投影仪屏幕被点亮。透过光线，小J撇到老板深邃的双眸，于是打消了这样奇怪的念头。
“下面就由我来介绍一下优惠券的整个需求吧”。
小J为了梳理需求、整理方案，连续加了2天的夜班。所以整个介绍还算顺畅。从卡的生成、下载打印，甚至安全性的考虑都有涉及。
介绍完成后，小J自信满满的等待领导的点评。
“整体功能还算可以，但有没有考虑追溯卡的整个生命周期管理”
“有的，领导。您看，在系统内有这样一张报表来看卡什么时候被领取，什么时候被激活”
“我不是说这个，卡从生成的那一刻就应该可以被追溯。比如，我得看到具体每一个分公司，具体领取到多少卡，然后再是有多少被领取到系统中。”
根据现在的设计方案，所有卡密在生成后就交给供应商。印制成实体卡后，密码就被覆盖了。用户只有刮开后才能看到密码。在这种情况下怎么可能追踪每一个分公司领取了什么卡呢？
于是，小J脱口而出，“似乎确实有点问题，但按照新的需求，就必须在卡的生成时候就做好标记，每一个分公司的卡单独生成。然后给到供应商时也得做好必要标记，因为卡印完后就区分不出来了。这样在管理上会有更高的要求。”
“根本不用这么麻烦啊，在卡上加一个卡号嘛。”不知道谁在会议室说了一句。
加一个卡号嘛
一个卡号嘛
个卡号嘛
卡号嘛
好嘛
嘛
领导的这个问题，确实一个简单的卡号就能完成。甚至卡号就应该才是卡的唯一标记，因为卡号可以被公开而轻易识别的，而密码的用途仅仅用户和卡号的映射，并有一定安全要求。在原来方案中，用密码作为卡的唯一识别的确不妥。
甚至，在小J的脑海中突然弹出自己钱包中各种刮刮卡其实也都有卡号，联华OK卡、手机充值卡、全家的会员卡……或许，对于刮刮卡而言，人们把注意力更多停留在挂出来的密码上了吧。
虽然这样，身为“业务分析师”(BA)，竟然百密一疏没有考虑到卡号如此频繁的东西，仍然有一丝尴尬。
复盘
在小J梳理整体业务需求时，一直都被业务描述者的思路带着走。
需要卡密系统生成卡密
需要实体卡卡密可以下载
需要领取卡密记录在系统中
当业务需求都围绕着密码展开时，似乎系统方案也围绕了密码开始了。卡号这个东西虽然常见，但因为在实际使用过程中，并不是直接参与到业务场景中，自然也就容易被忽略了。
所以在需求分析时，在根据业务方所描述的业务逻辑进行需求整理外，还必须能够跳出来看。所谓跳出来，也就是根据对业务的认识和理解，确认是否还有哪一些很重要，但被略过的重要业务需求？
在上例中，“追溯优惠券的全生命周期”就是一个管理上的重要业务需求。但由于他处在业务流程的最后，也就是运营分析的环节。
对于这类报表类数据，往往习惯的思路是：功能先上，报表后面慢慢完善。而如果需求分析没有在一开始就识别出这样的需求，往往到了最后才会发现由于缺少前端的必要数据采集，有一些重要报表无法生成，到头来还要归咎于需求分析师的功力不够了。
因为报表的形式可以随不同的管理思路和使用者的习惯有不同的需求，但业务核心数据的收集仍然是在功能阶段必须建立的。
此外，在进行一些必要功能的设计和需求梳理时，也可以记得一些类似场景下的成熟解决方案。不重复造轮子很有可能帮助绕过一些前人踩过的坑。
对于卡券类的业务模式，虽然在在具体业务规则上会有各种不同的玩法。但必要的卡号和密码、有效期都会有的。这时，如果再多问几个为什么，甚至很容易搭建出一个比较通用的卡券的领域模型。
在此基础上，再去根据个性化的业务特点进行扩展和设计就会容易很多。所以在业务经验不是很充足的情况下，借鉴一些同行业的做法也能在很大程度上帮助实现更完整的业务分析。
在基于业务方的描述完成需求整理后，注意跳出来看看是否有被遗漏的重要需求。
在开始就关注报表类需求，报表所需的基础数据应该在一开始就考虑如何收集。
在进行一些不熟悉领域的需求分析时，多参考同业的做法，多留意细节能够避免弯路
