共计 3561 个字符，预计需要花费 9 分钟才能阅读完成。
需要文档是咱们在开发中罕用的一类沟通形式和媒介，它承载着需求方的冀望，同时也标记着一系列事项的生命周期。
不同部门、不同受众的需要文档各异，例如经营人员向产品人员提出的流动需要、产品人员向开发人员提出的性能需要、开发人员向运维人员提出的服务撑持需要、各小组外部共事之间相互提出的需要等等。
为何须要需要文档？
大部分场景下需要提出方和需要承接方都存在不小的 信息差 ，需要提出方罕用的语句是“ 我须要做成这样 ”、“ 越快越好 ”、“ 怎么用你不必管，给我就行 ”、“ 这不是我想要的 ”、“ 我想要的其实是那样”。
一个人常常否定本人的抉择和语言的景象是存在的，无论无意或无心，但这无疑会消耗单方的工夫和精力。需要文档不仅能够作为单方沟通过程中的清单，还能够作为单方抉择和执行的日志，有了需要文档，就可能防止因前后矛盾导致空耗的问题。同时，需要文档能够清晰地体现参加人员的劳动成果与劳动价值，是自我总结的良好根据。
需要文档通用模板参考
一百种需要有一千种提法，但需要中的事项相差却无几。这里给出了一份需要文档模板，大家能够将其用在工作当中，作为不同人员之间的信息传递媒介。
要留神的是，需要和执行是双生相伴的，因而这里的上面这份参照文档与其说是需要文档，不如说是工作执行记录，因为它记录着这个工作从产生到执行结束的残缺生命周期。
为了不便大家了解，文档选用不同色彩来帮忙咱们辨别阶段，其中：
???? 浅粉色区块出现的是文档的根本信息；
???? 浅蓝色区块出现的是需要主体与需要生命周期主体；
???? 浅绿色区块出现的是需要生命周期靠近开端，行将达成目标；
为什么要这么设计？
置信各位见过不少的需要文档，因而对下面这份参考也有不同的认识，可能不禁会问：
- 为什么设计成这样的构造？
- 怎么不必在线需要文档管理工具呢？
- 必填项和非必填项如何体现？
- 这份参考如同不能满足所有开发场景？
为什么设计成这样的构造？
需要文档该当涵盖从需要产生到需要实现交付的残缺过程，例如 需要是在什么样的场景下产生的、到底要做成什么样、须要什么时候实现、以什么模式交付、需要是否可能实现、需要实现过程中做了哪些、交付的后果是否达到预期 等。
咱们能够将残缺过程分为以下几个阶段，以便更好地开展工作：
???? 需要形容
???? 需要调研
???? 需要评审
???? 开发 / 施行
???? 阶段验收
???? 测试 / 数据验证
???? 上线
依照这个构造，咱们可能设想工作流大抵如下：
首先需要提出方给出需要的背景、具体事项形容等信息，帮忙需要承接方更好地了解，同时提出对交付工夫、交付形式的冀望。需要承接方收到需要信息后须要做初步的调研，理解需要实现过程中的要害项并记录不明确的事项。
接着，单方初步接触后约定工夫对需要进行评审，单方的探讨将基于调研期间取得的信息开展，在评审讨论会完结后通常会 确定需要是否能实现 、 需要改变项 、 交付形式 、 交付工夫 、 最终参加人员 等。
而后评审通过，需要承接方开始进行开发 / 施行。需要承接方要记录这个过程中 谁在 什么工夫 做了 什么事 并失去 怎么的后果 、期间是否呈现了 哪些变动。
需要提出方可能会阶段性地跟进事件停顿，并帮忙需要承接方确认工作和工作后果没有呈现偏差，同时单方调换一些信息。
开发 / 施行靠近序幕或实现后，需求方组织人员测验成绩，测验通过则告诉需要承接方交付 / 公布上线，测验未通过则做相应调整。
版权水印 – 微信公众号 Python 编程参考
除了需要背景、开发 / 施行相干的信息外，需要文档自身也须要提供一些根底属性，用以对需要进行整顿、分类、追溯、总结等，所以在需要文档的结尾设定了一些重要信息栏，例如：
???? 需要重要等级；
???? 需要发动日期；
???? 需要完结日期；
???? 需要发起人及对应部门；
???? 需要承接人及对应部门；
???? 需要所属的业务类型；
???? 需要关键词；
???? 也求所属业务的名称；
???? 需要关注者；
???? 需要编号；
???? 需要名称；
团队外部能够定义对立的需要等级，例如 紧急且重要的设为 A、紧急但不重要的设为 B1、重要但不紧急的设为 B2、不重要也不紧急的设为 C 等，这样大家在参加需要的时候可能正当地调配工夫和资源，优先解决那些等级高的需要。
怎么不必在线需要文档管理工具呢？
市面上的需要文档管理工具繁多，Python 编程参考心愿在不依赖特定工具的状况下向大家介绍需要文档，各位在了解需要文档后再联合工作中用到的管理工具，效率定会更高。
实际上工作中总是会用到各式各样的管理工具，工具能够很好地帮忙咱们关联文档、汇总信息。例如一个编号为 TK2020120101 的需要实现后，后续又 衍生 出针对它的保护类需要 TK2021010103 时，能够将保护类需要 TK2021010103 与 TK2020120101 关联 起来，这样在治理需要文档的时候就可能直观地看到 需要之间的关系和变动，具体如下图所示。
理论工作中大概率会用到管理工具，工具能够进步咱们的效率，便于咱们治理事件，借助工具是十分好的抉择
必填项和非必填项如何体现？
实际上这份文档蕴含的区块都是必要信息，但区块中的子项能够依据理论状况省略。
首先，浅粉色区块的需要文档根底信息局部是必填的，这里的内容是整个需要的缩影，所以一个格子也不能少。
其次，浅蓝色区块的主体局部是能够省略的，例如有时候需要调研和需要评审能够放在同一时间开展，划分到需要评审即可；例如子项详细描述中的 注意事项 、 交付要求 等选项也是能够依据理论状况省略的；如果需要并不简单，或者说工夫周期也不长，那么子项 阶段验收 能够省略，在数据验证阶段校验即可；如果没有预上线，或者需要并不需要上线，那么能够省略浅绿色区块局部的项。
最初，如果感觉下面的阶段还不足以记录残缺的需要生命周期，能够依据理论状况减少阶段或子项；
这份参考如同不能满足所有开发场景？
当然，开发场景千千万万，Python 编程参考提供的这份需要文档作为根底，各位在具体应用的时候能够依据团队状况和业务状况自行调整文档项。
需要文档实例参考
尽管下面提供了一份根底模板，然而有一些读者可能还不太明确在理论应用的时候应该如何编写。上面以理论的工作需要给出一份实例参考。
浏览并排汇下面的常识后，想必聪慧的你对整个需要文档的形成、设计考量和具体实际有了肯定的认知，当初曾经可能很好地梳理、组织需要文档了。这里作者再帮忙诸位整顿一下需要文档的一些细节。
需要调研钻研的是什么？
需要调研是基于需要开展的理论状况摸索，次要诉求是得出 是否 、 是否 等确切的论断；例如参考实例中提到的：
???? 当火线上 Nginx 配置文件是否须要改变；
???? 调用方是否要在更换新 Nginx 后切换调用地址；
???? 线上服务地址权限是否能顺利取得；
需要评审探讨什么？
需要评审基于调研后果和需要背景开展，次要诉求是得出 实现形式 、 后果 、 出现形式 等确切的论断，并针对那些不稳固的事项给出后果，同时也蕴含 是否 、 是否 等确切论断，例如：
???? 评审项：监控项与可视化面板是否匹配
???? 评审后果：监控项与可视化面板匹配，但要设定告警则须要独自设置面板，不影响展现；
开发施行记录哪些内容？
开发 / 施行项中不用记录细节，只须要记录阶段性内容即可。通常是 谁在 什么工夫 实现了 什么事 ，也就是 工夫[事件] 这样的格局，例如参考实例中记录的：
???? 2020-12-01[张三] – 提供 Nginx 配置文件；
???? 2020-12-05[王五] – 在 Grafana 中导入 Prometheus 数据源并配置可视化面板；
???? 2020-12-07[王五] – 更改域名解析；
阶段验收写什么？
阶段验收关注的是事件后果，也就是 工夫[后果] 这样的格局，与开发 / 施行记录相似，例如参考实例中记录的：
???? 2020-12-08[张三] – 服务切换后一切正常；
???? 2020-12-06[张三] – Grafna 可视化面板数据；
???? 2020-12-03[张三] – Nginx 日志已同步到 ElasticSearch 中；
上线项关注什么？
上线项关注的是上线后果和业务自身的状态，是 工夫 [状态] 这样的格局， 例如参考实例中记录的：
???? 2020-12-09[王五] – 服务失常失常；
???? 2020-12-09[张三] – 数据失常；
???? 2020-12-09[李四] – 数据失常；
这里的 状态 也能够了解为 后果，但细细想来，还是用状态更为贴切一些。
这里是微信公众号 Python 编程参考，如果你感觉这篇文章对你有帮忙，请来关注我哦。点击返回作者韦世东的技术专栏 www.weishidong.com，看更多有用常识。热门文章一览：
《几个有效应对 35 岁危机的方法》
《工程师绘图与设计实际指南》
《继续交付实际 – GitHub Actions 部署 Node 利用到云服务器》
《SSH 免明码 / 免用户名 / 免 IP 登录云服务器实际》
《ElasticSearch 定时删除指定天数的数据实际》
