怎么根据一个需求写一个解决方案？

从规划构思、谋篇布局、行文格式、设计工具四个维度对怎样写一个解决方案进行阐述。

一、规划构思

比如你要建造一座房子，你会先去找谁？是找瓦工、室内设计师，还是厨房供应商呢？当然都不是。你需要去找一个建筑师。建筑师会根据你的需求，设计房屋图纸。建筑师知道要问什么问题，如何组织这些问题，并且他可以从括业务、功能、技术和实现四个视角为你提供关于房屋建造的有用知识。

1、方案规划的四个视角

方案编写也同样有四个视角：业务视角、功能视角、技术视角、实现视角。

1、业务视角 (Business view) | 我们为什么做这些?

需要回答以下几个关键问题：

①有哪些内部和外部的驱动力?

②有哪些业务模型和流程?

③哪些人参与到业务流程中?

④项目目标是什么?

⑤如何衡量解决方案是否成功?

2、功能视角 (Functional view) | 这个解决方案应该做什么?

回答以下几个关键问题：

①完整的解决方案能做什么?

②如何使用它？

③它能提供哪些服务?

④它将提供哪些信息?提供给谁?

⑤解决方案必须具备什么质量?

3、技术视角 (Technical view) | 这个解决方案如何工作?

回答以下几个关键问题：

①系统的结构如何，怎么构建?

②接口和其他约束条件是什么?

③需要哪些应用和数据?

④基础架构是什么样?

⑤适用哪些技术标准?

⑥如何保证系统质量?

4、实现视角 (Implementation view) | 用什么来实现这个解决方案?

回答以下几个关键问题：

①需要哪些供应商的哪些产品？

②需要哪些组件来建立系统?

③系统如何开发和部署?

④使用哪些验证方法?

⑤如何管理?

⑥资金来源是什么?

二、谋篇布局

解决方案有了准确的规划构思，就可以进行谋篇布局了。先看一个医院看病的例子。

1、方案的一般组成

解决方案的谋篇布局与上面看病的例子类似。内容一般由项目总述、现状及需求分析、系统总体设计、系统详细设计、项目管理和实施、效益分析、投资概算和附件等组成。

注：对于多系统的综合性方案， 以子系统为独立章节，每个子系统包括（系统设计、产品介绍、系统功能等）。注意过渡，章节间加过渡说明语句，承上启下。站在客户的角度思考和解决问题。

①总述部分

一般包括建设背景、建设目标、建设范围和建设原则，见下表：

②现状及需求分析部分

一般包括现状分析、需求描述、需求分析和建设必要性，见下表：

•项目概述一章已经明确说明了当前的问题，项目建设的目标和项目建设的范围，为何还需要做项目需求分析。其最大的原因是项目概述里面从问题域到目标域是没有分析过程的，所以无法看到问题和实现之间的真正关系，也无法看到目标是如何落地的？而需求分析的重点就是我们是如何看待问题的，如何理解需求的，如何理解需求和目标之间的关系的。只有需求分析清楚了才能够朝解决方案过渡。 •对于需求分析我们仍然建议采用如下的思考方式，即首先是描述现状，然后是根据目标来分析问题，而问题即是我们最终想要的需求。需求分析一定是现状+目标，通过这两者之间存在差距而产生的问题。 •现状分析如何做？在建议书阶段很难按照动态分析流程调研的思路做详细的现状分析，因为我们建议的现状分析至少需要体现分类和分解的思路。比如现状分析从业务和IT两个方面的分析，业务又可以从业务流程，数据，组织三个方面来分析，IT又可以从系统建设情况，系统集成情况，系统管控情况多个方面来分析。总之现状分析要体现这种展开的思路，覆盖和项目相关的所有现状点，保证分析的全面性。 •现状分析完后根据和目标的匹配提出具体的问题，问题即是我们需要的需求清单，需求清单又可以做简单的优先级排序，这个是解决方案所需要的关键输入材料。

③总体设计部分

一般包括设计依据、设计思路、架构设计、网络及硬件设计、系统创新/特色、平台选型等，见下表：

