人：三个角色不可省
业务负责人决定场景优先级，技术接口人负责环境与集成，验收人负责结果判定。三者可由两人兼任，但必须明确谁有最终否决权，否则争议会停在会议桌上。角色分工要写进项目章程，并在启动会上确认。
数据：口径比数量重要
一份字段定义清晰、标注一致的小样本，胜过大量来源不明的数据。启动前先做字段清单与勾稽关系核对，避免开发到中期才发现同一指标有两个口径，数据责任人要参与口径确认，避免后期反复对齐。
环境：比预期慢
网络策略、账号权限、测试库与脱敏规则通常比计划慢。把环境就绪列为开发阶段的前置条件，未就绪不计入开发工期，可避免后期用加班补前期等待。环境清单应在定界阶段一次列全，并指定跟进人。
制度：评审与变更
固定每周一次技术评审与一次业务确认，配套变更登记与验收签字。制度缺位时，投入再多人力也会消耗在反复确认与责任推诿上。制度由客户方发文，比项目组口头约定更稳定，也便于事后追责与交接。
适用与不适用
适合谁
- 准备立项、需要评估内部投入的转型项目
- 已经启动、但内部配合明显不足的团队
不适合谁
- 希望零内部投入、完全托管的采购方
典型场景
某食品企业要做经销商订单预测。立项时只安排了 IT 一名工程师，业务数据由销售助理临时提供，两周后因口径不一致返工。项目组补充业务负责人与数据责任人，把字段清单、环境申请与评审节奏写入项目章程，开发阶段才顺利推进。
可执行步骤
- 指定业务负责人、技术接口人与验收人，并把角色分工写入项目章程与通讯录
- 整理字段清单与指标口径，为每个字段确认数据责任人、更新频率与口径
- 提前申请网络策略、系统账号、测试库与脱敏环境，并指定专人跟踪审批进度
- 固定每周技术评审与业务确认的时间、参会人以及每次会议的输出物与待办
常见坑
- 只安排一名 IT 工程师对接，业务判断无人负责，需求在开发中反复变更，业务角色必须实配到具体的人，不能只挂名。
- 把数据准备当成一次性任务，上线后口径无人维护，报表与模型逐渐对不上，需指定长期数据责任人。
- 环境申请与开发并行启动，等待审批的时间最后全部转成项目延期，应把环境列为开发的前置条件。
自检与验收清单
- 三类角色是否已指定，是否有书面的分工与授权
- 字段清单与指标口径是否完成确认并指定责任人
- 网络、账号与测试环境是否在开发启动前全部就绪
- 评审节奏与变更制度是否已由客户方发文确认
常见问题
投入最少要多少人？
至少三类角色：能拍板的业务负责人、能改配置或对接系统的技术人员、能判定结果是否可用的验收人。人数可以少，但角色不能缺，尤其不能由外部团队代替业务方做优先级判断。
数据量不够能做吗？
可以，但要先确认样本是否覆盖主要情形。少量高质量样本足以验证可行性，不足的是覆盖面。若连字段口径都无法统一，应先做数据治理，而不是急着训练或接入模型，顺序错了返工更大。
内部投入要不要算成本？
要算，但不必折算成报价。更实用的做法是在立项文件里写明各角色投入的工时比例与周期，作为资源承诺；没有这份承诺，项目延期时很难判断责任归属，也无法向管理层交代。