行业资讯
去年有个做物流的客户找我，说他们那套 TMS 上线半年，验收会开了三次都没过。我去他们办公室待了一下午，发现甲方项目经理是老板娘的弟弟，原来是管仓库的，现在每天泡在开发群里，问的都是缓存命中率、消息队列、索引优化这些词，听着挺专业。可我翻了半天，他没记过一次需求变更，没写过一条验收标准。合同附件是一个 Excel，四十七行功能，没有编号，也没有优先级。开发那边的需求池一百三十六条，两边对不上。 这项目不是做坏的，是管散的。甲方项目经理不需要看懂代码，需要的是四本账，范围、进度、变更、验收。每一本都能落在一张纸上，每周五更新一次。一、范围账：合同那 47 行，要能和需求池的 136 条对上 第一件事是把合同附件里的功能清单重新编号。四十七行就编 C01 到 C47，一行一个号，不改原文，只在后面加一列。然后让乙方把需求池拿出来，按 R001 往下编，再加一列对应合同编号。这一列空着的，就是合同外的新增；一列对不上两个号的，说明合同里那条被拆过；一个合同号对着一堆需求的，说明乙方拆得比合同细，正常。 这张表拉出来，通常当天就能看出问题。有的功能合同写了但需求池没有，那是漏做；有的需求池有但合同没有，那是有人口头答应了。两种都要当周摆到桌上说清楚，别等到验收再翻。 状态那一列也有讲究，不要用百分比。客户管理已完成百分之八十这种话没法验收，也没法追。用四个状态，未开始、开发中、待测试、已验收，每周五更新，谁改的谁署名，改完发群里。看这张表就知道项目走到哪，比听汇报靠谱。 还有两个细节容易漏。合同里写明免费修改包含几轮，原型两轮、UI 两轮、整体两轮，这个轮要落到表上，改到第几轮标出来，超了就是变更。谁提的需求谁签字，部门负责人签，老板在饭桌上口头说的，让对接人补一条微信确认再进表。口头需求不是不能做，是做完没人认账。二、进度账：别问做了多少，要能看见东西 这周做了多少，这个问题没有答案。做了多少是个感觉，看不见也摸不着。乙方说做了五个模块，你没法验；说接口联调完了，你也没法验。要问的是这周有没有东西能拿出来看，看到了才算数。 里程碑要绑交付物，不绑日期。原型阶段交原型文件，UI 阶段交设计图，开发阶段交接口文档和联调记录，测试阶段交测试用例和缺陷清单，上线前交 UAT 签字和部署记录。每个里程碑后面挂一个具体的文件名，不写完成开发四个字。 周会别在会议室
上周一个做食品加工的客户把三份报价单发过来，说功能清单看着差不多，一家报 8.6 万，一家报 15 万，还有一家报 24 万，问我选哪个。我把三份打印出来铺在桌上看了半小时，最便宜那份最后一行小字写着不含第三方接口费用及服务器，最贵那份把云服务器、短信、等保测评、首年维护全列进去了。 这三份报价其实不在一个口径上。报价单这东西只看总价，很容易签的时候八万六，做完十八万六。下面这几项，签合同前建议一条条问清楚。一、按人天报还是按功能报 报价单最上面通常写着一个总价，往下翻才看到计价方式。有的写按人天计，单价一千二，预计六十人天，有的写按功能模块打包，客户管理八万，订单管理六万。 按人天报的，要问清楚天数是谁估的，估的依据是什么，做超了怎么算。同样一个客户管理模块，一家估十五人天，一家估四十人天，单价再低也没意义。按功能报的，要把功能清单落到能数得清的程度，几个端，几种角色，多少个页面，多少张报表，导出格式有几种。清单写得越粗，后面扯皮的空间越大。 还有一种写法是按阶段付款但没写总人天，这种报价最需要警惕。因为做完第一阶段你才知道总共要花多少，后面再谈价，余地就不大了。二、那几行「不含」 报价单的备注栏是重点，很多钱都写在那儿，字还特别小。拿到报价单先别急着看总价，把备注栏和不含项那几行读一遍，这几行常常比总价更能决定最后的落地价。 第三方服务费最常见。短信按条计费，一条几分钱，一年几万条就是几千块；实名认证、OCR 识别、电子签、地图定位、语音通知，这些都要单独向服务商买；支付通道有费率，收款还要结算周期。服务器也常被写成不含，云主机加数据库加带宽加备份，一年几千到几万，取决于访问量和数据量。 接口对接是另一笔。跟 ERP 对接、跟财务软件对接、跟钉钉企业微信对接、跟税控对接、跟银行或快递对接，一个接口从几千到几万不等，报价单里常常只写一句支持对接第三方系统，具体哪几个、谁去协调对方开放接口，都没写。 政企项目还要多一项，等保测评和整改。系统要过等保二级或三级，测评费、整改费、安全设备，这些通常不在开发报价里，一笔就是几万块。三、变更怎么算钱 软件项目几乎没有不改需求的，所以变更单价一定要在合同里写死。写清楚按人天还是按次，后面每次提需求才有依据，免得每改一次都重新扯一遍。 常见写法是变更按人天计，单价就是报价单上那个人天单价，问题是很多人天单
上个月陪一个客户开验收会，原定一个小时，从九点半开到下午一点。甲方信息中心的主任把打印好的问题清单摊在桌上，二十七条，一条一条往下念。乙方项目经理翻了两页就急了，说这些需求里根本没写。两边来回争，饭都没吃，验收单最后也没签。一、验收标准写在合同里，不写在需求里 合同里那句「符合甲方需求」，看着稳妥，实际等于什么都没说。甲方理解的需求和乙方理解的需求，中间隔着一整轮沟通。等到验收会才把两边的理解摆到桌面上，不吵才怪。 真正管用的做法，是在需求评审之后补一份验收口径清单。每个功能点后面写清楚什么算通过，尽量能数出来。比如报表导出这项，写到导哪些字段、单次十万行、点下去五秒内出结果，而不是笼统写一句支持报表导出。 这份清单不用多正式，一页表格就够，但要在开发动手之前让双方项目负责人签字。签的是理解一致，不是法律效力。目的很简单，后面不管谁换了岗，翻出来还能对得上。 有些甲方觉得这么干太较真，好像一开始就防着乙方。其实反过来想，前期把话说细，验收那天反而轻松，大家都按一张纸说话，不用比谁的嗓门大。乙方也愿意，边界清楚了，后期加需求才好谈钱。 清单的写法也有讲究，一行一个功能点，五列就够，功能名称、操作步骤、预期结果、测试数据量、通过与否。别写成大段文字描述，验收现场没人有耐心读。凡是能用数字的都用数字，十万条、三秒、五个角色，这些才是能当场验的东西。二、演示环境都好看，真实数据一跑就露 验收会上最常见的场面，是乙方打开演示环境，点几下，页面顺滑，图表漂亮，甲方点头。然后有人提议登到正式环境看看，一登进去，列表转圈半分钟，导出直接超时。 演示库通常只有几十条造得干干净净的数据。正式库跑了一年半，八十万条历史单据，手机号带空格，日期格式有三种写法，同一个客户重复建了四次档。这些脏东西，写代码的人没见过，测试也没专门造过。 权限是另一个重灾区。演示用管理员账号，什么都能看。换成一线业务员登录，该看的看不到，不该看的全露着。验收时找三个不同角色的人各登一次，比看十页截图都管用。 所以验收别只在演示环境走流程。拉一份脱敏后的真实数据，把最重的查询、最复杂的导出、最常用的审批路径各跑一遍。跑不动的地方当场记下来，别等上线以后让用户替你测。 准备这份数据一般要甲方 IT 配合，从生产库导一个副本，把姓名、手机号、身份证脱敏，再灌到验收环境。这件事听着麻烦，做一次也
上个月有个做母婴用品的老板找我，说公众号、小程序、企业微信都开了，粉丝攒了一万多，可到月底盘客户，谁也说不清这些人到底买过什么、该谁跟进。客户在公众号里问过价，在小程序里下过单，又加企业微信聊过售后，可这三个地方的记录对不上号，系统都当他们是三个人。这不是他一个人的问题。我接触的中小企业里，十个有八个是这种状态：入口开得挺齐，客户管理还是散的。第一步，先搞清楚三个入口到底各管什么公众号是内容阵地。用户关注你，是因为想看你发的东西，他今天看明天可能就不看了，你只能靠推文和菜单栏触达他。小程序是服务窗口。用户需要下单、查订单、领券的时候打开它，用完就走，不会天天来。企业微信是关系链。销售或客服能加客户为好友，一对一聊，发消息不折叠，客户离职了资源还留在公司。 这三个东西本来就不是替代关系。公众号负责让人认识你，小程序负责让人找你办事，企业微信负责把客户变成熟人。想用一个入口包打天下，多半哪个都没做好。第二步，看清各干各的，客户就悄悄丢了 三个入口数据不通，是最常见也最致命的问题。公众号看得到粉丝数，看不到他的订单；小程序看得到订单，不知道他是不是刚在公众号里留过言；企业微信里聊得热火朝天，却没有他过去半年买了什么的记录。 客户身份对不上是第二层。同一个人，在公众号里是 "用户 A"，在小程序里是 "会员 B"，在企业微信里叫 "王姐"，三个系统各自为政，等于把一个客户拆成了三个人管。 运营也跟着重复。这边公众号小编发活动，那边小程序团队做优惠，企业微信再群发一遍，客户收到三遍同样的内容，烦不烦。最怕的是老板还以为自己触达得挺勤快。第三步，打通的关键，是先把客户身份统一起来 微信生态里有个现成的工具叫 UnionID。公众号、小程序、企业微信挂在同一个开放平台主体下时，同一个微信用户的 UnionID 是一样的，靠它就能把三端的身份对起来。 UnionID 对不上的时候，手机号兜底。客户在小程序下单留了手机号，公众号关注时也绑了手机号，两个一比对，人还是那个人。 落地的顺序别搞反。先建统一的客户档案，一个客户一条记录，把来源、标签、订单、跟进历史都挂上去；再按渠道打标签，知道他是公众号来的还是活动拉来的；最后才是把各个入口的数据往这个档案里喂。一口吃不成胖子，先打通最赚钱的那条线，比如 "小程序下单 + 企业微信跟进"，比三个入口一起折腾强得多。第四步，
上个月有个客户带着三页需求清单来找我们，问的第一句话是 "系统什么时候能上线，中间你们到底都干些什么"。他不是不信任，是真的不知道一个软件项目会经历什么。这篇文章就把这套流程摊开讲，站在客户的角度，说清楚每个环节里你该做什么、该要什么。第一步不是写代码，是先把需求说清楚 很多客户以为需求分析就是 "把想法告诉开发公司"，其实这一步决定了后面所有的报价、工期和返工成本。专业做法是先做需求调研，开发公司会把你的业务流程拆成功能点、角色、数据流转，输出一份需求文档，你再逐条确认。需求文档看着像走形式，实际上它是后面所有开发和验收的参照物，也是需求变更时讲道理的依据。这个阶段你最重要的事，是把业务规则讲细，比如审批流程有几种分支、数据多久导一次、哪些人能看到哪些内容。讲得越细，后面越少扯皮。原型确认，是合同边界真正定下来的地方 需求文档确认后，开发公司会做原型图，把每个页面长什么样、按钮点了跳哪里先画出来。这一步客户最容易忽略，但其实最关键。原型不是 "看看效果"，它等于把合同里的文字翻译成了界面，边界在哪儿、功能有哪些，一眼就清楚。等到原型确认、报价锁定，后面的改动就从 "改文档" 变成 "改程序"，成本会成倍往上走。所以这个阶段别嫌麻烦，逐页看、拿给实际用的人看，发现问题越早，花的钱越少。开发和测试阶段，进度慢不等于没干活 原型确认后进入正式开发，这是整个周期最长、客户参与最少的一段。代码不是一天长出来的，功能模块要按顺序排，前端、后端、数据库要一起动，联调的时候两个系统对不上接口，一调就是两三天。这里建议客户每周要一次开发进度和可运行版本，别只看 "百分之多少"，要让对方演示实际页面，眼见为实。另外提醒一句，这个阶段最怕中途加需求，加一个看似简单的功能，往往牵动数据结构和接口，工期预算都会变。真要做，就把新需求记录下来，放到下一个版本排期里。上线不是交付，验收通过才算完 系统开发完先上测试环境，你按验收清单一条一条过，功能、权限、异常情况都要试。正式上线前，域名、服务器、备案、数据迁移这些事要提前办好，别让系统做好了卡在上线环节。交付时除了系统本身，还有几样东西必须拿到手：源代码或托管权限、数据库结构、部署文档、操作手册、管理员账号。很多客户到这一步才发现只有个网站能用，后续想改、想换人维护都动不了。合同里写明交付物清单，验收合格签字，这套流程才算
上个月有个做软件的老板带着合同来找我，说接了个区里的信息化项目，别的都好谈，就 "驻场" 两个字让他犯了难。人手得住到对方办公楼里，工期按驻场算，费用却没见多出多少。他第一反应是自己被拿捏了。其实驻场在政企项目里太常见，关键是搞清楚它到底在解决什么问题，钱又该谁出。一、驻场到底驻的是什么 先说数据。政务和国企的项目，很多数据出不了内网，代码、数据库、服务器全在对方的机房里，你想远程开发，人家政策上就不允许。数据不离开机房，人就得过去，这是最硬的一条理由。再说沟通。政企项目的业务部门往往一堆人，这个处室提一个需求，那个科室又补一句，电话里说不清，微信上更乱。人在现场，问题当场聊完当场定，省掉的返工时间比驻场成本高得多。还有验收。政企项目验收流程长，评审专家、监理、审计轮番上，随时可能被叫去演示、解释、改东西。人不在现场，一次响应不及时，验收就得往后拖。二、驻场这笔账，很多人算错了 驻场不是免费的，这一点不少老板报价时没想明白。驻场意味着占用一个人，这个人的时间成本、差旅、住宿、管理，全是钱。常见的情况是，报价按远程开发算，合同签完甲方才提驻场要求，这时候再谈加价基本谈不动，最后就是白干。想不吃这个亏，签合同前把三件事问清楚。第一，驻场范围是什么，全程驻场还是只有需求调研和上线阶段驻场。第二，驻场几个人，驻多久。第三，驻场费用怎么算，含在总价里还是单独列。这三件事写进合同，后面才吵不起来。三、哪些项目其实不用驻场 不是所有政企项目都必须驻场，判断标准就三条。数据敏感度，数据必须留在内网的，驻场跑不掉；数据能上云、能远程访问的，就有商量空间。沟通频率，需求边界清楚、业务部门配合度高，远程沟通也够用。验收复杂度，走普通流程验收的，比走专家评审的更容易谈成远程。更常见的做法是分阶段驻场，需求调研和上线验收这两个阶段人过去，中间开发期远程，配合视频会议和远程桌面，多数项目都能接受。四、驻场不是洪水猛兽，谈清楚才是关键 驻场本身不坑人，坑人的是稀里糊涂答应驻场又没谈费用。提前把范围、人数、时长、费用写进合同，驻场反而是政企项目顺利推进的保障。
很多老板签软件合同时，看到 "免费维护一年" 就觉得省心。真上线出了事才发现，合同里这句话可能就一行字，范围、时效、责任全没写。后面每修一个问题都要重新谈价，扯皮从验收那天就开始了。 我见过不少项目，维护期内出了 bug，开发公司说这算新增需求要另收钱，老板觉得合同写了免费就该全包，两边各执一词，最后只能翻合同。可合同里偏偏没写清楚，翻也翻不出结果。今天就把售后条款拆开，看看这一年到底值不值。一、免费维护，到底免费什么 行业里默认的维护范围，一般只含 bug 修复，也就是程序报错、闪退、功能不正常这类缺陷。这类问题属于开发质量范畴，本来就应该修，写上免费只是约定个时间窗口。 新增功能、界面调整、业务流程改动，通通算需求变更，不在维护范围内，要单独报价。这一点很多老板没概念，以为 "维护" 就是提什么需求都能免费做，等报价单出来才傻眼。 还有三样东西合同里经常不写：服务器费用、域名费用、第三方接口费用。这些是外部成本，跟开发公司没关系，但很多老板以为 "维护一年" 就全包了。合同没写范围，就等于没约定，到时候解释权在对方手里。 签合同前最好把维护范围列个清单，写清楚哪些算 bug、哪些算变更、哪些要另付费。哪怕只是把范围写明白，后面都能少很多麻烦。二、三个最容易漏掉的细节第一个是响应时效。故障报修后多久有人接、多久给出修复方案、多久修完，不写清楚就是没承诺。有的公司写了 "及时响应"，实际上三天回一条消息也叫及时。第二个是修复方式。远程能修的不算完，核心系统要不要现场处理、修复前要不要备份数据、会不会影响当天业务，这些都得落到合同里。特别是政企项目，系统一停就是事故，光靠远程可扛不住。第三个是验收前后的界限。上线当天发现的问题算不算验收前问题、验收后多久内算 "维护期问题"，最容易吵。双方各执一词，最后往往看谁嗓门大。有的合同把验收和上线混在一起写，出了问题根本分不清责任段。这三条看起来都是小事，真出事都是大事。合同里写了，是约束对方；没写，就是给自己留隐患。三、需求变更为什么总能吵起来 "顺手改一下" 和 "重新开发" 是两码事，边界在哪，合同里得写明白。改个按钮颜色算小事，改个审批流程就是新需求，工作量差出好几倍。很多老板觉得 "就改个逻辑"，程序员得重新梳理上下游，一改就是一两天的活。 规范的流程是：提需求、开发公司评估工时和费用、书面确认、再
上个月有个客户问我们，政务平台马上要验收了，甲方突然甩出一句话，系统要过等保三级测评。他一脸懵，等保是啥，以前从来没听过。其实这不是个别现象。现在做政企项目，招标文件里 "满足等保 2.0 二级 / 三级要求" 几乎是标配，你心里没数，很可能就卡在验收这一步。一、等保到底是个啥？ 等保全称网络安全等级保护，是国家给信息系统定的一套安全等级制度。等保 2.0 从 2019 年正式实施，核心逻辑很简单，按系统的重要性和被破坏后的影响分成五级，级别越高，要求的安全措施越严。大多数企业系统落在二级和三级，政企项目最常见的是三级。 打个比方，这就像给系统做安全体检加定级。一级是基础防护，三级要能防住常见攻击、有日志留存、有灾备和应急预案。它不是一个证办完就完事，是真要按标准配防护措施，测评机构会一项一项查。二、什么项目绕不开等保？ 一句话，凡是跟政府、医院、学校、国企沾边的项目，基本都绕不开。政务服务平台、医院信息系统、智慧校园、国企内部管理系统，招标文件里十有八九写着 "系统需满足等保 2.0 三级要求"，有的甚至把通过测评写进付款条件。 原因也简单，甲方自己也有考核，网络安全出了事要担责，干脆把等保写进合同，让系统方来兜底。你做这类项目，等保就是投标的入场券，不是可选项。三、从定级到测评，要走几步、要多久？ 流程固定四步：定级、备案、建设整改、等级测评，后面还有监督检查。定级要先请专家评审，二级以上都要，然后到公安机关备案，一般几个工作日办完。接下来是建设整改，按测评要求补安全设备、日志和管理制度，这步最花时间，也最容易被低估。最后找有资质的测评机构做测评、出报告。 周期没有固定标准，按我们的经验，从启动到拿到测评报告，顺利也要两三个月，涉及整改多的拖上半年很正常。还有一条硬规矩：三级系统每年至少测评一次，新建的三级系统要先通过测评才能上线运行。四、一般提前做三件事第一件，预算。测评费加整改投入，不同规模差很多，项目立项时就该算进去，别等验收前才发现没这笔钱。第二件，时间。定级备案可以提前走，整改和测评留出两三个月以上，别把等保当成验收前一星期能补的作业。第三件，找对测评机构。测评机构要有公安部认可的资质，各地名单公安网能查，提前问清周期和排期，热门机构年底经常排不上队。说到底，等保不是技术部门的事，是项目能不能顺利验收、款能不能按时收的事。提前把它当回事
项目开发到收尾，老板突然被问一句：软著办了吗？ICP 备案做了没？再一问商标，连什么是 "商标类别" 都不知道。上线日期从月底推到下月中，业务等着用，证一个都没有。这 4 样东西名字像、用处完全不同，办错时间就是白等两三个月。下面逐个说清。一、软著，不是必须，但上架和维权都靠它 软著就是软件著作权登记，登记中心出个证书，证明这软件是你的。它不是法律法规强制要求的，但安卓应用商店基本都要，华为、小米、应用宝这些主流渠道上架，没软著连提审的入口都没有。苹果商店不强制要，可你要维权、防别人抄，光靠 "我先做的" 说不清楚，证书一摆就明白。 好消息是登记费早就停征了，自己办基本不花钱，普通流程 35 到 60 个工作日，急用也能走加急通道。我的建议是代码冻结、准备发布的时候就去办，别等商店审核提示缺材料才想起来。二、ICP 备案，大陆上线躲不掉 ICP 备案是网站和线上服务在中国大陆上线的前提，说的是 "这个网站是谁的、在哪放着、谁负责"。它是免费的，办的是资质不是交钱。注意两个点：第一，小程序从 2023 年 9 月起强制备案，不备案不给上架，老小程序也得补；第二，备案要留时间，平台初审一到两个工作日，省通信管理局审核一到二十个工作日，顺利一般两到三周，材料被驳回一次就再等一周。 很多项目死在 "功能全做完了才想起备案"，早点把备案材料（营业执照、负责人信息、域名）准备好，和开发并行推进，能省下大半个月。三、别把备案和经营许可证搞混 备案是门槛，说明 "你有这么个线上服务"；经营许可证是 "你要靠它收费经营" 才要办的。做普通展示型官网、内部管理系统，备案就够。一旦业务涉及收费交易、信息发布、在线教育、金融信息这类经营性服务，就要看 ICP 许可证或者 EDI 许可证，电商平台类的业务大多绕不开。 这个判断做错很麻烦。有的老板以为办了备案就能开商城收钱，平台审核时被要求补证，补证又要走几个月的流程。拿不准业务属不属于经营性，做之前就找开发方或者当地通管局的服务窗口问清楚，别等上线前才补。四、商标，越早办越好 商标管的是名字和品牌，软件叫啥、小程序叫啥、公众号叫啥，都可能被人抢注。商标是 "先申请先得"，你用了三年不等于你有权利，别人抢注成功还能反过来告你侵权。整体周期从申请到下证十到十二个月，审查不通过重新再来，又是将近一年。 所以名字一旦定了就赶紧申
上个月有个做电商的老板跟我吐槽，说公司花几万块上了一套 AI 客服，结果客户问包邮吗，机器人答非所问扯了一堆会员积分，三天不到就被下线了。AI 客服这两年特别火，几乎每家做软件的都在推。但落地效果差距很大，有的确实顶用，有的纯属添乱。这篇就把答非所问背后的 4 个原因说清楚，也讲讲怎么判断一套 AI 客服靠不靠谱。一、第一个坑，知识库就没好好整理 很多企业上 AI 客服，就是把一堆产品说明书、售后文档、常见问题 PDF 直接丢进去，然后等着它变聪明。结果机器人一问三不知，或者答得牛头不对马嘴。原因不复杂。AI 客服不是搜索引擎，它是在文档里找答案的。文档里答案藏在长段落中间，机器人就抓不准。客户问法五花八门，文档里没有现成问答对，它就只能瞎猜。 上 AI 客服之前，先花时间把问题整理成问答对。客户会怎么问，标准答案是什么，逐条列出来。知识库整理得越规整，机器人答得越准。这一步省不得，省了后面全是事。二、第二个坑，它听不懂人话 同一个意思，客户有十种问法。问怎么退，问退款流程怎么走，问买了不想要了怎么办，AI 客服要是只认死词，前面三个问题全判成不同意图，答出来就乱套。 这里面有个环节叫意图识别，就是把客户的问法归类，判断他到底想干嘛。意图没调好，机器人就只会背答案，不会看问题。判断 AI 客服听不听得懂人话，有个土办法。把你们客户真的问过的问题拿出来，挑一百条，原样丢给它，看它能答对多少。别看演示，演示永远是挑好的说。三、第三个坑，它没接上你们的业务系统 很多 AI 客服只接了一个壳，脑子里装的还是通用知识。客户问我的订单到哪了，它答不上来。问余额多少，它也答不上来。一问到具体情况，就回一句请稍后，然后没有然后。 真正好用的 AI 客服，是要查系统的。订单查订单库，库存查库存库，工单查工单库。答完还能顺手帮你把售后单开了。这一步要对接业务系统，技术上比前面两步都麻烦，但恰恰是 AI 客服值钱的地方。光会聊天不会办事的 AI 客服，跟个复读机差不多。选型的时候，先问清楚它能不能接你们的订单、库存、工单系统。四、第四个坑，没有人工兜底 AI 客服答不上来，最怕的就是死磕。客户越问越气，机器人还在那儿绕圈子，绕到最后客户直接投诉。合格的 AI 客服，要知道自己答不了。连续几次没把握，就该判断转人工。转人工还要转得快，别让客户等三分钟还没人接。 人工兜底
去年有个做贸易的客户找我，说系统做一半了，想加个审批流。开发报价多出两万，他不理解，就多一个功能，凭什么这么贵。我反问他，这个审批流要跟哪些单据走，要走几级，超时怎么办，他说没想过，领导让加就加。做软件定制这几年，因为需求变更跟客户扯皮的，比因为功能做不出来扯皮的还多。这篇不站队，就把需求变更为什么贵讲清楚，也讲讲怎么让它不那么贵。一、加一个功能，动的是一整条线 客户眼里的加功能，是界面上多一个按钮。开发眼里的加功能，是数据表要加字段，接口要加参数，列表要加一列，详情页要加一块，权限要加一条，报表要跟着调，测试要重新跑。 一个审批流，最少牵动单据、审批、审批人配置、消息通知、操作日志五六个模块。哪个环节漏了，线上就得出问题。所以开发一听加需求就报价，不是想多收钱，是这笔账他算得比你清楚。二、真正贵的不是代码，是推倒重来 需求如果还没动工，加功能只是多写一段代码，成本有限。可大部分变更都发生在开发中段，甚至快验收的时候。这时候加需求，写好的代码要改，对好的接口要调，测过的功能要重测。更麻烦的是数据，有些已经录进去了，表结构一改，数据要迁移、要清洗、要对账。代码本身不贵，贵的是前面所有工作的返工。三、这 3 类变更，最烧钱第一种，改数据结构。今天加个字段，明天改个类型，表结构一变，查询、报表、导入导出全跟着动。第二种，改业务流程。销售流程原来一审，现在要二审三审，审批节点一变，流程引擎、权限逻辑、消息通知全部要重配。第三种，加第三方对接。原本没打算接系统，做到一半要接，接口文档、联调环境、异常处理，每一项都是看不见的工时。这三种变更，报价贵不奇怪，不贵才要担心。四、怎么减少无谓的变更第一，原型先行。开发前先看原型，界面、流程、按钮全摆出来，看得见摸得着，比讲一百遍需求文档管用。第二，签字确认。原型确认后书面留档，后面要改，就有据可依，客户也更能意识到每次变更都有成本。第三，一期只做核心。别想一步到位，先把最核心的流程跑通，上线用起来再迭代。系统用得越久，需求越清楚，返工越少。五、真遇到变更，怎么办 变更躲不掉，怕的是没有流程。规范的开发公司，接到变更会先评估影响范围，给出工时和费用，让客户自己决定做不做、怎么改。影响小的，顺手就改。影响大的，拆成阶段，先做收益最高的那部分。所有变更书面记录，事后对账清清楚楚。需求变更是常态，不是事故。变更管好了，费用透明，进
去年有个做机械加工的老板，花了三十万做了一块数据大屏，挂在厂区大厅里。客户来参观，看着满墙的图表和跳动的数字，觉得这厂子很先进。但问车间主任，他说那玩意儿就是给客户看的，自己从不在上面找数据，有一次库存数据还是错的，传了三天没人发现。 这不是个例。数据大屏这几年火得不行，几乎成了企业数字化的标配，但真正用起来的没几个。这篇不讲大屏有多酷，就讲它到底值不值，什么样的钱该花，什么样的钱是打水漂。一、大屏为什么这么火 先承认，大屏确实有它的价值。老板汇报的时候，一屏数据比十页 PPT 有说服力；客户参观的时候，一块动态大屏比任何口头介绍都直观；政府项目里，可视化大屏更是标配，没有都不好意思汇报。 火的原因也很简单，它把看不见的数据变成了看得见的东西。库存多少、订单多少、设备转没转，一眼就能看到，比翻报表快得多。这种直观感，是报表系统给不了的。 但问题也出在这。很多人只看到了大屏的 "好看"，没看到它背后的 "数据"，以为屏幕一挂，数字化就成了。二、什么样的数据大屏真有用第一类是生产监控类的。车间设备的状态、温度、产量、报警，实时投到屏上，值班的人盯着就能发现问题。这类大屏是给人用的，数据准、更新快，能直接帮管理。第二类是调度指挥类的。物流车队在哪、订单走到哪一步、仓库还剩多少货，管理者靠它做判断。这类大屏连着业务系统，数据是活的，不是摆样子。第三类是汇报展示类的。展厅、会议室、客户参观区，把企业关键数据做成可视化，用于对外展示和内部汇报。这类大屏重在设计感，数据要求没那么实时，但必须准确。 判断大屏值不值，就看一条：它服务的是 "看的人" 还是 "用的人"。给人看的，便宜点就行；给用的，数据底子才是关键。三、哪些大屏纯属浪费钱第一种是数据不准的。大屏上展示的数据和实际对不上，库存显示充足，实际已经缺货，这种大屏不但没用，还会误事。数据源都没打通，屏做得再好看也是摆设。第二种是没人看的。挂在大厅里当装饰，真正管业务的人从不看它，老板一年也开不了几次。花几十万买个静态背景墙，不如把钱投到业务系统上。第三种是为了做而做的。看同行有，政府检查要有，供应商也推荐，自己都没想清楚拿来干什么，就先把钱花出去。这种大屏，做完就吃灰的概率最大。四、做之前，先想清楚这 4 件事数据从哪来？大屏不是设计出来的，是数据喂出来的。你的库存、订单、设备数据，有没有系统在管？数据源没打通
在线
电话
微信
需求
TOP