注：“总体设计”客户技术负责人重点关注的地方，通过总体设计把握整个系统设计的大方向，在系统总体设计一定要体现整个方案的精华所在，以取得客户技术负责人的基本认可。

④详细设计部分

一般包括应用软件技术方案、IT硬件技术方案、设备技术方案、基础平台技术方案等，见下表：

⑤项目管理与实施部分

一般包括项目管理、项目实施、项目进度计划、人员安排、用户培训等。

注：一个方案如果没有办法落地和实施，再怎么完美也是没有用的，我们需要的解决方案是可实施的可行方案，而不一定是最优方案。

⑥效益分析部分

一般包括社会效益分析、经济效益分析、环境效益分析等。

⑦投资概算部分

包括项目投资概算总表和项目投资概算明细表，有的需要附上投资依据。

⑧附件

一般包括产品彩页、图纸、业绩案例、公司介绍及相关资质、阅读提示或摘要等。

三、行文格式

前面两部分阐述了方案的内在，第三部分将对方案的外在进行一个详细说明，做到“金玉其外”。

1、封面

方案需要包装，门面不可忽略。封面要素一般要包含：公司LOGO、公司名称、具有客户元素图片或表现解决方案主题元素图片、日期等。

注意：单独分节，不设置页码。

2、标题

标题一般到5级，定义好自动更新，字体加粗，居左对齐，标题中的数字建议采用Arial Unicode MS字体，文字用宋体，字号大小依次为二号、小二、三号、小三、四号、最小到小四，段前段后6磅。

3、目录

字体为宋体、小四、1.5倍行间距，一般到三级标题，单独分节，单独设置页码，页码采用一般采用(I、II、Ⅲ…)这种罗马数字。

注意：结构清爽，排列整齐。最后要进行目录刷新！

4、页眉、页脚

页眉一般包括公LOGO、公司中文名称、英文名称。页脚一般只包括页码，页码一般居中对齐。

5、页码

页码一般居中对齐、封面不设置页码、目录单独设置页码、正文内容单独设置页码、正文页码采用(1、2、3…)这种阿拉伯数字。

6、正文

文字采用A4版面、1.5倍行距、宋体、小四、段前段后0行。

注意： 方案的文字可能来自很多方面，建议多采用选择性粘贴，和整个文档格式保持一致。粘贴过来的Excle表格可能会造成页面纸张大小的改变，注意调整。

项目符号/编号建议对符号/编号采用一致的方式，可采用序号形式或符号形式。

注意：需要强调数目的用序号形式，不需求强调数目的用符号形式；如果存在多级，上级采用序号形式，下级采用符号形式。同时注意编号的起始！

图片需要加编号和边框。在每张图片下方加自动编号，如”图2-1 XXX”字体一般采用宋体、五号、加粗。图片加边框，一般居中对齐。位置灵活采用“嵌入文本行中”的形式和“文字环绕”形式。

注意： 图片说明采用解释性文字、方便阅读； 加水印，保护版权；方案完成后，全选，按F9键刷新编号。

表格需要设置编号，并对表格进行调整。在每张表格上方加自动编号， 如”表2-1 XXX”，字体一般采用宋体、小五、加粗。对表格进行调整时建议对齐到窗口，重新格式线表格线粗细，设置跨页重复标题行，突出标题行的颜色，表格的字体一般用五号，单倍行距。

本部分最后总结下方案排版的注意细节。

四、设计工具

工欲善其事，必先利其器！ 作为方案设计编写人员应该学好和用好下面的一些工具。

这些都是方案的表达方式：OFFICE用于方案文档，AUTOCAD用于图纸设计、VISIO用户拓扑图设计、PHOTOSHOP用户图片加工处理、COREDRAW用户图片、图纸处理、 SnagIt 用于截图，快速加水印。

五、总结与注意事项

1、做好方案的九阴真经

•动笔前先打一个电话，听听需求方案人的想法和需求，可以启发大量写好方案的线索；

•找一个好的标准模板，站在巨人的肩上，就算没有提高也是巨人；

•先构思提纲，再讨论，最后动笔：没有结构化的思维，写出来方案是一盘散沙，结构化的思维得到认可后就不会遇到写好被推翻的尴尬，可以用思维导图来协助自己写方案；

