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

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

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. 总结

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

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

 

这些都是咱们在动笔或讨论前须要准备的，所谓谋定然后动。