先把问题讲清楚，再谈解决方案
这次产品信息管理项目真正困难的部分，不是接口实现，而是先确认哪些问题值得解决，以及未来希望怎样管理产品数据。
- 专业方向
- 业务分析
- 项目类型
- 已匿名的真实项目
概览
这个项目最初看起来像一次典型的系统实施：引入产品信息管理平台，连接现有企业系统，再把分散的产品数据集中起来。 如果只看项目名称，难点应该是接口、字段对应和数据同步。
实际做下来，技术实现反而是后面相对直接的一部分。真正花时间的，是让不同部门对几件事达成一致：产品数据到底代表什么，哪些日常不便是真正需要解决的问题，以及新平台以后应该支持怎样的工作方式。
前面这些问题没有说清楚，接口做得再快，也只是把旧问题搬到新系统里。
背景
客户希望建立统一的产品信息中心，同时继续与原有企业系统交换数据。
问题在于，不同部门虽然都在处理同一批产品，却未必在说同一件事。市场团队关心客户看到什么，产品团队关心商业结构，信息技术团队关心系统边界，数据专家则最了解多年积累下来的特殊情况。
原有企业系统里，一个库存单位的定义本身就可能包含多个业务变体。简单地把一个字段对应到另一个字段，并不能解决这些含义上的差异。
所以，这个项目后来不只是“怎样连接系统”，而是“以后大家准备怎样共同管理产品信息”。
定义问题
客户在讨论中首先说出来的，通常不是已经整理好的业务问题，而是各种日常不便：某个步骤太慢，某项属性总要反复修改，一个产品定义经常引发误解，或者某段流程用起来很别扭。 我们没有立刻把这些意见写成需求，而是先把它们当作线索。
每次讨论结束后，咨询团队会重新梳理：哪些不便背后是真正的业务痛点？哪些只是旧系统造成的限制？哪些做法只是沿用多年，却未必值得继续保留？
下一次和客户见面时，我们先确认这些判断，而不是直接展示方案。我们会问：这些真的是最需要解决的问题吗？有没有更重要的情况被忽略了？ 只有双方对问题本身达成一致，方案设计才继续往下走。
做出决定
不同问题需要不同的人参与。我们没有让同一批人参加所有会议，而是根据当次需要做出的决定，邀请真正了解影响和后果的人。
业务事实掌握在客户手里，平台能力掌握在咨询团队手里。最终的数据模型不是任何一方单独设计出来的，而是在两种专业知识不断确认和修正中形成的。
验证决定
一个业务痛点确认以后，我们没有马上写完整规格，而是先在开发环境中把拟议模型配置出来。
然后让未来真正使用系统的人自己操作：创建产品、维护属性、按新的流程完成日常任务。
这一步很重要，因为“听起来合理”和“真正用起来合理”完全是两回事。
有些配置一上手就能确认方向没有问题；有些则会马上暴露之前讨论中没有发现的摩擦。用户亲自操作时，反馈通常比看演示更具体，也更接近真实工作。 所以，配置在这里不只是实施准备，它本身也是一种验证方法。
结果
业务模型稳定以后，后续实现推进得很快。
接口中的每个字段已经有明确含义，数据对应关系不再只是机械地把字段连起来，校验规则也可以从已经确认的业务定义中自然推导出来。
技术实现最终只是把前期决定落到系统中，而不再承担继续发现业务问题的任务。
新的视角
以前，我更容易把系统集成理解成技术问题：两个系统能不能交换数据。
这个项目让我看到，真正难交换的往往不是数据，而是不同团队对数据含义的理解。
接口只能把信息送过去。要让信息到了另一边以后仍然表达同一件事，前提是组织先形成一套共同理解。
核心观点
当前期已经把业务问题、数据含义和未来流程讲清楚，后面的实现通常会简单很多。