•在规定的时间和安静的地方去写，处理掉小事情才有功夫写大文章，不连续的写作会导致不连续的思维；

•按客户业务逻辑写，一切以客户为中心；

•认真准备目录提示和摘要，领导是最大的群众，领导不爱厚方案；

•随时积累素材；

•多写，熟能生巧；

•寻求回馈意见持续改进。

2、认真检查！

假如你能像看下图那么认真…

检查项包括：

•替换不完整

•替换过度

•只注意文字替换

•忽视页眉页脚的替换

•目录忘记刷新

•案例不对

•联络方式不对

•文件属性没有更改

•堆砌专用词汇和概念

•文件格式（doc、docx）

附Cheklist：

3、平常注意积累解决方案素材库

•标准公司介绍

•公司介绍PPT版本

•公司营业执照电子版

•公司资质文件电子版

•公司获奖材料

•法人代表授权书模板

•公司在有影响的电台，媒体上发表的资料、视频、图片

•公司近三年的财务数据报表

•公司主要政府领导人考察照片

•公司参加的主要社会公益活动照片

•公司近三年的销售业绩

•标准产品介绍

•能让客户快速启蒙的产品简明介绍材料（彩页）

•产品技术白皮书

•产品实施白皮书

•产品常用报价模板（N个版本）

•主导产品功能明显表和简要说明

•主导产品与竞争对手的对比清单

•公司公开发表的技术论文清单

•典型用户明细表（包括地区、分年份、分行业典型用户清单）

•公司典型用户综合介绍材料

•公司产品图片，软件截图，现场安装图、工艺图等

•负面用户明细表

•竞争对手近年来典型解决方案

•项目立项建议书模板

•豪华版本解决方案模板

•简明版本解决方案模型

•业务调研报告模板

•产品解决方案演示PPT

•产品解决方案配套视频演示动画

•主导产品用户手册电子版

•主导产品系统管理员手册

•主导产品二次开发手册

•项目实施方案书模板

•客户常见问题FAQ应对

•项目过程控制文档体系清单和模板

4、用图表说话

如：A比B长、B比C长、所以，A比C长。改为图表更直观。

5、厚方案“瘦身”技巧

6、薄方案“增肥”技巧

•把内容多的文字分段；

•方案留白，适当插入分页符；

•多放图片或图表；

•增加行距，一般1.5倍，可适当增加到1.8倍。

7、成本核算及保密

成本核算一定要准确，并争取成本优势。发送给用户之前，把每个文件作次检查，并由主管领导审核报价。尽量不要用Excel表发送清单，错发成本这样的事情会发生(一般会用Excel做成本核算，设置隐藏列)，但一旦发生要努力补救。

切忌把成本发给用户!!!

注意方案保密：可转换为加密的PDF格式。

8、方案编写人的标准（要求）

•文笔好，有较强的语言组织能力；

•条理性好，头脑灵活清醒；

•细心、耐心、有责任心；

•精通本行业知识，熟悉相关行业知识，有较宽的知识面；

•熟练掌握计算机、网络知识，计算机制图，有一定的平面设计功底；

•能够运用现有的知识、产品进行科学、合理、切实可行的拓展；

•思维开阔，思想灵活，善于组织，统筹把握能力强；

•良好的文字组织与语言表达能力；

•积累多方面的技术知识与操作能力；

•严谨认真的工作态度，勤奋；

•有良好的身体素质，身体强壮！（O(∩_∩)O哈哈~）

分享一个从业务需求到可落地方案的完整过程，给面对客户需求不知从何下手的 BA（业务分析师）新手们或对 BA 工作内容感兴趣的同学们一些参考。

阅读提示

文中分享的工作方法基于特定的客户合作模式和业务场景，可能不是广泛适用的流程，但我相信其仍具备广泛的参考价值；文中可能会穿插使用“需求”、“设计”、“方案” 这些词，有时他们指代的是同一个对象。为避免误解，特此提示：每个层级的需求都是对其上一层需求的解决方案或设计。

故事的上下文

这是一个 ToB 类业务场景。

