需求分析之从编写到阅读到讨论
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. 总结
综上所述，我们编写/阅读需求文档的时候，是需要有一套高效的方法的，不能说这个点直觉上感觉很别扭，我得好好琢磨琢磨再写再讨论，而是先将大纲罗列出来，分门别类划重点（用户群体，象限归类），重点解决核心问题。
同样，我们在一起讨论业务、设计或实现的时候，也需要提前有所准备，我要问的问题是什么，归类到哪个象限，解决的是哪个用户群体的哪个业务痛点，花费多长时间讨论是值得的？
这些都是我们在动笔或讨论前需要准备的，所谓谋定而后动。