正文
目标部分应该包括：
非目标也同样重要，用于描述项目不会解决哪些问题，让每个人都达成共识。
里程碑
一系列可衡量的检查点，你的 PM 和上司可以借助它们大致了解项目的每个部分将在什么时间完成。如果项目时间超过 1 个月，我建议你将项目分解为面向用户的里程碑。
在设定里程碑时可以使用日历日期，把延期、假期、会议等因素都考虑进去。例如：
开始日期：2018 年 6 月 7 日
里程碑 1——以暗模式运行新系统 MVP：2018 年 6 月 28 日
里程碑 2——弃用旧系统：2018 年 7 月 4 日
结束日期：在新系统中添加新特性 X、Y、Z：2018 年 7 月 14 日
如果其中一些里程碑的 ETA 发生变化，需要在此处添加 [更新]，相关人员可以很容易看到更新的内容。
当前的方案
除了描述当前的实现之外，还应该通过示例来说明用户如何与系统发生交互以及数据是如何流经系统的。
这个时候可以使用用户故事。请记住，你的系统可能拥有不同类型的用户，他们的使用场景也不尽相同。
提议的方案
有人把这部分称为技术架构。这部分也可以通过用户故事来进行具体化，可以包含多个子部分和图表。
先从大处着手，然后填充细节。你要做到即使你在某个荒岛上度假，团队的其他工程师也能按照你的描述来实现解决方案。
其他替代方案
在提出上述解决方案的同时，你还考虑了其他的方案了吗？替代方案的优点和缺点是什么？你是否考虑使用第三方解决方案——或使用开源解决方案——来解决问题，而不是自己构建解决方案？
监控和警报
人们经常把这部分视为马后炮，甚至直接忽略掉。而在发生问题后，他们就手忙脚乱，却不知道该怎么办，也不知道为什么会发生这些问题。
跨团队影响