客户 S 公司是一家在全球能源市场占据领先地位的公司，旗下有多条业务线，Thoughtworks 与其工业润滑油业务线已建立了长期稳定的合作。Thoughtworks 交付团队在持续交付计划中需求的同时，也常常临时从客户侧获取新的需求。

某日，客户侧 PO Amy 找到我说，S 公司的市场部有个关于散装润滑油的去包装环保解决方案，想依托我们当前维护的产品去实现，大概情况是 S 公司计划使用 IBC 替代当前使用的标准油桶作为散油容器，以解决含油废桶处理带来的成本问题。

Amy 所了解的信息仅限于此，后续需要约个会与市场部负责该方案的同事 Amanda 详聊。

一、 准备工作

1. 厘清已有信息

Amy 提供的信息不多，但也有必要对其进行整理，以便在与业务方正式沟通时能更容易建立上下文。
• 散油运输。这是一个新的概念。查阅后得知散装润滑油通常使用槽车（油罐车）运输，到达收货点后需要现场计量，经泵送入储罐仓储，或直接使用标准油桶运输和存储
• IBC 与标准油桶。IBC 全称 Intermediate Bulk Container，也就是中型散装容器，俗称吨包。由内容器和金属框架组合而成，是现代仓储、运输液体产品的有效工具，可以大副降低储存、运输、操作成本。而标准油桶随处可见，在当前背景下的关注点是标准油桶使用后需要进行固废处理，会带来较大的成本

现在，我们对该业务的背景有了基本了解，但还不清楚 IT 系统如何帮助 S 公司实现去包装化。

2. 设计访谈提纲

下一步是与业务方的首次沟通，那么我们期望从这次沟通中获取哪些信息呢？一个较高阶的问题框架如下：
• 需求背景翻。译翻译就是：现状是怎样的？为什么想要改变？
• 业务目标翻。译翻译就是：期望新的方案能带来什么价值和改变？
• 客户的设想。翻译翻译就是：被访谈者对新方案有着怎样的想法？

二、 与业务方的首次沟通

与方案负责人 Amanda 的沟通会议如期举行。

类似的沟通中，我习惯让客户先把他想讲的讲完，只要他的话题没跑太偏并且时间允许，我愿意充分地聆听。聪明的客户的自述往往会自然而然地围绕着需求背景和想要达成的目标展开，或许他还会忍不住对未来的产品模样进行描绘。

不少 BA 同学会 naturally 不喜欢“这些不懂数字产品的客户”对功能设计指手画脚，但这里提醒一下， 客户对系统功能上的直接要求往往隐藏着很直接的业务目标。他对功能的设计可能不好，但其对应想要实现的业务诉求一定不能忽略，这些需求可能比我们“挖”来的要直接的多、重要的多，遇到这种情况可以多问几个为什么

等客户把故事讲完，我会回顾之前计划获取的信息是否都已涵盖，如果有缺失我会补充提问。

幸运地，Amanda 的自述中已经把我想要了解的信息都回答了，我只需要对重点内容进行确认。于是我得到了如下信息（拣重点讲）：
• 大部分散装润滑油客户会采购标准铁桶包装润滑油，但 2018 年开始面临环保政策收紧，含油废桶处置成本日益增高，从而客户会倒逼供应商降价。 所以 S 公司决定全面推行去包装环保解决方案，即使用槽车运输散油至经销商处，到达经销商侧时卸油至 IBC 中，散油客户需要用油时由经销商将 IBC 运输至客户处，客户用油完毕后经销商再回收 IBC
• 使用 IBC 可以带来不少收益，但同时也有一些问题需要解决：IBC 是可循环利用的，如何对油品防伪？并且如何让客户信任这是 S 公司的正品润滑油?（业务痛点和业务目标）
• Amanda的初步设想是给IBC安装电子锁，仅当S公司的槽车往 IBC 卸油时才可通过系统打开电子锁，同时监测加注量和用油量，确保油品可盘点、可溯源

