规则比较特殊
现成软件覆盖不了公司的字段、角色、审批或业务计算方式。
适合什么情况
业务已经存在，
标准产品却总有一段绕不过去。
系统需要打通
多个平台之间重复录入，希望通过接口或数据同步减少人工搬运。
已有明确需求
真实用户、业务流程和负责人基本明确，需要把想法做成可运行产品。
旧系统难维护
原有系统影响业务，但需要先判断保留、改造还是分阶段替换。
交付什么
从需求依据到上线交接，
每一项都有范围。
需求与原型
需求边界、角色流程、页面原型、验收口径和报价范围。
定制系统
按确认范围开发的业务系统、管理平台或内部工具。
接口与数据
必要的第三方接口、数据迁移、权限和操作记录。
源码与交接
约定范围内的源码、部署说明、测试记录和操作手册。
第一步怎么做
先用原型和验收清单，把双方理解对齐。
不急着写代码。先确认真实使用者、关键流程、页面字段、权限、接口和暂缓内容；范围仍然模糊时，先完成需求梳理和原型。
怎么推进
把大项目拆成可确认的小结果。
- 01
确认业务目标
先判断项目解决什么问题、谁会使用、为什么要现在做。
- 02
原型对齐
用页面和流程减少文字理解偏差，提前发现范围问题。
- 03
拆分里程碑
按可运行结果拆阶段，明确每阶段的交付与验收。
- 04
持续展示
开发过程中查看可运行版本，及时处理偏差。
- 05
上线交接
完成测试、部署、操作说明和已知问题记录。
边界与证据
不把范围说模糊，
也不把风险留到最后。
- 不为未经验证、没有真实使用者的想法直接承诺完整产品开发。
- 不接受范围长期不确认、需求随时变化却要求固定成本和工期的合作方式。
- 第三方接口、审核、硬件和历史数据可能影响工期，会单独说明依赖。
- 新增功能先判断对原范围、数据和进度的影响，再决定进入当前阶段或后续版本。
先看原型
在编码前用页面与流程确认理解是否一致。
持续看版本
按里程碑查看可运行结果，不到最后一天才看到成品。
按清单验收
交付内容、已知边界和后续维护都有书面口径。
常见问题
定制开发最怕含糊，先把规则讲清楚。
01只有一个大概想法，可以直接报价吗？
通常不能准确报价。需要先确认目标用户、核心流程、页面范围、接口和验收方式；信息不足时更适合先做需求梳理或原型。
02怎么避免做到一半不断加钱？
合作前会写清范围和验收口径。原范围内的问题负责修正；新增需求说明影响后，由双方确认是否加入。
03开发过程中能看到进度吗？
可以。项目按里程碑提供原型或可运行版本，负责人可持续确认，而不是最后一次性交付。
04源码和部署资料会交付吗？
按合同约定交付源码、部署说明和相关资料；第三方授权或客户未购买的商业资源不包含在内。
05上线后谁负责维护？
会在项目开始前约定质保、日常维护、功能迭代和第三方费用的边界。
说说你的问题，
我们先把第一步想清楚。
不需要准备一份完美的需求文档。说清业务现状、最卡的环节和大致考虑，我们会回复能继续讨论的判断。
在线留言