行业资讯
一、类目选错，代码没问题也过不了 小程序在开发工具里登录、下单、支付都正常，提交审核第二天收到驳回，理由写着服务类目与实际内容不符。团队第一反应是改代码，查接口、换页面、重新打包，改完再提，还是同样的理由。问题不在程序跑不跑得起来，在审核员看不出你到底提供什么服务。 审核员打开小程序，看到的是首页、菜单、下单流程、客服入口。他判断你卖的是餐券、课程、工具还是咨询服务，不会进你的后台看数据库，也不会翻你的源码。首页摆着附近门店和外卖套餐，类目却选了工具，用户举报入口也没有，驳回并不意外。 类目要和实际业务对得上。主营类目选错，后面资质、支付、内容规则都会跟着错。一个程序里混了商城、预约、资讯、会员几块业务，要把每个入口的服务说清楚，该补充类目就补充，该拆就拆。别为了省一次提审，把所有东西塞进一个相近的类目里。 提审前找个不写代码的同事，拿手机从第一屏开始走一遍。让他说这个产品是干什么的，入口在哪里，下单之后谁来服务。他说不清楚，审核员大概率也说不清楚。二、资质和前置审批，缺一项就卡住 有些类目不是选对就能过，还要资质。餐饮要食品经营许可，医疗健康要相关执业资质，教育要办学许可，招聘要人力资源服务许可，直播和短视频要内容资质。缺一项，页面做得再顺也卡在材料这一关。 资质文件不是拍张照传上去就行。主体名称要一致，证件要在有效期，经营范围要覆盖实际业务，授权书要盖公章。连锁门店用总公司资质，要看清楚是否覆盖这家门店。拿一份过期证件反复提交，只会把驳回次数越积越多。 前置审批要看业务实质。你写预约到店，实际做上门服务，类目和资质都可能对不上。你写知识付费，实际卖保健品，审核不会只看标题。页面上的服务说明、下单流程、客服话术，都会影响审核员对业务性质的判断。 提审前把资质清单拉出来，一项一项对。缺的先去办，不要拿审核当试错。每驳回一次，版本节奏就往后拖几天，活动档期也可能错过。资质这种事，提前问清楚比事后补材料省时间。三、隐私协议和权限，审核员会逐项看 隐私保护指引不是随便填几句。小程序收集手机号、位置、相册、摄像头、剪贴板、设备信息，都要说明用途、方式和范围。用了第三方 SDK，也要把 SDK 收集的信息写进去。页面实际采集什么，指引里就要有什么。 审核员会拿页面行为对照指引。你申请了位置权限，页面却没有定位功能，或者一进来就弹授权，都会被挑出来。权限申请
上周有个做本地生活小程序的客户找我，说订阅消息发了几百条，点击率不到百分之一。运营团队把文案改了十几版，标题从「您的订单有新动态」换到「别错过这次优惠」，结果还是一样。我让他们把授权数据拉出来，第一次弹窗的拒绝率超过七成，后面根本没有发送资格。 很多团队把订阅消息当成群发工具，用户一进小程序就弹授权，注册完再弹一次，下单后还弹。用户还没用到服务，先被要一个权限，第一反应就是点拒绝。拒绝一次，后面再想发消息，成本就高很多。 小程序订阅消息的规则不复杂。用户点一次授权，你才能发一条对应模板的消息。一次性订阅发完就消耗掉，长期订阅要用户主动勾选「总是保持以上选择」。用户没勾，你手里就只有一次机会。一、第一次弹窗就伸手，用户只会点拒绝 第一次授权最忌讳在用户没做事之前弹。用户刚打开小程序，还在找入口，你问他要不要接收通知，他不知道你要发什么，也不知道同意了有什么好处。这个时候的授权率，通常是最难看的。 更合适的时机，是用户刚完成一个明确动作之后。提交预约、下完单、填完表单、领完券，这些动作后面本来就有服务通知的需求。你在结果页告诉他，授权后能收到预约确认、发货提醒、审核结果，他知道这条消息跟自己有关，点允许的概率会高很多。 授权文案也别写「接收通知」四个字。写成「预约成功后，我们会通过微信通知您到店时间」，用户知道消息长什么样，点允许时心里有数。文案越长越像广告，越具体越像服务。 有些产品喜欢一次把所有模板都申请一遍，订单、活动、积分、系统公告全塞进弹窗。用户看到一长串权限，只会觉得你要天天给他发广告。一次只申请当前场景真正要用的模板，后面的场景到后面再补，授权率反而更稳。二、模板选错，发出去的消息像骚扰 有些团队拿到发送权限后，第一件事是发促销。新品上架、限时折扣、活动倒计时，全都往订阅消息里塞。用户授权的是订单提醒，收到的却是广告，下一次他不会再看，严重的还会点投诉。 订阅消息适合跟服务动作绑在一起。订单支付成功、预约时间快到了、审核有结果、服务即将到期，这些消息用户本来就在等。模板标题写清楚发生了什么，时间、地点、状态放在该放的位置，别堆一堆用不上的字段。 发送时间也要克制。用户刚授权就收到一条欢迎消息，容易觉得自己被盯上了。把第一条消息留到他真正需要的节点，比如预约前一天、订单发货当天，消息才有用。 跳转也要跟着场景走。订单消息点进去就到订单
项目验收后的第三个月，一种很常见的交接现场是，客户那边的 IT 主管提了离职。新来的人第一次进机房，先问服务器密码在哪。运维翻了两小时聊天记录，最后在一个已经退群的同事头像下面找到。系统没坏，业务也没停，但接手的人已经知道，这活不好接。 很多公司以为项目上线就结束了。合同签了，验收单也签了，原团队撤场，后面的事交给客户自己的 IT 或者另一家服务商。真正难的阶段从这时开始。代码在，服务器在，数据库也在，可系统怎么跑起来、出了问题先看哪里、哪些操作不能碰，没人说得完整。一、人走了，系统里断掉的不只是人手 很多交接文档写得很厚，目录也漂亮。打开一看，前半本是需求说明书，后半本是数据库表结构，真正要用的东西没有。生产环境怎么部署，定时任务在哪台机器上跑，证书什么时候到期，第三方后台谁有管理员权限，出了问题先找谁。这些内容不在文档里，平时也没人记。 一项对 133 个流行 GitHub 项目的研究发现，65% 的项目只要走掉两个核心开发者就会停摆。研究里把这叫卡车因子，意思是最少几个人离开，项目就会停。开源项目有公开代码和历史记录，仍然会这样。企业项目更依赖现场环境、客户口径和历史补丁，人员一走，断掉的地方只会更多。 更麻烦的是，很多知识没有写下来的价值。某个报表每月月末要手工重算，因为财务口径改过；某个客户订单超过十万要走特殊审批，因为当年出过事；某台服务器重启后要先起某个服务，不然接口会超时。这些动作不在代码里，也不在需求文档里，只在原来那个人的习惯里。 新人接手后，最常听到的一句解释是，之前就是这么处理的。再问为什么，没人知道。系统还能跑，判断却断了。一个人请假，项目还能顶住；一个人离职，整条链路就开始发虚。二、交接清单里，文档只占一行 交接要把一套系统交到别人手里，还得让这套系统继续做变更。文档只能说明设计，账号、环境、权限和判断标准才决定接手的人能不能动手。很多项目交接做了三天，结果只留下一个网盘链接，链接里的文件还没人打开过。 先盘账号。服务器、数据库、云平台、域名、SSL 证书、短信、支付、地图、对象存储、日志平台、监控平台、堡垒机、VPN，每一个都要写清用途、当前持有人、管理员是谁、什么时候到期。很多项目出问题，原因不在代码，证书过期、短信欠费、支付密钥没人更新，都会让系统停。 再盘环境。测试环境和生产环境差在哪，配置文件有哪些，密钥放在
我们做外呼项目时，最常见的一种上线方式是这样。系统上线第一周，运营看板上的接通量、通话时长、意向客户数都在涨，业务部门很兴奋，觉得终于把人力成本压下来了。到了第三天，客服主管开始接到回拨电话。有客户说同一件事被问了三遍，有客户说按 9 转人工按了半分钟没人接，还有客户开口就问，你们是不是机器人。原本指望外呼分担客服压力，结果客服先被外呼带来的电话堵住了。 这类投诉很少只由一个原因引起。电话打得太密，号码被标记，名单重复，话术太长，身份没交代清楚，转人工藏得太深，任何一个环节出问题，客户都会挂断或者投诉。智能语音外呼把拨打成本压得很低，原来一个坐席一天打两百通，现在一台机器一天能拨上千通，错误也会跟着放大。客户感受到的，往往只有反复打扰。一、先分清三类外呼，投诉口径不一样 外呼先要分清办的是哪件事。服务通知、客户回访、营销触达，三类的边界不一样，客户预期也不一样。服务通知是订单变化、物流异常、预约提醒、欠费提醒这一类，客户基本知道这通电话跟自己有关。客户回访是售后回访、满意度回访、续费提醒，前提是客户跟公司已经有业务关系。营销触达是新产品、新活动、新线索，客户没有主动要，抵触感天然更高。 三类混在一条线路、一套话术、一个号码池里，投诉就会串在一起。客户刚下完单，接到一个号码，前面说订单异常，后面开始推会员卡。客户会觉得自己被套路了，下次看到同一个号码直接挂断。服务通知的号码被营销用脏以后，真正的订单提醒也打不出去，业务部门还以为是接通率下降。 服务通知可以自动化程度高一些，话术短，信息准，重点是让客户听清楚发生了什么、下一步怎么办。客户回访要先了解上下文，知道客户买过什么、用到哪一步、上次的问题有没有解决。营销触达要更克制，先确认客户有没有接收意愿，再决定打不打、什么时候打、打几次。 很多团队的问题出在任务命名上。内部叫客户关怀，实际话术是卖套餐。内部叫服务回访，实际开场是免费领取权益。客户挂断以后，投诉分类写成了服务态度差，真正的根因被盖住了。任务名称可以内部统一，客户听到的内容必须跟任务名称对得上。 把三类任务分开以后，号码、话术、频控、指标也要跟着分开。服务通知用服务号码，营销触达用另一组号码，回访用回访专线。客户在一个任务里明确拒绝，拒绝记录要在同一通电话里落库，不能等坐席下班再补。第二天另一个任务再打过去，客户只会记得你们说话不算数。 监管
很多项目现在是这么干的。设计用 AI 出三张产品主图，运营用 AI 写五条详情页文案，开发用 AI 补一段接口代码。图发到官网，文案上了店铺，代码跟着版本交付。等到客户问一句，这些东西版权归谁，能不能商用，被别人搬走怎么办，现场往往没人能答完整。 大家习惯把 AI 当成一个作者。著作权法里能当作者的只有自然人、法人或者非法人组织，模型本身不行。AI 出图、出文案、出代码，最终还是要看人在里面做了什么。版权就是著作权，下面两个词混着用。先把归属、训练数据、合同、分类这四件事捋一遍，再谈怎么用，边界得自己定，不能等出了事再补。一、AI 生成物不一定有版权，先看人的贡献 北京互联网法院判过一个 AI 出图的案子。原告用 Stable Diffusion 生成古风人物图，提示词改了几十轮，参数也反复调，最终选定一张发到小红书。图被别的账号拿去配文，还抹了署名水印，法院认定这张图有独创性，原告享有著作权。 另一个案子走向相反。张家港市人民法院审的「幻之翼透明艺术椅」，原告只输入了简单提示词，拿不出完整的创作过程记录。法院认为提示词停留在思想层面，生成结果没有体现足够的人类智力投入，没把那张图认定为作品。 两个案子放在一起看，分界线不在用没用 AI，在人做了多少选择。提示词怎么设计，参数怎么调，生成了几版，为什么选这一版，后面有没有再改，这些动作能不能留下记录，直接影响法院怎么看。 只写一句「帮我画一张科技感海报」，然后从结果里挑一张，风险很高。反过来，先定构图、色调、主体、文字位置，再反复改，再人工修图，人的贡献更容易被看见。改了什么、改到什么程度，最好有分层文件或者版本记录。 代码也按这个逻辑看。AI 吐出来的代码不自动带著作权，人在需求拆解、结构设计、关键逻辑修改、测试验收里做了多少，才是重点。文案更吃人的判断，一句广告语可能因为太短，达不到独创性门槛，一篇有自己结构、案例和观点的长文，情况会不一样。 不管有没有版权，过程记录都要留。提示词、参数截图、生成版本、修改记录、最终选定理由，能存就存，法院看证据，不听口头解释。如果生成物没有被认定为作品，合同还可以约定保密和使用限制，商标、商业秘密、反不正当竞争也能用，只是路径不同。二、训练数据来源不清，商用风险谁承担 企业多数时候不自己训练模型，直接用第三方工具。工具的用户协议常写「输出内容归用户使用」，很
先看一个很常见的场面，一个做设备销售的客户，合同审批、发货、开票都搬进了系统。月底财务把一张报销单退回去，理由很简单，附件里只有一张发票截图，没有原始文件。销售说系统里就有，财务打开一看，确实只有一张 JPG。 另一头，销售用电子签章签了一份合同，法务让他补盖公章。销售说系统里有签章记录，法务把合同打印出来，纸上没有红章，心里不踏实。系统明明上了，财务还在手工登发票、跑查验平台、追着销售要合同原件。 电子发票和电子签章接进系统，接口调通只是开始，财务敢不敢认才是后面的难题。财务认的是能验真、能追责、能归档的凭证，一张图和一个红章图案不够。下面这四件事没补齐，系统上线了，财务还是会退回手工流程。一、财务要的不是一张图片，是能验真的发票原件 很多业务系统接发票，只做了一个上传附件的框。销售把发票打印出来拍照，或者从邮箱里存一张 JPG 传上去，流程就算走完了。财务拿到这种附件，第一件事是去全国增值税发票查验平台手工查，第二件事是翻报销记录，看这张票有没有人报过。 发票截图有两个硬伤。它没有原始电子文件，查验平台能查到票面信息，查不到这张图有没有被改过。它也没有发票号码、开票日期、金额税额、购销方信息的结构化字段，财务没法自动对账，只能对着屏幕一笔一笔敲。 重复报销是另一个麻烦。同一张票换个人、换个项目再传一次，系统也看不出来。供应商红冲了、作废了，业务单据还挂在那里，财务到月底对账才发现。发票查验不能只做一次，报销前、付款前、归档前都要能重新查，红冲和作废要能回写业务单据。 电子发票的原始文件通常是 PDF、OFD 或 XML，不同开票渠道给的东西不一样。业务系统要存原始文件加结构化字段，最好再接发票查验接口，把验真结果、发票状态、红冲和作废信息一起拉回来。财务在系统里点一下就能看到查验结果，才愿意把手工查验这一步去掉。 发票查验接口拿回来的不只是一句真伪。发票号码、开票日期、金额、税额、销售方和购买方信息，要能落到业务单据的字段里。财务审核时看到的是可筛选、可汇总的数据，不是一张需要放大看的图。供应商换了开票信息，系统要能提示抬头或税号不一致，别等付款后才发现票开错了。二、电子签章，红章图案只是表面 有些系统里的电子签章，就是一张透明 PNG 盖在合同上，谁都能拖上去，大小还能随便拉。这种东西打印出来好看，真出纠纷，拿不出签署人身份、签署时间，也说
去年有个做园区物业的客户，为了压预算，把新访客系统拆成四块。门禁硬件给一家，访客小程序给一家，后台管理给一家，短信和电子发票再给一家。四份合同分别签，项目群拉了六个，平时对接的是老板的行政。 上线前一周，门禁刷卡的记录进不了后台，访客在门口等，保安拿纸质本子登记。硬件商说只保证刷卡开门，小程序公司说接口按文档写的，后台公司说字段对不上，短信服务商说模板还没过审。会开了三次，每家公司都能拿出自己没做错的证据，整条链路却停在那里。一、拆包本身没错，错在没人当总包 很多甲方拆包，是为了压价，也为了找更专业的公司。硬件找做硬件的，小程序找做界面的，后台找做数据的，听起来每一块都更划算。合同一签，各自的功能都能做，拼在一起却没人对最终结果负责。拆得越细，接口越多，没人管的地方也越多。 每家公司的责任边界，通常只写到自己的合同范围。硬件商负责设备能刷，软件公司负责页面能开，后台公司负责接口能通。至于刷卡之后记录怎么进后台，访客信息怎么同步给保安，异常时谁先排查，合同里没有一个人名。 这时候需要一个总包角色。总包可以是一家开发公司，也可以是甲方自己指定的项目经理，还可以是第三方。形式可以变，三样东西不能少，接口清单的确认权，联调排期的决定权，验收单上的签字权。没有这三样，总包只是一个称呼。 有的甲方找一家公司做总包，合同里只写收几个点管理费，实际工作还是各家干各家的。这样的总包只多了一道转手，出事时照样找不到人。总包合同要写清它对整体交付负责，分包款由它结算，接口扯皮由它裁决，延期也要算它的责任。总包还要审核分包的技术方案，不能等出了事再拉群。 如果甲方自己当总包，别让行政兼职传话。行政能约会议、能收发票，但压不住四家公司的技术负责人。至少要给这个项目指定一个能拍板的人，老板要明确授权，不然他在群里说的话，别人只当建议。二、合同里最该写死的，是接口边界和交付物 四份合同里最常见的一句话，就是配合甲方完成联调。这句话看着礼貌，实际没有约束力。有的合同写提供标准接口，标准是谁的标准，也没有下文。 接口清单要单独做一份附件，不能只放在聊天记录里。清单上至少写清五件事，接口地址和调用方向，字段名称和类型，数据多久同步一次，鉴权和失败重试怎么处理，测试环境和上线时间。每一行后面要有提供方和确认人。这张表由总包起草，甲方确认，各家签字。 付款节点也要挂到接口上。硬件到货
去年有个做物业的客户找我，问要不要招个程序员。公司刚上线一套收费和报修系统，开发公司在外地，平时微信沟通。老板说自己不懂技术，底下也没人懂，每次开会只能听对方讲，讲完了也不知道该问什么。 我问他，招来的人具体干什么。他想了一会儿，说帮着改改代码，顺便管管服务器。再问服务器在哪、谁在续费、数据库有没有备份，他叫来行政，行政翻了半天手机，只找到一张云厂商的账单截图。一、先分清，你要的是程序员还是技术管家 很多老板一问就是「要不要招个程序员」，真聊下去，自己也说不清招来干什么。改代码、管服务器、盯进度、验收、跟开发公司对接，这些活看着都跟技术沾边，实际是几种不同的岗位。 写代码的人最贵，而且一个人撑不起一套系统。前端、后端、数据库、服务器、支付接口，随便一块出问题，都得有人接。小公司招一个程序员，多数时候是让他修电脑、导表格、催外包，代码没写几行，工资一分不少。 多数甲方真正缺的是另一种人。他不用会写代码，但看得懂方案，知道报价单里少了什么，能判断开发公司说的「这个做不了」是真做不了，还是不想做。项目上线前，他能把验收清单、备份、账号、续费一项项盯住。这种角色，有的公司叫技术负责人，有的叫 IT 主管，也有公司让产品经理兼着。 前年还有一家做建材贸易的，老板招了个刚毕业的程序员，月薪一万二。干了半年，人每天忙着给仓库装打印机、帮财务导数据、替开发公司复现 bug。后来老板把专职辞了，换成一个月来两天的兼职顾问，验收和账号反而理清楚了。人不是越多越好，得看放在哪个位置。二、这几种情况，别再让行政兼着对接 行政兼着对接，在小项目前期还能撑。合同签了，系统上线，事情一多，问题就藏不住。不是行政不认真，是很多事超出了这个岗位能判断的范围。第一种信号，是系统数量上来了。一套 OA、一套进销存、一个小程序，再加上公众号和支付后台，彼此还有数据往来。今天这个登不上，明天那个对不上账，行政只能挨个问，问到最后自己也不知道该找谁。第二种信号，是钱花得有点分量了。每年云服务器、短信、域名、维护费加起来，已经超过一个岗位的工资。这笔钱花在哪、该不该花、明年会不会涨，得有一个人能拉出账单，跟供应商对一遍。第三种信号，是系统开始碰客户数据和钱。生产服务器上有订单、有会员手机号、有支付接口，出了事不是「页面打不开」这么简单。备份有没有做、权限给了谁、离职的人还能不能登，这些没人管，迟
去年冬天，一个做仓储的客户给我打电话，说原开发公司关停了。微信群里最后一条消息是对方老板发的，说公司不做了，后续有问题找技术负责人。他打过去，号码已经停机。系统还在跑，出入库、对账、司机排队都在用，但服务器在哪、数据库密码是什么、域名挂在谁名下，没人说得清。 他最初的想法很简单，把代码要到手，再找个人接着维护。真开始接才发现，代码只是一个压缩包，解压出来跑不起来。配置文件是空的，证书过期了，定时任务停在旧服务器上，短信和地图的账号还是用原公司名义注册的。 这类事这两年听得越来越多。开发公司规模小，抗风险能力弱，团队一散，项目就成了孤儿。接手的人不是不努力，是根本不知道有哪些东西需要接。一、先接住「能跑」，别急着接代码 交接其实分三层。最下面是能跑，业务今天不断；中间是能改，代码能编译、能部署到新机器；最上面是能维护，账号、备份、监控都在自己手里。很多老板一上来盯的是代码，结果最下面那层先塌了。 先确认几件最急的事。服务器现在谁能登录，域名和证书续费到哪一天，数据库有多大、备份放在哪，有没有监控和报警。今天夜里出故障，电话该打给谁。这些问题的答案，比源码放在哪个仓库重要得多。 我见过一个客户，代码拿到手，部署时发现系统依赖一个已经停服的短信通道，接口调不通，验证码全发不出去，业务停了半天。后来查出来，短信账号是用原公司员工手机号注册的，人走了，验证码收不到，账号也找不回来。二、代码之外，还有四样东西在别人手里第一样是环境和配置。数据库连接、缓存地址、对象存储的密钥、支付回调地址、第三方接口的 appid 和 secret，这些通常写在服务器的环境变量或者配置文件里，不在代码仓库里。还有 SSL 证书、定时任务、消息队列、webhook 地址，少配一个，系统就少一块功能。第二样是数据和备份。数据库账号密码只是入口，真正要接的是备份策略。每天几点备份，备份文件放在哪，保留多少天。最怕的是备份有，但从来没恢复过。真出事的时候才发现备份文件损坏，或者恢复出来少了最后三天的订单。第三样是第三方账号。域名、云服务器、小程序和公众号、微信支付商户号、短信签名、地图授权、CDN、OSS，这些账号大多挂在原公司或者原公司员工名下。给密码不等于能接手，很多要过户。小程序主体变更要审核，支付商户号变更要重新签协议，域名备案主体不一致，后面续费都麻烦。第四样是文档和知识。部署文
上个月一个做建材批发的客户，把合同和结算单一起发给我。合同总价 18.6 万，最后付了 23 万多，多出来的四万多，大半落在报价单最后一行，四个字，「其他费用」。 他说签的时候问过这行是什么，对方回答先做着看，发生多少算多少，都是实报实销。听着挺合理，做完才发现这行没有清单，也没有上限，今天一笔短信签名报备，明天一趟现场部署，后天一笔旧数据清洗。每笔都不大，加起来比一个功能模块还贵。 「其他费用」本身不是骗人的。项目里确实有说不准的开支，谁也没法在开工前把每一分钱算死。问题在于，这四个字把「说不准」写成了「不用说明」，签字的时候双方都不知道这个口袋有多深。一、这四个字，为什么容易变成口袋 报价单按模块报，模块能数页面、数角色、数报表。到了收尾，总有些东西数不清，销售又不想把总价写得太高，就往最后一行一放，写个「其他费用」，具体多少不写。 这一行最省事的地方在于，它没有计量单位。服务器能按年算，短信能按条算，数据迁移能按张表算，其他费用按什么算，没人说得清。没有单位，就没有比价的基础，三家报价单拉到一起，这行只能空着。 更麻烦的是，三类钱经常混在一起。一类是确定会花、只是没算进模块的，比如首年服务器和域名证书；一类是可能花、要看现场情况的，比如接口联调和历史数据清洗；还有一类是开发方本来就该做的，比如部署、培训和验收范围内的修改。 三类钱混在一个词里，结算的时候就有了操作空间。甲方拿着一行总数，不知道哪笔该付、哪笔不该付，只能听对方解释。解释一次两次还行，项目做了半年，谁还记得当初是怎么说的。二、拆开看，里面通常装着四类钱第一类是账号和资质。域名、SSL 证书、微信认证、小程序主体认证、APP 开发者账号、地图商用授权、短信签名和模板报备，还有软件著作权和 ICP 备案的代办服务。单笔看着都不大，几百到几千，但没人提前列，最后就都从「其他」里出。第二类是资源和流量。云主机、数据库、带宽、对象存储、CDN 流量、短信条数、实名认证和 OCR 的调用量、电子签的份数。这些东西第一年常常由开发方垫着或者送一点，第二年续费就是甲方自己的事，报价单上不写清楚，预算里很容易漏掉。第三类是数据迁移。旧系统导数据、字段对应、历史数据清洗、重复客户合并、附件和图片搬过来，这些活最容易被低估。表少、数据干净，几天能做完；表多、字段乱、还有一堆手工补录的脏数据，做一个月也收
上周有个做建材批发的老板来找我，说系统上线四个月，仓库报了个 bug，出库单打印出来的数量对不上。他找开发公司，对方回了句这是新需求，要按变更收费，报价三千。他翻遍合同只看到 “免费维护一年” 六个字，气得想换人。 这种事我一年能碰上七八回，争执的点几乎都一样，合同写了免费维护，为什么修个 bug 还要钱。我的判断比较直接，收不收费跟验收过了多久、跟维护期写没写，关系都不大。决定性的问题是，这个错，在当初就该不该做对。一、先分清它到底是缺陷还是变更 行业里判断缺陷只有一条硬标准，拿已确认的需求文档、原型图、验收清单去对照。文档写了出库单要显示数量，程序显示出来了但算错，这叫缺陷，上线四年也该免费修。文档里压根没提出库单要打印，你现在要用，这是新增功能，收钱合理。 验收单签了字，也不等于开发方从此免责。签字只代表当时看到的功能符合清单，不代表以后发现的所有问题都归客户自己扛。但验收确实是条分界线，清单里明确标着 “本期不做”“二期实现” 的东西，上线后再要，那就是变更，别拿维护期去压对方。 最容易吵的是需求写得含糊那种，比如只写了 “支持库存查询”，没说要区分仓库、要不要显示批次。这种模糊地带谁签字谁吃亏，事后各说各话。我的经验是按业务能不能跑来判，不做这个业务根本走不通，算缺陷；做了更好用但不做也能跑，算优化。二、三分钟能判完的三个对照第一个对照看同类功能。系统里别的列表都能按日期筛选，唯独费用明细不能，这种不用翻文档，就是漏做。同一个系统里两套标准，本身就是开发方自己没对齐，截图发过去，一般没人敢辩。第二个对照看环境。换个浏览器、换台电脑、换个账号登录还是同样的错，大概率是程序问题。只有某一台电脑不行，先查本地缓存、网络、打印机驱动，这一类多半不该算开发方的账，折腾半天发现是客户端版本太老，双方都尴尬。第三个对照看时间线。问题是不是某个版本更新后才冒出来，或者某个第三方接口改版后才出现。版本更新带出来的叫回归缺陷，开发方自己改坏了，免费修没得说。第三方接口变了导致的，属于适配工作，收不收费要看合同当初怎么约定。还有一种常被忽略的情况，数据本身错了。客户自己导了一批错误的基础资料，报表数字跟着离谱，这时候修的是数据不是代码。开发方帮忙可以，按工时收点费用不算过分，别一上来就扣 “系统有 bug” 的帽子。三、真要谈钱，先把 bug 分级 不分级就谈钱，
一、监理不是来盯程序员的，很多人一开始就请错了 我见过一个客户，合同签完就找了监理，要求对方每天去开发公司办公室，盯着程序员写代码，发现 bug 就记下来。监理干了两个月，交了一份三十页的问题清单，开发公司照单全改，项目该延期还是延期，验收会该吵还是吵。 监理这个角色，本来就不管写代码。他管的是你这边的账，需求有没有形成基线、里程碑是不是真的完成、测试报告是谁出的、付款节点该不该签字。技术细节他当然要看，看的是交付物够不够，不是替开发公司做架构方案。 还有一种更常见的误会，把监理当项目经理用。客户自己没人牵头，指望监理组织开会、催进度、协调几个部门。监理没有这个权限，也没有这个义务，他只能把问题摆到桌面上，推不动就是推不动。你缺的是甲方项目经理，不是第三方监理。 请之前先想清楚自己缺什么。缺技术判断，可以请监理或者技术顾问；缺人组织协调，招一个项目经理更直接；缺的是心里那点安全感，多少钱都买不来。二、几万十几万的项目请监理，钱基本白花 小项目有个很明显的特征，一个供应商，标准产品改改，周期一两个月，功能清单二三十条，金额几万到十几万。这种项目请监理，光起步费就吃掉一大块预算。 监理收费一般两种算法，按项目金额的比例，常见的在百分之三到百分之八，或者按人月算。十几万的项目掏两三万请监理，占比接近两成，这笔钱加到测试上，或者压在尾款里，效果都比多一个旁观者强。 这个规模真正管用的是三件事。需求清单写到字段和按钮级别，验收标准写成能一步步操作的用例，尾款留一成到两成压三个月。老板自己花两个下午把这些捋清楚，比请人替你捋更靠谱。 监理的价值来自信息不对称和多方博弈，甲方不懂技术，乙方说了算，才需要有人在中间核对。只有一个供应商、你自己就能拍板的时候，监理没有发挥空间，最后干的活就是把你微信里的意见整理成周报。 钱花了，责任还在你身上。监理签了字，软件出问题照样是开发公司和你之间的事，别指望一张监理报告能顶雷。三、几十万以上、多供应商、政企项目，监理才真正起作用 判断要不要请，看三个条件就够了。合同金额几十万以上而且周期超过三个月，两家以上供应商同时进场，项目要过审计或者用的是财政资金，占上两条就值得认真考虑。 多供应商的场景最值钱。软件商说硬件没到位，硬件商说接口没人给，集成商说这事不在我范围内，三方开会三次没结论。监理把责任矩阵列出来，接口谁提供、字
在线
电话
微信
需求
TOP