BUYER GUIDE / 选型指南
怎样判断一个定制需求能否沉淀为标准产品？
定制需求只有在问题重复出现、核心流程稳定、差异能够配置、交付和支持可以复用，并且存在持续付费场景时，才可能沉淀为标准产品。
FIELD NOTES / 专业文章
先看判断依据，再把方法带回真实项目。
客户愿意付费，不等于需求可以产品化
单个客户的强烈需求可能来自特殊组织、历史系统或短期政策。定制可以解决这一次问题，但如果下一位客户的角色、流程、数据和验收完全不同，就还没有形成产品。
产品化需要证明问题在不同客户之间重复出现，并且客户愿意为同一类结果持续付费。不能只因为代码已经存在，就假设市场已经存在。
识别稳定内核和可变外层
可以把每次项目拆成核心对象、关键流程、权限、规则、接口和展示。若核心对象与主流程稳定，差异集中在字段、模板、阈值和组织结构，就有机会通过配置解决。
如果差异进入底层数据关系、责任链和验收标准，每次都需要改核心代码，则更接近项目型交付。此时强行标准化，常会形成大量条件分支和难以升级的版本。
第二次、第三次实施是产品假设测试
真正的复用不仅是复制代码，还包括需求问卷、数据模板、部署脚本、培训材料、验收用例、监控和支持流程。每一次新实施都应记录哪些直接复用、哪些需要配置、哪些仍需开发。
这里的“第二次、第三次”是一种验证思路，不是硬性门槛。关键是存在相互独立的场景证据，并且复用比例随着实施增加而提高。
产品化还要通过经营检验
标准产品需要持续维护安全、兼容、文档、升级和客户支持。若每笔收入都被高额售前、定制和人工服务消耗，即使界面统一，也未形成可持续产品。
企业可以保留“产品底座＋标准实施＋必要定制”的结构：稳定能力进入产品，交付过程形成标准服务，真正差异化的部分单独评估。边界越清楚，升级和报价越可控。
SCOPE / 项目范围
先看这类项目通常包含什么。
- 01问题是否重复
多个独立客户是否在相似条件下承担同一种业务损失。
- 02核心是否稳定
主流程、角色和结果是否相对一致，而不是每次重新设计。
- 03差异能否配置
行业、组织和规则变化能否通过参数、模板和扩展点处理。
- 04经营是否成立
销售、实施、支持、升级和续费成本是否允许持续运营。
DECISIONS / 关键判断
开始开发前，先把这些问题回答清楚。
验证独立重复需求
不要把同一客户的多次变更当成多个市场证据。
计算交付复用率
同时观察代码、配置、文档、测试、培训和支持。
设定产品边界
明确标准能力、可配置项、扩展接口和不承接事项。
BOUNDARY / 项目说明
产品化是业务模型变化， 不只是代码重构。
FAQ / 常见问题
从项目走向产品的两个问题
01
有多个客户提出相似功能就够了吗？
还要确认他们的问题、使用角色、付费理由和验收结果相似，避免只看到表面功能名称。
02
应该先做通用平台还是先交付项目？
通常先用受控项目验证稳定内核，再逐步提取配置和标准流程，避免为假设中的通用性过度设计。
NEXT / 继续了解
从相关服务、案例或资料继续判断。
PROJECT CONTEXT / 项目沟通
问题已明确，直接讨论首期范围。
不用先整理完整需求文档，说明当前做法、使用角色、预算与首期目标即可。