上一篇，重点讲述的是撰写项目规划和方案设计文档的指导原则，要写成什么样子才能发挥它应有的价值。

具体如何做到，往往还需要实践经验和技术功底的支撑，仅仅知道方向，很可能也是心有余而力不足。

尽管如此，还是有一些在具体实践环节中通用的方法论和Checklist清单，可以帮助到大家。让大家在自己的能力范围内，将思考的过程变得标准化，体系化，尽量完成一篇无论在产品目标还是技术架构层面，都相对靠谱的方案设计文档。

需要注意的是，这个checklist一定是挂一漏万的，所以下面的内容，可能更多的是一些常规必要的点，或者容易被大家忽略的点，而非完整的需要考虑的问题列表（事实上，具体项目千差万别，所以也不可能有这样一个列表），希望能起到发散思维，查遗补漏，多角度评估方案完整性的作用

整体流程步骤方面的Checklist

• 如果可能, 尽量从多个来源收集问题和需求，包括：系统自身架构角度，用户使用角度，开发者开发迭代角度，后续运行维护角度，过往历史问题总结的角度，还可以参考业内类似成熟系统方案的目标设定，需求列表等来拓宽视野，拓展思维。
• 尽可能把自己套入到具体的使用场景中去，完整的从用户的角度端到端的思考一下整个业务流程中可能的需求和问题。
• 从旁观者的角度换位思考，不要站在开发者的角度给自己找理由，先想问题和需求，后想困难。
• 归类和整理上述需求，问题。思考对应可能的解决和实现方案的大致方向，同样及时纪录下来。如果暂时没有思路，也明确记下待定的内容，后续针对性的统一时间深入研究。
• 将这些大致的方案逻辑，再次套入到具体的产品形态需求中，结合业务流程和整体架构框架，进一步思考和列举可能遇到的问题，需要攻克的技术/业务难点，并思考对应的解决方案。
• 将上诉所有问题和方案统一放在一起，结合目标，优先级和可能的冲突，综合考虑，做出最后的取舍。
• 如果需要，迭代上述步骤，直到对项目架构或流程可能造成影响的主要问题，你都有了大致的思路和解决方案。

上面是抽象的思考过程，下面再针对各个环节，列举一下注意事项和问题清单

需求和目标规划环节

这个其实更多的是对具体项目范围的一个确定过程，列一下需要考虑的点，防止遗漏。

• 项目的相关业务方有哪些？项目可能的外部依赖方有哪些？

  • 是否找他们沟通过相关计划？
  • 是否需要找他们详细了解问题需求?
  • 这些需求和问题是否是他们真正关心的？
  • 是否有些问题和需求目标已经有替代解决方案？
  • 是否能和上下游达成协议，最好大家能为了一个目标共同努力，而不是单方面努力。

• 当前项目目标解决的核心问题范围是什么？最终产出结果如何评估

  • 哪些要做，哪些不做，哪些优先，哪些可以后续考虑。
  • 针对这些问题，最终想要达到的效果是什么？
  • 如何检验目标的达成与否，有没有可量化的评估标准

• 在规划阶段就需要引入一个明确的目标业务，作为（小）种（白）子（鼠）业务

  • 尽最大可能，沟通和服务好这个业务
  • 便于开发过程及时闭环反馈，有针对性的及时改进系统
  • 如果没有这样的种子业务，找到一个为止。找不到说明项目没有价值，趁早放弃。
  • 但凡可能，自己的狗粮自己吃，自己的系统自己要想办法重度使用，没有需求创造需求也要上。

概略方案设计和工作量评估

• 确认项目方案涉及到的内容模块，各模块的责任人，分工细化
• 产出各模块的技术要点，问题列表等
• 产出具体内容的工作列表，资源和进度评估安排
• 持续维护和完善各模块的具体方案设计文档。

上述内容，特别是模块级别的设计方案文档，不强求详细，但是得确保有。底限是在开始具体开发工作之前，得经过思考整理，而不是边做边想。

产品/技术方案中可能需要考虑的问题

以下的列表，即不可能面面俱到，也不代表每个项目都会包含所有这些内容。仅作参考用途，提醒和检验还有哪些事项或者问题角度需要考虑，大家因地制宜，不要为了回答这个问题而回答。

具体的内容组织方式，详细程度不限，以能把控住项目的走向和风险为目标

可控性和稳定性相关

• 能否隔离业务，负载，减少并发或多租户环境下可能问题的相互影响
• 是否需要支持流控，优先级等管控手段，提升系统可控性。
• 上游数据源或外部依赖出现问题，如何应对？
• 使用方或下游链路出现问题，负载过大，写入阻塞，消费延迟等等，如何应对？
• 是否有故障或错误的恢复的手段？比如修复错误数据，修正错误行为等等。
• 在故障无法快速恢复或者负载过高的场景下，是否有系统降级的方案，能够保证最低可用性。
• 如何提高灾难恢复的速度？是否能做到系统无状态化，能快速重启？能自动恢复？能智能容错？

