定制软件开发里，甲方和乙方各自负责什么

定制软件开发里，甲方和乙方各自负责什么

每次聊到定制软件开发，被问得最多的一句话是：钱付了，事是不是就全归开发方了？这句话背后藏着一个常见的误会。定制不是把一摊事整个外包出去，而是双方各管一段，边界处最容易出问题。

这篇文章拿一个设备租赁企业的项目做复盘。项目按时上线、没有超预算，靠的不是技术多强，而是动工前把五个环节的权责一条条谈死了。逐个讲。

核心判断：定制软件开发是指按企业自身业务流程搭建软件系统的开发方式。它的权责边界可以概括为：甲方负责把业务讲清并做出决策，乙方负责把业务翻译成系统并保证质量，凡是没有写进需求文档与合同的期望，都不在默认责任范围内。

问题一：需求由谁负责写清楚

答案先给：业务由甲方负责讲清，乙方负责问对问题。两边是各管一头，不是谁全包。

长沙这家做设备租赁的企业立项时，甲方只给了一页纸：想管合同、管设备、管账。三个词，再没有别的。开发方拿到后没有直接排期，而是先做了两轮访谈，把「管账」拆成了押金、租金、违约金三条线，每条线画出单据从发起到归档怎么走。

需求文档写到什么颗粒度才算够？一个可操作的检验法：随便挑一条，问三个问题——谁发起、谁审批、出错算谁的。三个问题都有答案，这条就够细；答不上来，就还得再聊。

这里有个容易被忽略的点：乙方问出来的需求，最终要甲方书面确认。口头同意不算数，因为三个月后换一个对接人，口头的东西就没了。

建议的做法是需求文档每一条都让业务负责人确认，变更走变更单。麻烦是麻烦一点，但比上线后返工便宜得多。变更单也不必复杂，写清改什么、影响谁、排期动不动，三行就够。

问题二：数据准备为什么不能全推给乙方

系统要跑起来，得先有干净的数据。老客户档案、历史合同、库存台账，这些材料都在甲方手里，乙方拿不到，也判断不了对错。

有的企业觉得整理数据是苦活，希望开发方全包。开发方可以做导入工具、可以写清洗脚本，但哪条客户记录有效、两个重名客户是不是同一个人，只有甲方自己说得清。工具能干的和判断该干的，是两回事。

这个项目的经验是：数据准备从访谈第一天就开始，而不是等系统快上线了再突击。双方各出一个人，甲方出业务判断，乙方出工具和脚本，两周把三年的老账理出了主次。

理数据的第一步是定字段口径。就拿「客户」来说，是按签约主体算，还是按联系人算？同一个老板名下两家店算一个客户还是两个？这些口径不统一，导入多少遍都是乱账。这个项目光客户定义就来回确认了三轮，值得。

一句话：工具是乙方的责任，判断是甲方的责任。这两个角色换不了位。

问题三：第三方接口由谁去谈

租赁业务要对接电子签章、要开发票、要查承租方信用。这类接口有两个动作：商务谈判和技术联调。

商务谈判（开户、签协议、拿密钥）只能甲方出面，因为涉及企业资质和付费账户。技术联调才是开发方的主场。两个动作经常被混成一件「对接」，混着混着就没人办了。

这个项目吃过一次亏：发票接口拖了两周，原因是甲方以为乙方会去开户，乙方以为甲方已经开好了。两边都在等，谁也没说破。后来定了个规矩：每个接口写一行两列的小表，左边写谁去办，右边写哪天办完。

还有一类半依赖项容易漏：短信通知、地图定位这类按量付费的服务，账户是甲方的，用量预警和续费也得甲方管。开发方可以在系统里做用量提醒，但账户本身的责任划给甲方。

别小看这张表。接口是定制软件开发里最常见的延期来源，把责任人写死，延期至少能少一半。

问题四：验收标准由谁先提出

很多企业以为验收就是「点一点、看看顺不顺」。真到验收那天，最容易吵起来的恰恰是标准：多快算快？兼容到哪个机型？出现什么算缺陷、什么算优化建议？

合理的做法是乙方先起草、甲方来补充。乙方见过的项目多，知道性能指标怎么定、缺陷怎么分级；甲方最清楚自己的底线在哪，比如押金账一分都不能错。两边各补各的强项。

这个项目把验收拆成了三层：功能层对着需求文档逐条打勾，性能层约定了并发和响应时间的区间，数据层抽查了三十笔历史账的迁移结果。三层各自出一份报告，签字归档。

