概述
做过一些大大小小业务系统，都有点经验了。大到一个产品一个模块，小到一个接口一个功能，在开始需要一个“方案”。
但这个方案其实并不好写，难点有几个：
- 产品经理没有，需求方（基本上）没有产品文档，都是来来去去的邮件和几个会议，最后通常就是一个需求列表，我们需要自己梳理。
- 项目经理没有，成本要算，风险要估。
- 架构师没有，架构、拓扑部署还是要涉及，对网络环境也是需要熟悉的。
虽然涉及点挺多，难搞是难搞但项目还是要做的，这个方案怎么写呢？
目的
那我们先搞清楚几个问题：
1、这个方案是干嘛的呢？
其实就一个作用，输出时间计划，给出承诺。
2、方案给谁看？
领导：扼要告诉领导你准备要干嘛，不然哪来资源（资源最主要的包括人力和时间）。
团队：你要给团队的人介绍这个系统要做成什么样，设计都在自己脑袋里面的话，别人怎么帮你一起搞。
自己：写方案本身同时是一个消化需求的过程，可以看需求是否合理、是否有遗漏、是否有漏洞矛盾。
提纲
方案最后的时间计划是一个结论，并不是（完全）拍脑袋来的，我们需要一个“推导”的过程，过程如下：
1、确认需求。
虽然业务跟我们说过了，开会讨论过，也可能写过需求文档（人少的团队是通常没有什么正规的需求文档啦~），但我们还是要确认一遍，输出一个需求列表，看有没有做漏了。
2、业务方案设计
进一步对梳理需求的过程，补充用例图、业务流程图，交互页面等。
3、程序设计
针对需求做概要设计，可以输出部署拓扑图、表设计ER图、甚至类图等。
4、WBS（具体是什么自行百度一下）
根据前面的各种设计，可以分解出任务项，针对每个任务项就可以估算时间人日。
5、结论
根据任务项和人日，就可以计算出需要多少人、有什么里程碑、总共多长时间可以完成，即最后的输出时间计划，给业务、给领导、给团队一个承诺。
最后回头看这个推导的过程，就是方案的提纲。
可以根据实际情况，即系统业务复杂度做删减，但套路差不多就是这样。
图
上面说了一些“图”，其实图是一种比较直观的描述方式，文字反倒是一种补充。
用例图
用例图最重要包括两部分：用户角色、功能。
用户角色，就是明确你的系统是给谁用的，比如说一个流程系统，角色就有：普通员工、流程管理员、系统管理员。
功能，就是功能列表，粗粒度大一点（比如以某个模块）列出来就可以。
最后把角色和功能连起来，这样就可以很直观的看出，你现在这个业务系统，是给谁用的、谁能用什么功能。
别看这么简单的这一步，很多需求谈了半天，沉下来去画这个用例图的时候，还是没搞清楚这个系统有多少个角色。
业务流程图
流程图大家都比较熟知了，其实就是业务数据流转、输入输出的过程。
一个系统，肯定有一个产生数据的地方（比如用户填写提交一个表单），然后经过来回流转、分解集合、逻辑分支之后，最终落到什么地方，以什么方式展现给用户。
这个流程可以是很简单，也可以很复杂，但千言万语不敌一张流程图。
交互图
交互图，我们可以确定页面的数量，页面上面有什么元素。也就是用户如何输入数据，用户怎么查看数据。
这个在很多场合也是业务需求方比较关注的点，因为这个直接涉及到实现了，界面已经有了雏形。
常用的软件就是Axure。
部署拓扑图
业务系统的上游可以提供什么能力，有提供什么服务吗？下游依赖什么服务？
系统部署落地在网络的哪个区，系统有多少个应用部署，各自边界在哪里。
上游和下游之间的网络是怎么交互的。
部署拓扑图就是为了回答以上问题。