我们的六项交付标准

这六条标准分别是什么？

行业常见做法和我们的做法有什么不同？

六条标准逐条怎么理解？

定制开发：开发公司怎么选？

全部项目采用定制开发，不套模板。

• 模板能解决「有个东西能用」，解决不了「这个流程正好是我要的」。业务系统、内部工具、管理后台的核心价值在于贴合实际流程，套模板意味着你在迁就软件的逻辑，而不是让软件适配你的业务。
• 定制的代价是开发周期更长、报价更高。换来的是功能真正可用，不需要在系统上线后再花时间改。

自由技术团队：谁来开发？技术能力怎么保证？

技术栈不做死限制，按项目需求匹配团队。

• 不同项目适合不同的技术组合。工具类项目追求交付效率，营销类项目追求视觉表现，工具型后台追求稳定性。不预先锁定技术栈，而是根据项目特点匹配人员。
• 对客户而言，这意味着你不会因为供应商只擅长某一种技术，而被迫接受不适合的方案。

源码交付：开发完之后代码归谁？

交付完整可运行的源码，不做源码授权限制。

• 项目验收时交付完整可运行的源码，而不是只能在线上使用的系统。源码、部署说明、账号密码一并交接。
• 这意味着后续想换服务商、想自己维护、想在现有基础上继续迭代，都是你的选择，不受制于任何一方。

不转包：会不会转包给第三方？

所有项目由自有团队完成，不转包、不外包。

• 转包的常见问题是需求在传递过程中失真：客户提的需求，中间环节理解一遍，交付方再理解一遍，最后做出来的东西和客户的预期有偏差。
• 不转包意味着需求沟通、方案设计、开发和验收是同一批人，需求理解偏差的风险从环节上被消除。

需求写到合同上，可面谈：需求变更怎么办？能当面沟通吗？

确认的需求写进合同作为验收依据，项目负责人支持面谈对接。

• 需求梳理完成后，形成需求文档并作为合同附件，双方确认后再进入开发。开发按已确认需求执行，验收按合同逐项核对。
• 这一点同时约束双方：客户的需求有据可依，不会被临时推翻；供应商也不能交付一个缩水版本。需求变更有约定流程，不靠口头协商。
• 支持面谈意味着项目负责人直接参与对接，不是转述。软件开发最怕沟通失真，涉及业务逻辑、系统边界、优先级排序时，当面沟通效率明显高于线上沟通。

上线后 12 个月免费维护：上线之后出问题怎么办？维护怎么算？

项目上线后 12 个月内的维护免费，不额外收费。

• 免费维护期覆盖上线后 12 个月，包含系统缺陷修复、运行环境问题排查、微信或应用商店接口变更导致的适配调整。
• 免费维护期内提出的问题不额外计费，这一条写进合同，不靠口头承诺。
• 需要说明的是免费维护与新增功能的边界：缺陷修复属于维护范围，新增功能或需求变更属于新工作，按约定流程单独评估。
• 系统交付时一并提供源码、部署说明与账号交接，客户对系统有完全掌控，不因维护期结束而被绑定。

关于这六条标准，常见问题有哪些？