《Spring Boot 实战纪实》之如何攥写需求文档

前言
(思维篇)人人都是产品经理
- 1.需求文档
  - 1.1 需求管理
  - 1.2 如何攥写需求文档
  - 1.3 需求关键点文档
- 2 原型设计
  - 2.1 缺失的逻辑
  - 2.2 让想法跃然纸上
- 3 开发设计文档
  - 3.1 功能梳理
  - 3.2 数据库设计
- 4 制定开发任务和计划
  - 4.1 时间管理
  - 4.2 任务管理(任务拆分+排期)
(技术篇) 码农的自我修养
5 Java基础
- 5.1 Java环境搭建
- 5.2 Java基本语法
- 5.3 Java流程控制
- 5.4 Java 集合
- 5.5 Java 类与对象
- 5.6 构造方法
- 5.7 封装,继承,多态
- 5.8 Java抽象/接口
- 5.9 Java常用类
- 5.10 Java异常处理
- 5.11 异常的定义及捕获
- 5.12 Java多线程/线程池
- 5.13 Java的反射机制
- 5.14 Java的23种设计模式
6 Spring框架
- 6.1 了解spring
- 6.2 Spring带给Java开发的便利
- 6.2 Spring ioc/aop
7 SpringMVC
- 7.1 了解springMVC
8 SpringBoot
- 8.1 MVC 模型
- 8.2 拦截器
- 8.3 过滤器
- 8.4 POJO
- 8.5 controller
9 MyBaits plus
8 Web基础
- html+css
- javascript
- bootstrap
(实战篇) 打造自己的轮子
- 10 项目架构
- 11 网站母版构建
  - 11.1 thymeleaf介绍
  - 11.2 使用thymeleaf构建网站模板
- 12 首页
  - 12.1 banner
  - 12.2 轮播图
  - 12.3 文章分页
  - 12.4 编码实现
- 13 登录
  - 13.1 功能点介绍
  - 13.2 知识点
  - 13.3 编码实现
- 14 注册
  - 14.1 功能点介绍
  - 14.2 知识点
  - 14.3 编码实现
- 15 用户管理
  - 10.1 功能点介绍
  - 10.2 知识点
  - 10.3 编码实现
- 16 权限控制
  - 10.1 功能点介绍
  - 10.2 知识点
  - 10.3 编码实现
- 17 权限控制
  - 11.1 功能点介绍
  - 10.2 知识点
  - 10.3 编码实现
总结
源码
参考

不合理的需求,对用户不友好的需求,低收益,高投入的需求,要敢于拒绝。当然,拒绝也是一门艺术,这就是与人沟通的艺术。如果经过深思熟虑,你能够给出比较合理的解释或者提出更有建设性的方案,我想这样才会更加容易让人接受。

闭环

闭环这个词,真是互联网领域的万金油。但是,笔者这里特指产品需求逻辑的闭环。

笔者曾经待过一个互联网教育创业公司。因为参与人很多都是TOB行业经验的人。大家都是知道,TOB公司的产品卖出去很多时候是线下的操作。比如,微软公司,我做操作系统一流,我赢家通吃。但是,TOC就不一定了,个体用户更加注重用户体验,比如曾经的电商百团大战的竞争,后面的共享单车的竞争,消费者可以直接用脚投票的。

我们做了一个课程官网,包括课程展示,订阅充值的官网。官网上线之后,市场同事也做了宣传,但是发现基本上没人注册,很多用户都是让我们帮忙注册。经过研究发现了原因:

因为集成Azure注册慢,登录页面,而且极不友好。这导致用户放弃注册。
官网没有展示客服咨询电话,只有一个用户建议表单。无法实时联系客服。

这个案例,很典型。从市场到技术,我们做了很多工作,但是最终效果不理想。最大的愿意就是产品不闭环。用户想学习课程,但是登录和注册体验太差,这就已经挡住了大部分的用户。

写作套路

前面我们讲了很多坑和避坑策略,那要如何才能写好需求文档呢？

铺垫

根据百度百科-铺垫法。戏剧情节结构的一种手法。在戏剧的进展中，对于某些将要出现的关键性情节和起关键作用的人物，必须在事前有所准备、暗示；为情节的展开，为高潮的到来，酝酿气氛，作好准备，铺平道路。这种手法叫埋伏或伏笔。

其实可以简单理解为背景说明。在需求文档中,增加一定的背景表述,可以增强事物间的因果联系和完整性,不显突兀。

一般可以在你的需求前增加一个背景交代，

这样的好处是,其一,让之前没有参与的人有个背景认识;其二,为自己后续的观点(或者设计思路)提供可信依据,至少不知自己拍脑袋想出来的。

下定义

对于不同的业务,有时候会有一些专有名词,或者是你自己了说明某个事物而定义的名词。如果不做一些定义的解释,很难理解。比如,在设计IM聊天时候,可能会有一些定义,可以给出定义。

逻辑清晰

需求文档,不是日记,切记流水账。排版工整,重难点突出。逻辑清晰,富有层次感。

利用图表配合文字,有条不紊的表达出合理地逻辑。这样大家阅读起来,一目了然。

说人话

针对不同的人群一定要设计不同的话术

这里的人是指不同的受众。考虑到需求文档面向的对象较多,有技术,业务,测试等,需要抛弃过于专业的技术语言，比如不要出现技术设计的细节,尽量要用自然语言表达。

说句题外话,其实严格意义上,需求文档可能是要写两份,一类是给技术同学看的,一类是给非技术同学看的。对于前者,你当然可以用类似抽象的uml图或者直接给出伪代码来说明。

视角

子非鱼,安知鱼之乐

你以为的就是你以为的吗?很多时候,需求的来源并不单一,比如公司要做一个工单系统,这个工单系统的使用者几乎涵盖了公司的各个部门。按照"用户第一"的要求,我们需要考虑到不同业务方的诉求和用户习惯。

我们在做需求的时候,就要提前想到。否则,后面的设计一定会违背使用者的意图。前面,讲过的换位思考,或者多角色思考该排上用场了。

在文档中,如何体现呢？通常,可以按照不通视角来描述。这就是类似程序的switch...case...

切记站在上帝视角看待问题。

版本延续性

需求文档很少一次性就让各方满意的,或多或少都会有补充和调整。比较好的习惯是使用修订版本来记录。

修订历史是一个版本的可追溯源，对需求变更历程有一个清晰的认识。

新建默认为相应模块的首次使用，对于文档的修改以及增加的地方可加入超链接，同时在增加与修改的具体地方进行颜色标示或者其他标志来进行区分，方便其他人员进行查询。

结语

写好一个需求文档,让人觉得很专业有很多东西需要学习。这里笔者只根据个人多年的工作经验,抛砖引玉,欢迎大家怕批评和斧正。