上周半夜收到一条消息一位做售前的老朋友说他卡住了客户催着要一份解决方案明天中午之前必须发过去他打开文档写了三页删了两页剩下那一页还全是形容词。这种场景我太熟了因为我自己早些年也是这么过来的——把产品介绍复制一遍把功能列表排一排再套上背景—方案—报价的老三段自我感觉写得挺全结果发出去连个回音都没有。后来才慢慢想明白一件事解决方案不是一份介绍我们有什么的文档而是一份说服对方为什么该按这个路子走、并且相信我们能把事办成的行动说明书。它要同时服务三类人——拍板的人看结论和投入把关的人看逻辑和细节执行的人看步骤和边界这三类人的阅读耐心加起来可能不到二十分钟。所以这篇东西我会按从想清楚到写出来再到交出去的顺序讲把我自己反复改过好几版的框架、常踩的坑、以及几个能直接用上的模板摊开来说适合第一次被派去写方案的新人也适合写了几年但总觉得差点意思的老手对照着看。1. 先界定清楚解决方案和另外三种文档的边界在哪很多人写不好不是因为文笔差而是从第一分钟就搞错了文体。手里拿着产品手册的素材、投标文件的模板、技术文档的目录往解决方案这个筐里一装出来的一定是个四不像。动手之前先花十分钟把边界划清楚比后面改十遍都管用。1.1 它和产品说明书、技术文档、报价单的本质区别产品说明书的视角是我主语是产品技术文档的视角是物主语是系统报价单的视角是钱主语是条目。而解决方案的视角必须是你主语是对方要达成的那个目标。这个差别听起来像句正确的废话但落到字面上非常具体产品说明书写支持多级审批流配置解决方案要写成你们现在三级审批靠邮件转发平均卡单两天半按这套流程配置后卡单时间能压到四小时以内。前者陈述能力后者陈述改变。我一般用一句话来检验自己写的是不是解决方案把文档里所有我们换成你们如果句子读不通说明写跑偏了。比如我们拥有十年行业经验这句换了主语就废了因为它跟对方的处境没有半点关系而你们现有两条产线的数据口径不一致导致月度报表要人工核对三天这句主语天然就是对方。这个笨办法屡试不爽改稿的时候逐段过一遍能砍掉大量自嗨内容。技术文档可以只讲怎么做解决方案必须讲为什么这么做、做完之后你的哪一天会变得不一样。报价单可以只有数字解决方案里的数字必须挂在某个具体收益上否则那些数字就只是成本。1.2 三类读者的耐心不同方案的信息要分层投放一份方案通常会被至少三类人看到他们的关注点差异极大这一点在动笔前就必须想清楚否则你会陷入写细了老板不看写粗了技术不认的两难。读者角色最关心的问题通常看哪几页停留时间决策者花多少钱、多久见效、出问题谁负责摘要、投入产出、实施周期、风险5 到 10 分钟技术把关人逻辑是否自洽、边界是否清楚、有无隐藏依赖现状分析、总体架构、模块细节20 分钟以上执行者我下周要做什么、要什么权限、找谁对接实施计划、组织分工、验收标准翻到对应章节看清这张表你就明白为什么方案要有摘要先行的设计决策者很可能只读前三页那前三页就必须能独立成篇把结论、投入、周期、关键风险说圆。而技术把关人会往后翻所以主体部分不能注水得经得起追问。执行者只在项目启动后才会细看计划章节但那部分写虚了后面落地就会天天扯皮。一个实用的做法是给每一章加一句本章结论用加粗放在章首。这样即使对方跳读也能在三十秒内抓到这一章要证明什么。我见过太多方案把结论藏在章节末尾第三段读者翻到那儿早就走神了。1.3 判断一份方案成不成的标准不是全而是敢签字新人最容易犯的执念是写全恨不得把所有可能性都覆盖到结果文档八十页读完的人零个。真正的验收标准其实很朴素对方看完之后敢不敢在会上说就按这个来。敢说明逻辑闭合了不敢多半是某个关键疑问没被正面回答。我习惯在写完初稿后自己列一张反对意见清单把对方可能提出的质疑一条条写下来——为什么不用现成的工具、为什么周期要四个月、为什么这一步不能省、如果中途需求变了怎么办。然后逐条回文档里找答案找不到的就补进去。这个动作通常只要半小时但它能提前消化掉评审会上百分之七十的火力。方案的说服力不来自篇幅来自你想问的我都想到了这种确定感。2. 动笔前必须钉死的四件事比写正文重要得多我见过效率最高的写法是调研两小时列提纲一小时写正文半天。也见过效率最低的写法直接开文档边写边想写三天改五天。差别不在打字速度在于动笔之前脑子里有没有把下面这四件事钉死。这四件事只要有一件含糊正文写多漂亮都会在评审时被打回。2.1 对方到底在为什么事发愁用原话记下来需求这件事书面描述和真实痛感常常差着十万八千里。邮件里写的是希望提升数据利用效率实际坐下来一聊才发现真正让他们睡不着的是每个月开经营会前三个部门交上来的数字对不上老板当场发火。这两种描述对应的方案完全是两码事前者你会去讲数据平台架构后者你得先解决口径统一和取数流程。我的习惯是在沟通时开着文档把对方的原话原封不动敲进去尤其是那些带情绪的句子——每次都要手工核上次因为这个事耽误了一周这个我们试过不行。这些句子后面会直接变成方案里的现状描述因为原话自带可信度比你转述一遍的书面语有力得多。有个小技巧把原话里的动词圈出来核对导出催补返工这类词往往就是方案要消灭的动作一个动作对应一个功能点或者一个流程改造点。2.2 先把不做什么写下来边界比范围更能建立信任新手喜欢把范围写大觉得覆盖面越广越显得有实力。老手恰恰相反会主动在方案里划出一条清晰的界线明确哪些不在本次范围内。原因很简单范围写得越满对方的预期越高交付时的落差越大而主动划界反而显得你懂行因为只有真的做过的人才知道哪里容易失控。我通常会在方案里单独用一小段写本次不包含比如历史数据只迁移近两年、第三方系统的接口改造由对方协调、移动端适配放到第二阶段。写的时候注意措辞不要写成推卸责任而要写成阶段划分考虑到首期目标是先让核心流程跑通以下内容安排在二期评估避免首期战线过长影响上线时间。 同样的意思前者听着像甩锅后者听着像替对方省钱。2.3 约束条件盘点预算、工期、现有环境、人员能力方案不是写在真空里的。同样一个目标预算充足和预算紧张走出来的是两条完全不同的路。所以动笔前我会拉一张约束清单通常包括四栏钱、时间、现有环境、人的能力。这四栏里任何一栏是硬约束方案的技术路线就得绕着它设计。举个常见的例子。如果对方现有环境里已经有一套在用的系统且明确说了短期不换那方案的重点就不该是重建而应该是对接与增量改造架构图上必须把这套老系统画进去标清楚数据从哪进、从哪出。如果对方的技术人员只有两个人那方案里就不要设计一套需要专职运维的复杂架构否则上线之日就是烂尾之时。这些判断不需要多高深的技术需要的是愿意多问一句你们现在手上有什么、有几个人。2.4 摸清决策链谁拍板、谁可能反对、谁负责落地这一条最容易被技术出身的人忽略。方案写给谁看直接决定了详略和语气。我曾经见过一份写得很扎实的技术方案被否掉原因很简单真正拍板的那位只关心今年能不能少雇两个人而方案里通篇在讲架构分层没有一个字提到人力节省。所以沟通的时候我会刻意问一句这份材料后面还会有谁看通常能问出一条链子业务负责人在意效果和周期技术负责人关心可行性和维护成本采购关心价格构成和付款方式财务关心这笔钱算资产还是费用。不同角色的关注点不同方案里就要预留对应的段落。反对者尤其要重视如果知道某位技术负责人对某个路线有疑虑与其绕开不如在方案里正面写一段关于某某路线与某某路线的对比把顾虑摆到台面上讨论比藏着掖着强。3. 骨架怎么搭章节顺序本身就是一条说服路径提纲不是把内容分个组而是设计一条阅读路径——从你说得对到这个办法可行再到我愿意为它签字。所以章节的排列顺序有讲究不能随手拼。我给不少人改过提纲最常见的问题是把我们公司介绍放在第一章这等于让读者先看三页广告再看正文耐心早就耗光了。3.1 一套经得起追问的通用骨架下面这套结构我用过很多次适用于大多数B端场景可以按实际需要增减但主干不建议动摘要与核心结论一页之内说清问题、思路、周期、投入、关键收益。现状与问题拆解用事实和数字描述当前状态指出三个以内的核心矛盾。目标与成功标准这次要做到什么程度算成功用可验证的指标写。总体思路与架构一句话讲清路线配一张分层图讲清边界。分模块方案按业务模块或功能域展开每块统一模板。实施计划与里程碑阶段划分、交付物、时间点、责任方。组织与保障谁来做、怎么配合、沟通机制。风险与应对明确列出风险、影响、应对措施。投入与收益成本构成、收益测算、测算口径。附录术语表、参考案例、详细参数。这个顺序背后的逻辑是先建立共识问题确实存在再给出方向思路合理然后证明可行模块和架构接着回答怎么落地计划和组织最后处理万一不行风险和值不值投入收益。每一步都在消解一类疑虑顺序颠倒就会让人读得别扭。3.2 篇幅分配上的倒金字塔陷阱绝大多数写得难看的方案问题出在篇幅分配上背景写了八页方案写了两页风险写了三行。这就是典型的倒金字塔——把力气花在了读者已经认同的地方在他真正想看的地方草草收场。我的建议是把总篇幅按这样的比例分配现状与问题占百分之十五总体思路与模块方案占百分之四十实施计划与组织占百分之二十风险与投入收益占百分之二十摘要和附录占百分之五。也就是说方案主体必须是文档里最厚的部分。写的时候可以用一个土办法自查把每一章的字数统计出来列个表如果背景那一章的字数超过了分模块方案基本可以判定这篇要返工。还有一个细节值得注意背景部分不要写成行业分析。有些方案开头动辄三段宏观趋势读起来气势很足但跟对方的具体处境没有关系。背景的唯一作用是让对方点头说对我们就是这样凡是不服务于这个目的的段落都可以删。3.3 目录就是说服路径标题要写得像结论很多人写标题的习惯是名词化比如现状分析方案设计实施保障。这类标题信息量为零读者扫一眼目录什么也得不到。更好的做法是把标题写成结论句让目录本身就能传递信息。对比一下就明白差别在哪名词式标题结论式标题现状分析三条产线数据口径不一致月度核对耗时三天方案设计用统一取数层收敛口径报表自动生成实施保障分两期上线首期先跑通核心三条流程风险说明老系统接口不稳定需预留两周联调缓冲右边这一列读者哪怕只翻目录也能大致知道你要说什么、值不值得往下看。这个改动成本极低但观感提升非常明显。唯一的代价是写标题时要多花点脑子得先想清楚这一章到底要证明什么。4. 把痛点写透是整篇方案说服力的地基方案的说服链条是这样的先让对方承认问题确实严重他才会有动力接受解决方式确实要改。跳过这一步直接讲方案对方心里会一直悬着一个疑问——我们现在这么干也挺好的为什么要折腾。所以现状描述这一章值得单独拿出来反复打磨。4.1 用对方的语言复述而不是用你的术语概括描述现状时最容易犯的错是用自己熟悉的专业词汇去概括对方的处境。你说数据孤岛严重对方听了没感觉你说销售在系统里查完客户还得再去另一个系统里翻合同一份合同平均要切三次页面对方立刻点头因为这就是他每天在做的事。具体做法是把调研时记下的原话搬进来稍作整理。比如把每次月底都要手工核扩展成一段每月最后两个工作日财务要从三个系统分别导出明细人工比对差异项上一期核出十七处不一致逐条追溯平均耗时一天半。 这段话里有动作、有系统、有数量、有时长全是事实没有一个是形容词。事实堆到一定程度痛点自己就站起来了根本不需要效率低下亟待提升这类词去强调。4.2 现状描述的颗粒度可量化、可验证、可复现判断一段现状描述合不合格我有个简单的尺子对方的技术人员能不能照着这段描述在自己的环境里把问题复现出来。能说明写实了不能说明还停在印象层面。要达到这个颗粒度通常需要补齐三类信息一是数量比如单据量、并发数、出错频次二是路径一件事从发起到结束要经过几个环节、几次人工干预三是后果这个问题每次发生会造成多少返工、多少等待。三者凑齐问题就有了重量。需要提醒的是这些数字必须来自对方不能自己估。我见过方案里写预计每年因此损失约两百万元对方当场反问这个数你怎么算的答不上来就很难看。宁可写据贵方运营部门提供的数据上季度因此产生的返工工时约为四百小时也不要写一个来路不明的宏大数字。4.3 不要急着给答案先让对方在问题页上停留有些方案写得太急现状只写了两段第三段就开始讲因此我们建议采用某某架构。读者的情绪还没被调动起来就被推着往前走效果往往很差。我一般的做法是让现状章节独立收尾用一小段话把矛盾归结成两三条然后停住下一章再谈思路。比如这样收尾综合来看当前的核心矛盾集中在三点口径不统一导致数据不可信环节过多导致周期不可控依赖人工导致质量不稳定。这三条不解决任何上层的分析都建立在流沙上。 这段话没有提任何方案但它把问题钉死了读者往下翻的时候是带着那怎么办的疑问在读注意力自然不一样。这一步在实际沟通中还有额外好处如果你有机会当面讲方案在讲完现状后故意停顿一下问一句这几点我理解得对不对通常能换来一轮补充信息甚至能把对方内部没达成一致的矛盾暴露出来。这些信息比方案本身更值钱。5. 方案主体把我们有什么改写成你会怎么用这是整篇文档的核心也是最容易写成产品目录的地方。判断标准只有一个每一个模块描述读者能不能对应到自己工作中某个具体场景。对应得上就是有效内容对应不上就是凑字数。5.1 总体架构图要画三样东西分层、边界、数据流向架构图不是画得越复杂越显专业。我见过一张图框套框套了五层箭头横七竖八讲的人自己都要看半天才找到入口。好的架构图只需要说清三件事分了哪几层每层负责什么系统的边界在哪哪些是已有的、哪些是新增的数据从哪进、经过什么处理、从哪出。画法上我习惯用横向分层、纵向分域底下是数据与基础层中间是业务处理层上面是交互层左边画外部系统的接入右边画输出与消费方。已有的系统用浅色新建的部分用深色一眼就能看出改造量。图上每个框不超过六个字细节放到下面的文字里说图只承担讲清关系的职责。这里有个常被忽略的点图里一定要标出对方的既有系统。有些方案为了显得干净把老系统全省略了画出来像个全新世界对方一看就知道你没做功课。老老实实把老系统画进去并标清接口方式反而显得你摸过底。5.2 模块描述用一个固定模板逼自己写清依赖和输入输出模块部分最容易写成功能罗列。为了逼自己写实我给每个模块定了一个五段式模板写不满就说明这块我还没想清楚对应问题这个模块解决前面提到的哪一条痛点编号对应。处理逻辑输入是什么、经过哪几步、输出是什么。使用场景谁在什么情况下会用到一天大概用几次。依赖条件需要哪些系统配合、需要谁提供什么数据。不覆盖的情况什么场景下这个模块不管交给谁管。这五条里依赖条件和不覆盖的情况最能体现专业度也最容易被跳过。实际项目里出问题十有八九出在这两条上——要么是某个数据源没人提供要么是某个边界场景双方理解不一致。提前写清楚等于提前把责任划清。举个具体的写法差别。功能罗列式会写支持多条件组合查询支持导出。 模板式会写对应问题二。业务人员按时间、区域、品类三个维度组合筛选结果实时返回单次查询响应在两秒内结果可导出为表格用于月度经营会材料准备。依赖统一取数层的汇总表若上游延迟查询结果会滞后一个批次。不含跨年度对比该场景由分析模块承担。 后者读起来啰嗦但它把什么时候能用、什么时候不能用交代清楚了这才是执行的人需要的。5.3 技术选型要写出取舍过程只给结论等于没写方案里凡是出现采用某某技术选用某某架构的地方后面都应该跟一段为什么。原因很实在评审会上一定会有人问为什么不用另一个你写在文档里等于提前回答了不写就得当场答答不好前面所有内容都会被质疑。取舍的写法不用很长三句话足够候选有哪几个各自的关键差异是什么在当前约束下为什么选这个。比如消息处理部分考虑过两种做法一种是引入独立的消息队列组件吞吐高但需要额外运维另一种是基于现有数据库做轮询实现简单但延迟较高。考虑到本期日均消息量在万级以内且对方暂无专职运维人员选择后者并在方案中预留了后续替换的接口。 这段话把量级、人员约束、未来扩展都带到了说服力比一句采用成熟方案强太多。5.4 用一张对齐表把痛点、方案点、预期效果串起来写完全部模块后我会回头做一张对齐表放在方案主体章节的末尾。这张表的作用是让读者一眼看出每一条痛都有对应的解法没有遗漏也没有多余的堆砌。编号现状痛点对应方案模块预期改善验证方式P1三系统口径不一致统一取数层月度核对由三天降至半天连续两个月对比核对工时P2审批靠邮件转发流程引擎配置平均卡单时间由两天半降至四小时流程日志统计P3关键节点依赖人工催办提醒与看板超期单据占比降到百分之五以内月度超期率报表这张表看着简单实际写的时候特别能暴露问题。有不少次我列到一半发现某个痛点在正文里没有对应模块或者某个模块找不到它服务的痛点——前者说明方案有缺口后者说明这个模块可能是自嗨得考虑删掉或者说明它的支撑作用。6. 实施、风险与投入让方案从想法变成可签字的承诺前面几章证明的是这个办法对这一章要证明的是这件事办得成。很多方案在这里泄气计划写得像愿望清单风险写得像免责声明投入收益写得像财务预测小说。评审人恰恰最看这一块因为这里藏着他真正要担的责任。6.1 里程碑按可验收的交付物切不要按工种切常见的错误切法是按团队分工切需求阶段、开发阶段、测试阶段、上线阶段。这种切法只对内部有用对读者毫无意义因为他关心的是什么时候能看到东西。正确的切法是按交付物切每个阶段结束时必须有一样能看得见、能验收的东西。比如第一阶段结束交付三条核心流程跑通并完成一轮真实数据验证第二阶段结束交付报表自动生成与人工核对结果一致第三阶段结束交付全员切换旧流程停用。每个交付物都自带验收标准推进过程中也不会出现做完了但不知道算不算完成的扯皮。时间估算上我的经验是每个阶段都留缓冲尤其是涉及对接外部系统的环节。老实写预留两周联调缓冲不但不掉价反而显得有经验。反过来把计划排得严丝合缝、一天不差评审时反而会被质疑你怎么保证。6.2 风险清单写到有人负责、有动作、有触发条件才算数风险章节最怕写成这样本项目可能存在需求变更、人员变动、接口不稳定等风险我们将加强沟通确保项目顺利推进。 这段话一个字的信息量都没有。合格的风险条目应该包含五列风险描述、可能影响、发生概率、应对措施、责任人。用表格呈现最清楚。风险影响概率应对措施触发条件老系统接口文档缺失联调延期高首周安排接口摸底必要时抓包补文档摸底发现三个以上接口无文档关键用户参与度不足需求偏差中每周固定一次业务确认会缺席则升级连续两次确认会无人出席历史数据质量差迁移返工中迁移前先做样本清洗出具质量报告样本错误率超过百分之五写到这个程度风险章节反而成了加分项因为它传递的信息是我们想过最坏的情况并且准备好了。反过来一份通篇没有风险、全是顺利预期的方案稍有经验的人看了都会皱眉。6.3 收益测算宁可保守成本测算必须留余量收益这块最容易写飘。我见过方案里写预计提升效率百分之三百评审时被一句怎么算的问得哑口无言。稳妥的做法是把测算过程摊开先算单个动作节省多少时间再乘上发生频次最后折算成人天或金额每一步的假设都写出来让人能自己复核。比如以单据录入为例改造前平均每单录入耗时四分钟改造后约两分半按日均两百单计算每日节省约三百分钟折合五个人时全年按二百五十个工作日计约节省一千二百五十人时。 这个数比效率提升百分之四十扎实得多因为它可验证即使对方不完全认同也能就某个参数展开讨论而不是全盘否定。成本侧则相反要留余量。人力、外部采购、培训和后期维护这四块都要列到尤其是后期维护很多方案只算建设不算维护对方第二年发现还要持续投入信任度会掉得很快。主动把维护成本写出来短期看是给自己加价长期看是省掉后面的扯皮。6.4 验收标准写清楚等于给双方都上了保险验收标准这一小节经常被省略或者写成系统稳定运行满足业务需求这种没法执行的表述。它的作用是双重的对客户来说知道什么时候算交付完成对实施方来说避免无限期返工。好的验收标准通常包含三部分功能验收看什么关键流程是否跑通用哪批数据验证、性能验收看什么响应时间、并发量、可用性指标的具体数值、文档与培训验收看什么交付哪些文档培训几场多少人参加。每一条都写成可勾选的形式双方签认的时候逐条对对不上就是没完成谁也没法含糊。7. 四种最常见的翻车写法以及具体怎么改写方案的手感是靠改稿练出来的。我把这些年见过最多的四类问题整理出来每条都给出改写思路对照着看比空谈标准有用得多。7.1 满篇形容词找不出一个动词和数字典型症状是高效智能全面一体化深度赋能这类词密集出现一段话读下来气势很足但说不出到底做了什么。这种文风多半是从宣传材料里带过来的。改法很简单把所有形容词划掉逼自己用谁在什么时候做什么、原来要多久、之后要多久的句式重写。写不出来说明这块内容你其实没想清楚或者压根没有实质内容。我给自己定过一条规矩一段话里如果形容词超过两个就重写。执行下来文档厚度通常减三成可读性翻倍。7.2 复制粘贴改个名字就交细节全是模板味这类方案的特征很明显案例部分写的是别的行业的场景图表里的字段名和正文对不上甚至连对方公司的业务描述都不准确。收到这种材料的人第一反应不是写得不好而是你不重视这个事后面再想挽回很难。规避办法有两个。一是所有案例都要换成对方能理解的场景哪怕是自己编的示意数据也要和对方业务沾边。二是交稿前搜一遍全文把可能残留的旧名称、旧行业词、旧数字全部核对一遍。这个动作看着笨但每年都能救回不少人。我自己的习惯是最后通读一遍时专门盯数字和专有名词其他都可以放过这两类错了最伤。7.3 头重脚轻前面讲了三页背景方案只写了两段这种结构在高校背景或者咨询背景出身的写作者身上特别常见习惯了先做宏观分析再落到具体。问题是读者不是来听行业课的他要的是解法。改法是把背景压缩到一页以内只保留和本次目标直接相关的部分其余全部挪到附录或者直接删掉。判断依据是这句话删掉之后后面的方案还成不成立。成立就删。用这把刀砍一遍通常能砍掉一半以上的背景内容。7.4 风险章节写成我们没有风险有些方案出于各种顾虑把风险写得极轻甚至通篇不写。读者不傻越是没有风险的项目描述越让人觉得不真实。真正做过项目的人都知道任何改造都有风险区别只在于有没有提前想好对策。改写思路是把风险当成专业度的展示窗口。挑三到五条真实存在、对方也大概率会想到的风险认真写清影响和对策。写的时候注意措辞重点放在怎么控而不是多可怕。一条好的风险描述读完会让人觉得踏实而不是想打退堂鼓。8. 交稿前的最后一公里自检、排版和口头讲解内容写完了不等于能交。我看过太多底子不错的方案栽在排版混乱、错字连篇、讲的时候抓不住重点上。这一公里不长但决定了前面几公里的努力能不能变现。8.1 一张十分钟能过完的自检清单每次交稿前我都会固定跑一遍下面这几条花了多少时间省下的返工时间往往是它的好几倍。检查项判断标准摘要独立成篇只看前三页能否说清问题、思路、周期、投入痛点与模块对齐每条痛点都有对应模块每个模块都有服务的痛点数字有出处所有关键数字都能说清来源或计算方式边界清晰明确写出本次不包含的内容风险可执行每条风险都有应对措施和触发条件计划可验收每个阶段都有具体交付物和验收标准术语统一同一个概念全文只用一种叫法无残留信息没有旧项目名称、旧行业词、旧数据其中术语统一这条最容易被忽略。同一个东西在方案里一会儿叫数据中台一会儿叫数据底座一会儿叫统一取数层读者会以为是三个不同的东西追问起来很被动。定稿前搜一遍关键词统一成一个说法。8.2 排版是阅读体验的一部分不是装饰排版的目标只有一个让读者能快速找到他关心的部分。具体做几件事就够了摘要单独成页核心结论加粗每章开头加一句本章结论表格统一表头样式数字右对齐重要图表配一句图注说明这张图想表达什么页眉放文档名和版本号页脚放页码。有一个细节值得单独提图表一定要有编号和标题。评审时经常出现刚才那张图再翻回去看一下的情况有编号就能一句话定位没编号就得翻半天。这个成本几乎为零收益很直接。另外版本号和日期务必写清楚。方案是会反复改的没有版本号很容易出现双方拿着不同版本讨论的尴尬场面。我一般用版本号加日期的格式每次修改都更新并在文档开头附一小段修改说明写明这一版改了什么。8.3 讲方案的时候顺序和文档顺序可以不一样如果方案需要当面讲讲法和写法要分开设计。文档是按逻辑顺序写的从问题到方案层层递进但口头汇报的时间通常只有二十分钟必须倒过来讲——先给结论再讲依据。我的讲法一般是四句话开场现在的问题是什么、我们打算怎么做、需要多长时间和多少投入、最大的风险是什么以及怎么控。这四句讲完听众心里有了框架后面再展开细节他们才知道该往哪儿放。展开的时候优先讲对方最关心的那一两个模块其余略过留到问答环节。问答环节有个经验遇到答不上来的问题不要硬编。直接说这一点我需要回去核实明天之前给您书面答复比现场编一个答案然后被追问穿帮要好得多。方案的信任感是靠一次次准确回复积累起来的一次含糊就可能全盘打折。最后分享一个我自己的习惯。每次方案交付之后我会把对方的反馈、评审会上被问到的问题、以及最终落地时和方案不一致的地方简单记在一个文档里。攒上十几份之后回头看会发现被问来问去的就是那么几个点落地走样的也总是那几类环节。下次动笔前先翻一遍这份记录比看任何写作教程都管用因为那里面全是真实的、带着具体场景的教训。 
长河君 · 2026/10/31 3:57:59 · 阅读 1.2k B端解决方案写作指南：从痛点分析到评审交付的完整框架
上周半夜收到一条消息一位做售前的老朋友说他卡住了客户催着要一份解决方案明天中午之前必须发过去他打开文档写了三页删了两页剩下那一页还全是形容词。这种场景我太熟了因为我自己早些年也是这么过来的——把产品介绍复制一遍把功能列表排一排再套上背景—方案—报价的老三段自我感觉写得挺全结果发出去连个回音都没有。后来才慢慢想明白一件事解决方案不是一份介绍我们有什么的文档而是一份说服对方为什么该按这个路子走、并且相信我们能把事办成的行动说明书。它要同时服务三类人——拍板的人看结论和投入把关的人看逻辑和细节执行的人看步骤和边界这三类人的阅读耐心加起来可能不到二十分钟。所以这篇东西我会按从想清楚到写出来再到交出去的顺序讲把我自己反复改过好几版的框架、常踩的坑、以及几个能直接用上的模板摊开来说适合第一次被派去写方案的新人也适合写了几年但总觉得差点意思的老手对照着看。1. 先界定清楚解决方案和另外三种文档的边界在哪很多人写不好不是因为文笔差而是从第一分钟就搞错了文体。手里拿着产品手册的素材、投标文件的模板、技术文档的目录往解决方案这个筐里一装出来的一定是个四不像。动手之前先花十分钟把边界划清楚比后面改十遍都管用。1.1 它和产品说明书、技术文档、报价单的本质区别产品说明书的视角是我主语是产品技术文档的视角是物主语是系统报价单的视角是钱主语是条目。而解决方案的视角必须是你主语是对方要达成的那个目标。这个差别听起来像句正确的废话但落到字面上非常具体产品说明书写支持多级审批流配置解决方案要写成你们现在三级审批靠邮件转发平均卡单两天半按这套流程配置后卡单时间能压到四小时以内。前者陈述能力后者陈述改变。我一般用一句话来检验自己写的是不是解决方案把文档里所有我们换成你们如果句子读不通说明写跑偏了。比如我们拥有十年行业经验这句换了主语就废了因为它跟对方的处境没有半点关系而你们现有两条产线的数据口径不一致导致月度报表要人工核对三天这句主语天然就是对方。这个笨办法屡试不爽改稿的时候逐段过一遍能砍掉大量自嗨内容。技术文档可以只讲怎么做解决方案必须讲为什么这么做、做完之后你的哪一天会变得不一样。报价单可以只有数字解决方案里的数字必须挂在某个具体收益上否则那些数字就只是成本。1.2 三类读者的耐心不同方案的信息要分层投放一份方案通常会被至少三类人看到他们的关注点差异极大这一点在动笔前就必须想清楚否则你会陷入写细了老板不看写粗了技术不认的两难。读者角色最关心的问题通常看哪几页停留时间决策者花多少钱、多久见效、出问题谁负责摘要、投入产出、实施周期、风险5 到 10 分钟技术把关人逻辑是否自洽、边界是否清楚、有无隐藏依赖现状分析、总体架构、模块细节20 分钟以上执行者我下周要做什么、要什么权限、找谁对接实施计划、组织分工、验收标准翻到对应章节看清这张表你就明白为什么方案要有摘要先行的设计决策者很可能只读前三页那前三页就必须能独立成篇把结论、投入、周期、关键风险说圆。而技术把关人会往后翻所以主体部分不能注水得经得起追问。执行者只在项目启动后才会细看计划章节但那部分写虚了后面落地就会天天扯皮。一个实用的做法是给每一章加一句本章结论用加粗放在章首。这样即使对方跳读也能在三十秒内抓到这一章要证明什么。我见过太多方案把结论藏在章节末尾第三段读者翻到那儿早就走神了。1.3 判断一份方案成不成的标准不是全而是敢签字新人最容易犯的执念是写全恨不得把所有可能性都覆盖到结果文档八十页读完的人零个。真正的验收标准其实很朴素对方看完之后敢不敢在会上说就按这个来。敢说明逻辑闭合了不敢多半是某个关键疑问没被正面回答。我习惯在写完初稿后自己列一张反对意见清单把对方可能提出的质疑一条条写下来——为什么不用现成的工具、为什么周期要四个月、为什么这一步不能省、如果中途需求变了怎么办。然后逐条回文档里找答案找不到的就补进去。这个动作通常只要半小时但它能提前消化掉评审会上百分之七十的火力。方案的说服力不来自篇幅来自你想问的我都想到了这种确定感。2. 动笔前必须钉死的四件事比写正文重要得多我见过效率最高的写法是调研两小时列提纲一小时写正文半天。也见过效率最低的写法直接开文档边写边想写三天改五天。差别不在打字速度在于动笔之前脑子里有没有把下面这四件事钉死。这四件事只要有一件含糊正文写多漂亮都会在评审时被打回。2.1 对方到底在为什么事发愁用原话记下来需求这件事书面描述和真实痛感常常差着十万八千里。邮件里写的是希望提升数据利用效率实际坐下来一聊才发现真正让他们睡不着的是每个月开经营会前三个部门交上来的数字对不上老板当场发火。这两种描述对应的方案完全是两码事前者你会去讲数据平台架构后者你得先解决口径统一和取数流程。我的习惯是在沟通时开着文档把对方的原话原封不动敲进去尤其是那些带情绪的句子——每次都要手工核上次因为这个事耽误了一周这个我们试过不行。这些句子后面会直接变成方案里的现状描述因为原话自带可信度比你转述一遍的书面语有力得多。有个小技巧把原话里的动词圈出来核对导出催补返工这类词往往就是方案要消灭的动作一个动作对应一个功能点或者一个流程改造点。2.2 先把不做什么写下来边界比范围更能建立信任新手喜欢把范围写大觉得覆盖面越广越显得有实力。老手恰恰相反会主动在方案里划出一条清晰的界线明确哪些不在本次范围内。原因很简单范围写得越满对方的预期越高交付时的落差越大而主动划界反而显得你懂行因为只有真的做过的人才知道哪里容易失控。我通常会在方案里单独用一小段写本次不包含比如历史数据只迁移近两年、第三方系统的接口改造由对方协调、移动端适配放到第二阶段。写的时候注意措辞不要写成推卸责任而要写成阶段划分考虑到首期目标是先让核心流程跑通以下内容安排在二期评估避免首期战线过长影响上线时间。 同样的意思前者听着像甩锅后者听着像替对方省钱。2.3 约束条件盘点预算、工期、现有环境、人员能力方案不是写在真空里的。同样一个目标预算充足和预算紧张走出来的是两条完全不同的路。所以动笔前我会拉一张约束清单通常包括四栏钱、时间、现有环境、人的能力。这四栏里任何一栏是硬约束方案的技术路线就得绕着它设计。举个常见的例子。如果对方现有环境里已经有一套在用的系统且明确说了短期不换那方案的重点就不该是重建而应该是对接与增量改造架构图上必须把这套老系统画进去标清楚数据从哪进、从哪出。如果对方的技术人员只有两个人那方案里就不要设计一套需要专职运维的复杂架构否则上线之日就是烂尾之时。这些判断不需要多高深的技术需要的是愿意多问一句你们现在手上有什么、有几个人。2.4 摸清决策链谁拍板、谁可能反对、谁负责落地这一条最容易被技术出身的人忽略。方案写给谁看直接决定了详略和语气。我曾经见过一份写得很扎实的技术方案被否掉原因很简单真正拍板的那位只关心今年能不能少雇两个人而方案里通篇在讲架构分层没有一个字提到人力节省。所以沟通的时候我会刻意问一句这份材料后面还会有谁看通常能问出一条链子业务负责人在意效果和周期技术负责人关心可行性和维护成本采购关心价格构成和付款方式财务关心这笔钱算资产还是费用。不同角色的关注点不同方案里就要预留对应的段落。反对者尤其要重视如果知道某位技术负责人对某个路线有疑虑与其绕开不如在方案里正面写一段关于某某路线与某某路线的对比把顾虑摆到台面上讨论比藏着掖着强。3. 骨架怎么搭章节顺序本身就是一条说服路径提纲不是把内容分个组而是设计一条阅读路径——从你说得对到这个办法可行再到我愿意为它签字。所以章节的排列顺序有讲究不能随手拼。我给不少人改过提纲最常见的问题是把我们公司介绍放在第一章这等于让读者先看三页广告再看正文耐心早就耗光了。3.1 一套经得起追问的通用骨架下面这套结构我用过很多次适用于大多数B端场景可以按实际需要增减但主干不建议动摘要与核心结论一页之内说清问题、思路、周期、投入、关键收益。现状与问题拆解用事实和数字描述当前状态指出三个以内的核心矛盾。目标与成功标准这次要做到什么程度算成功用可验证的指标写。总体思路与架构一句话讲清路线配一张分层图讲清边界。分模块方案按业务模块或功能域展开每块统一模板。实施计划与里程碑阶段划分、交付物、时间点、责任方。组织与保障谁来做、怎么配合、沟通机制。风险与应对明确列出风险、影响、应对措施。投入与收益成本构成、收益测算、测算口径。附录术语表、参考案例、详细参数。这个顺序背后的逻辑是先建立共识问题确实存在再给出方向思路合理然后证明可行模块和架构接着回答怎么落地计划和组织最后处理万一不行风险和值不值投入收益。每一步都在消解一类疑虑顺序颠倒就会让人读得别扭。3.2 篇幅分配上的倒金字塔陷阱绝大多数写得难看的方案问题出在篇幅分配上背景写了八页方案写了两页风险写了三行。这就是典型的倒金字塔——把力气花在了读者已经认同的地方在他真正想看的地方草草收场。我的建议是把总篇幅按这样的比例分配现状与问题占百分之十五总体思路与模块方案占百分之四十实施计划与组织占百分之二十风险与投入收益占百分之二十摘要和附录占百分之五。也就是说方案主体必须是文档里最厚的部分。写的时候可以用一个土办法自查把每一章的字数统计出来列个表如果背景那一章的字数超过了分模块方案基本可以判定这篇要返工。还有一个细节值得注意背景部分不要写成行业分析。有些方案开头动辄三段宏观趋势读起来气势很足但跟对方的具体处境没有关系。背景的唯一作用是让对方点头说对我们就是这样凡是不服务于这个目的的段落都可以删。3.3 目录就是说服路径标题要写得像结论很多人写标题的习惯是名词化比如现状分析方案设计实施保障。这类标题信息量为零读者扫一眼目录什么也得不到。更好的做法是把标题写成结论句让目录本身就能传递信息。对比一下就明白差别在哪名词式标题结论式标题现状分析三条产线数据口径不一致月度核对耗时三天方案设计用统一取数层收敛口径报表自动生成实施保障分两期上线首期先跑通核心三条流程风险说明老系统接口不稳定需预留两周联调缓冲右边这一列读者哪怕只翻目录也能大致知道你要说什么、值不值得往下看。这个改动成本极低但观感提升非常明显。唯一的代价是写标题时要多花点脑子得先想清楚这一章到底要证明什么。4. 把痛点写透是整篇方案说服力的地基方案的说服链条是这样的先让对方承认问题确实严重他才会有动力接受解决方式确实要改。跳过这一步直接讲方案对方心里会一直悬着一个疑问——我们现在这么干也挺好的为什么要折腾。所以现状描述这一章值得单独拿出来反复打磨。4.1 用对方的语言复述而不是用你的术语概括描述现状时最容易犯的错是用自己熟悉的专业词汇去概括对方的处境。你说数据孤岛严重对方听了没感觉你说销售在系统里查完客户还得再去另一个系统里翻合同一份合同平均要切三次页面对方立刻点头因为这就是他每天在做的事。具体做法是把调研时记下的原话搬进来稍作整理。比如把每次月底都要手工核扩展成一段每月最后两个工作日财务要从三个系统分别导出明细人工比对差异项上一期核出十七处不一致逐条追溯平均耗时一天半。 这段话里有动作、有系统、有数量、有时长全是事实没有一个是形容词。事实堆到一定程度痛点自己就站起来了根本不需要效率低下亟待提升这类词去强调。4.2 现状描述的颗粒度可量化、可验证、可复现判断一段现状描述合不合格我有个简单的尺子对方的技术人员能不能照着这段描述在自己的环境里把问题复现出来。能说明写实了不能说明还停在印象层面。要达到这个颗粒度通常需要补齐三类信息一是数量比如单据量、并发数、出错频次二是路径一件事从发起到结束要经过几个环节、几次人工干预三是后果这个问题每次发生会造成多少返工、多少等待。三者凑齐问题就有了重量。需要提醒的是这些数字必须来自对方不能自己估。我见过方案里写预计每年因此损失约两百万元对方当场反问这个数你怎么算的答不上来就很难看。宁可写据贵方运营部门提供的数据上季度因此产生的返工工时约为四百小时也不要写一个来路不明的宏大数字。4.3 不要急着给答案先让对方在问题页上停留有些方案写得太急现状只写了两段第三段就开始讲因此我们建议采用某某架构。读者的情绪还没被调动起来就被推着往前走效果往往很差。我一般的做法是让现状章节独立收尾用一小段话把矛盾归结成两三条然后停住下一章再谈思路。比如这样收尾综合来看当前的核心矛盾集中在三点口径不统一导致数据不可信环节过多导致周期不可控依赖人工导致质量不稳定。这三条不解决任何上层的分析都建立在流沙上。 这段话没有提任何方案但它把问题钉死了读者往下翻的时候是带着那怎么办的疑问在读注意力自然不一样。这一步在实际沟通中还有额外好处如果你有机会当面讲方案在讲完现状后故意停顿一下问一句这几点我理解得对不对通常能换来一轮补充信息甚至能把对方内部没达成一致的矛盾暴露出来。这些信息比方案本身更值钱。5. 方案主体把我们有什么改写成你会怎么用这是整篇文档的核心也是最容易写成产品目录的地方。判断标准只有一个每一个模块描述读者能不能对应到自己工作中某个具体场景。对应得上就是有效内容对应不上就是凑字数。5.1 总体架构图要画三样东西分层、边界、数据流向架构图不是画得越复杂越显专业。我见过一张图框套框套了五层箭头横七竖八讲的人自己都要看半天才找到入口。好的架构图只需要说清三件事分了哪几层每层负责什么系统的边界在哪哪些是已有的、哪些是新增的数据从哪进、经过什么处理、从哪出。画法上我习惯用横向分层、纵向分域底下是数据与基础层中间是业务处理层上面是交互层左边画外部系统的接入右边画输出与消费方。已有的系统用浅色新建的部分用深色一眼就能看出改造量。图上每个框不超过六个字细节放到下面的文字里说图只承担讲清关系的职责。这里有个常被忽略的点图里一定要标出对方的既有系统。有些方案为了显得干净把老系统全省略了画出来像个全新世界对方一看就知道你没做功课。老老实实把老系统画进去并标清接口方式反而显得你摸过底。5.2 模块描述用一个固定模板逼自己写清依赖和输入输出模块部分最容易写成功能罗列。为了逼自己写实我给每个模块定了一个五段式模板写不满就说明这块我还没想清楚对应问题这个模块解决前面提到的哪一条痛点编号对应。处理逻辑输入是什么、经过哪几步、输出是什么。使用场景谁在什么情况下会用到一天大概用几次。依赖条件需要哪些系统配合、需要谁提供什么数据。不覆盖的情况什么场景下这个模块不管交给谁管。这五条里依赖条件和不覆盖的情况最能体现专业度也最容易被跳过。实际项目里出问题十有八九出在这两条上——要么是某个数据源没人提供要么是某个边界场景双方理解不一致。提前写清楚等于提前把责任划清。举个具体的写法差别。功能罗列式会写支持多条件组合查询支持导出。 模板式会写对应问题二。业务人员按时间、区域、品类三个维度组合筛选结果实时返回单次查询响应在两秒内结果可导出为表格用于月度经营会材料准备。依赖统一取数层的汇总表若上游延迟查询结果会滞后一个批次。不含跨年度对比该场景由分析模块承担。 后者读起来啰嗦但它把什么时候能用、什么时候不能用交代清楚了这才是执行的人需要的。5.3 技术选型要写出取舍过程只给结论等于没写方案里凡是出现采用某某技术选用某某架构的地方后面都应该跟一段为什么。原因很实在评审会上一定会有人问为什么不用另一个你写在文档里等于提前回答了不写就得当场答答不好前面所有内容都会被质疑。取舍的写法不用很长三句话足够候选有哪几个各自的关键差异是什么在当前约束下为什么选这个。比如消息处理部分考虑过两种做法一种是引入独立的消息队列组件吞吐高但需要额外运维另一种是基于现有数据库做轮询实现简单但延迟较高。考虑到本期日均消息量在万级以内且对方暂无专职运维人员选择后者并在方案中预留了后续替换的接口。 这段话把量级、人员约束、未来扩展都带到了说服力比一句采用成熟方案强太多。5.4 用一张对齐表把痛点、方案点、预期效果串起来写完全部模块后我会回头做一张对齐表放在方案主体章节的末尾。这张表的作用是让读者一眼看出每一条痛都有对应的解法没有遗漏也没有多余的堆砌。编号现状痛点对应方案模块预期改善验证方式P1三系统口径不一致统一取数层月度核对由三天降至半天连续两个月对比核对工时P2审批靠邮件转发流程引擎配置平均卡单时间由两天半降至四小时流程日志统计P3关键节点依赖人工催办提醒与看板超期单据占比降到百分之五以内月度超期率报表这张表看着简单实际写的时候特别能暴露问题。有不少次我列到一半发现某个痛点在正文里没有对应模块或者某个模块找不到它服务的痛点——前者说明方案有缺口后者说明这个模块可能是自嗨得考虑删掉或者说明它的支撑作用。6. 实施、风险与投入让方案从想法变成可签字的承诺前面几章证明的是这个办法对这一章要证明的是这件事办得成。很多方案在这里泄气计划写得像愿望清单风险写得像免责声明投入收益写得像财务预测小说。评审人恰恰最看这一块因为这里藏着他真正要担的责任。6.1 里程碑按可验收的交付物切不要按工种切常见的错误切法是按团队分工切需求阶段、开发阶段、测试阶段、上线阶段。这种切法只对内部有用对读者毫无意义因为他关心的是什么时候能看到东西。正确的切法是按交付物切每个阶段结束时必须有一样能看得见、能验收的东西。比如第一阶段结束交付三条核心流程跑通并完成一轮真实数据验证第二阶段结束交付报表自动生成与人工核对结果一致第三阶段结束交付全员切换旧流程停用。每个交付物都自带验收标准推进过程中也不会出现做完了但不知道算不算完成的扯皮。时间估算上我的经验是每个阶段都留缓冲尤其是涉及对接外部系统的环节。老实写预留两周联调缓冲不但不掉价反而显得有经验。反过来把计划排得严丝合缝、一天不差评审时反而会被质疑你怎么保证。6.2 风险清单写到有人负责、有动作、有触发条件才算数风险章节最怕写成这样本项目可能存在需求变更、人员变动、接口不稳定等风险我们将加强沟通确保项目顺利推进。 这段话一个字的信息量都没有。合格的风险条目应该包含五列风险描述、可能影响、发生概率、应对措施、责任人。用表格呈现最清楚。风险影响概率应对措施触发条件老系统接口文档缺失联调延期高首周安排接口摸底必要时抓包补文档摸底发现三个以上接口无文档关键用户参与度不足需求偏差中每周固定一次业务确认会缺席则升级连续两次确认会无人出席历史数据质量差迁移返工中迁移前先做样本清洗出具质量报告样本错误率超过百分之五写到这个程度风险章节反而成了加分项因为它传递的信息是我们想过最坏的情况并且准备好了。反过来一份通篇没有风险、全是顺利预期的方案稍有经验的人看了都会皱眉。6.3 收益测算宁可保守成本测算必须留余量收益这块最容易写飘。我见过方案里写预计提升效率百分之三百评审时被一句怎么算的问得哑口无言。稳妥的做法是把测算过程摊开先算单个动作节省多少时间再乘上发生频次最后折算成人天或金额每一步的假设都写出来让人能自己复核。比如以单据录入为例改造前平均每单录入耗时四分钟改造后约两分半按日均两百单计算每日节省约三百分钟折合五个人时全年按二百五十个工作日计约节省一千二百五十人时。 这个数比效率提升百分之四十扎实得多因为它可验证即使对方不完全认同也能就某个参数展开讨论而不是全盘否定。成本侧则相反要留余量。人力、外部采购、培训和后期维护这四块都要列到尤其是后期维护很多方案只算建设不算维护对方第二年发现还要持续投入信任度会掉得很快。主动把维护成本写出来短期看是给自己加价长期看是省掉后面的扯皮。6.4 验收标准写清楚等于给双方都上了保险验收标准这一小节经常被省略或者写成系统稳定运行满足业务需求这种没法执行的表述。它的作用是双重的对客户来说知道什么时候算交付完成对实施方来说避免无限期返工。好的验收标准通常包含三部分功能验收看什么关键流程是否跑通用哪批数据验证、性能验收看什么响应时间、并发量、可用性指标的具体数值、文档与培训验收看什么交付哪些文档培训几场多少人参加。每一条都写成可勾选的形式双方签认的时候逐条对对不上就是没完成谁也没法含糊。7. 四种最常见的翻车写法以及具体怎么改写方案的手感是靠改稿练出来的。我把这些年见过最多的四类问题整理出来每条都给出改写思路对照着看比空谈标准有用得多。7.1 满篇形容词找不出一个动词和数字典型症状是高效智能全面一体化深度赋能这类词密集出现一段话读下来气势很足但说不出到底做了什么。这种文风多半是从宣传材料里带过来的。改法很简单把所有形容词划掉逼自己用谁在什么时候做什么、原来要多久、之后要多久的句式重写。写不出来说明这块内容你其实没想清楚或者压根没有实质内容。我给自己定过一条规矩一段话里如果形容词超过两个就重写。执行下来文档厚度通常减三成可读性翻倍。7.2 复制粘贴改个名字就交细节全是模板味这类方案的特征很明显案例部分写的是别的行业的场景图表里的字段名和正文对不上甚至连对方公司的业务描述都不准确。收到这种材料的人第一反应不是写得不好而是你不重视这个事后面再想挽回很难。规避办法有两个。一是所有案例都要换成对方能理解的场景哪怕是自己编的示意数据也要和对方业务沾边。二是交稿前搜一遍全文把可能残留的旧名称、旧行业词、旧数字全部核对一遍。这个动作看着笨但每年都能救回不少人。我自己的习惯是最后通读一遍时专门盯数字和专有名词其他都可以放过这两类错了最伤。7.3 头重脚轻前面讲了三页背景方案只写了两段这种结构在高校背景或者咨询背景出身的写作者身上特别常见习惯了先做宏观分析再落到具体。问题是读者不是来听行业课的他要的是解法。改法是把背景压缩到一页以内只保留和本次目标直接相关的部分其余全部挪到附录或者直接删掉。判断依据是这句话删掉之后后面的方案还成不成立。成立就删。用这把刀砍一遍通常能砍掉一半以上的背景内容。7.4 风险章节写成我们没有风险有些方案出于各种顾虑把风险写得极轻甚至通篇不写。读者不傻越是没有风险的项目描述越让人觉得不真实。真正做过项目的人都知道任何改造都有风险区别只在于有没有提前想好对策。改写思路是把风险当成专业度的展示窗口。挑三到五条真实存在、对方也大概率会想到的风险认真写清影响和对策。写的时候注意措辞重点放在怎么控而不是多可怕。一条好的风险描述读完会让人觉得踏实而不是想打退堂鼓。8. 交稿前的最后一公里自检、排版和口头讲解内容写完了不等于能交。我看过太多底子不错的方案栽在排版混乱、错字连篇、讲的时候抓不住重点上。这一公里不长但决定了前面几公里的努力能不能变现。8.1 一张十分钟能过完的自检清单每次交稿前我都会固定跑一遍下面这几条花了多少时间省下的返工时间往往是它的好几倍。检查项判断标准摘要独立成篇只看前三页能否说清问题、思路、周期、投入痛点与模块对齐每条痛点都有对应模块每个模块都有服务的痛点数字有出处所有关键数字都能说清来源或计算方式边界清晰明确写出本次不包含的内容风险可执行每条风险都有应对措施和触发条件计划可验收每个阶段都有具体交付物和验收标准术语统一同一个概念全文只用一种叫法无残留信息没有旧项目名称、旧行业词、旧数据其中术语统一这条最容易被忽略。同一个东西在方案里一会儿叫数据中台一会儿叫数据底座一会儿叫统一取数层读者会以为是三个不同的东西追问起来很被动。定稿前搜一遍关键词统一成一个说法。8.2 排版是阅读体验的一部分不是装饰排版的目标只有一个让读者能快速找到他关心的部分。具体做几件事就够了摘要单独成页核心结论加粗每章开头加一句本章结论表格统一表头样式数字右对齐重要图表配一句图注说明这张图想表达什么页眉放文档名和版本号页脚放页码。有一个细节值得单独提图表一定要有编号和标题。评审时经常出现刚才那张图再翻回去看一下的情况有编号就能一句话定位没编号就得翻半天。这个成本几乎为零收益很直接。另外版本号和日期务必写清楚。方案是会反复改的没有版本号很容易出现双方拿着不同版本讨论的尴尬场面。我一般用版本号加日期的格式每次修改都更新并在文档开头附一小段修改说明写明这一版改了什么。8.3 讲方案的时候顺序和文档顺序可以不一样如果方案需要当面讲讲法和写法要分开设计。文档是按逻辑顺序写的从问题到方案层层递进但口头汇报的时间通常只有二十分钟必须倒过来讲——先给结论再讲依据。我的讲法一般是四句话开场现在的问题是什么、我们打算怎么做、需要多长时间和多少投入、最大的风险是什么以及怎么控。这四句讲完听众心里有了框架后面再展开细节他们才知道该往哪儿放。展开的时候优先讲对方最关心的那一两个模块其余略过留到问答环节。问答环节有个经验遇到答不上来的问题不要硬编。直接说这一点我需要回去核实明天之前给您书面答复比现场编一个答案然后被追问穿帮要好得多。方案的信任感是靠一次次准确回复积累起来的一次含糊就可能全盘打折。最后分享一个我自己的习惯。每次方案交付之后我会把对方的反馈、评审会上被问到的问题、以及最终落地时和方案不一致的地方简单记在一个文档里。攒上十几份之后回头看会发现被问来问去的就是那么几个点落地走样的也总是那几类环节。下次动笔前先翻一遍这份记录比看任何写作教程都管用因为那里面全是真实的、带着具体场景的教训。