IT和业务部门如何协作？从需求沟通到共同验收

需求提了三个月，系统上线，业务看完说这不是我们要的。数据对不上，IT说口径是业务定的，业务说系统是IT做的。类似的拉扯，在很多企业反复出现。

项目管理协会 PMI 在 2014 年 8 月发布的《职业脉搏》需求管理研究显示，在不成功的项目中，47% 因需求管理不准确而未能达成目标。协作卡住的地方，常常在几个关键决策点：谁定义问题，谁确认口径，谁排优先级，谁签字验收。把这些动作固定下来，IT和业务部门协作才有稳定的基础。

1. 先统一问题，再讨论功能

业务部门提需求时，常用方案语言。比如运营说，给我做一个留存分析，越快越好。IT接到的是一个功能，却不知道业务要用它做什么决定。

先问四个问题，需求会清楚很多。

• 你想改变哪个业务结果
• 这个结果现在卡在哪里
• 拿到分析后准备做什么决定
• 什么时候必须拿到

以上面的留存为例。业务要判断的，可能是新用户次日留存下降由渠道结构变化引起，还是由新版本激活流程引起。目标不同，需要的分析粒度、时间窗口、对比维度完全不同。只写留存分析四个字，IT只能按最常见的方式做，结果很容易偏离。

把这些内容写成一页问题定义，包含五块：现象、影响、决策、假设、边界。业务负责说明前四项，IT补充数据可得性、系统限制和初步成本。需求沟通的第一步，是把方案还原成待决策的问题。

业务一时说不清，IT不用替业务编目标。把未知项列出来，约业务负责人确认。确认不了，就先做小范围样例。用样例推动讨论，比在会议室里反复描述更有效。

2. 需求评审要落下四张纸

需求评审会容易开成汇报会。项目组讲进度，业务方提意见，散会后没有结论。评审要留下四张纸，少一张都不进入排期。

需求范围

先写清本次做什么，再写清本次不做什么。可以用四档：必须做、应该做、可以后做、本次不做。范围写不清，开发过程中就会不断加东西。

验收标准

Atlassian 的验收标准指南把验收标准定义为产品、用户故事或增量必须满足的条件，要求清晰、可测试、可量化。标准要在开发前确定，由产品负责人、开发团队和相关利益方共同制定，开发过程中可以继续修订。

模糊说法是留存分析要准、要快。可验收的说法是，能按渠道、版本、注册日期查看新用户次日留存；筛选后的结果与数仓口径表一致；没有数据时页面给出明确提示。这是示例，具体指标要按企业实际口径确定。

验收标准写到开发和测试都能据此判断通过与否，才算可用。

数据口径

数据类需求最容易在口径上返工。口径表至少写清指标名、业务含义、计算公式、时间窗口、过滤条件、数据源、更新频率和负责人。业务确认业务含义，数据团队确认计算逻辑，IT确认系统取数。

同一个指标在不同报表里有不同算法时，先确定一个主口径，再说明其他口径的适用场景。不要把一个指标的所有历史变体都塞进一张表，维护成本会迅速上升。指标多、口径经常变的企业，可以参考Agent 语义层建设指南，把指标定义集中管理。

风险与依赖

权限、接口、第三方系统、上线窗口和合规要求，都要在评审时摆出来。哪一项没准备好会导致延期，哪一项需要业务出面协调，写进风险清单。

评审会结束前，四张纸没有齐，不进入排期。未决事项写负责人和截止日期，下一次评审先看这些事项有没有关闭。

3. 优先级用同一套标准排

优先级争议经常变成部门之间的权力比拼。把评价维度拆开，讨论会容易很多。业务评价价值、紧迫性和影响范围，IT评价实现成本、技术风险和依赖关系。两边用同一张评分表，最后共同定顺序。

• 价值：不做会损失什么
• 紧迫性：有没有外部时间点
• 影响范围：影响多少用户、多少团队
• 成本：人力、时间、系统改造
• 风险：数据、安全、稳定性
• 依赖：必须先完成什么

需求池按固定节奏评审，比如每周一次或双周一次。紧急通道可以保留，但要说明挤掉了哪个已排期需求，延期由提出方确认。

变更管理也要有规则。新需求进来时，写清新增价值、影响范围、准备替换哪项原需求、是否接受延期。口头变更不算数，写进变更记录。 变更记录跟着版本走，验收时一起回看。

变更不一定都要拒绝。市场变化、政策调整、线上故障都会带来合理变更。判断标准是新增价值是否值得挤占现有资源，以及代价由谁承担。

4. 开发过程中设三个同步点

业务等到上线才第一次看到成果，返工几乎不可避免。开发过程中设三个同步点，让问题早一点暴露。

原型与口径确认

开发前，业务看原型和指标口径，确认页面上的筛选、字段、排序和空状态符合实际工作。数据类需求还要确认样例报表，避免开发完成后才发现维度不对。

样例数据联调

开发到中途，用一周真实数据跑一遍。业务和数据团队一起看空值、重复、延迟和口径差异。业务确认这就是要看的数，IT再继续做完整页面。

UAT 前检查

用户验收测试 UAT 开始前，IT提供测试环境、测试账号、已知问题清单和本次变更说明。业务准备真实业务场景、验收人员和测试数据。环境和人员不到位，UAT就会变成形式。

每周加一次 15 分钟同步，只过三件事：已确认、待确认、有风险。会议短，但要让双方都知道当前卡在哪里。业务越早看到真实数据，返工成本越低。

数据项目尤其要早看数。看板上线后再核对口径，发现问题往往要改数据链路，成本比改页面高得多。

5. 共同验收，用证据说话

