软件开发公司：按客户预算匹配方案的完整逻辑

核心原则：预算决定技术选型、功能范围、交付标准、售后模式，而不是先做一套方案再砍价。

思路：先拆分成本基线 → 预算分层 → 裁剪功能/替换技术方案 → 锁定范围 → 输出多版本方案，同时标注二期迭代项。

第一步：先算项目最低成本基线（内部）

拿到预算前，公司内部先拆解项目的刚性成本（人力是大头） 项目人力构成（常规定制项目）：产品经理、UI、后端、前端、测试，有的还要运维、接口开发。

人力成本 = 人天单价 × 预估工期 刚性底线：低于这个数，项目就亏本，直接不接，或者引导客户改用低成本方案（模板/低代码）

举例：一套简单企业订单管理系统

• 纯定制从零开发，预估40人天，内部底线成本4万 客户预算如果只有1.5万，不能硬接定制开发，必须换路线，而不是硬砍开发工时。

第二步：预算分级 + 对应方案策略（最常用实操）

档位A：预算＜最低定制成本（小额预算，比如1~3万）

✅ 推荐方案：模板/SAAS + 少量二次修改（低代码优先）

• 技术选型：成熟SAAS平台、低代码（宜搭、简道云、氚云等）、成品源码改UI

• 功能策略：只做刚需，不做底层定制 保留：基础表单、数据录入、简单查询、基础权限 砍掉：自定义复杂报表、复杂业务逻辑、独立部署、服务器、复杂第三方对接

• 交付：快速上线，UI简单微调，不做大改；用平台自带服务器

• 风险说明：平台限制大，业务逻辑不能太特殊；数据归属看SAAS服务商

• 二期：后续有钱了，再迁移到独立定制系统

一句话：不造轮子，拿现成产品改皮肤，满足基础业务。

档位B：预算刚好覆盖基础定制（中等预算，3~10万）

✅ 推荐方案：半定制（核心自研，外围组件复用）

• 技术选型：独立数据库，前后端分离基础框架，开源组件复用

• 功能策略：核心业务自研，次要功能用现成插件 保留：核心业务流程、基础权限、简单接口对接（微信/支付）、独立部署 砍掉：高并发架构、复杂工作流、多端同步（只做Web或小程序一端）、高级数据看板、全量安全渗透测试

• 交付：源码交付，基础测试，提供部署包；服务器客户自备或代采购

• 售后：短期免费bug修复，版本迭代单独收费

一句话：核心业务自己写，通用功能直接用现成组件，压缩成本。

档位C：预算充足（10~50万）

✅ 推荐方案：全定制，预留扩展能力

• 技术选型：独立架构，可扩展，模块化设计

• 功能策略：完整需求落地，支持多角色权限、多接口对接、数据报表、文件存储 保留：Web+小程序双端、完整工作流、日志审计、基础安全加固、完整测试用例 可取舍：不做分布式集群、7×24小时运维、高级BI大屏（可放到二期）

• 交付：完整源码+文档+测试报告，部署培训，3~6个月免费维护

• 预留扩展：架构预留接口，方便后续加功能，不用重构底层

档位D：高预算（50万以上，企业级）

✅ 推荐方案：企业级架构 + 完整配套服务

• 技术选型：微服务、集群、负载均衡、数据库主从、独立安全体系

• 功能：全部需求落地，BI大屏、高并发、多端（PC/小程序/APP）、数据备份、权限细粒度、单点登录SSO

• 附加：安全渗透、压力测试、7×24运维、持续迭代、技术培训、文档全套

• 支持后期大规模业务增长

第三步：同一预算下，做「功能取舍」，而不是压缩质量

同一个预算，有3个方向做取舍（售前必用）

1. 功能裁剪（优先） 把需求分成【P0必须做｜P1一期可选｜P2二期迭代】 P0：核心业务，不能砍；P1能放到二期的，全部剥离出去，二期单独计费。

   示例：客户想做客户管理，预算有限 P0：客户录入、跟进记录、查询 P1：短信通知、客户标签自动统计 → 放到二期开发

2. 技术方案降级（其次） 不改变核心功能，更换技术方案降成本

• 独立服务器 → 云服务器低配版

• 原生APP → 改用H5/小程序打包替代

• 自研报表引擎 → 使用第三方报表插件

1. 交付与售后缩减（最后选项，谨慎用） 减少交付物：精简文档，缩减免费维护周期，去掉免费培训，保留bug修复，绝不减少核心代码质量

   ❌ 禁止操作：压缩测试时间、减少安全校验、写一次性“垃圾代码”，后期极易翻车扯皮

第四步：输出两套对比方案给客户（标准售前输出）

拿到预算区间后，一般输出方案A（精简一期版）、方案B（完整版） 每个方案写清楚：

1. 包含功能清单

2. 技术架构

3. 交付物

4. 价格

5. 不包含哪些（重要！）

6. 二期扩展清单和预估价格

举例：

客户预算5万，需求：客户管理+订单+消息提醒 方案A（4.8万，一期）：PC后台+小程序，客户录入、订单管理；消息通知二期做 方案B（7.5万完整版）：加上短信、自动报表、数据导出高级功能，一期全部做完

第五步：风险标注，提前规避后期扯皮

匹配方案时，必须提前写明限制：

• 哪些需求超出预算，只能二期

• 第三方接口（微信、支付、短信）费用是平台收取，不含在开发费内

• 服务器、域名、SSL证书是客户承担还是包含

• 新增需求如何计价（人天报价）

第六步：预算明显虚高 / 客户预期过低怎么处理

1. 预算远高于需求：不刻意堆功能抬价。可以建议把预算一部分放在安全、性能、文档、运维上，而不是强行增加无用功能；也建议分阶段投入，控制风险。

2. 预算略低于定制底线：不直接拒绝，提供备选路线：低代码/成品系统 + 分两期实施，或者缩减需求范围。

3. 预算差距巨大：直接告知，定制开发成本达不到，推荐SAAS，节省双方时间。

Mermaid流程图（可直接放到PPT）

flowchart LR
    A[获取客户预算+需求] --> B[内部核算项目最低成本基线]
    B --> C{预算 >= 定制基线?}
    C -->|否| D[方案：SAAS/低代码+少量修改<br/>裁剪非核心功能]
    C -->|是| E{预算充足?}
    E -->|中等预算| F[半定制方案<br/>核心自研，复用第三方组件<br/>P0功能一期，其余二期]
    E -->|高预算| G[全定制/企业级方案<br/>模块化、可扩展、完整测试与运维]
    D & F & G --> H[拆分P0/P1/P2需求清单]
    H --> I[输出精简版&完整版两套方案]
    I --> J[标注范围边界、二期价格、不含项]
    J --> K[客户确认，锁定需求范围，立项]

实战要点（很多公司容易踩坑）

1. 不能为了贴合预算降低代码质量，只能裁剪功能、更换技术路线；低价项目代码写烂，售后成本会爆炸。

2. 预算是区间，不是固定死数，比如客户说5~8万，优先按5万做基线方案，8万做增强版。

3. 一定要锁定需求边界，方案写清楚“超出清单的新增需求单独计价”，防止需求蔓延。