做系统分析师这些年我翻过不少项目的前期文档也参加过好几次立项评审会。一个很扎心的现象是很多项目在技术选型、代码架构上争论得热火朝天但问到“这个项目到底该不该做、值不值得做”大部分人反而说不清楚。教材里第十章第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年”的评估思路并说明计算涉及的变量。评分老师看到你有成本效益意识这部分分就拿到了。最怕的是“该方案经济上可行”一句话就结束没有任何计算支撑这在阅卷时会被当作无效作答。最后分享一个我备考时踩过的坑。有一年做模拟题题目场景是做一套医疗信息系统我当时只写了技术和经济维度结果标准答案里重点竟然在隐私合规和医生操作习惯上。从那之后我养成了一个习惯拿到任何一个案例先强制自己把五类可行性全部过一遍再考虑哪些是重点。这套思维在后来真实项目的评审会上也帮了我大忙因为提案方容易遗漏的地方恰好就是评委最爱提问的地方。我在实际工作中做可行性分析最深的体会是它不是为了证明项目能做成而是为了在投入大量资源之前把“不能做”或“不该做”的原因找出来。一个成熟的系统分析师应该有勇气在报告里写下“结论不可行”这几个字。这比硬着头皮把一个注定失败的项目推进下去要有价值得多。备考的人把这节学透答题时会轻松从业的人把这节用好立项时会少踩很多坑。