验收会变成签字会，常见原因是标准没提前定，或者业务直到开会才第一次看到系统。把验收拆成准备、开会和上线后复盘三段，签字才有依据。

验收前准备三张清单

• 验收标准清单：每条标准对应哪个需求、谁来验证、通过条件是什么
• 测试用例清单：覆盖主流程、异常流程、权限和边界情况
• 已知问题清单：哪些问题已修复，哪些带条件上线，哪些不影响验收

三张清单提前发给业务，业务有异议在会前提出。会上才第一次看清单，很难做出准确判断。

验收会怎么开

逐条对照验收标准，结论只写三种：通过、不通过、带条件通过。不通过要写缺陷等级、修复时限和复验人。带条件通过要写清遗留问题、上线后的处理时间和责任人。

验收记录要能回溯到需求条目和验收标准。 记录里只写通过，不写依据，下一次出问题还是说不清。

三类验收

功能可用，看业务流程能不能走通，权限是否正确，异常有没有提示。数据可信，看口径是否一致，数据是否完整，延迟是否在约定范围，异常能不能追溯。业务结果可解释，看上线后的使用情况、业务指标变化和立项目标是否达成。

上线验收解决系统能不能用，业务验收解决有没有解决问题。 两个节点分开，验收标准也不同。业务结果需要时间验证的，约定上线后 30 天、60 天或 90 天复盘，不在上线当天勉强下结论。

谁签字

业务负责人对业务问题是否解决、流程是否可用负责。IT负责人对功能、性能、权限和运行稳定负责。数据负责人对口径和数据质量负责。签字表示对各自范围的结论负责，有遗留问题就写进验收单，不用口头承诺代替。

业务不签字时，先回到验收标准。标准清楚，按标准处理。标准本身模糊，先补标准再验收。把新需求混进验收争议里，问题会越拖越久。

6. 一张协作卡，把六个阶段的责任固定下来

把上面的动作压缩成一张协作卡，可以直接放进项目文档，也可以打印出来贴在评审会议室。

先选一个在途项目，不要一上来就推全公司。每次评审会更新对应行，缺哪一项就在会上补。项目结束后回看，哪一步没有留下证据，下一次就补哪一步。协作卡只固定关键决策点，项目计划、需求文档仍按现有制度管理。

团队规模小，可以只保留问题定义、验收标准和变更记录三样。流程轻重服从项目风险，文件数量不是目的。

7. Agent 进入流程后，人的责任更清楚

Agent 进入需求、开发和验收流程后，重复工作的耗时会下降，责任边界反而更需要写清楚。

Agent 可以接手哪些重复工作

会议纪要整理、需求初稿、口径查询、测试用例初稿、验收证据汇总、异常提醒，这些都适合先交给 Agent。它们占时间，判断空间有限，输出也容易核对。

比如业务提出留存分析需求，Agent 可以先查现有指标口径、找出相似的历史需求、列出还需要业务确认的问题。人拿到初稿后再判断，比从空白文档开始快。

哪些判断必须由人负责

业务目标、优先级取舍、验收结论和责任承担，仍由业务负责人判断。权限分配、系统集成、安全合规和运行稳定，仍由 IT 负责。Agent 可以给出建议和证据，签字仍由人完成。

Agent 的输出要能追溯到数据源、规则和操作记录。关键动作设置人工确认，敏感数据和越权操作要有拦截。Agent 参与越深，权限和审计越不能省。

治理边界

ThinkingAI 的 Agentic Engine 具备全域感知、多 Agent 协作和私有化部署能力，企业可以在平台上创建和管理不同职责的 Agent。需求整理、数据查询、验收材料汇总可以拆给不同 Agent 承担，再由人确认关键结论。具体连接器、权限配置和部署条件，要按企业现有系统和合规要求确认。

不同 Agent 之间的分工和交接，可以参考多 Agent 协作业务闭环。

ThinkingAI 已服务全球超 1500 家企业，接入产品超 8000 款。这些经验能说明平台经过一定规模的企业场景检验，具体到某家企业，仍要从数据范围、系统环境和验收标准开始定义。

8. FAQ

业务部门说不清需求怎么办？

先不要要求业务写完整需求文档。用四个问题把业务目标、现状、决策场景和时间要求问出来，IT再拆成功能、数据口径和验收标准。仍然说不清，就做一个页面原型或一份样例数据，让业务看着实物确认。确认不了的事项列成待决问题，约定负责人和日期。

需求总变怎么控制？

变更不一定都要拒绝。先区分新信息带来的合理调整和范围蔓延。每次变更写清新增价值、影响范围、替换哪项原需求、是否接受延期。紧急通道可以保留，但要说明挤掉了什么，代价由谁承担。变更记录跟着版本走，验收时一起回看。

业务不认可验收结果怎么办？

回到验收标准。标准清楚，按标准逐条核对。标准本身模糊，先补标准再验收。把缺陷和新需求分开，缺陷按等级修复，新需求进入需求池。争议较大的事项由业务负责人和IT负责人共同确认，不把签字压力丢给一线执行人员。

数据口径由谁负责？

业务负责人确认指标的业务含义和适用场景，数据团队确认计算公式和技术实现，IT确认系统取数和数据链路。每个核心指标设一个口径负责人，变更走版本记录。跨部门使用的指标，要在指标字典里写清主口径和其他口径的适用条件。

小团队没有专职项目经理怎么落地？

先保留三样东西：一页问题定义、验收标准和变更记录。每个阶段指定一个负责人，每周开一次 15 分钟同步，只过已确认、待确认和有风险的事项。先在一个项目跑通，再决定要不要增加流程。文件数量按项目风险调整，不按团队规模机械复制。