做 IT 系统选型这件事说它是技术活其实不太准确它更像是一场同时涉及业务、财务、法务和工程实施的综合博弈。我自己参与过大小十几次系统选型从几十人的协同工具到上千人规模的核心业务平台都有踩过的坑足够写一本小册子。很多团队以为选型就是列几个产品、比一比功能、挑个便宜的结果签完合同才发现功能演示里那个丝滑的流程实际配置要三个月报价单上那个数字只是第一年的入场券供应商说的完全支持定制意思是完全没有现成的。这篇内容我想把从需求梳理、供应商比价、POC 验证、合同谈判到上线交付、验收运维的完整链条拆开讲重点放在那些文档里不会写、但真正决定项目成败的细节上。不管你是第一次主导选型的技术负责人还是被拉来当技术评审的业务骨干或者只是想搞清楚公司买系统到底该怎么买下面这些内容应该都能直接拿去用。1. 选型翻车的真实原因与需求盘点的底层逻辑1.1 那些看起来都对的方案为什么落地就变形先说说选型失败的典型形态。我见过最多的不是选了个烂产品而是选了个不错的产品但和自家情况不匹配。这两种失败的性质完全不同前者是判断力问题后者是方法论问题。而绝大多数翻车都属于后者。举一个我印象很深的场景。某公司要做一套内部工单流转系统参与选型的有三家供应商A 家产品功能最全演示时什么都能点出来报价也最贵B 家产品界面朴素功能覆盖大概七成但架构很干净C 家是行业里口碑不错的中型产品价格居中。最后拍板选了 A 家理由是功能多总没坏处以后要用到就不用再买了。结果上线四个月实际用起来的模块不到三成剩下七成因为流程和公司现有审批制度冲突一直被搁置更麻烦的是 A 家产品为了兼容那些全功能底层表结构极其复杂公司自己的技术团队想做个简单的报表对接光是理清数据关系就花了两周。这个案例里真正的错误不是选了 A 家而是把功能数量当成了决策变量却没有定义哪些功能是必须落到业务场景里的。功能多本身不是缺点但如果多出来的功能会带来架构复杂度、配置成本和后续维护负担那它就在事实上变成了一种负债。这就是我常说的选型不是在挑最强的产品而是在挑匹配度最高、且未来三年不会成为负担的产品。还有一个更隐蔽的失败模式需求在选型过程中被悄悄替换。一开始业务方说我们要提高审批效率到了评标环节评审标准变成了谁的支持移动端审批。这两件事有关系但不是一回事。前者是目标后者只是可能的手段之一。一旦目标被手段替换后面所有的比较都建立在一个被偷换的前提上选出来的东西自然很难真正解决问题。1.2 需求清单的三层拆法痛点、约束、期望需求梳理这件事最怕两种极端一种是老板说你们技术看着办然后技术团队凭感觉列一堆功能点另一种是业务方洋洋洒洒写了一百多条需求每条都标重要最后没法排序。我的做法是把需求强制分成三层每一层用不同的方式处理。第一层是业务痛点回答现在到底哪里疼。这一层必须由真正干活的人来提不能由管理者代笔。比如每月对账要人工核对两天客户投诉工单经常丢失新员工开通账号要走五个部门签字。这些描述的共性是具体、可观察、有频率或耗时。我一般要求每个痛点附上一个粗略的量化哪怕是大概两天经常一个月三四次这种模糊量级也行因为它直接决定后面值不值得为这个功能付钱。第二层是硬性约束回答什么条件是绝对不能破的。这层最容易被忽略但它往往是选型的真正门槛。典型约束包括必须部署在本地机房数据不出内网、必须支持现有的统一身份认证、必须能对接某个已经用了很多年的老系统、必须满足某个行业的合规审计要求、预算上限是多少、上线时间窗口是几月。这些东西在功能对比表里体现不出来但只要有一条不满足产品再好也只能出局。我的经验是硬性约束最好在接触供应商之前就写成白纸黑字避免被销售话术带着走。第三层是期望与加分项回答如果有更好没有也能接受。移动端、报表自定义、界面美观、多语言、开放 API 之类大多属于这一层。把它们和硬性需求混在一起是灾难因为供应商会用加分项来掩盖硬伤评审也会在加分项上耗费大量精力。三层拆完之后我会做一件事给第二层的每一条约束标注验证方式。比如必须支持统一身份认证这条验证方式是在 POC 环境里用我们现有的账号体系实际登录一次而不是供应商口头确认支持。这个习惯看起来琐碎但它能把后面 80% 的扯皮提前消灭。1.3 把模糊需求翻译成可验证指标的实操方法需求清单最常见的毛病是形容词太多、动词太少。高性能易用稳定灵活这类词在选型文档里出现频率极高但它们无法比较。我的处理办法是做一次翻译练习每个形容词都必须落成一个可以当场测出来的动作。模糊表述翻译后的可验证指标验证方式系统要快核心列表页在 10 万条数据下首屏加载 ≤ 2 秒POC 环境灌入测试数据用浏览器开发者工具录时间要稳定连续运行 72 小时无重启压测 200 并发错误率 0.5%压测工具跑一轮看错误日志操作要简单新用户不看文档完成一次完整工单提交 ≤ 5 分钟找两个没接触过的同事实测并计时要灵活可配置新增一个审批节点不需要改代码、不需要供应商介入现场让实施顾问演示配置过程并录像要能对接提供标准 API 文档且能在 1 天内完成一次双向数据同步让自家开发按文档实际调一次这张表看起来简单但它带来的改变是根本性的评审会上不再争论我觉得这个更易用而是对着同一组指标看结果。我在一次项目中就靠这张表把一个演示很炫但实际配置极慢的产品筛掉了——演示时那个流程配置花了 40 分钟销售说熟能生巧但我们要的是业务人员自己能改40 分钟和 4 分钟是性质差别。这里补充一个实操心得翻译指标的时候尽量选择供应商无法临时准备的验证方式。演示环境都是精心准备过的你要做的就是打破这种准备。比如临时给一组他们没见过的基础数据或者要求现场改一个流程节点或者让自家工程师当场按文档调接口。真正扎实的产品经得起这种突击检查而靠演示脚本撑起来的产品会立刻露馅。2. 供应商与产品评估把营销话术拆成可对比的维度2.1 报价单里的三层成本看懂才不会超预算价格这件事我建议所有主导选型的人都把它当成一个独立的专业问题来对待。因为供应商给你的第一版报价几乎从来不是你要付的总金额。我习惯把成本拆成三层来看。第一层是软件许可成本。这里的花样最多按用户数计价、按并发数计价、按模块计价、按服务器核数计价、按数据量计价还有一次性买断和年度订阅两种模式。同样是支持 200 人使用A 家按注册用户算B 家按同时在线算C 家按命名用户算最后价格能差出好几倍。所以比价的时候一定要问清楚计价口径并且要求供应商按我们实际的用户增长曲线报三年价格而不是只报首年。第二层是实施与集成成本。这部分经常被低估。实施费通常按人天算而人天数取决于需求复杂度、数据迁移量和定制程度。一个常见陷阱是供应商在投标时报一个很低的实施人天数中标后再以需求变更为由追加。我在合同里一定会要求写明实施范围的具体边界以及超出范围后的人天单价上限。第三层是长期持有成本也就是常说的 TCO。它包括年度维保通常是许可费的 15% 到 22%、服务器与存储、专职运维人力、版本升级带来的二次实施、以及最容易被忽略的内部用户支持成本。我做过一个粗略测算某系统首年采购加实施花了 60 万但三年下来维保 30 万、硬件和云资源 15 万、半个运维人力折算 25 万总持有成本接近 130 万是首年支出的两倍多。如果选型时只盯着那张 60 万的报价单预算判断就会严重失真。注意要求供应商提供三年总持有成本测算表并明确列出哪些项会随用户数、数据量、调用量增长而变化。凡是拒绝提供这一项的基本可以判定后面会有增项。2.2 产品架构怎么判断好坏看这五个地方功能可以演示架构很难伪装。我判断一个产品架构是否靠谱通常看五个地方。第一看数据模型是否清晰。让供应商打开后台看看核心业务对象比如订单、工单、客户的表结构或者数据字典。如果对方的回答是这个不方便看那就要打个问号。架构干净的产品数据关系一眼能看懂架构混乱的产品往往一个业务对象散落在七八张表里字段命名毫无规律。第二看权限模型是否支持细粒度。大部分系统都有角色概念但真正能用的权限模型要能支持数据行级字段级控制。我一般会问一个具体问题同一个部门里普通员工只能看自己的单据主管能看本部门总监能看跨部门但不能看财务字段——这个能不能配置出来能当场配出来的说明权限引擎是真的回答需要定制开发的说明它只有粗粒度角色。第三看扩展方式。产品对外提供的是标准 API、Webhook、插件机制还是只能找原厂改代码这决定了你未来三年的自主性。一个只有原厂能改的产品意味着每一次小需求都要排期、报价、等版本。第四看升级策略。问清楚版本升级是强制的还是可选的升级会不会覆盖本地定制有没有回滚方案我见过一个产品每次升级都会把客户自己加的自定义字段冲掉导致客户三年不敢升级最后卡在一个老版本上连安全补丁都打不了。第五看技术栈的寿命。如果产品依赖的是某个已经停止维护多年的框架或者用了很小众的数据库那它未来的人才招聘、问题排查、生态支持都会成问题。这一条不需要很深的技术判断问问对方用的什么语言、什么数据库、什么前端框架再自己查一下这些技术的活跃度就够了。2.3 案例考察的正确姿势别只看样板间供应商给的成功案例基本等同于开发商的样板间——真实存在但经过了挑选和布置。我不否认案例的价值但要会看。我的做法是要求看同规模、同行业、同复杂度的三同案例并且尽量争取一次和对方实际使用者的直接沟通。注意是和使用者聊不是和对方的项目经理聊。问的问题也要具体上线花了多久上线后前三个月最痛苦的是什么有没有哪些当初承诺的功能最后没用起来供应商的响应速度怎么样版本升级踩过坑吗有一次我用这个方法问出了一条关键信息某产品在另一家公司的实际并发承载能力只有销售宣称的三分之一因为销售说的是理论峰值而对方实际跑业务时数据库连接池配置一直没调对。这个信息在任何一个官方案例里都不会写但它直接影响我们的容量规划。还有一个细节看案例要看用了几年而不是用没用。一个系统上线半年说明不了什么上线三年还在稳定运行、还在跟着版本升级才说明它经得起时间。如果供应商拿不出任何一个使用超过两年的案例那风险是实打实的。3. POC 验证用最小成本把问题提前暴露3.1 POC 不是演示是带着刀子去试很多人把 POC 理解成让供应商再演示一遍这是极大的浪费。演示是供应商主导的POC 必须是你主导的。它的目的不是看看产品好不好而是验证那几个如果出问题就会毁掉整个项目的点。我的 POC 设计原则有三条。第一只测关键路径。把需求清单里第二层硬性约束和第一层里最痛的三个场景拿出来测其他一律不测。POC 时间通常只有一到两周贪多必失。第二必须有真实数据。用脱敏后的真实业务数据不要用供应商准备的演示数据。数据结构、字段长度、脏数据比例这些才是真实世界的模样。第三必须有明确的通过标准。每一项测试开始前就写好达到什么结果算通过避免事后各说各话。具体到执行我会准备一份 POC 测试清单格式大概是这样的测试项、前置条件、操作步骤、预期结果、实际结果、结论通过/不通过/有条件通过。比如审批流配置这一项前置条件是使用我方提供的三级审批场景操作步骤是由我方业务人员独立完成配置供应商只允许答疑不允许代操作预期结果是30 分钟内配置完成并可正常流转这样测出来的结果才有参考价值。提示POC 期间一定要安排自己人动手而不是全程看供应商操作。看别人做和自己做体验差距大概是十倍。很多用起来别扭的问题只有自己上手才会暴露。3.2 测试用例怎么写才不流于形式写测试用例这件事我建议由业务方和技术方各出一半。业务方出业务场景用例技术方出技术边界用例两边合起来才完整。业务场景用例的重点是完整闭环不是单点功能。比如新员工入职这个场景要覆盖HR 发起、部门审批、账号开通、权限分配、通知送达、异常回退。走完一遍你就能看出产品在流程衔接上的真实水平。很多产品单点功能都齐全但流程一跨模块就断这是演示里绝对看不出来的。技术边界用例的重点是压到极限。常见的几类大数据量下的列表查询和导出比如 50 万行导出会不会超时、并发写入冲突两个人同时改同一条记录会怎样、异常输入超长文本、特殊字符、空值、权限越界的拦截、以及接口的幂等性。这些测试不需要很深的功底但能筛掉一大批演示好看、实战拉胯的产品。我还习惯加一类运维友好度用例日志在哪里看报错信息是否可读能不能自己重启某个服务备份和恢复怎么做、要多久这些东西上线后天天要用但选型阶段几乎没人测。3.3 POC 现场的记录方式与最终决策POC 期间一定要有人专门做记录最好是用共享文档实时记而不是事后回忆。记录的内容不只是通过没通过还包括卡住的时候供应商的反应速度、遇到问题时对方是现场解决还是回去研究、以及那些能用但很别扭的细节。这些软性观察往往比测试结果更能预测未来。一个在 POC 阶段就响应迟缓、遇到难题就回避的团队你很难指望它在正式实施和上线支持时变得积极。我见过一次 POC产品功能测试全过但供应商的实施顾问在遇到一个配置问题时说这个我得问总部大概要两三天而另一家规模小一些的供应商当场就调通了。最后我们选了后者理由很简单上线之后你会遇到几百个这样的两三天。决策阶段我建议用加权打分表但权重必须在看结果之前定好。常见的权重分配大致是功能匹配度 30%、技术架构与扩展性 25%、总持有成本 20%、供应商服务能力 15%、案例与口碑 10%。这个比例不是标准答案但它的思路是不要让任何单一维度尤其是价格一票决定。打分表的价值不在于算出那个分数而在于强迫团队把我觉得变成我在某个维度上给它打了几分理由是。4. 合同与实施把口头承诺变成可追责的条款4.1 合同里必须写死的几类条款合同这件事技术人员往往不参与但它恰恰是选型成果能否落地的最后一道闸门。我不做法律建议但从项目交付角度有几类条款我一定会推动写进去。第一类是范围条款。明确写清楚交付物包含什么最好附一份功能清单作为合同附件并注明哪些是标准功能、哪些是定制开发、定制部分的工作量如何计算。含糊的根据实际需求实施是最危险的表述。第二类是验收条款。验收标准要可量化、可复现最好直接引用 POC 阶段定下的指标。同时要写清楚验收流程谁签字、分几批验收、每批的期限、逾期未验收如何处理。我见过太多项目卡在业务方觉得不好用但说不出哪不好用的状态最后拖成烂尾。第三类是付款节奏。常见的分期是 3:4:2:1 或者 3:3:3:1尾款比例不要太低否则没有约束力也不要一次性付清。关键是每一期付款都要绑定一个明确的交付节点而不是绑定时间。第四类是服务级别。响应时间、解决时间、服务时段、升级路径这些要写具体。比如严重故障 30 分钟内响应、4 小时内给出方案而不是提供 7×24 小时优质服务。第五类是知识产权与数据归属。定制开发部分的代码归属、数据的所有权、合作终止后的数据导出方式这些都要提前约定。尤其是数据导出一定要写明以标准格式完整导出否则将来想换系统时会被卡住。第六类是退出机制。这条最容易被忽略。要约定如果实施严重延期或者验收多次不通过甲方有什么权利能不能部分退款能不能要求源码托管能不能平滑迁移把这些写在前面比事后打官司有用得多。4.2 实施计划的里程碑怎么设计才靠谱实施计划最忌讳的是一条直线走到上线。我的经验是把整个实施拆成若干个可以独立验证的里程碑每个里程碑都有明确的产出物和验收动作。一个比较稳的节奏是启动与蓝图2-4 周→ 基础配置与数据准备3-6 周→ 核心流程联调3-4 周→ 用户验收测试2-3 周→ 试运行2-4 周→ 全面上线。每个阶段的时长取决于项目复杂度但这个先蓝图、再配置、再联调、再试运行的顺序不能乱。其中最关键的是蓝图阶段。这个阶段的产出物应该是一份未来流程说明书把每个业务场景在新系统里怎么走、谁审批、数据怎么流画清楚、写明白并由业务方签字确认。蓝图没定清楚就进入配置后面必然是无限返工。我在一个项目里坚持把蓝图阶段从两周延长到四周当时业务方很有意见但后来配置阶段一次返工都没有整体反而提前了。还有一个实践细节里程碑验收要有可演示的成果不能是文档写完就算完成。比如基础配置阶段的验收应该是用真实数据跑通三条核心流程而不是配置文档已提交。4.3 数据迁移与上线切换最容易出事的两段数据迁移是实施阶段翻车率最高的环节没有之一。它的难点不在于把数据搬过去而在于老数据里的脏东西怎么办。我的一般做法是分三步走。第一步是数据摸底在正式迁移前把源数据跑一遍质量分析有多少条记录、多少个字段、空值率多少、有没有重复、格式是否统一、有没有孤立的关联数据。这一步至少要花三到五天但能省掉后面几周的扯皮。我遇到过的情况包括客户名称里混着全角半角括号、手机号字段里存着座机和备注、订单状态有三套历史遗留编码。这些问题如果不提前处理迁移脚本跑一次错一次。第二步是试迁移用全量数据在测试环境跑一遍记录耗时、失败条数、失败原因然后修正脚本再跑一遍。通常要跑三轮以上才能稳定。第三步是正式迁移与校验迁移后必须做数据核对核对的维度包括总条数、关键字段汇总值、抽样记录逐字段比对。核对结果要有书面记录双方签字。上线切换策略上我倾向于并行运行一段时间新老系统同时跑比如两周到一个月虽然短期工作量翻倍但它是唯一能兜住上线才发现致命问题的办法。如果业务不允许并行那至少要准备好回滚方案并且回滚方案要真的演练过一次而不是写在纸上。5. 上线之后验收、运维交接与长期保障5.1 验收标准怎么定才不会变成拉锯战验收之所以容易变成拉锯战根本原因是标准在变化。项目初期定的标准到了验收时业务方会说我们当时没想到还有这种情况。要避免这个核心办法是把验收标准前置到蓝图阶段并在每个里程碑都做小验收。具体来说我会在合同附件里放一张验收清单清单的每一条都对应一个可执行的测试动作。验收时不是大家坐在一起讨论好不好用而是按清单逐条执行记录结果。清单之外的诉求走变更流程不纳入本次验收。验收的组织方式也有讲究。我建议分两轮第一轮是技术验收由 IT 团队做重点是功能、性能、安全、接口第二轮是业务验收由实际使用者做重点是流程顺畅度和操作效率。两轮的通过标准不同不能混在一起。技术验收看是否符合规格业务验收看是否解决问题。还有一个容易被忽略的点验收不只是验能用还要验能维护。所以验收清单里应该有这几项运维文档是否齐全、监控告警是否配置、备份恢复是否演练过、常见故障的处理手册是否交付、供应商的支持渠道是否接通。这些不做系统上线第一天就会变成黑盒。5.2 运维交接与知识转移别让自己变成离了供应商就转不动知识转移这件事很多项目都写在计划里但执行得很敷衍常见做法是上线前供应商来培训两天。这种方式的效果很有限因为培训时大家还没有实际操作经验听完就忘。我的做法是把知识转移拆散到整个实施周期而不是集中在上线前。具体分三种形式一是配置阶段就让自家 IT 人员参与边做边学供应商只做指导二是每个里程碑结束时做一次复盘式讲解由供应商讲这次做了什么、为什么这么做三是上线后安排一到两周的影子运维自家团队主导日常操作供应商在旁边待命答疑。同时要盯住几份关键交付物系统架构图、部署手册、配置说明、接口文档、运维手册含常见故障处理、以及最重要的——一份这个系统有哪些坑的非正式清单。最后这份通常不在合同里但它价值极高我会在项目收尾时专门请实施顾问吃顿饭把这些问题问出来记下来。这些问题包括哪些配置改了会影响全局、哪个定时任务容易卡住、日志暴涨通常是什么原因、升级时哪些自定义会被覆盖。这些东西文档里不会写但运维的时候天天用得上。5.3 退出机制与备选方案成年人要给自己留后路谈退出机制听起来不吉利但它是成熟选型的标志。我一般会在选型阶段就考虑三个问题数据能不能完整拿走、业务流程能不能迁到别的系统、以及最坏情况下能不能回到手工或老系统。第一个问题的落点是数据导出能力。要在合同里约定系统必须支持以通用格式CSV、JSON、标准数据库备份导出全部业务数据且导出不依赖供应商现场支持。有条件的话在 POC 阶段就实际导一次看看导出文件的字段是否完整、关联关系是否保留。第二个问题的落点是流程的标准化程度。如果业务流程被系统绑得死死的一旦换系统就要重新梳理流程迁移成本会非常高。所以在实施阶段我会尽量让流程保持行业通用逻辑避免为了省事做大量非常规定制。定制越多锁定越深。第三个问题的落点是过渡期的兜底方案。至少要明确如果新系统在试运行期间出现严重问题回退到旧系统的操作步骤是什么、需要多长时间、数据如何补录。这个方案要写下来并且让相关的人都看过。6. 常见问题速查与避坑清单6.1 选型各阶段的高频问题对照表阶段高频问题典型表现应对办法需求需求没有优先级一百多条需求全标重要强制三层拆分硬性约束单独列需求目标被手段替换提高效率变成要移动端每个需求追问解决什么痛点评估只看功能数量功能最全的胜出按使用频率加权评估配置成本评估忽略隐性成本只比首年报价要求三年 TCO 测算表POC变成二次演示全程供应商操作自己人动手用真实数据POC没有通过标准事后凭印象判断测试前写好预期结果合同范围含糊根据需求实施附功能清单明确定制边界合同验收标准缺失只写满足业务需求引用 POC 指标逐条可测实施蓝图不清就开工边配边改蓝图签字确认后再配置实施数据迁移低估上线前一周才开始导数据提前摸底至少三轮试迁移上线没有回滚方案出问题只能硬扛并行运行或演练回滚运维知识没转移离了供应商转不动全程参与影子运维6.2 几条用血换来的实操心得心得一不要在演示环节做决定。演示是供应商的主场灯光、脚本、话术都是设计过的。所有关键判断都应该发生在你自己主导的环境里。我现在的习惯是任何产品在进入正式比选前先要一个测试环境账号自己玩两天很多问题不用别人说你自己就感受到了。心得二销售的热情和实施团队的能力是两回事。选型阶段接触的往往是销售和售前他们口才最好、响应最快。但真正陪你走完项目的是实施顾问。所以在决策前一定要想办法见一见将来可能负责你项目的实施人员哪怕只是聊半小时。一个经验不足的实施顾问能把好产品做砸一个靠谱的实施顾问能把普通产品用出花来。心得三把变更当成常态来设计流程。几乎所有项目都会有需求变更区别只在于变更是否可控。我的做法是在合同里约定一个变更池比如包含 20 人天的小额变更额度超出部分单独报价。这样小的调整不用每次重新走审批大的调整也有明确的价格锚点双方都省事。心得四留一个用户反馈通道从试运行第一天就开着。上线初期的问题往往集中在几个点上如果有一个简单的反馈入口哪怕是一个共享表格收集两周就能发现规律。我在一个项目里靠这个办法发现80% 的抱怨都指向同一个保存后不提示成功的交互细节改掉之后满意度立刻上来了。心得五验收签字之前把运维拉进来一起看。技术人员验收关注功能对不对运维关注的是出问题我能不能查到原因。让运维在验收阶段就提要求比如日志级别、监控指标、告警阈值这些在验收时提还有得改上线后再提就是变更了。6.3 一份可以直接拿去用的选型检查清单最后给一份我常用的清单按顺序过一遍基本能避开大部分明显的问题。需求侧痛点是否由一线提出并量化硬性约束是否单独列出并标注验证方式需求是否有明确的优先级排序是否有不做什么的明确边界评估侧是否至少对比了三家是否核对了计价口径是否测算了三年 TCO是否实地或线上看过同规模案例是否见过未来的实施负责人POC 侧是否用自己的数据是否自己人动手是否有书面通过标准是否测过性能边界和权限边界是否观察了供应商的响应速度合同侧功能范围是否附清单验收标准是否可量化付款是否绑定交付节点SLA 是否写具体数据导出和退出机制是否明确实施侧蓝图是否签字确认数据是否提前摸底是否安排试迁移是否有并行或回滚方案知识转移是否贯穿全程运维侧监控告警是否配置备份恢复是否演练运维文档是否齐全支持渠道是否打通是否有一份坑清单这套流程走下来项目不一定能做得完美但大概率不会出现那种签完合同才发现根本用不了的灾难。选型这件事的本质是在信息不对称的条件下做决策而所有的功课都是为了把不对称尽量拉平一点。我自己的体会是前期多花两周把需求和验证标准磨清楚后面能省下两个月的返工这笔账怎么算都划算。
