IBM咨询2026年5月14日公布Forward Deployed Units（FDU）模式：由业务专家、架构与工程角色组成交付小组，配合AI代理，并强调上线后的持续执行与客户共同参与。FDU指交付单元，不能与FDE个人岗位混为一谈。该公告是企业自身的方法主张，没有逐一披露客户项目的任务清单和运营记录。
一个上线项目，会不断收到不同性质的改动
以下是小团队可讨论的独立工作设计。某个资料查询流程上线后，客户可能同时提出三件事：原来能用的查询现在报错，希望调整一个分类规则，还想增加新的数据源。三件事都叫需求，但处理顺序、责任和成本不相同。若全部直接插入开发，团队就很难判断正在维护原服务，还是又开始了一个项目。
可以把改动分成故障恢复、既定规则维护和新增范围三类。故障先确认受影响用户与可替代办法；规则维护核对谁能确认新口径；新增范围则评估依赖和工作量。分类是为了安排工作，不宜只凭名称判断收费或责任。具体边界仍需回到双方已经确认的服务约定。
连续服务需要安排容量，而不只是保留联系人
小团队可以从最近一个服务周期的实际工单入手，记录临时处理占用了多少时间、哪些问题反复发生、计划工作被推迟了多久。在此基础上，给故障处理留出明确容量。没有足够记录时，应先观察，不能用一个行业平均百分比声称所有团队都应预留相同的人手。
若维护工作持续超过容量，应与客户一起检查原因：是资料源不稳定、业务规则频繁变化，还是方案本身仍不成熟。不同原因对应不同处理，有的需要修复组件，有的需要降低变更频率，有的应重新确认试点范围。把反复出现的问题写进下个周期的计划，比长期靠同一个人临时救火更便于讨论。
正在运营的版本与正在开发的版本要能对上
持续交付不意味着所有改动都立即进入正在运行的系统。团队可为线上版本保留一个明确编号，再把待处理改动关联到目标版本。紧急修复先记录实际更改了什么；后续开发要吸收这次修复，避免下一轮发布重新带回旧问题。这些是本站提出的工程安排，并非公告披露的IBM实施细节。
客户业务人员也可以直接参与改动取舍。例如，一个新增字段究竟会改变哪些日常操作、是否需要补历史数据、谁会使用结果，应在排期前讨论。这样共同参与的产物，是一份双方理解一致的变更说明，不只是每周参加会议。AI可以辅助整理工单和关联记录，优先级与业务承诺仍需要有责任的人决定。
周期复盘要能改变下一轮的工作
复盘时，可比较本周期原定计划、实际完成项与被临时任务挤出的事项，再列出下一轮需要减少的重复工作。若只能报告处理了多少工单，却无法解释哪些重复故障被消除，持续服务可能仍在积累负担。小团队可以把一项可验证的改进作为下一周期目标，而不急于扩充更多功能。
IBM的FDU公告提供了把开发和运营放在同一交付体系中观察的线索。本文没有采用其人员效率宣传数字，也未把IBM或交付小组认定为OPC。研究大型服务商时，更适合提取能够落到自身工作安排的问题，再用实际记录检验是否适用。
延伸阅读：个人创业的维护容量与第一位协作者怎样选择，把持续服务需求与团队容量放在一起考虑。