做系统分析师这些年，我翻过不少项目的前期文档，也参加过好几次立项评审会。一个很扎心的现象是：很多项目在技术选型、代码架构上争论得热火朝天，但问到“这个项目到底该不该做、值不值得做”，大部分人反而说不清楚。教材里第十章第7节的“系统可行性分析”讲的就是这件事。它不写一行代码，却能决定一个系统是顺利启动还是中途夭折。备考系统分析师的朋友如果只把这节当背诵点，那就亏了——案例分析考试里，可行性分析出现过不止一次，而且在实际项目里，它其实是帮我们少走弯路的第一道闸门。
这篇文章我把可行性分析掰开揉碎讲一遍，从它在知识体系里的定位，到五类可行性到底怎么落地评估，再到一份能过评审的可行性报告怎么出炉，最后结合案例分析题的踩坑经验，给出一套可以直接照抄的答题思路。不管你是冲刺系统分析师高级资格，还是正在做项目立项准备，这篇文章都值得读完。
1. 可行性分析在系统分析师知识体系中的位置
1.1 教材为什么把10.7放在需求工程这一章
系统分析师教材里，可行性分析内容不多，但位置很关键——它处在需求工程章节的前半部分，紧挨着需求获取。为什么这么编排？因为可行性分析本质上就是需求分析的前置动作。你还没搞清楚用户到底要什么之前，得先回答一个更基础的问题：这个系统有没有可能做成功。
这里要分清两个层面：需求分析回答的是“做什么”，可行性分析回答的是“能不能做、值不值得做”。很多项目失败，不是因为开发人员技术不行，而是因为上马之前没人认真做过可行性判断。我见过一家企业花大半年开发了一套智能制造执行系统，结果上线时才发现一线操作工的电脑配置根本跑不动客户端，硬件升级预算又没批，项目直接烂尾。这个问题如果在可行性分析阶段就被发现，完全可以避免。
教材把这节放在需求工程里，还有一个原因：可行性分析和需求获取是交替进行的。你访谈用户、梳理业务流程的同时，就在不断收集评估可行性的证据。比如用户提出想上AI质检，你要一边记录需求，一边评估算法精度能否满足产线节拍、算力成本是否在预算内。所以它不是独立的一个活动，而是贯穿立项初期的一条暗线。
另外要提醒备考的朋友，教材第二版对这一节的表述比第一版更强调“全生命周期视角”，也就是说可行性分析不只是立项前做一次就完了，后续方案选择、招投标、需求变更时，都要回到可行性维度重新审视。考试如果出概念题，容易在这个地方挖坑。
1.2 可行性分析和需求分析到底谁先谁后
很多刚入行的朋友容易把这两件事混在一起，实际工作中它们有明确的先后顺序，但又互相影响。我的经验是：可行性分析先行，需求分析随后，但两者之间有一次“回旋镖”式的迭代。
为什么要先做可行性分析？因为需求分析的成本不低。你要做用户访谈、业务流程梳理、数据建模、原型验证，每一件事都要投入人力和时间。对于一个在技术上不成立、在成本上严重超支的项目，提前做这些事就是浪费。所以我通常在接到一个系统建设请求时，会先花几天时间做一轮快速可行性判断：技术有没有先例、预算大概什么量级、业务上能不能被接受。这个判断结果会直接决定要不要启动完整的需求调研。
但也不能把顺序理解成铁板一块。很多时候，需求分析做到一半，会发现新的约束条件，比如某个关键业务数据根本采集不到，或者用户期望的操作方式在现有硬件上无法实现。这时候就要回到可行性分析层面，重新评估方案。我习惯把可行性分析当成一个“反复进出”的过程：先粗筛，再细化，最后在需求规格说明书中固化为可行性论证。这也正是系统分析师考试中“综合知识”题目喜欢考察的点——问你会不会根据情境判断应该先做什么。
还有一点值得注意：可行性分析的结论不只是“能行”或“不能行”，还可能得出“有条件可行”。比如技术上可行，但需要采购新的中间件；经济上可行，但必须压缩功能范围。这个“有条件可行”的结论，会直接转化为需求分析阶段的约束条件和假设前提，写进需求规格说明书里。所以严格来说，可行性分析产出的是项目是否继续推进的决策依据，而需求分析产出的是系统到底建设成什么样。两者一个管“生死”，一个管“长相”。
2. 五类可行性的评估方法与落地工具
2.1 技术可行性：别光想能不能做，还要想团队配不配
技术可行性是大家最熟悉的一类，也是误区最多的一类。我见过不少技术负责人拍着胸脯说“这个用某某框架三个月就能做出来”，结果做到一半发现团队里没人懂这个框架的底层原理，遇到问题只能上网搜，进度一拖再拖。技术可行性评估的不是“理论上有没有可能”，而是“在现有条件下能不能实现”。
我一般从三个维度去判断：
- 技术成熟度。这是指技术本身处于哪个发展阶段。成熟技术在行业内已有大量成功案例，风险低；新兴技术有前景但坑多；研究性技术则不应该出现在一个以交付为目标的项目里。判断方法很简单：查一查同行业同规模企业有没有成功案例，看一看社区活跃度、版本更新频率。如果一个框架半年才发一个版本，遇到关键bug可能都没人修。
- 团队技能匹配度。这是最容易被高估的一环。别只看简历上写过某种技术，要看团队是否用它交付过完整项目。我常用的办法是让核心开发人员做一个半天到一天的PoC（概念验证），把项目中最不确定的技术点先跑通。PoC过了，技术可行性才算真正过关。
- 基础设施约束。包括硬件配置、网络环境、第三方系统接口、数据资源等。我遇到过一个典型的反面案例：某单位想上一套视频智能分析系统，算法选型都没问题，但现场网络带宽只有20M，要传4路高清视频根本传不动。这种基础设施约束，在技术可行性评估里必须要纳入考量，否则方案做得再漂亮也是纸上谈兵。
技术可行性评估完，要输出的是明确的风险清单和替代方案。凡是有一项风险等级为高的，都应该在报告中给出备选技术路线，不能把宝押在一个不确定的技术上。记住一个原则：技术可行性要回答的是“我们能不能做出来”，而不是“别人能不能做出来”。
2.2 经济可行性：一套可以直接套用的算账模板
经济可行性是决策层最关心的部分，也是最需要严谨计算的部分。说白了就是算一笔账：投入多少钱，能省多少钱或者赚多少钱，多长时间收回成本。
成本估算要做好两件事：一是不遗漏，二是不拍脑袋。我常用的成本分类包括：
- 一次性开发成本：人力成本、硬件采购、软件许可、机房改造、外部咨询。
- 持续性运行成本：云资源或服务器租赁、运维人力、电费、带宽费、软件年费、数据备份存储。
- 隐性成本：用户培训、数据迁移、业务切换期的并行运行成本、停机损失。
举个例子，假设要给一家中型贸易公司开发一套进销存系统，我去年做的前期测算大致是这样的：
开发阶段投入4名开发人员，周期5个月，人力成本按人均月薪2万算，就是40万；采购一台服务器3万；购买数据库和报表工具许可费2万；外部顾问费5万。一次性开发成本大约50万。上线后每年运维成本：服务器托管费1万，运维工程师兼职支持折合人力成本6万，软件年费2万，加起来不到10万。
效益方面，系统上线后可以减少2名仓库统计员，每人年薪8万，一年省16万；库存周转率提升带来资金占用减少，估算一年省20万；错发货率降低减少赔偿损失，一年约5万。年总效益大约40万。
这笔账算下来，静态投资回收期大概是50万除以40万，也就是1.25年。如果把资金时间价值算进去，用净现值法调整一下，回收期大概会延到1.5年左右。对管理层来说，这个数字就是决策依据。我还习惯在报告里做一个敏感性分析：如果效益只能达到预期的70%，回收期会变成多少？如果开发成本超支20%，又会影响多少？这些数字写出来，报告的分量完全不同。
经济可行性最忌讳的就是只算开发成本，不算运维成本。很多项目上线后发现维护成本高得离谱，就是因为前期没把账算全。
2.3 操作、法律、进度可行性：三个容易翻车的地方
相比技术和经济，操作、法律、进度这三类可行性在教材里着墨不多，但实际翻车概率一点都不低。
操作可行性（也叫运行可行性）评估的是系统上线后，用户能不能接受、能不能真正用起来。你觉得系统再高效，一线操作人员觉得难用、影响他的工作习惯，他就有一万种办法让系统“运行不起来”。我过去做操作可行性判断时，重点看三件事：一是用户的计算机操作水平，二是系统上线对现有工作流程的改变程度，三是管理层有没有决心推动系统落地。有次在一个传统制造企业做系统规划，车间里的老师傅普遍不会用键盘鼠标，操作可行性就打了个大大的问号。后来方案改成触屏加扫码枪，整个交互重新设计，项目才没有死在推广环节。
法律可行性包括系统是否违反法律法规、是否符合行业监管要求、是否涉及知识产权侵权。现在做系统开发，个人信息保护合规、数据出境合规、软件开源许可证合规都是必查项。前两年有个项目想直接拿一个开源协议限制较严格的组件封装到商业系统里，法务一查就发现了问题，差点埋下隐患。这块内容在案例分析题里也经常出现，比如银行类项目涉及金融数据安全，制造类项目涉及工业数据分类分级。
进度可行性评估的是在既定的时间约束下，项目有没有可能按期交付。这里要看资源日历、关键路径、外部依赖。很多项目时间不够宽裕，压缩进度的手段是加人，但加人只能短期提升并行度，并不能让关键路径上的任务缩短。我评估进度可行性时喜欢用倒推法：从目标上线日期倒推，看看设计、开发、测试、试运行、数据迁移每个阶段各要多少时间，哪一段卡死，哪一段可以并行。如果倒推下来时间不够，要么调整上线日期，要么缩小上线范围，这两个选项必须在可行性报告里明确写出来。
3. 一次完整可行性分析的实操流程
3.1 分析前的准备：范围界定与访谈提纲
很多人把可行性分析理解成“写一份报告”，实际上它是一个包含准备、调研、分析、论证的完整过程。准备工作做不好，后面的调研和分析都会跑偏。
第一步是界定范围。你要明确这次可行性分析针对的是什么：是一个全新的系统，还是现有系统的改造升级？是业务系统建设，还是技术平台搭建？范围界定的输出是“系统建设目标”和“主要约束条件”。我习惯让业务方的负责人用三句话讲清楚目标：为什么要做这个系统、做完之后业务上有什么变化、半年后和一年后分别希望看到什么效果。如果对方说不清楚，说明需求本身还不成熟，可行性判断就要更保守。
第二步是制定访谈提纲。访谈对象至少要覆盖三类人：决策层（问目标、预算、期望）、业务执行层（问流程、痛点、工作量）、技术运维层（问现有系统结构、数据、基础设施）。访谈提纲不能太开放，否则聊一小时也抓不住重点。我会预设一些“验证性问题”，比如“如果新系统上线后你仍然需要用Excel处理数据，你能接受吗”“月结时系统处理时间超过30分钟可以接受吗”，这种问题能快速探测用户的真实底线。
第三步是收集背景材料。包括现有的业务流程文档、表单、统计报表、硬件资产清单、网络拓扑、已采购的软件清单。这些材料能帮你判断现有系统的运行状态和改造代价，也能为技术可行性提供依据。
3.2 信息收集与方案比选：用矩阵打分代替拍脑袋
准备阶段完成后，进入信息收集和方案比选环节。这个环节的核心是“不要只有一个方案”。不少项目一上来就默认要自研，或者默认要外购，其实都忽略了方案比选这一步。
我常用的做法是先把可行的候选方案列出来，至少两到三个。比如一个进销存系统，方案A是采购成熟商用产品做二次开发，方案B是基于开源框架自研，方案C是租用SaaS服务。然后从技术、经济、操作、进度四个维度分别打分。
打分时要注意权重设置。不同项目的关注点不同：一家重视快速交付的公司，进度维度的权重可以高一些；一家现金流紧张的公司，经济维度的权重就要提升。我自己习惯用一个4xN的矩阵，行是方案，列是技术可行性、成本、上线周期、用户接受度、维护难度，每列按1到5打分，再加权求和。比如：
- 商用产品方案：技术4分、成本4分、进度5分、维护4分——适合快速上线。
- 开源自研方案：技术3分、成本5分、进度2分、维护3分——适合长期迭代。
- SaaS方案：技术4分、成本5分、进度5分、维护3分——适合中小团队轻量使用。
把矩阵结果放到评审会上讨论，比单纯靠“我觉得”要靠谱得多。方案比选还有一个隐藏价值：它能帮你提前发现某些方案在法律或数据安全上的硬伤，比如SaaS模式数据存放在境外，可能不满足合规要求，直接一票否决。
3.3 可行性分析报告的写法：结论先行，论证闭合
可行性分析报告的结构比较固定，我一般按这个骨架来组织：
- 引言：项目背景、分析范围、分析依据。
- 现行系统描述：当前业务流程、系统现状、存在的核心问题。
- 建议系统方案：目标系统概述、核心功能范围、拟采用的技术路线。
- 可行性论证：按技术、经济、操作、法律、进度五个方面逐一展开。
- 方案比选：记录候选方案和选择理由。
- 结论与建议：明确的决策建议和后续行动计划。
写报告最忌讳的是结论含糊。很多人写到最后来一句“项目基本可行，建议进一步论证”，这种话等于没说。我给报告定结论时只用三个词：可行、不可行、有条件可行。如果是“有条件可行”，必须逐条列出前置条件，比如“需要在预算中增加100万用于硬件扩容”“需要等新版本中间件发布后才能启动开发”。条件列得越具体，后续的执行就越扎实。
经济可行性部分的表格一定要写清楚计算过程和假设依据，不能直接扔一个回收期数字。我在报告里通常会附上成本明细表和效益测算表，把每一条金额的来源都标注出来，这样评审会上有人质疑数字时，能马上找到依据。技术可行性部分，要把PoC验证的结果附上，截屏、测试数据、结论都放进去，这比空口说“我们认为没问题”有说服力得多。
4. 案例题里的常见陷阱与备考要点
4.1 案例分析题最常考的可行性问题
系统分析师考试的案例分析题，经常会给一个信息系统建设场景，要求你分析项目存在哪些问题，或者对某个方案进行可行性评价。这种题表面看是考需求分析，实际上很多得分点都落在可行性分析上。
我梳理了一下近几年考过和常见的出题模式，大致有三类：
第一类是“场景找茬型”。题干描述一家企业要建设某个系统，但字里行间埋了很多雷。比如：技术选型用了一个刚开源半年的框架（技术可行性存疑）；预算只算了软件开发和硬件采购，没算数据迁移和培训（经济可行性测算不完整）；业务人员强烈抵触新系统（操作可行性不足）；没有考虑行业监管对数据的特殊要求（法律可行性缺失）。这类题考察的就是你能不能把潜伏的可行性问题识别出来。我的经验是，凡看到“客户要求三个月内上线”“团队从未用过该技术栈”“现有网络条件较差”这类表述，都要高度敏感，一条条对应到五类可行性上去。
第二类是“方案评价型”。题干给出两个或多个候选技术方案，让你从可行性的角度进行比选。这种题考的是方案比选的逻辑性。答题时要有框架：技术成熟度、团队能力匹配度、初期成本、长期运维成本、上线风险、用户接受度、法律合规性，一个一个维度去对照。不能只是说“方案A更好”，要给出每个维度的比较和权重逻辑。
第三类是“追加判断型”。题目说系统开发到一半，业务方提出增加一个新功能，或者项目进度严重滞后，让你决定下一步怎么办。这类题的实质是“可行性分析要动态跟进”——原来可行的方案，在新约束下可能变得不可行。答题要点是重新评估工期、成本、技术风险三个维度，给出明确的取舍结论，比如延期上线、缩小范围或增加预算。
4.2 答题套路与备考心得：避开这些坑能多拿分
案例分析题是主观题，卷面结构往往比内容还重要。我批改过不少模拟卷，发现大家失分主要是三个原因：答案要点不完整、要点之间逻辑混乱、没有结合题干信息。
答题时我建议用“分维度作答”的方式。比如题目问你可行性方面有什么问题，你就分列技术可行性、经济可行性、操作可行性、法律可行性、进度可行性五个标题，每一条后面用题干中的具体表述做佐证。例如：
技术可行性方面：该方案采用了目前尚未大规模商用的组件（结合题干），且开发团队此前没有相关项目经验，存在较大技术风险。
经济可行性方面：预算仅包含开发费用，未估计数据库迁移和人员培训成本（结合题干），可能导致项目上线后总成本严重超支。
这样写的好处是：评分老师一眼就能看到你覆盖了几个维度，给分点一目了然。哪怕某一个维度的判断不够精准，其他维度的得分也能保住。
备考时有一个很有效的办法：把教材里可行性分析的五类维度做成一张速查表，每类下列两个“信号词”。比如技术可行性对应“新技术”“经验不足”，经济可行性对应“预算”“成本”“回收期”，操作可行性对应“抵触”“培训”“接受度”，法律可行性对应“合规”“数据安全”“授权”，进度可行性对应“节点”“并行”“资源”。做题时拿着信号词去题干里扫，命中一条就写一条，基本不会漏掉大方向。
还有个小技巧：案例分析题答题时数字不一定准确，但一定要有。就算你不会精确计算回收期，也要写出“回收期约X年”的评估思路，并说明计算涉及的变量。评分老师看到你有成本效益意识，这部分分就拿到了。最怕的是“该方案经济上可行”一句话就结束，没有任何计算支撑，这在阅卷时会被当作无效作答。
最后分享一个我备考时踩过的坑。有一年做模拟题，题目场景是做一套医疗信息系统，我当时只写了技术和经济维度，结果标准答案里重点竟然在隐私合规和医生操作习惯上。从那之后我养成了一个习惯：拿到任何一个案例，先强制自己把五类可行性全部过一遍，再考虑哪些是重点。这套思维在后来真实项目的评审会上也帮了我大忙，因为提案方容易遗漏的地方，恰好就是评委最爱提问的地方。
我在实际工作中做可行性分析，最深的体会是：它不是为了证明项目能做成，而是为了在投入大量资源之前，把“不能做”或“不该做”的原因找出来。一个成熟的系统分析师，应该有勇气在报告里写下“结论：不可行”这几个字。这比硬着头皮把一个注定失败的项目推进下去要有价值得多。备考的人把这节学透，答题时会轻松；从业的人把这节用好，立项时会少踩很多坑。