可维护性

• 系统如果后续更新升级，可能遇到的问题有哪些，如何降低对业务的影响？
• 系统迭代，可能的API和数据结构的兼容方案？
• 系统是否可以通过配置等手段，动态调整行为？降低维护成本

可扩展性相关

可拓展性是一个无底洞，不需要过度设计，但是适当的考虑还是必须的，可以根据实际情况酌情考虑以下方面内容

• 从代码的设计模式的角度，能否方面拓展，复用，重构
• 从系统架构模块化，插件化的角度，能否在核心架构不调整的情况下，具备一定的定制化能力
• 从数据结构定义，和存储方案的角度，是否留下拓展空间。是否要预留拓展字段? 怎么设计预留拓展字段? -> 比如json格式, 位图格式等等
• 和上下游系统的对接方式，能否封装和抽象底层逻辑，不要暴露太多实现细节。尽量做到上下游系统之间的松耦合。

易用性相关

• 是否有/能够提供必要的文档？架构思想，接入步骤，用户手册等等？
• 是否应该提供一些分层的简化抽象，便于满足不同用户的需求，在易用性和功能性，灵活性方面取得更好的平衡。
• 用户使用过程中可能遇到的问题，错误等，是否能提供足够明确和及时的信息反馈，尽量让用户知道下一步该怎么办。
• 能否提供配置工具或者接口，让用户能自主定制业务或系统行为。
• 对用户常见问题，能否提供辅助工具，标准化处理过程，沉淀最佳实践，降低解决难度。

性能相关

性能相关的考虑点，大都需要结合实际例子考量，这边只是泛泛的列一些大家可能容易忽视的点，后续有重点需要关注的，再持续补充。

整体上：

• 这个项目中，性能重要吗，哪个环节的性能最重要？
• 性能衡量指标是什么？如何评估？最低要求是什么？
• 不仅是具体技术实现，从大的业务流程，系统框架的角度，哪些地方可能会影响性能的？
• 必要的代价和收益的分析，性能够用就好，做到什么程度能相对最大化投入产出比？
• 有没有性能压力测试方案？

除了代码工程实现，性能问题，在很多场景下是一个“算法与数据结构”的问题。所以从数据的角度可能需要考虑的点有：

• 数据存储方案如何选择？
  • 主要的读写模式是什么？批量还是随机，采用那种存储系统存储更合适？
  • 是否需要压缩，是否需要根据特定的业务需求做预处理。
  • IO效率重要还是计算效率重要？如何平衡取舍？
  • 表结构如何设计，响应速度和吞吐率要求能否满足。
  • 是否单一存储方案能够满足，还是需要混合方案。
• 数据采集和获取方式，有什么和性能相关的点需要考虑的
• 数据的加工过程，能否/需不需要分层递进处理，提升数据复用能力，减少重复处理工作量？

监控告警相关

• 如何监控系统自身的运行状态，如何判断系统功能行为是否正常？
• 需要监控哪些数据或指标，如何埋点和获取这些数据？
• 监控相关数据，如何加工和展示？如何呈现给终端用户？
• 能否将监控结果和业务流程进行闭环，更好的发挥作用？
• 监控相关数据的重要性和必要性梳理，不是监控信息越多越好
• 考虑报警收敛，如何避免无效报警，或者不能采取行动的报警的生成。

具体实践

• 在一开始，就尽可能罗列问题，快速形成文档，不要停留在口头上或者脑海里，便于大家沟通讨论
• 步骤上可以先总结问题，后续再补充构思，增加解决方案，最后细化设计文档。避免出现遗忘，反复，议而不决等情况。
• 沟通和反馈过程，尽可能以文档为载体，提前发送给相关同学，事前熟悉和反馈，提高讨论效率，
• 相关文档，争取和项目本身同步维护，比如在同一个git仓库内，进行版本管理，避免文档和具体工程实现脱节。

小结

方案目标定得多高，范围圈得多大，会不会太过草率，会不会过度设计，如何平衡，并没有绝对的衡量标准。但前期在时间允许的情况下，把问题尽量考虑周全，做好整体目标路径规划，通常总是好过边做边看的模式。

何况，事实上，多数设计方案通常是欠思考的居多，却要号称敏捷号称测试驱动开发？而所谓的过度设计通常也只是抓不住重点，或者目标跑偏而已，不少同学其实并不具备过度设计的能力和觉悟，所以压根没有必要替自己操这个心 ；）

至于具体方案该定得多细，问题想得多全面，根本上还是取决于项目的价值产出和风险的大小。但没有经验的同学可能很难评估风险的大小，或者压根就没有意识到有些风险的存在。这时候，当然就需要有经验的同学来帮忙讨论和评估。而一个问题checklist清单，也能起到一定的帮助作用，平时注意积累常见的问题，更新自己的清单，才能发挥它的最大价值。

---

常按扫描下面的二维码，关注“大数据务虚杂谈”，务虚我是认真的 ；）