不可行性分析报告模板

去年秋天，我参与了一个内部工具的行性开发评审。团队花了三周写了一份“可行性分析”，分析结论是模板“技术路径清晰，资源匹配，不可报告建议立即启动”。行性结果呢？分析两个月后项目搁浅，核心原因是模板他们压根没认真写“不可行性分析”。那份可行性报告里所有“风险”都被轻描淡写地归入“待解决事项”，不可报告没人敢说“这事可能根本做不成”。行性

所以我现在写任何方案，分析第一页永远是模板“不可行性分析”。不是不可报告唱反调，是行性先把最要命的障碍摆出来，省得后面浪费感情。分析下面这个模板，是我自己踩坑后攒出来的，不保证全面，但保证每一条都来自真实翻车现场。

一、先写“死因”，别写“风险”

“风险”这个词太温柔了。风险意味着“可能发生，可以缓解”。不可行性分析要写的是“死因”——那些一旦成立就直接让项目归零的条件。比如：

• 技术死因：核心依赖的某个库已经两年没维护，且没有替代品。这不是风险，这是定时炸弹。
• 法律死因：数据采集方式直接违反《个人信息保护法》第13条，没有模糊地带。
• 经济死因：单位获客成本算下来是LTV的3倍，且模型里没有任何变量能扭转这个比值。

写死因的时候，不要用“可能”“或许”“在一定程度上”。直接写：“如果X成立，项目立刻停止。”我见过最实在的一份报告，第一句话就是：“本方案在现有预算下，无法在12个月内产出可演示原型，因此不建议启动。”

二、把“假设”单独列一节，逐条标注可信度

任何方案都建立在一堆假设上。不可行性分析的核心工作，就是把这些假设挖出来，然后问一句：如果这条假设是错的，方案还成立吗？

我习惯用表格，但这里用文字说更清楚。比如做一个社区团购工具，假设可能包括：

1. 团长愿意每天花20分钟操作后台（可信度：中。实际测试中，超过60%的团长第三天就嫌烦）
2. 供应链能支持次日达（可信度：低。本地供应商只有三家，其中两家没有冷链）
3. 用户对价格敏感度高于便利性（可信度：高，但只限于生鲜品类）

每条假设后面，直接写“如果这条不成立，则……”。不要写“需要进一步验证”，那是废话。写“如果团长不愿操作，则整个模式退化为电话订货，工具价值归零”。

三、算“最坏情况下的代价”，而不是“预期收益”

可行性分析喜欢算ROI，算NPV，算内部收益率。不可行性分析只算一件事：如果这事彻底失败了，我们损失什么？

损失分四层：

• 直接成本：已经花掉的钱、人力、服务器费用。这个最好算。
• 机会成本：同样的团队做另一个项目，最差能拿到什么结果？把那个结果当作基准，而不是零。
• 沉没成本陷阱：团队会不会因为“已经投入这么多了”而继续追加？如果会，把追加部分也提前算进最坏情况。
• 隐性代价：技术债、团队士气、对外信誉。这些东西没法量化，但必须写出来。比如“如果失败，核心开发可能离职，招聘替代者需要至少两个月”。

我见过一个反面教材：某SaaS创业公司做不可行性分析时，只写了“最坏情况损失50万”。但实际失败后，因为签了对赌协议，赔了200万，加上团队解散的遣散费，总共超过300万。他们漏掉了法律条款里的连带责任。

四、给出“停止条件”，而不是“里程碑”

可行性报告喜欢设里程碑：Q1完成原型，Q2上线内测。不可行性分析要设的是“停止条件”——满足什么条件就必须砍掉项目，不许找借口。

停止条件必须可观测、可量化、无歧义。举几个例子：

• 如果原型在第三次迭代后，核心接口响应时间仍大于800ms，停止。
• 如果前两周地推转化率低于0.5%，停止。
• 如果关键专利检索显示已有高度相似的在先申请，停止。

注意，停止条件不是“如果效果不好就停”，那是耍流氓。要写清楚谁来判断、什么时候判断、依据什么数据。我自己的习惯是：每个停止条件后面跟一个负责人名字和检查日期。没人负责的条件等于没写。

五、最后写一段“如果非要干，最少需要什么”

不可行性分析不是让你当缩头乌龟。它的终点是：如果所有死因都能被绕过，或者你愿意接受最坏代价，那最少需要什么条件才能启动？

这一段要极其具体。比如：“如果非要干，需要：1）换用某款已停产的芯片库存，但只能支撑500台；2）找到一家愿意接受对赌的供应商；3）CTO亲自带队，且暂停其他所有项目。” 写完之后，决策者自己就能判断值不值。

我现在的习惯是：任何方案，先写不可行性分析，写满一页A4纸。如果写不满，说明我还没想清楚。如果写满了但每一条都有明确解法，那再写可行性报告也不迟。顺序反过来，大概率是自我催眠。