1. 可行性研究不只是走流程，它决定了项目是省百万还是亏百万
做软件系统的人多少都有过这种经历：领导一句话“这个系统我们要上”，团队就闷头开始写代码，结果做到一半发现预算不够、技术栈选错、业务部门根本不买账，最后项目烂在手里，谁也说不清当初为什么要做。我干了十多年软件项目，见过太多这样的烂尾项目，问题根源往往不在开发阶段，而在更早的地方——没有认真做可行性研究。
所谓可行性研究，就是在动手之前，用最小的成本回答一个最核心的问题：这套软件系统到底该不该建？该按什么方案建？建了能不能收回成本？很多团队把可行性研究当成一个应付流程用的文档，随便抄模板一两页纸就交差，这完全是用形式主义掩盖战略失职。真正合格的可行性研究，能帮你在一个项目还没烧钱的时候就判断出它值不值得做、怎么做风险最小，它是整个软件生命周期里性价比最高的一环。
这篇文章我会把可行性研究的完整步骤、每个环节怎么落地、里面的计算口径怎么定、报告怎么写才有人听，以及我在这条路上踩过的坑，一次性讲透。不管是刚入行的项目经理、转型做产品的开发，还是带团队的负责人，看完基本就能照着套用。这套方法论不一定能保证你每个项目都成功，但它能帮你避开那些注定要失败的项目。
1.1 为什么必须做可行性研究：省下的不只是钱
很多人觉得可行性研究就是算笔账，看看赚不赚钱，其实它解决的问题远不止钱。
首先是技术层面的验证。有些系统看着简单，真做起来技术难度超出团队能力。比如我曾遇到一个项目，要做一个实时数据处理平台，老板觉得“这不就是个报表系统嘛”，但等我们评估下来，数据量每秒几万条、延迟要求毫秒级，现有团队根本没有流式计算经验，硬上的话光磨合期就得三个月。可行性研究能帮你提前发现这类技术悬崖，还能用原型验证的方式在写正式代码之前试探深浅。
其次是资源层面的匹配。系统开发不是光有程序员就行，还要有业务专家配合梳理流程、有运维人员保障部署、有测试人员把质量关。很多项目立项时只算了开发人力，忽略了业务方要投入的时间，结果开发做到一半才发现业务接口人不配合，需求反复变更，工期一拖再拖。可行性研究阶段把资源账算清楚，能避免这种“隐性成本”。
再往深处说是战略层面的校准。有些系统技术上能做、资源也够，但它和公司的战略方向并不匹配。比如一家做传统零售的公司，非要自研一套社交电商平台，技术上完全可行，但运营能力、用户获取成本、平台生态完全是另一套玩法，这就不只是技术问题而是战略问题了。可行性研究里有一个重要动作，就是跳出“能不能做”去问“该不该做”。
这也是为什么我把可行性研究放在项目最前面的原因。它不是一道可有可无的流程关卡，而是一道安全阀。把错的方向在图纸阶段就拦下来，成本可能只是几万元的外协调研费和几周的投入；等代码写完了再发现方向错了，烧掉的就是几百万的真金白银和团队半年的士气。
1.2 可行性研究五大维度：一张表理清评估框架
软件系统可行性研究在业内其实已经有成熟框架，不管项目大小，核心都是五个维度：技术可行性、经济可行性、运营可行性、时间可行性、法律与合规可行性。我给很多团队做培训时发现，大家最容易漏掉的是后两者，而恰恰是这两个维度常常让项目翻车。
技术可行性，解决的是“做得出来吗”。要评估现有技术方案能不能满足需求、团队有没有对应技能、基础设施是否具备、关键技术指标是否可达。说白了就是给技术方案做一次压力测试。
经济可行性，解决的是“做得值吗”。要算清楚整个系统生命周期内的总成本（建设成本加运维成本）和总收益（直接收益加间接收益），得出投入产出比。这一块是可行性研究的重中之重，也是很多项目写不明白的部分。
运营可行性，解决的是“用户买账吗”。系统做出来，业务人员愿不愿意用？能融入现有工作流程吗？会不会造成额外的管理负担？很多系统死亡不是因为技术烂，而是因为用户不肯用。这一条需要跟真实的业务方访谈，不能坐在办公室里拍脑袋。
时间可行性，解决的是“赶得上吗”。系统上线有窗口期，比如配合某项业务活动、法规生效日或者财年节点，你评估的方案能不能在这个时间约束内完成。如果不能，就得重新定义项目范围或者放弃。
法律与合规可行性，解决的是“能碰吗”。涉及数据处理要符合相关法规，涉及支付要有相应资质，涉及行业系统要满足行业标准。这一条如果违反，系统做得再好也可能被叫停。
这五个维度不是并列关系，而是环环相扣的评估链条。技术上做不出来，经济账就不用算了；技术上能做，但经济上不划算，方案就得调整；技术、经济都过关，但用户不认可，依然不能启动。我在实际操作中习惯用一张评估表把这些维度串起来，每个维度下再拆具体指标、判断标准、数据来源、风险等级，这样整个可行性研究的骨架就立住了。
2. 可行性研究五步法：从接到任务到输出结论的完整路径
光知道五个维度还不够，关键是怎么一步步落地。我在实操中把可行性研究拆成五个步骤，每步都有明确的输入、动作和输出。这套流程我用了很多年，在十几个项目上验证过，不敢说适合所有场景，但覆盖了绝大多数软件系统的评估需求。
五步分别是：现状调研与约束盘点、候选方案定义与技术预研、经济可行性测算、风险评估与量化、编写可研报告并输出结论。每一步的工作量可以按项目规模伸缩，小项目可能一天走完，大项目可能要两三个月。下面我逐个拆解。
2.1 第一步：现状调研与约束盘点
这一步的输入是项目背景和初始需求，输出是一份《现状调研简报》和一份《约束清单》。
很多团队跳过了泛泛的“摸底”就直接进入方案设计，这是大忌。你不了解现状，设计出来的方案就是空中楼阁。现状调研至少要做三件事：一是访谈关键干系人，包括业务方、管理层、一线操作员，搞清楚他们要什么和他们的痛点是什么；二是调研现有系统与流程，摸清系统当前的运行状态、性能瓶颈、数据分布、接口关系；三是研读相关文档和历史资料，比如之前做过的需求文档、运维记录、用户反馈，这些里面藏着很多前人造好的轮子和埋好的坑。
约束盘点是我特别想强调的一步。约束分四类：时间约束（什么时候必须上线）、预算约束（最多能花多少钱）、技术约束（必须兼容什么旧系统、必须部署在什么环境）、组织约束（业务方能投入多少人力配合）。把这四类约束列成清单，后续所有方案评估都在这个框子里进行。没有约束清单就谈方案，就像没有边界条件就解方程，能解出一百个答案，但没有一个可落地。
这里还要做一件很多人忽略的事：可行性研究本身的边界界定。你要清楚这次研究是覆盖整个系统的全面评估，还是只针对某个关键点的专项预研。边界定得太宽，研究周期过长，还没研究完市场机会就过去了；边界定得太窄，可能漏掉关键问题，结论的可靠性就打折扣。我一般建议用“二八原则”来框定范围：抓住影响项目成败的核心20%要素重点研究，其余部分用快速判断带过。
2.2 第二步：候选方案定义与技术预研
现状摸清了，约束也清楚了，接下来要做的是把“一条路走到黑”变成“几条路选最优”。
这里要说个常见误区：很多人做可行性研究只出一套方案，然后为核心方案找各种理由背书。这不是研究，这是自我说服。正确的做法是至少准备两到三个具备显著差异的候选方案，让决策层有的选。我常用的方案差异化角度有三种：第一种是建设方式差异，比如自研、外购、混合开发；第二种是技术路线差异，比如单体架构、微服务架构、低代码平台；第三种是范围差异，比如一步到位全量建设还是分阶段迭代。三个方案可以两两组合，但没必要太多，太多会分散研究精力。
方案定义之后，核心动作是技术预研。技术预研不等于查文档，而是要动手验证关键技术风险点。比如方案里要用某个开源中间件支撑高并发，你就得搭个最小环境跑个压测；方案里要跟某个老旧系统做对接，你就得调通接口确认数据格式和性能。我做过最有效的一次预研，是在两周时间内做了三个技术原型的验证，最终否定了两个看上去很美的方案，避免了团队上线后的大返工。
预研的产出是一份《技术可行性评估表》，内容包括：每个方案的技术实现难度、关键指标预估值、团队技能匹配度、第三方组件成熟度、需要补学的新技术清单。这张表是后续经济测算的输入，因为技术难度直接决定人力成本，第三方组件成熟度直接决定采购费用和风险成本。
2.3 第三步：经济可行性测算：成本与收益的算法
经济可行性是可行性研究里最硬核、也最容易扯皮的部分。扯皮的原因通常不是算得不对，而是口径不一致。你算的成本和财务算的成本不是一回事，你估的收益和业务方期望的收益对不上，那结论肯定打架。所以我先把口径问题说清楚。
成本侧要算总拥有成本 TCO（Total Cost of Ownership），不只是建设期的一次性投入，还要算未来三到五年的运维成本。TCO通常包含六块：硬件与云资源采购费用、软件许可或订阅费用、开发人力成本、测试与上线成本、培训与推广成本、长期运维与升级成本。这里最容易被低估的是运维成本，很多系统建设期花了100万，每年运维又要吃掉30万，三年下来总成本接近200万，比预算多了整整一倍。
我习惯用一张成本测算表把各项列出来，每项都有计算依据和取值说明。人力成本按“人月单价 × 投入人月数”来算，人月单价一定不要取纯工资，要包含五险一金、办公成本、管理分摊，通常按工资的1.4到1.6倍来折算，这个系数我踩过坑，低估人力单价会让整个成本测算失真。云资源费用按“规格 × 数量 × 时长”来算，千万别忘了网络带宽和存储这三块往往占比最高的细项。
收益侧分直接收益和间接收益。直接收益是可以量化的钱，比如系统上线后减少的人力工时、提高的吞吐量带来的销售收入、降低的错误率减少的赔付。间接收益不太好量化，比如客户体验提升、品牌形象改善、数据资产沉淀，这类收益可以定性描述，但不要硬塞进ROI公式里凑数字。如果间接收益占比过高，本身就是个危险信号，说明项目的经济模型不够扎实。
计算指标上，我最常用的是投资回收期和投入产出比 ROI。投资回收期 = 累计投入总额 ÷ 年化净收益，它回答的是“多久能回本”；ROI =（总收益 - 总成本）÷ 总成本 × 100%，它回答的是“每投一块钱能赚多少”。另外推荐做一个三年期的现金流量表，把每年的投入和收益逐项列出来，折现率按公司的资金成本取，这样能算出净现值 NPV，比单纯看累计值更科学。
这里要特别提醒，经济测算一定要做敏感性分析。什么叫敏感性分析？就是把最不确定的参数分别往乐观和悲观方向调整，看看结论会不会翻转。比如核心收益参数“预计提升30%效率”如果实际只能做到15%，项目还划算吗？运维成本如果上浮20%，回收期要多长？如果参数稍微一波动结论就变成亏损，那这个项目的经济可行性就非常脆弱，决策时要格外谨慎。我通常选三到五个关键参数做敏感性分析，输出一张结论区间表，这份表在给高层汇报时特别有说服力。
2.4 第四步：风险评估与量化
做完可行性分析，还要把风险摆到桌面上。很多人觉得风险评估就是列一堆“可能存在的风险”，写成那种永远正确的废话清单，这事就算干完了。真正有用的风险评估要回答三个问题：风险发生的概率有多大？一旦发生影响有多严重？我们能用什么措施来降低概率或减轻影响？
我把软件系统可行性阶段的风险分为五类：技术风险、进度风险、成本风险、业务采纳风险、外部依赖风险。技术风险比如核心算法不达标、第三方服务突然变更收费模式；进度风险比如关键人员离职、需求蔓延导致工期失控；成本风险比如硬件价格波动、外包报价超出预算；业务采纳风险比如业务流程改造阻力大、一线员工抵触新系统；外部依赖风险比如某些数据源接口关闭、合作方系统宕机。
每个风险项都要做概率和影响的二维评估。我习惯用1到5分制，概率分为“很低、低、中、高、很高”，影响分为“可忽略、轻微、严重、致命、灾难性”。概率乘以影响得到风险值，风险值高的项目一定要有应对预案，没有预案的高风险项应该在结论里明确指出“需要决策层确认接受还是放弃”。
风险评估带来的一个直接产出是“风险准备金”。在成本测算里，除了确定性成本，还要按风险敞口留一笔风险准备金。这笔钱不是乱花的，而是为了应对那些概率不高但影响很大的风险事件。我一般建议风险准备金按总成本的10%到20%计取，具体比例根据风险矩阵结果调整。很多项目预算没有这笔钱，出了问题只能东挪西凑，最后拆东墙补西墙，项目一塌糊涂。
2.5 第五步：可研报告编写与结论分级
所有分析和测算做完，最后落到一份可研报告。报告写给谁看很关键，是写给业务决策层看，不是写给技术人员自我欣赏。所以报告里技术细节要收敛，核心结论要前置，数据图表要直观。
报告的标准结构我总结为六段式：背景与目标说明、现状分析与问题定义、候选方案描述与对比、经济与风险评估、结论与建议、附件与支持材料。这里要强调一个写作技巧：结论先行。把最终建议放在前面，决策层打开第一页就能看到“建议采用方案A，总投资约XX，回收期约XX，主要风险为XX”，然后再找支撑依据。很多人写报告像写小说，前面铺垫一大堆背景，到最后才揭晓结论，这在商业文档里是大忌。
结论分为三档：建议实施、条件实施、不建议实施。建议实施意味着综合评估通过，可以进入立项和详细设计阶段；条件实施意味着大方向没错，但存在必须满足的前提条件，比如业务方承诺某个资源到位、某个技术验证必须在特定日期前完成；不建议实施意味着项目当前环境下不具备可行性，需要重新定义目标或等待条件成熟。三档结论都要给理由，但切忌在报告里堆砌模糊词汇，每条理由都要能对应到前面的分析数据。
我处理过不少“老板一心想上但测算结果不理想”的项目，这时候结论写作要格外讲究艺术。不要用激烈的措辞否定项目，而是要用数据和方案去引导决策。比如“该方案在当前市场环境下经济性较弱，若能将建设成本压缩30%或聚焦到特定业务场景，可行性将显著提升”，既陈述了事实，又给出了建设性方向。这种写法既保证了评估的独立性，又维护了决策层的体面，项目后面真调整了范围再启动，反而更容易成功。
3. 实操中的关键细节：这些坑我正在帮你踩
步骤讲完了，但光知道步骤远远不够。我在实操中积累了一些细节和技巧，这些是课本上不会写的内容，但对结果影响非常大。这一节我挑三个最重要的讲：调研访谈怎么做才有效、方案对比怎么避免屁股决定脑袋、报告的数据呈现怎么让决策层一眼看懂。
3.1 调研访谈技巧：别让被访谈者给你“标准答案”
访谈是可行性研究信息获取的主渠道，但访谈很容易变成走过场。业务部门的人面对外部或项目组的人来访谈，通常会给出你“想听的话”或者说“不犯错的话”，你得有技巧地把真实信息挖出来。
我的经验是，访谈问题不能太抽象，要尽量具体并要求举例。你问“你们现在的流程有什么痛点”，对方多半会回答“流程还行，就是系统有点慢”。你要是换个问法，“你上个月在处理订单的时候，有没有哪一单让你印象特别深、花了特别久？当时发生了什么？”通常就能挖出具体业务场景下的真实问题。再比如问“这个功能你们多久用一次”，不如问“你上周操作这个模块大概几次，每次操作要多久”，具体数字比模糊描述可靠得多。
访谈对象的覆盖面也要讲究。除了找业务负责人，一定要找一线操作人员聊。负责人看到的往往是“流程应该怎么样”，而一线员工知道的是“流程实际怎么样”，两者经常有冲突。我有个项目，业务负责人信誓旦旦说新系统接入后审批能缩短到一天，结果一线操作员告诉我，他们手里积压了几百个待审批单，系统再快也没用，瓶颈根本不在系统而在人手。这种信息你坐在会议室里是永远听不到的。
访谈记录也很重要。每次访谈后当天整理访谈纪要，把关键结论、引用的数据、存疑事项分列出来。积累到一定数量后做一次交叉验证，看看不同角色描述里的矛盾点，这些矛盾点往往就是最需要设计方案去解决的核心问题。
3.2 方案对比的正确姿势：先定标准，再评方案
候选方案出来的下一步是比选。很多人比选的方式是心里先有一个偏好方案，然后设计一套评分表让偏好方案得最高分。这不叫比选，这叫表演。
正确的做法是，先跟决策层和关键干系人确认评估标准，再拿标准去套所有方案。标准要尽量可量化，比如建设成本、工期、运维复杂度、风险等级。如果非要用定性指标，也要给出可判断的锚点，比如“运维复杂度”定义成“日常运维需要专职人员X人以上为高，X人以下为低”，不要让人凭感觉打分。
我常用的比选工具是一张权重评分表，四到六个评估维度，每个维度按重要性加权，最后算出加权总分。权重不是谁拍脑袋定的，而是要在评估启动前跟决策层开一次会，花半小时把权重锁定下来。一旦权重确定，后面就只做客观评分，不再讨论权重合理性，这样才能避免在收获环节扯皮。权重分配有讲究，我给大多数项目的建议是：经济权重30%、技术权重25%、运营采纳20%、风险15%、时间10%，但具体项目要动态调整，以项目目标为准。
还要警惕“方案漂移”。评估过程中，随着信息越来越丰富，不同方案的支持者会不断往里加新需求、新条件，使得原本清晰方案变得越来越面目全非。应对办法是设一个评估基准日，基准日之后新的重大信息，原则上不进入当前评估，而是记录在案留待下一阶段。这样才能保证比选能在可控范围内收敛，否则会陷入永无休止的方案调整循环。
3.3 数据呈现技巧：一张好图胜过一个会议
可研报告里的数据呈现，直接决定决策层愿不愿意继续往下听。你在Excel里算得天花乱坠，到PPT上变成密密麻麻的表格，领导看一眼就不想再看第二眼，你的研究结论就白做了。呈现的本质是降低信息接收成本。
成本构成我建议用堆叠柱状图，不同颜色代表不同成本板块，一眼能看出钱花在哪。三年现金流量表用表格配折线图，让曲线的趋势和拐点一目了然。方案对比用横向条形图或雷达图，权重不一样时用加权后的得分对比。风险矩阵直接画一个九宫格，横轴是影响，纵轴是概率，每个风险点是一个圆圈，大小代表风险值。这种图材料专业，决策层一看就知道哪些地方是雷区。
最怕的是把报告写成论文，全是文字描述，没有图表。文字密度过高会让决策层失去耐心，很可能只翻最后一页结论。所以我在报告编排上坚持“一图胜千言”的原则，凡是能用图表表达的内容绝不用文字重复。每个关键结论旁边配一个小图表，汇报时指着图说结论，效果远好于念PPT。
敏感性分析的结果我通常做成一个区间图，把关键参数的乐观、基准、悲观三种取值对应的项目收益分别标出来。这张图的冲击力最强。有一回我汇报一个项目，对比了“开发效率提升30%”和“只提升10%”两种场景下的回收期差异，领导看完整个人都不好了，当场拍板把项目范围绕回最核心的部分。这就是数据呈现的力量。
4. 常见问题与排查技巧：我踩过的坑和这套方法论救回的项目
再好的方法论，落到实践中都会遇到问题。这一节我不讲理论，全部讲真实发生过的案例和使用技巧。你读完会发现，很多看起来是技术问题或者管理问题的项目危机，根子都在可行性研究阶段埋下了隐患。
4.1 一个被可行性研究救回来的项目实录
有家做供应链服务的客户，要上一个全渠道订单管理系统，目标是整合线上电商、线下门店、分销商三类订单来源。启动时老板很兴奋，要求半年内上线，预算报了300万。技术团队也觉得没问题，毕竟订单系统是成熟领域，市面上参考产品很多。
我在可行性研究阶段先做了现状调研，结果发现了三个关键事实：第一，线下门店的订单录入依赖POS机，而POS机来自三个不同的老旧品牌，接口文档早已遗失，数据格式靠逆向工程，这一项至少得预留四到六周；第二，分销商那边说好“配合接入”，实际上他们用的是自己内部系统，数据接口标准完全不一样，业务部门表态“要他们改造得商务谈判”而不是技术问题；第三，电商平台的订单峰值出现在大促期间，量级是平时的20倍，按峰值设计成本会大幅超出预算。
如果按原计划硬干，半年内根本不可能上线，就算勉强上线也只能覆盖线上电商这一个渠道，另外两个渠道照样手工操作，300万打了水漂不说，业务矛盾还会积压。
我们把方案拆成两组来对比：方案A是全渠道一步到位，方案B是分阶段实施，第一阶段只做线上电商渠道统一，第二阶段接入门店，第三阶段再攻坚分销商。经济测算结果很清楚：方案A预测投资回收期长达两年半，而且存在重大交付超期风险；方案B回收期只要一年，第一阶段四个月就能上线见效，还能用产生的收益去支撑后面阶段的建设。
最终客户选了方案B，项目按时上线，线下接口后来用了一个第三方适配中间件解决，分销商则在商务谈判达成后做了二期接入。回头看，如果当初没有做可行性研究，这个项目最好的结局也是延期加超支，最差的结局是彻底烂尾。这就是可行性研究的价值：它不需要保证你选的路一定对，但它能拦着你走那条明显是死路的路线。
4.2 高频踩坑点与排查清单
下面这些坑是我在多个项目里踩过或者见过同行踩的，整理成一个排查清单，你在做可行性研究时挨个对照就行。
第一，需求方给出的数据严重乐观。业务方说“新系统能帮我们提升50%效率”，但你访谈一线员工后发现，他们目前每天一半时间在开会和手工核对，系统能优化的部分只有三成左右。对策是所有收益数据都要找到可验证的依据，至少用两个独立渠道交叉验证。
第二，低估接口集成的复杂度。新系统可能整个建设都很顺利，但对外系统的对接永远是最不可控的部分。外方系统的接口文档可能过期、接口可能没有沙箱环境、对接人员可能不响应。对策是可行性研究阶段就要对每个外部依赖做成熟度评估，标注“高依赖、中依赖、低依赖”，高依赖项的对接计划必须写进可行性研究报告。
第三，把培训成本漏了。系统上线不是发布了就行，业务人员要会用、要用得溜，需要投入大量培训时间和练习时间。很多系统上线后使用率低，不是系统不好用，是培训没跟上。可行性研究阶段就要估算培训的场次、人数、成本和业务停摆的代价。
第四，不关注隐性收益与隐性成本。隐性收益比如决策更及时、库存周转率提升、客户满意度提高，虽然不好量化，但对项目立项很关键，要在报告中定性说明。隐性成本比如系统需要专人维护数据质量、需要安全团队定期做合规审计、需要法务部门参与合同评审，这些费用如果不计入，成本黑洞就出现了。
第五，报告写完后没有找“反对者”评审。自家人看的报告通常自嗨，找一两个对项目持怀疑态度的人来挑刺，让报告在内部被狠狠批评过一轮再拿出去汇报，比出去被决策层现场打脸强。我每次在报告正式提交前，都会请一位“毒舌”同事来评审，每次都发现过测算口径不一致或者风险遗漏的问题。
4.3 新人做可行性研究最容易犯的五个错误
如果你刚入行，第一次主导可行性研究，这五个错误特别容易犯，提前知道了能少走很多弯路。
一是把可行性研究和需求分析混为一谈。可行性研究回答“要不要做、能不能做”，需求分析回答“具体做什么”。调研阶段收集了大量用户需求细节，却不聚焦在可行性的核心问题上，写出来的报告像需求说明文档，决策层看了不知道该怎么拍板。正确做法是，可行性研究阶段收集需求信息只为辅助判断可行性，详细的用户故事和功能清单留到立项后再做。
二是时间安排上本末倒置。有的团队在写报告上花了大量时间反复雕琢措辞，却在真正的调研和测算上草草了事。报告再好看，里面的数据是拍脑袋拍的，结论就是沙滩上盖楼。我的建议是60%的时间花在调研分析和测算，30%花在方案设计和风险梳理，只有10%花在报告成文上。
三是不敢说“不”。年轻的研究人员面对强势领导提的项目，很容易顺着领导的意思得出“可行”的结论。但可行性研究的职业操守就是独立客观，对得起数据，而不是对得起领导脸色。如果测算结果真的不支持立项，就要用数据和图表清晰表达，把判断依据摆出来，把决策压力留给决策层。只要你的数据扎实，最终领导反而会感激你的专业判断。
四是忽略“做不了”的方案价值。很多团队觉得研究半天得出“不建议开发”就是白干了，其实这是最大的误解。一次严谨的“不建议”结论帮助公司省下了几百万的潜在亏损，这就是项目最大的价值。我做过的最有成就感的一次评估，就是从技术、成本、业务三个维度论证了一个热门项目在当前条件下不可行，后来市场变化验证了这个判断，客户专门回电话感谢那次评估。
五是忘记沉淀评估数据。可行性研究阶段收集的很多数据，比如性能压测结果、第三方服务报价、业务量统计口径，后面做详细设计时非常有用。项目结束后把这些数据整理归档，二次开发或做一个新项目时能直接复用。不要每次做项目都从零开始，资料沉淀是个人和团队无形的资产。
5. 一些掏心窝的建议
做了这么多年的软件系统评估，我越来越觉得，可行性研究考验的不只是专业能力，更是判断力和沟通力。判断力体现在你能不能在杂乱的信息里抓住影响成败的核心变量，沟通力体现在你能不能让决策层和业务方都实实在在理解评估的结论并参与决策。这两项能力都不是看几本书能学会的，得靠真刀真枪做项目磨出来。
我个人在实际操作中的体会是，第一步的现状调研花多少时间都不过分。很多项目后期出现的需求变更、范围蔓延、业务方不配合，几乎都能追溯到调研阶段的理解偏差。你调研做得越细，后面走弯路的概率越低。哪怕领导催着你快速出结论，我也会至少保证把关键业务方都访谈一遍，把核心数据都交叉验证一次，这个习惯救过我太多次了。
最后再分享一个小技巧：每次做完可行性研究，我会把自己当时的预测和假设列一个清单，项目走上正轨后隔几个月回看一遍，哪些预测准了，哪些完全跑偏，跑偏的原因是什么。这样做几轮之后，自己对项目判断的敏感性会明显提升，下次做评估时知道该重点核什么数据、该警惕什么话术。这套“复盘-修正”的循环，比任何方法论都管用。软件的可行性研究，说到底研究的是不确定性，谁能让不确定性变得可控，谁就能在项目启动之前胜人一步。
