谁来建模：业务分析师与开发者的职责划分与反馈循环

业务分析师专注”是什么”和”为什么”，尽量不碰”怎么做”（留给开发者去决定实现方式），通常是创建流程模型初稿的人，这份初稿会直接塑造最终的可执行流程——最理想的做法是分析师和开发者一起开研讨会共同产出第一版模型，再邀请最终用户、行业专家、运维人员加入获取更多视角，这种研讨会本身就在促进彼此理解对方的处境：分析师可能因此了解为什么某个流程在当前IT生态里很难实现，开发者也可能因此了解某个流程之所以复杂是因为法律要求，这些认知本身就有巨大价值。开发者负责让模型真正可执行，在尝试执行初始模型的过程中经常能发现模型缺陷（比如某个API需要流程里没有的参数，或者某个API根本无法按设想的方式调用）——因此必须赋予开发者在必要时调整模型的权力，不只是加属性让模型能跑，还包括真正调整模型去应对现实约束。关键的一环是所有变更都必须反馈给业务分析师，每次改动都要有能向所有干系人解释清楚的理由——长期坚持这个反馈循环，能在分析师和开发者之间建立起真正的共识和统一语言，业务方一旦理解了模型里某个技术任务背后的原因，也会更容易接受它。在敏捷项目里，这个反馈会随着每个冲刺自然发生，各个物理副本模型的同步方式取决于具体工具栈，但一般来说越简单的方法效果越好（比如开发者每次发布新版可执行模型就发给分析师，分析师应用变更到下一轮迭代），一些工具支持模型版本化、差异对比、合并甚至自动回滚会有帮助，但根本上纪律比工具功能更重要。为了保护可执行模型不被破坏，必须避免让业务分析师在自己的工具里覆盖或删除他们看不到的技术属性——这正是为什么可执行模型的所有权必须归属开发者。