在与业务方的沟通中，需要快速识别一些关键问题并与业务方确认（考验 BA 的业务敏锐度和经验），以提高后续方案设计的效率。此次我识别到的问题包括：
• 承运商、经销商、客户、S 公司将分别扮演什么角色?
• 电子锁和用油量监测需要硬件支持，我们是否已有合作的硬件厂商？
• 如何确保经销商打开电子锁行为是合规的？
• ......

我与 Amanda 初步讨论了这些问题，不一定要得出答案，但需要明确问题和方向是正确的。

三、 方案的初步设计

经过与业务方的初次沟通，需求的轮廓已经初现，足以支撑初步的方案设计，而这个方案将成为后续继续讨论的基线。

1. 整理目标业务流程

此时不必关注实现层的东西。 根据前面与业务方的沟通，得出的业务流程如下：

2. 思考如何在业务流程中达成各项业务目标

此时不必关注实现层的东西。 根据前面与业务方的沟通，得出的业务流程如下：

业务目标 1：油品防伪

Amanda 提出了她的电子锁设想，该方案在业务层面没有“硬伤”，可以对其进行拆解，观察现有资源如何达成此方案。所以，问题聚焦在如何控制仅在从槽车卸货时才能打开电子锁。

基于对业务的理解，加上一些“脑暴”，我给出的解决办法是“需要录入正确的运单号才能打开电子锁”。因为运单编号是唯一的且可溯源的，将运单与卸油一一对应，加之实际注油量与运单油量的对比、实际注油油品型号与运单油品型号对比，可以解决该问题。

解答了 How、Who、When、Where 也呼之欲出：经销商，在从槽车卸油到 IBC 之前，在系统中录入正确的运单编号后才能打开电子锁。

业务目标 2：油品可溯源

解决思路是系统自动记录 IBC 每次发生液位变化的时间、地点、变化量、 IBC 当前所属人。于是，将解决方案补充在业务流程中后我们得到了下面的流程图

不可否认，有时解决问题的关键往往是类似上面的“点子”。但点子的得出也不总是灵光乍现，它需要对业务、背景、能力有足够的认知。

3. 支持业务目标的方案已有雏形，但距离流程能运转起来还有距离，思考还需要哪些支撑

针对上一步的输出，尝试回答：

涉及的业务数据从何而来? 通俗点讲，数据不会在系统中凭空而生，那么这个数据是谁录进去或者从哪个系统集成而来或者是怎样生成的呢?

如何达成该结果? 通俗点讲，上一步中的每个方框给出的是期望的结果，那通过怎样的系统内过程能达成该结果?

于是，对于“经销商录入运单号，选择 IBC，打开电子锁”：
• IBC从何而来？它在物理上应该由S公司为经销商提供，对应在系统中，可以由 S 公司维护好后分配给各个经销商
• 电子锁从何而来？它在物理上应该安装在 IBC 上，对应在系统中，它应该属于 IBC 的一个附加信息
• 电子锁开锁如何实现？常见做法是服务器远程下发开锁指令给电子锁，我们先做出该假设，后期与硬件厂商确认

再比如对于“客户在系统中查看 IBC 油品溯源信息”：
• 油品溯源信息从何而来？在当前上下文中溯源信息即 IBC 中的油从何而来，于是可知每次从槽车卸油至 IBC 时应记录对应信息
• 如何让客户能看到IBC油品溯源信息？IBC日常只是归属经销商，那此处必然涉及到为客户分配 IBC 这一业务过程 ......

通过以上分析梳理，扩充了整体的方案如下图：

至此，一个在一定层面上能跑通的方案初步完成，重新组织下流程，使其具备更好的可读性：

图中我并没有将系统行为、用户行为或线下步骤完全分隔表达，我的颗粒度是达成业务目标所需的“关键步骤”

四、 方案的对齐

在开始更详细的设计前，应该与各业务参与方对齐该方案，确保该方案在业务层面、实操层面可行且能帮助达成目标，也可就一些提前识别到的重要问题进行确认。

于是，在与 Amanda 的二次沟通中，她认可了大体的方案，并提供了一些补充信息：
• S 公司其实是没有人来管理 IBC 的，这一职责可以交给硬件厂商；
• 所有S公司采购的IBC会统一发货至硬件厂商，由他们改造安装电子锁，再发货至指定经销商；
• 希望加强油品使用的管控，非卸油过程中的 IBC 油位升高或非客户使用过程中的 IBC 液位降低都属于异常情况，需要给出告警......

