需求看不懂到底是谁的责任？
关于Jeff：传统保险行业电子商务需求分析师，原ERP咨询顾问。得益于其在ERP行业的工作经验，其对需求引导、企业流程梳理有着较为独到的认识，也致力于在需求分析领域进一步深耕。
十年的工作经验，可以是用同样的方法将工作重复十遍，也可以是在每一次工作中有不同的收获。其中的区别就在于——是否有不断的思考和总结。
Jeff的需求分析札记，素材都取自于Jeff的真实工作经历。每一篇总结包含了：一个需求的故事，以及Jeff的复盘。Jeff希望通过对工作细节的整理，帮助自己更清晰的认识需求分析。并且在分享的同时，Jeff也期待得到志同道合者的反馈。
天书.png
8月21日上午10:30 @办公室
“终于搞定了！”小J在座位上舒舒服服的伸了个懒腰。
昨天一下午需求通过了业务部门评审。今天上午又对几个细节做了调整，需求文档就算是完成了。
又花费了5分钟，小J从上头到尾又浏览了一遍文档。说心里话，他对文档的质量还是颇为满意的。
他知道，需求文档必须层次段落清楚。并且为了便于阅读和理解，语言组织要尽可能精简，同时，最好是使用小段落来展现对功能点的描述。
如果就拿上面这个段落就是需求文档都一个章节，如果修改成更容易理解的形式，应该是这样的：
更清晰表达的注意事项：
- 层次段落清楚
- 语言精简
- 使用小段落
需求文档的最终目的是让写代码的兄弟看明白。应该让他们的脑力更多的用于代码的架构，而不是理解需求上……
想着想着，小J不经又欣赏了一遍自己的“作品”……
8月25日上午9:20 @办公室
“叮铃铃”
“喂”
“小J，和你确认一个需求。”电话那一头传来R的声音。
R是项目组的测试，项目繁重的测试任务练就了R飞一般的操作手速，如果这样的微操来玩魔兽，也绝对是把好手。
“怎么了？”
“是这样的，在需求文档里面有提到一个流水号的概念。但目前似乎大家的理解有一些不一致。”
“流水号还不好理解吗？同一种类型的优惠卡流水号顺序往下排呗~”
“可问题是，每一次生成卡号时流水号唯一，还是系统内的流水号就是唯一？”
“当然是系统内同一个流水号只能存在一个咯！”
“但目前他们做的效果是每一次生成流水号的时候都从“1”开始编号，这样也不能说和需求不一致，因为这个点需求上也没写明确。但我觉得实际需要的应该不是这样的，所以和你确认一下。”
“嗯，你理解的没错……”
“好的，我刚才给你发了个邮件，你答复确认一下吧。”
“没问题……”
挂了电话，小J显得有一些局促。
虽然和项目组的私交不错，这样的小问题不至于通过需求变更来处理。但毕竟是对需求理解歧义造成的问题，如果就这样上线，那还真不好说还算不算一个“小问题”了。
复盘
从上面的例子中可以看到，就一个如此简单的“流水号”的概念就可以产生如此巨大的偏差，要保证需求文档中的描述准确其实并不那么简单。
虽然，大部分业务场景中，流水号就是整个系统中唯一的，但确实可能存在一些业务需要会在每一个事务状态下从1开始生成流水号，以便于知道某一条记录在事务中的处理顺序。
比如足彩3D的开奖程序，就必须记录每一次开奖的第1、2、3个数字，并且三个数字的顺序不能替换；到下一次开奖时需要记录的还是第1、2、3个数字，而不是第5、6、7个数字。
所以，如上的理解差异并不能说案例中的程序员理解是错误的。
甚至可以说，在一个有需求分析师的开发团队中，保证需求传递不失真就是需求分析师的职责。
虽然通过书面表述的确会存在各方理解不一致的情况；虽然一些理解能力欠缺或者缺乏责任心的程序员也会导致需求理解的扭曲。但需求分析师的存在，就是需要去采用各种手段来化解各方对需求理解的不一致，减少需求传递失真导致的开发风险。
所以在上面这个案例中，虽然可以认为程序员也没有必要的开发常识或者责任心。但出现这样的错误归根到底仍然是需求分析师的责任。
需求文档的质量就是需求分析师的基本功。虽然不可能直接通过文字传递来保证各方理解100%的准确，但事实上仍有办法来避免一些可以预见的歧义。
在一些需求文档的模版中，都会有一个“项目背景”或者“需求背景”的章节。在一些项目团队中，这个章节也就是形式上必须得写，以提高逼格的部分。
但事实上，在阐明需求的细节前，介绍清楚需求的背景和目的，是帮助读者理解需求文档必不可少的环节。
任何需求细节的描述都是为了一个统一的业务背景服务。说明白了业务背景，事实上就是解释明白了“为什么要做这个需求”。这是在需求细节之外的更高层次的东西。如果在这个层面能让读者保持理解上的一致，那么下一层的理解往往可能就水到渠成。
比如在本文的例子中，编写流水号的目的是为了：“让卡片在系统内有一个唯一识别的编号，以便于未来运营分析时可以追溯每一张卡的去处”。如果解释清楚了这一层的意思，就不再需要详细的解释更细节的东西，开发者自动就会知道要实现这个目的，绝不是每次生成流水号都从1开始。
再举一个例子，我们需要在app中做一个消息推送的功能。
如果我们就写成：“app能够推送消息，用户点击推送的消息就可以查看对应的内容”。而这一个描述还有很多的歧义，如果要描述清楚，我们必须在增加很多细节：
- 推送消息是必须在APP打开时才能收到还是关闭时也能收到？
- 消息推送是指定推送，还是在预装app的所有软件中都进行推送？
但如果我们直接的表述清楚需求的目的和背景：推送消息是为了激活长久不使用app的用户。这样在更高的层次上和读者达成了一致，那么就算缺少那些细节，理解上也不会有太大的误差。
- 因为目标是长时间不使用app的用户，所以推送的消息必须在App关闭时也能够送到
- 对于用户激活来说，需要能够识别出那些不经常登录的用户，然后进行精准的推送
我们可以看到，当开发者知道了需求的最终目的和背景，很多细节上的东西就会主动的去寻求确认，甚至自主的决策（因为目标已经一致了，所以一些细节上的差异想法也不会有太大的偏差）。
