又见树木,又见森林(2):需求设计

如果说《用户故事地图》可以解决大部分PO以及BA在需求分析时可以“又见树木,又见森林”的话,《需求设计》其实主要是写给BA和SA的。之前说到最近在看几本书,基本上都是用来解决“只见树木,不见森林”的问题的。

今天和大家分享第二本《需求设计》。

如果说《用户故事地图》可以解决大部分PO以及BA在需求分析时可以“ 又见树木,又见森林 ”的话,《需求设计》其实主要是写给BA和SA的。

如果运用得当的话,我们可以使用用户故事地图来进行需求的收集和整理,用需求设计提到的情境驱动设计来进行构思和设计。

之前我曾经接触过一些设计师,非软件的。

大家知道汽车或者飞机是怎么设计出来的吗?

一般来说,客户方会给出需求,比如我要求车子要能运送1吨以内的货物,满载时车子的速度可以达到80码,油气混合动力,其他满足国家标准……

接下来会由总体设计师对其需求进行分析,也就是进行指标的分解。

比如,要能运送1吨以内的货物,可能会对车体设计、动力设计等都有相应的需求。

而整个设计部门会按照功能进行划分,会有车体结构设计部门,动力设计部门,电子设备设计部门。

一条客户需求可能会涉及到多个设计部门,同样的多个需求可能会对同一个设计部门的一个指标有影响。

比如,结构设计部门发现如果要载重1吨的货物,必须要有一定的强度支撑,这会增加车身重量。

但是,增加的车身重量就会影响到车速。

纷繁复杂,理不清。

曾几何时,各个设计部门也是各自为政,只关心自己的指标,不考虑对其他设计的影响。

最终在物理机外场联试联调的时候就会出现各种各样的问题,造成非常大的损失。

嗯,你可以想象一下,一架飞机在进入风洞实验的时候,才发现问题……

这个损失后面大概有几个零?

我是数不清楚的……

这都是因为“ 只见树木,不见森林 ”导致的。

而随着技术的发展和观念的更新,在工程设计过程中,会采取总体牵头先进行需求的分析和设计,再由各个设计部门去进行设计。

并且因为计算机技术的发展,越来越多的测试和调试不是实物的,不是物理机的调试了,而是采用大量的仿真、模拟手段进行测试。

保证在早期将大量的问题消除,避免不可挽回的数不清的零的损失。

《需求设计》提出的我们的软件设计可以借鉴工程设计的部分。

作者提出了六框设计模型:

而与我们今天想要解决问题关系比较密切的是第一层, 情境设计 。

回忆一下前文,汽车的需求时怎么提出的呢?

用户提需求的时候大部分是情境化的。

在这种情况下,我们是怎么处理的。

在那种情况下,我们有怎样的流程。

对了,我们还有一些特殊的情况。

对于如此多的纷繁复杂的信息,在进行需求的分析的时候难免会迷失方向。

我们需要避免几个常见的问题,需求的遗失以及需求的冲突。

需求的遗失

需求的遗失,往往因为我们在进行需求收集的时候,自我假设了一番:

  • 用户一定会将所有的需求非常明确的告诉我。
  • 用户说的东西是一致的不存在矛盾的。
  • 我能够联系到所有的干系人,并且获得信息。
  • 最终我设计的方案会由客户方进行评审,并且对于其中的问题,他们都能明确的指出。

呵呵哒……

我相信做过年把的BA不会如此单纯了,因为这些假设而产生的坑和锅多的数都数不清了。

曾经在UAT的时候,用户说,不对啊,我们还有这样的场景……你们这样交付,我们没办法签字的。

你会很委屈,因为你觉得客户之前调研的时候根本没有提过这样的需求。

而整个团队可能都会责怪你,责怪你没有“认真”的收集并和客户做确认。

这是收集和确认的问题吗?

很多情况下,并不是。

需求的遗漏,有可能是你没有做需求验证导致的。

前两天我在BABOK中分享了关于Requirement Validation的相关内容。

其实需求验证也是提前对需求进行测试的工作,保证需求的完整性。

那具体怎么进行需求验证呢?

需求设计

《需求设计》的作者提出了一个方法,就是 情境设计 。

通过对任务、用户组、数据表以及任务间消息的设计,来减少需求验证。

任务

首先,可以通过情境分析出涉及到的任务,最好是能拆分到原子任务。

对于BA来说,你可以将任务理解为活动。

但是对于SA来说,任务可能或者说,应该是比活动更细的元素。

比如,在地上挖洞,这是BA眼中的任务。