在与硬件厂商的沟通中，他们认可了由他们来管理 IBC 这一设计，但提出开锁方式应该是由他们远程下发开锁指令，液位发生变化时他们会主动推送数据，并建议应考虑异常开锁流程；

在与经销商的沟通中，他们认可了这一流程，但提出通常每次卸油可能涉及到多个 IBC，希望能尽量减少操作步骤；

在与工厂客户的沟通中，他们提出了“尽量简化系统操作”这一诉求。

这几轮沟通中获取的信息尤为重要，他们或是针对当前方案的建议，或是明确的用户诉求，或是功能的条件约束，这些反馈对下一步的详细设计有很大的帮助。

BeeArt | 行知蜂 - 「用户故事地图」模板

五、 更详细的需求设计

方案基本确定后，可针对其中的功能需求（上图蓝色方块）进行更详细的设计。

1. 为功能需求设计解决方案

其直接输出便是拆分出的 story 和系统流程图、状态流图之类可帮助读者理解的模型

2. 为关键步骤设计草图

没有什么比呈现在眼前的设计更容易把故事讲明白了。（以下草图都是拿 keynote 画的，十几分钟一个，简单快捷）

3、团队内部评估

邀请前后端 TL、QA 共同对需求和设计进行内部评估。评估主要围绕着以下 3 点进行：

（1） 背景及方案结束

面对新需求，个人习惯在方案相对成熟后再将其暴露给团队，以提升团队工作效率。在对需求进行评估时，需要让团队清楚故事的来龙去脉，才能帮助发现潜在问题、对现有方案做出合理评估。

（2）方案可行性 & 有无更优方案 & 发现隐藏需求

前期的工作通常是 BA 独自完成，团队聚在一起进行评估是个发现问题的好机会。

例如，我们在内部评估中就发现了一些隐藏需求：
• 仅凭运单号在 S 公司 ERP 系统中是无法查询到运单详情的，入参还需要经销商在 ERP 中的代码。于是衍生出一个“为经销商维护 ERP 代码”的需求；
• 根据液位传感器数值变化判断 IBC 是在加注还是放油以及变化量是多少将是一系列复杂的算法问题，因为液位传感器探测到的数值变化一定不是线性的......

（3）工作量估算

甲方客户往往比较关注工期问题，越早给出工作量评估越能帮助客户和团队更好地计划，但矛盾的是越早给出的工作量评估可信度越低。在当前上下文中，我是建议在此时基于现有设计给出一版工作量评估。而工作量的表达方式，可以换算成需要几个人做几周这个粒度，便于客户理解和决策。后续若有明显的工作量变化应及时知会客户方。

六、 带着细化的设计与各业务方进一步沟通确认

肉眼可见的设计往往能“勾”出业务方更多的想法，所以这里需要注意控制需求膨胀，把重点聚焦在方案设计和业务规则的确认。 另外，在此过程中，难以避免会出现对前期设计的否定，对此应该是积极拥 抱的态度，想一想“还好在设计阶段就发现了这些问题”会不会感觉好一些? 与甲方客户的沟通中别忘了对开发和交付计划进行对齐，以便安排后续资源。

这里有一个值得讨论的问题，每次设计的更新都需要与各业务方再次确认吗？我的建议是，涉及业务规则、业务逻辑的变更肯定是要再次确认的，但解决方法的变更可视情况而定。当然，条件允许时保持持续的沟通是更可靠的选择。

七、 进一步细化设计

上述方案和设计得到确认后即可进入下一步的设计阶段。

基于我所在的上下文，我会要求 Amy 给出正式的 kick off 确认，因为接下来要投入的资源远超前面几个步骤。比如，我所在的项目不会常备 UX 这一角色，在此阶段才引入 UX 进行详细的用户体验设计是相对比较高效的。在 UX 出设计的同时，BA 就可以着手细化 story 了。

