行业资讯
上周有个做建材批发的老板来找我，说系统上线四个月，仓库报了个 bug，出库单打印出来的数量对不上。他找开发公司，对方回了句这是新需求，要按变更收费，报价三千。他翻遍合同只看到 “免费维护一年” 六个字，气得想换人。 这种事我一年能碰上七八回，争执的点几乎都一样，合同写了免费维护，为什么修个 bug 还要钱。我的判断比较直接，收不收费跟验收过了多久、跟维护期写没写，关系都不大。决定性的问题是，这个错，在当初就该不该做对。一、先分清它到底是缺陷还是变更 行业里判断缺陷只有一条硬标准，拿已确认的需求文档、原型图、验收清单去对照。文档写了出库单要显示数量，程序显示出来了但算错，这叫缺陷，上线四年也该免费修。文档里压根没提出库单要打印，你现在要用，这是新增功能，收钱合理。 验收单签了字，也不等于开发方从此免责。签字只代表当时看到的功能符合清单，不代表以后发现的所有问题都归客户自己扛。但验收确实是条分界线，清单里明确标着 “本期不做”“二期实现” 的东西，上线后再要，那就是变更，别拿维护期去压对方。 最容易吵的是需求写得含糊那种，比如只写了 “支持库存查询”，没说要区分仓库、要不要显示批次。这种模糊地带谁签字谁吃亏，事后各说各话。我的经验是按业务能不能跑来判，不做这个业务根本走不通，算缺陷；做了更好用但不做也能跑，算优化。二、三分钟能判完的三个对照第一个对照看同类功能。系统里别的列表都能按日期筛选，唯独费用明细不能，这种不用翻文档，就是漏做。同一个系统里两套标准，本身就是开发方自己没对齐，截图发过去，一般没人敢辩。第二个对照看环境。换个浏览器、换台电脑、换个账号登录还是同样的错，大概率是程序问题。只有某一台电脑不行，先查本地缓存、网络、打印机驱动，这一类多半不该算开发方的账，折腾半天发现是客户端版本太老，双方都尴尬。第三个对照看时间线。问题是不是某个版本更新后才冒出来，或者某个第三方接口改版后才出现。版本更新带出来的叫回归缺陷，开发方自己改坏了，免费修没得说。第三方接口变了导致的，属于适配工作，收不收费要看合同当初怎么约定。还有一种常被忽略的情况，数据本身错了。客户自己导了一批错误的基础资料，报表数字跟着离谱，这时候修的是数据不是代码。开发方帮忙可以，按工时收点费用不算过分，别一上来就扣 “系统有 bug” 的帽子。三、真要谈钱，先把 bug 分级 不分级就谈钱，
一、监理不是来盯程序员的，很多人一开始就请错了 我见过一个客户，合同签完就找了监理，要求对方每天去开发公司办公室，盯着程序员写代码，发现 bug 就记下来。监理干了两个月，交了一份三十页的问题清单，开发公司照单全改，项目该延期还是延期，验收会该吵还是吵。 监理这个角色，本来就不管写代码。他管的是你这边的账，需求有没有形成基线、里程碑是不是真的完成、测试报告是谁出的、付款节点该不该签字。技术细节他当然要看，看的是交付物够不够，不是替开发公司做架构方案。 还有一种更常见的误会，把监理当项目经理用。客户自己没人牵头，指望监理组织开会、催进度、协调几个部门。监理没有这个权限，也没有这个义务，他只能把问题摆到桌面上，推不动就是推不动。你缺的是甲方项目经理，不是第三方监理。 请之前先想清楚自己缺什么。缺技术判断，可以请监理或者技术顾问；缺人组织协调，招一个项目经理更直接；缺的是心里那点安全感，多少钱都买不来。二、几万十几万的项目请监理，钱基本白花 小项目有个很明显的特征，一个供应商，标准产品改改，周期一两个月，功能清单二三十条，金额几万到十几万。这种项目请监理，光起步费就吃掉一大块预算。 监理收费一般两种算法，按项目金额的比例，常见的在百分之三到百分之八，或者按人月算。十几万的项目掏两三万请监理，占比接近两成，这笔钱加到测试上，或者压在尾款里，效果都比多一个旁观者强。 这个规模真正管用的是三件事。需求清单写到字段和按钮级别，验收标准写成能一步步操作的用例，尾款留一成到两成压三个月。老板自己花两个下午把这些捋清楚，比请人替你捋更靠谱。 监理的价值来自信息不对称和多方博弈，甲方不懂技术，乙方说了算，才需要有人在中间核对。只有一个供应商、你自己就能拍板的时候，监理没有发挥空间，最后干的活就是把你微信里的意见整理成周报。 钱花了，责任还在你身上。监理签了字，软件出问题照样是开发公司和你之间的事，别指望一张监理报告能顶雷。三、几十万以上、多供应商、政企项目，监理才真正起作用 判断要不要请，看三个条件就够了。合同金额几十万以上而且周期超过三个月，两家以上供应商同时进场，项目要过审计或者用的是财政资金，占上两条就值得认真考虑。 多供应商的场景最值钱。软件商说硬件没到位，硬件商说接口没人给，集成商说这事不在我范围内，三方开会三次没结论。监理把责任矩阵列出来，接口谁提供、字
一、培训要按角色来，别把所有人叫进同一间会议室 很多项目的培训现场是这样的，会议室坐满人，项目经理放 PPT，从登录讲到报表，一口气讲两个小时，下面的人低头看手机。讲完发一份 PDF，签到表一签，培训这一项就算交付完成。 问题在于，不同角色需要的操作根本不是一套东西。老板关心审批卡在谁那里、数据准不准；管理员要管账号、组织架构、基础资料；一线员工只关心自己那五步怎么走；运维要会备份、看日志、重启服务。把这些人放在同一间会议室听同一套内容，结果是谁都没学会。 培训要按角色拆开，小班讲，最好在测试环境里拿真实业务跑一遍。管理员学建账号、配权限、导基础数据；关键用户学本部门的完整流程；一线员工只学自己每天要重复的操作；运维学备份、恢复、日志和故障上报。每类人讲完当场练，练完签字确认。 培训排期也不要挤在上线前三天。管理员和关键用户提前两周学，才有时间导基础数据、核对权限；一线员工在上线前一周学，离实际操作近，忘得少。上线当天再讲，现场只够处理登录问题。 验收标准要落到操作上。让关键用户在没有开发人员站在旁边的情况下，独立完成一笔业务，从录入、提交、审批一直走到出报表。做得下来，才算培训过；做不下来，课时再长也是走过场。二、操作手册要能让人自己查，别只会堆截图 操作手册最常见的做法，是把系统每个页面截一张图，凑成几十页 PDF。培训当天看着很全，上线后没人翻，因为它只告诉人按钮在哪，不告诉人什么时候该点、点错了怎么办。 能用的手册按角色分册，每一册只写这个岗位会用到的流程。每个流程写清四件事，什么情况下用、前置条件是什么、步骤一二三、失败时看哪里。步骤里的菜单名和字段名要和正式环境完全一致，截图不能用开发环境的测试数据。 手册还要能搜索。目录按业务场景排，不按菜单层级排，比如报销、请假、入库、对账，让人从自己要干的事找到页面，不用在系统功能树里猜。常用流程配一个二维码或短链接，贴在工位上，比翻 PDF 快。 交付格式写进合同，给可编辑的源文件，不要只给锁死的 PDF。系统改版后手册要同步更新，很多公司吃过亏，系统升了三个版本，手册还是第一版，新员工照着做全是错的。 手册的更新责任也要有人担。系统每次发版，开发方更新对应章节，客户接口人确认，版本号和系统版本对齐。没有人担这件事，手册三个月就废了。三、异常场景不演练，上线第一周一定乱 正常流程讲得再顺，上
上个月一个做餐饮连锁的老板拿来两份报价，同一个会员系统，功能清单几乎一模一样，一家报 38 人天，一家报 76 人天。他没问技术，只问了一句，这是不是有一家在坑我。我把两份报价拆开对着看了一晚上，结论是都没坑他，这两份报价说的根本不是同一件事。一、一个人天里，装的不只是八小时敲代码 先把计量单位说清楚。人天是工作量单位，一个人干一天算一个人天，但它从来不等于八小时都在写代码。我们内部算有效工时按 6.5 小时，剩下一个半小时是开会、回消息、等环境、被上一版的 bug 打断。有的公司按 8 小时满打满算，有的按 6 小时，同一个项目光口径就能差出两成。 真正占时间的还有很多不写进功能清单的活。需求要一条条捋，原型要跟甲方对，接口要跟前端联调，测试环境要部署，上线那天要有人守着，交付前还要写部署文档和操作手册。这些活不产生页面，也不产生接口，但都吃人天。 拿一个最不起眼的功能举例。手机号登录加验证码，看着半天能做完。实际要接短信通道，要处理验证码有效期和重复发送，要防刷，要写清各种失败提示，要在 iOS 和安卓两端各测一遍，测试环境的域名还得先备案。规规矩矩做完，一个人天打不住。报价里只写「登录模块 1 人天」的，要么是真做过很多遍，要么是没打算把这些算进去。 还有一块最容易吵起来，返工。需求改一次，前面做的一半要推倒重来，改三次的项目我们见过不少。人天报价通常是按需求冻结之后算的，冻结之前改多少次、怎么计价，合同里不写清楚，后面就是扯皮。二、同样的功能，人天数为什么能差一倍 差距通常出在四个地方，跟功能清单没关系。先看是谁来做，一个做过五个会员系统的熟手，和第一次接触这类业务的新人，同样的模块差两三倍很正常。新人未必不行，只是熟手知道哪里有坑，不用边做边试。 再看有没有现成的组件。支付、短信、文件上传、消息推送、权限菜单，这些通用能力如果团队封装过，接进来配一下就行，没有积累的团队，每个项目从头写一遍。复用是合理差价，但要看清复用的是组件还是上个项目的整段代码，后者迟早要还债。 质量要求同样吃人天。能不能扛住活动峰值，有没有操作日志，权限做到菜单级还是按钮级，出问题能不能查到哪一步，这些都不在功能清单上。同一张页面，能点通和能上线是两回事。 最后是甲方配合。素材谁提供，第三方接口谁去谈，验收谁签字，这些问题拖一周，开发就停一周。有的报价把这块风险算
去年有个做物流的客户找我，说他们那套 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 三级要求"，有的甚至把通过测评写进付款条件。 原因也简单，甲方自己也有考核，网络安全出了事要担责，干脆把等保写进合同，让系统方来兜底。你做这类项目，等保就是投标的入场券，不是可选项。三、从定级到测评，要走几步、要多久？ 流程固定四步：定级、备案、建设整改、等级测评，后面还有监督检查。定级要先请专家评审，二级以上都要，然后到公安机关备案，一般几个工作日办完。接下来是建设整改，按测评要求补安全设备、日志和管理制度，这步最花时间，也最容易被低估。最后找有资质的测评机构做测评、出报告。 周期没有固定标准，按我们的经验，从启动到拿到测评报告，顺利也要两三个月，涉及整改多的拖上半年很正常。还有一条硬规矩：三级系统每年至少测评一次，新建的三级系统要先通过测评才能上线运行。四、一般提前做三件事第一件，预算。测评费加整改投入，不同规模差很多，项目立项时就该算进去，别等验收前才发现没这笔钱。第二件，时间。定级备案可以提前走，整改和测评留出两三个月以上，别把等保当成验收前一星期能补的作业。第三件，找对测评机构。测评机构要有公安部认可的资质，各地名单公安网能查，提前问清周期和排期，热门机构年底经常排不上队。说到底，等保不是技术部门的事，是项目能不能顺利验收、款能不能按时收的事。提前把它当回事
在线
电话
微信
需求
TOP