而SA会将其拆分成领队者命令团队开始挖洞,以及挖洞结束两个任务。

请BA细细品味一下这两者的不同。

这也是BA和SA在思维上不同的地方。

用户组

对于用户组,我们需要进行界定。

这个比较简单,我们在绘制泳道图或者用例图的时候,本就会涉及到用户组的识别。

而其实我们之前在识别任务的时候就可以识别出相关的用户组了。

并且将哪些用户归在一组,很大程度上与任务相关。

一般情况下,我们会把执行同类型的任务,甚至是相同任务的用户归在一个用户组里面。

数据表

我不知道有多少BA在设计的过程中会考虑数据表的问题。

但是SA或者DBA肯定会考虑这个问题。

作为BA需要清楚的是,你这个任务中使用到的对象属性,可能会在其他什么任务中使用到。

是否有数据之间的传递等等。

业务设计数据库不是你的职责,但是你有责任清晰的表明数据的关系。

任务之间的消息

在BA理解,任务之间的关系无非是一个用户在执行一个触发了什么机关,导致了另外的一个任务的变化。

而对于SA来说,范围要广的多。

在我粗略的阅读了Activitii的相关书籍后,发现单就工作流来说,消息是无处不在的。

但是无一例外,消息的产生都是基于情境的。

即在一种什么样的情况下会由谁发消息给谁,产生什么结果。

说到这里,我们可以知道,基于情境进行需求设计,主要是将任务、用户组、数据表、任务之间的消息这4个元素进行相互验证,以保证需求的完整性,减少遗漏。

如果我们在需求分析和设计的初期就这么去做,能够识别出相当多之前遗漏的部分。

如果有机会大家可以尝试一下。

矛盾的需求

有两种情况可能会有需求矛盾的状况。

同一个用户,他在描述一个流程的时候,使用规则A,比如快递敲门的时候,要在关闭水龙头之后,才能去开门。

而当他在描述另外一个流程的时候,可能时隔数月,使用规则B,比如女朋友敲门的时候,要先去开门,再去关闭水龙头。

如果你简单的设计为先关水龙头再开门,或者先开门再关水龙头,都不妥当。

此时你需要做的应该是分析这两种情境,找出矛盾点和解决方案选项。

不同的用户,他们在描述同一个流程的时候,有矛盾。

这个可以理解,因为每个人的角色不同,看待一件事情的角度也就不一样,很可能会有矛盾的规则出现。

此时,你必然需要找出产生这样问题的原因,并且根据项目或者产品的目标进行引导,以达成一致。

OK,问题来了。

我们怎么发现需求是矛盾呢?

如果需求是一份清单,或者是一个长长的Backlog,必然很难发现。

而如果使用情境设计中的四个元素是很容易分析出来的。

我们在识别出任务后,对用户组以及任务间的消息分析可以很快得出,因为参与的用户组不同,而导致了任务间的消息触发机制不同。

这其实也相应的可以识别出备选的解决方案。

全局性

而我们在提到“只见树木,不见森林”的时候,不得不提到需求的全局性的问题。

在工程设计中,有个部门叫做“总体部”,主要职责是统筹各个专业设计部门对于需求的分析、设计和实现、测试。

他们会接收到来自于客户的情景化的需求,进行分析和总体设计后,将需求拆分成为各个设计指标,下发给各个专业设计部门。

比如,结构设计部门,你这边强度要求是多少多少。

动力设计部门,你这边要求要支持多少多少。

很显然,总体在分析这些需求的时候,会从全局上看,因为有些指标是相互牵制的。比如,你强度要是很大,那么可能自重会很重,对动力的要求也会高。

借鉴这样的想法,在使用情境设计的时候,也需要考虑这样的全局性。

在进行需求分析及设计的时候,一定要时不时的退后一步,看一下四层的关系,全局的目标。以保证不会偏离航线。

《需求设计》这本书,我会推荐给偏向后台设计的BA阅读,特别是抱怨和程序猿沟通不能的BA进行阅读。

我也不止一次的被程序猿提醒:“你这样的方案和客户对接,当然没问题。但是我们在设计的过程中需要考虑更多的细节。”

我们如果可以在需求分析和设计的前期,通过情境设计的方式,对需求进行验证,进而保证解决方案的整体效果,是解决“ 只见树木,不见森林 ”的方法之一。

小婧是一名行走在实践路上的资深业务分析师(BA),如果想与我同行,就请关注我呗!

作者:小婧,个人公众号:与小婧同行

关键字:产品经理, 需求

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部