时间: 2021-07-30 11:11:24 人气: 18 评论: 0
如果说《用户故事地图》可以解决大部分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），如果想与我同行，就请关注我呗！
作者：小婧，个人公众号：与小婧同行
本文由 @小婧 原创发布于人人都是产品经理。未经许可，禁止转载。
题图由作者提供