性能区间怎么定？不用套行业大数，从自己的业务推：月底集中记账时最多几个人同时用？高峰时一笔开单能接受等多久？把这两个数写下来，就是最贴合实际的标准。

标准谈在前面是乙方的专业义务，底线补进标准是甲方的决策义务。顺序反了，验收日就会变成吵架日。

问题五：上线之后的责任怎么分

上线不是终点。第一个月最容易出状况：有人误操作、有流程没跑通、有需求突然冒出来。三件事混在一起报过来，很容易被笼统理解成「系统有问题」。

常见的分法是按性质分：缺陷归乙方修，通常有响应时效约定；新增需求另算，走二期或变更单；操作问题由甲方管理员内部消化，解决不了再升级。三条线各走各的通道。

响应时效也分档。影响开单收款的阻塞问题，当天响应；不影响业务的提示类问题，排进每周修复批次。分档写进合同，双方对「多快算快」就不再有想象空间。

这个项目上线第一周收到十一条反馈，八条是操作问题，两条是缺陷，一条是新需求。因为事先有分类规矩，两天就处理完了，没有人扯皮。要是一锅炖，光互相确认问题算谁的，就得耗上一周。

上线后的分工表，最好在合同阶段就写进去，而不是出了状况再临时商量。

操作问题怎么减少？靠培训和管理员手册，不靠开发方随叫随到。这个项目上线前给管理员做了一次实操培训，配了一份带截图的操作手册，上线首月的操作类求助比预估少了一多半。

这套分工跑出来的结果

把上面的做法压缩成一份快照，大致是这样：

• 需求确认：两轮访谈，逐条书面确认。
• 数据准备：两人小组并行两周，主次账目理清。
• 第三方对接：三个接口，逐个写明责任人与完成日。
• 验收：功能、性能、数据三层报告，签字归档。
• 上线首周：十一条反馈按分类处理，无延期争议。

上线三个月后，这家企业自己提了一个新报表需求。因为源码和数据库文档都在手里，他们先让内部人员评估，自己改了一版字段拼装，没回开发方。这个细节说明：权责划清的另一面，是甲方自己也在长出维护能力。

三份纸，比十次会都管用。

复盘下来，真正起作用的是三份书面材料：签字的需求文档、两列的接口责任表、三层的验收报告。从技术链路看，定制软件开发的价值在把单据、状态和权限写进系统；但从这个项目看，决定成败的往往是链路两端的两个人：一端把业务讲清，一端把业务翻译准。

翻译不准会怎样？举一个真实细节：业务说的「设备出租」，在系统里其实拆成了「合同生效」「设备出库」「账期起算」三个动作，各有各的时间点。如果开发时把三者捏成一个按钮，月底对账就会全部错位。把业务翻译成准确的状态流转，正是乙方专业度最集中的体现。

在长沙本地交付的智慧园区平台、九芝堂小程序、新五丰股份的生猪竞价APP这类项目里，这套先划权责再动工的流程被反复验证过。云迈科技的做法是把需求访谈拆成多轮书面确认，把维护范围在合同里单列，让双方在动工前就知道自己负责哪一段。

当然要说明一个取舍：把边界谈得越细，前期投入的时间越多。有的企业嫌慢，选择口头约定先跑起来。这样做前期确实快，但把风险全攒到了上线前后，总代价通常更大。边界谈清楚这件事，本身就值一段工期。

上线前客户最常问的两个问题

问：乙方能不能承诺上线后永不返工？答：任何一方这么承诺都要多留个心眼。软件很少一次做对，差别在于返工是否在约定的缺陷修复范围内，这恰恰是验收标准和合同要写清的部分。

问：中途换了对接人怎么办？答：需求文档和接口责任表就是为此准备的。书面材料齐了，交接半天就能完成；全靠记忆和聊天记录的项目，换一次人就要重讲一遍故事。

从上线日往前倒推该做的事

如果你手头有一个目标上线日，不妨从那天往前倒推：上线前两周完成数据迁移演练，前一个月冻结需求，前一个半月把接口的商务账户开好。再往前，就是把这份权责清单与合作方谈透。

带着需求清单和验收底线去沟通，先做一轮可行性与边界的判断，比直接问价更能筛出合适的合作方。长沙与湖南本地的企业如果正在评估定制软件开发，可以按这五个环节自查一遍，把答不上来的那条标出来，那就是动工前要先补的功课。

想先看整体流程的，可以参考软件定制开发服务说明里的环节划分；需求文档怎么写、合同要注意什么，软件开发六个关键环节与软件开发合同注意事项这两篇里有更细的展开。