【无标题】

1.背景

通常我们需要对于项目（一个功能或者一个问题）提出合理的解决方案，这时候我们就需要设计一个合理的方案来供大家讨论，并产出对应的工作计划；这类方案可以是对于系统架构的设计，也可以是对于一个具体的功能点，亦或者是系统改进、系统性能提升等等。

一份设计文档的好坏，往往会直接影响项目的推进进度以及最终的产出成果；而决定方案好坏的标准并非模板、格式等，而是取决于其具体的内容、综合的考量、细节的掌控等等；对于如何分析和设计，便是本文主要探讨的方向。

2. 原则

2.1 模板

在日常工作中，已经存在非常多的模板以供挑选；内容主要分为三部分：背景&目标、功能概述&详细设计、干系人&排期，这三部分可以总结为：为什么做（why），怎么做（how），谁来做（who）。

2.2 背景&目标

2.2.1 为什么做（why）

• 首先必须要明确项目的背景和目标，必须了解其核心诉求。

• “WHY”的作用非常重要，可以尝试问以下几个问题：
  为什么要做这个需求？为什么要现在做？主要为了什么核心目标？

• 也就是说RD需要站在产品和业务的角度去理解和推演他们想要做的事情，如果对于“WHY”没有很好的解答，那么后续的内容也就没有了讨论的依据了。

2.2.2 目标

站在业务的角度，他们对于结果的讨论往往需要量化，比如提高准确率0.01pp等，然而这背后如何实现这0.01pp提升的动作，便是我们需要讨论的行为目标，数据只是对于行为目标的一种衡量；业务或产品往往会给出一个方案，用于达成行为目标，从而完成数据提升，然而业务给出的方案是我们需要主要探讨的；目标的合理性、数据评估的准确性、如何推到出来的，对于当前系统是否存在特殊的制约等等。
目标和背景的不同，推导出的核心需求可能也不同，从而导致最终的实现方向发生完全的偏离。

2.2.3 总结

• 本质上需要什么能力，而非具体实现上需要做什么，即注重目标而非手段。
• 技术方案的第一步便是了解需求，推导出业务真正想要的核心需求。
• 存在的问题、哪些影响、改变后的益处（背景） -> 解决的问题、可量化结果（目标）-> 真正需要解决的点（核心需求）。

总体来说就是，为了让参与的人能从背景和目标中获取到明确的方向，并切实地了解到实际需要提供的能力。

2.3 功能概述&详细设计

2.3.1 怎么做（how）

这一部分内容主要围绕着之前既定的目标进行细化，如信息收集、影响分析以及功能拆解 等等；需要注意的是，这一步必须和核心目标强关联，如果发现存在于目标不符的情况，则需要找到问题并进行单独分析。

这一环节真正的难点便是对于问题的发现；实际上，在需求设计的过程中最重要的便是发现流程中所埋藏的问题，如果未能及时发现问题便进入开发环节，那么等到风险产生时就迟了，而且未考虑到的环节往往对于预期的设计影响是毁灭性的。

2.3.2总结

需要详细描述对于核心目标的功能实现和技术细节，而非核心目标可以简单阐述，但是需要将可能遇见的问题详细的罗列出来，就是将可能发生在开发阶段的问题，在设计阶段就暴露出来。

2.4 干系人&排期

具体的工作计划，除了找到最短路径然后进行优化外，更多的需要考虑系统的的迭代步骤（短期应急or长期解决方案）、上下游依赖、需要协同的工作，以及整体需求周期内部的工作安排（设计、开发、联调、测试、上线、维护），同时对于风险产生影响的预估等等。

这一环节最重要的是：什么时候做什么事，最重要的是理顺事情的依赖关系，控制所有的意外风险，最重要的便是对于进度的可控性。

3. 总结

技术文档没有绝对的规范，更多的都是根据项目的实际情况和复杂程度进行自行调整，但是最重要前提便是绝对不可形式主义。