【商业分析】“举个例子”是一个不错的方法

发布时间:2018-12-27

下文章内容来源于与小婧同行,作者小婧

01

最近重读了一本书《实例化需求》。

之前第一遍读的时候无感,于是放在豆瓣上想卖掉。

结果有好多人联系我要买这本书。

我在想:难道我忽视了这本书的真正价值?

所以这次我又重读了这本书,结果也没觉得这本书有特别特别好。

我觉得主要是因为我是站在BA的角度来读这本书的,而这本书其实是讲在TDD/BDD和自动化测试的过程中如何写需求。

这本书并不涉及什么很新的很特别的需求分析和管理方法,对我的启发也有限。

但还是有一点启发的,今天就分享给大家。

02

在项目和产品的开发过程中,需求规格或者story的维护和更新一向是一个耗费心力的活儿。

曾经我写了一个模块的SRS(软件需求规格)大概有100多页的word,里面有很多业务规则。

后来系统上线后有些增强的业务需求被提出来了,需要修改之前的规则逻辑。

和程序猿讨厌改代码(不论之前是不是他写的代码)一样,我也很讨厌去更新SRS(不论之前是不是我写的文档)……

1.jpg

而随着AgileDevOps的兴起,在简化文档工作的过程中,提出了“代码即文档”的“活文档”观念。

但是代码对于需求人员、测试人员以及业务人员很不友好(其实就是读不懂)。

实例化需求提出来的是,直接将需求编写成自动化测试的脚本的样式,即“脚本即文档”。

这样如果代码和需求不相符,自动化测试就会不通过。

从而一方面保证需求是持续更新和维护的,与代码是一致的;另一方面,这样的编写方式对于团队成员和业务代表都很友好(大家可以看得懂)。

03

实例化需求是在需求获取和讨论分析的时候识别关键业务例子,并且将其整理抽象形成实例化的需求。

2.jpg

我觉得可以简单粗暴的理解为,在简单描述需求或者story的时候,附带了实际的例子。

这里强调的是实际的例子,而不是臆想出来的例子。

我赞同作者说的这点,非常重要。

因为我们在YY例子的时候,往往会理想化,觉得用户会按照我们设定好的剧本出演。

殊不知,用户一旦使用系统就各种放飞了,在上线运行时会出现完全没有预料到的情况。

比如,我以前就遇到过让用户填写城市信息,结果他填写了地址信息,导致数据库崩了……

04

我觉得现在可能大部分的产品和项目的自动化程度或者说人员技能达不到这本书上所说的程度。

所以想要真正实现书中的方法还是有一定困难的。

但是不妨碍我们作为BA或者产品用这个方法来优化我们自己的工作。

在你的需求文档或者你的user story添加附件,用来写实际的例子是个不错的想法。

3.jpg

比如我们可以把从客户处获取到的业务数据,特别是那些很经常出现或者出乎意料的数据进行处理后形成例子放到附件中。

这样不仅有助于业务用户进行确认(因为你让他确认例子比确认一个长长的if else业务规则要简单的多),而且有助于开发团队的人理解并进行开发和测试。

当然例子只是一些关键的例子,而不是枚举出所有的例子,重点在于真实。

05

除了上面说到的使用场景,我们不论是在进行需求调研还是在plan meeting上和团队成员过需求的时候,都可以使用这个方法。

举几个真实的例子,或者集思广益的让与会成员举例子:如果这个用户那样操作了,我们会执行这条规则吗?

千万不要相信业务代表说:“这种情况永远不会发生。”

如果他真的这么说了,作为BA和产品你需要思考有没有办法将“这种情况”彻底杜绝,而不是跳过这种情况进而留下一个“漏洞”。


Copyright © 2020 All Rights Reseverd Designed by 5thspace.net      备案号:沪ICP备15017019号-1