至此，“散装润滑油的去包装环保解决方案” 这一业务需求就一步步拆解成了系统功能级的解决方案，具备进入开发阶段的条件。

本篇文章“从业务需求到可落地方案的实战案例“收录于 BeeArt 文集「职」言产品系列第二期，文集合计 11 篇文章，2篇工具推荐。作为为产品经理和业务分析师量身打造的文集「职」言产品 2，我们对需求理解的不同段位进行了划分，你会看到高阶产品经理对需求背景把控的维度，中阶对需求的全局分析方法，以及初阶对获取需求后的拆解与执行建议。

希望这本文集，可以在你犹豫不决时，获得些许勇气；在你踌躇不前时，获得些许灵感。

点击获取电子文集全稿「职」言产品2 ： https://jinshuju.net/f/mYVaZd

BeeArt | 行知蜂 - 数字化产品协同平台

或联系 BeeArt 小助手提供建议和反馈（叶子，lsye@thoughtworks.com）

如果仅从表达逻辑上来看有点像八股文，算是有比较固定的套路。首先理解需求，从业务场景对需求场景准确复数；之后分析需求，从专业角度分析造成需求场景的关进因素；然后方案憧憬，从业务场景描述通过解决方案能够实现的效果和场景；接下来做方案介绍，从产品技术的角度介绍解决方按的实现方法，需要什么样的产品、技术、配套组合等；然后是方案实施计划，从项目管理角度介绍整个进程如何开展，大致分几个阶段，不同阶段的计划和资源需求是怎样的，如何保证完成质量和风险控制。最后是团队和案例介绍，你们团队有哪些成员如何分工，之前完成过类似的哪些需求项目。

基本上这样就能明白的说清楚一个可落地的解决方案长什么样了

要写好一个解决方案，最重要的核心是深刻了解客户的需求。

所以，你首先一定要了解客户具体是想要解决什么问题？

解决方案的核心，是围绕客户的需求问题，做出全方位的解决方案。所以，对客户问题的准确理解成为了方案的基础，因其直接涉及到后期解决方案围绕的核心。

从解决方案的内容表达来看，其层次包括以下三种：

1、客户基本需求的满足

2、客户基本需求的满足 + 需求的延伸、功能的完善

3、客户基本需求的满足 + 需求的延伸、功能的完善 + 未来蓝图的实现

接下来，你需要梳理方案的思路。

对收集到的资料进行归纳整理，解决方案需要有清晰的方案思路，围绕需求解决方案，构建其基本提纲与框架结构，再对框架内容进行填充，以确保方案的整体性与内容的连贯性。

方案思路的要求：清晰的框架，流畅的逻辑（因果关系、先后顺序）

方案思路的重要性：直接影响方案的传达。

然后是方案落地书写阶段与定稿。

1. 传达：找一个适宜的演示模板

强调适宜的模板，而不是好的模板，心中要有模板也只是辅助，主要功能是视觉的美观。

2. 初稿：内容的表达

方案初稿是方案框架的填充，内容的表达需要满足直观、精准、极简的表达。

3. 内容的演示、修改、添加

好的东西都需要精细的打磨的，“一千个人心中有一千个哈姆雷特”，方案更是如此，而方案的最好呈现，是集多方建议，将方案最优化。

4. 定稿

定稿是最开心的时刻，前期所有的付出终于有了收获，犹如“十月怀胎”，最终“呱呱坠地”。

最后你的方案还需要反馈与复盘，不断优化。

方案提交或演示后，客户提出的问题都需要一一记录下来，便于方案的持续优化与修改，即便是结果导向的方案，我们也需要为下次更优的方案做准备，提升不正是在每一次方案中累积，最后越来越优秀。

以上！

……

每个职场人都应该有一个自己的案例库：

道一：【营销人的方案库】2023品牌营销策划方案大全：长期持续更新中……

道一：2023公关策划方案-99例，史上最实用公关攻略！

道一：2023直播营销策划案-113份

==========================

如果这篇内容对你有帮助，欢迎点个小赞，让更多朋友学习到哈，谢谢你！

不想错过更多干货？欢迎点击头像关注道叔哈！

了解它,方案自然就出来了