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