需求分析之从编写到阅读到讨论

2019-11-29

需求分析之从编写到阅读到讨论

1. 落笔/需求理解

1.1 背景

我们在面向用户需求时(开始编写/阅读文档),首先要做的就是去理解这个需求出现的背景。通常,分析师会在该节阐述用户业务痛点,以帮助研发人员充分理解我们做这个项目的意义,对这个环节的理解程度,将直接影响项目的成果甚至成败。

1.2 目标和边界

然后就是“目标”,这个目标的设计,通常情况下是以项目为计量单位,或是一个项目的某个阶段的目标,在快速迭代的敏捷团队中则是一个里程碑。

我们讨论的最终目的,是“达成共识”。而明确的目标,清晰的边界,是我们要达成的第一个共识,所以,为了解决用户业务痛点,我们要做这个项目是没错,但做到什么程度,达到什么样的效果,则是根据多方因素(时间,人力,机会成本等)衡量出的结果。比如用户只想要一个填写表单存到数据库,并提供简单查询的简单功能,那么,我们就不能无限发散,将查询做成全文检索,或使用其他复杂的设计,都是不可取的。但如果说需求分析师预测到用户有80%的可能性会有全文检索的需要(依据用户习惯,数据体量等因素),那么开发人员在设计实现方案初期,就可以花费少量的时间为全文检索设计预留接口,当用户真正需要这个功能的时候,去做这个接口的实现。相反,如果我们没有预测到用户可能的需求,开发也没有根据预测预留设计接口,后期更改的成本往往是巨大的。

我们学习数据库设计范式、程序设计原则和设计模式的目的,不外于此。

 

因此,“目标和边界”这个问题写清楚或问清楚,是需求理解和讨论的基础,更是在面向用户需求变更时,项目成本考量的依据。

2. 项目依赖

当下微服务之所以流行,是因其“微”。“微”则意味着快,开发快,上线快,修复也快。 在当今多变的用户需求环境下,意味着我们能快速启动一个项目,以尽量小的成本去试错。这也是防御性编程思想的体现,其核心则是机会成本的计量。同样做一个项目,花费3周做出一个粗糙的版本给用户使用并持续迭代3个月和花费3个月之后再给用户使用,哪个对于用户价值交付更有意义是显而易见的。况且等你3个月做出项目来,市场和需求早就变了。

但微服务的微,带来的代价则是运维成本和隐性开发成本的增加。没有DevOps,就没有微服务(这是个先有鸡还是先有蛋的问题,不要跟我讨论这个)。而随着微小的服务越来越多,项目间复杂的依赖和关联关系,则成了开发团队的噩梦。

因此,团队各角色成员,均应对平台项目有一个清晰的了解,最起码应该有一个速查表,哪个项目提供哪个功能,输出了哪些数据。我当前写的看的需求文档,业务流程是从哪开始的,数据是从哪个项目来的,持久化的数据有哪些项目要订阅,等等这些,都是我们应该重点讨论的问题。

当前团队技术平台建设尚处于开始阶段,我们的标准库等很多基础设施还在建设中,在开发业务项目的过程中,将服务能力中公用的部分沉淀下来,则是团队所有角色成员共同的责任。注意我说的是所有角色,不仅仅是开发人员这个角色。

一言以概之:捋顺项目间的依赖关系,整理出哪些项目哪些接口和数据被依赖的多,我们就沉淀哪个服务/接口为公用服务/数据。

3. 功能分解

功能分解的支撑思想是“解耦”。解除各模块,各功能之间的耦合,使各模块功能之间通过接口或服务进行调用,能提高代码复用率。

水平层面的功能分解相对简单,比如发送语音和人脸识别,这在程序员之外的群体中可能是两个完全不同的功能。但若要从程序设计的角度去分解,则需要一定程度的抽象思维,从垂直的方向上去分解。

同样是发送语音和人脸识别这个例子,有一定经验的开发人员,会将其分解为“基础通信层”和“数据处理层”。基础通信的方法可能是WebSocket,也可能是Stream或者Http,且因其多样性,必须要做出抽象接口以提供具体实现的支撑。数据处理层则将人脸数据和语音数据作为输入数据进行持久化,在程序设计师的眼中,他们只是数据的不同表现形式,并非是两种完全不同的数据。所以,在这个层面上来说,程序设计师将会做两个项目,一个是基础服务,提供通信服务,另一个是业务服务,提供业务接口和数据持久化。而分解出来的这个基础服务,则会为后续类似的业务需求提供技术支撑,从而在平台的层面上降低研发成本,提高开发效率。

总结一下,发送语音和人脸识别这个例子,在程序设计师的眼里,和在用户以及需求分析师,UI设计人员的眼中,是两种完全不同的设计思路和分解方法。在我们说到功能分解的时候,大家要意识到,“功能”这个词,在不同的人思维里,是不同的东西。

所以,团队各角色的成员,需要将自己所设想的功能分解说出来,都需要告诉大家,我的分解为什么是这样的,这样分解有什么好处,这样分解如何为用户服务以及价值。

4. 用户群体划分

没有明确的用户群体的区分,做出来的项目功能面向用户群体模糊,我们得到的反馈往往就是用户的一句:不好用。

我们经常会看到有些系统具备管理员角色负责系统的各项配置,普通用户角色负责数据录入,而领导层的角色则只是看看报表无法操作数据录入。

其实在我们编写/阅读需求文档的过程中,也同样需要搞清楚我写/读的这个功能所面向的用户群体,解决的是该用户群体的哪个业务痛点。你给A群体用户展示/操作B群体用户的业务痛点,显然A群体用户根本就不会在乎数据的真实性及时性和准确性。如此这般,最终导致的结果就是用户反馈差,整个团队的劳作成果付诸东流。

5. 象限归类

象限归类方法是目前各行业各岗位非常流行的工作技巧。在项目实施规划中,可以从:

v 主要功能,必要需求

v 外围功能,必要需求

v 外围功能,辅助需求

v 主要功能,辅助需求

四个方面对项目,模块,功能进行归类,这样做的好处是什么呢?

首先想到的就是用户价值最大化和降低实现风险,同时还能作为我们迭代的依据。更厉害的是,这个简单的象限图,还能帮我们抵御各种实现风险。

想想看,眼看项目要延期了,而开发人员早就把核心功能做好了,现阶段正在做某个外围的辅助功能,我们这时候能不能上线?

项目开发依赖,开发风险,服务/模块/功能依赖,都可以在这个象限图上表达出来。可以说这个图画的越好,你的项目做的就会越成功。

6. 总结

综上所述,我们编写/阅读需求文档的时候,是需要有一套高效的方法的,不能说这个点直觉上感觉很别扭,我得好好琢磨琢磨再写再讨论,而是先将大纲罗列出来,分门别类划重点(用户群体,象限归类),重点解决核心问题。

同样,我们在一起讨论业务、设计或实现的时候,也需要提前有所准备,我要问的问题是什么,归类到哪个象限,解决的是哪个用户群体的哪个业务痛点,花费多长时间讨论是值得的?

 

这些都是我们在动笔或讨论前需要准备的,所谓谋定而后动。