AI 时代的经理，如何从“追进度”转向“管结果”？

要点速览

如果主管大部分时间都在问工作做到哪了，说明系统还没有尽到自己的职责。
主管的新角色是盯住异常，再从规则层面解决问题，逐件追进度的事交给系统。
同时要调整的是决策权：讲清楚谁可以不用请示、自己决定哪些事。

别再靠盯活动来管理

如果您的团队主管每周要花半天追问“做到哪了”，这半天其实是一笔成本：没有人能同时看到工作状态，只好靠人去问。好的系统会让这个问题根本不用问。

问谁发了几封邮件、开了几次会、用了多少条 AI 提示词（Prompt），团队就会忙着制造活动，价值却没有增加。经理应该从结果约定（Outcome Contract）开始：成果交给谁，要交付什么，最低质量是多少，什么时候完成，哪些限制不能违反。例如“24 小时内处理完投诉，客户数据不外泄，且一次解决到位”，就比“尽快回复”清楚得多。

接着把工作流程分成标准工作和例外情况。AI 帮忙准备数据、排定优先级、起草标准工作；主管则把时间花在瓶颈、资源调配、辅导（Coaching）和影响重大的决策上。主管的分量并没有减轻，重心从控制每一个步骤，转到了设计一套值得信赖的系统。

主管的新问题：今天哪些结果有风险？原因出在产能（Capacity）、数据、规则、工具还是技能？我们要怎么解决，才能不再发生？

以例外为中心的管理节奏

试着从看每一项工作，改成只看异常的工作。就像医生不会每天给每位患者做检查，只看指标偏离正常值的病例。省下来的时间，就能用来从根源上解决问题。

节奏	议题	不该做的事
每日 15 分钟	可能违反服务水平协议（SLA）的工作及其负责人	每个人逐项汇报所有工作
每周	P90、错误、积压和根本原因（Root Cause）	只看平均值
每月	Cost/Outcome、客户和产能	把软件授权或提示词数量当成业务成果
每季度	停掉、扩大或重新设计工作流	因为已经投了钱，就继续做下去

好的仪表盘要能促成行动：每个指标都有负责人（Owner）和阈值（Threshold），出现异常时有应对手册（Playbook）。审核队列（Review Queue）应该列出理由、证据、可选方案和截止时间，不要把一大段文字丢给主管重读。告警太多的系统，会让人干脆静音，结果错过重要的事。

找准原因数据不全，从接收环节（Intake）改；规则过时，交给流程负责人（Process Owner）改；模型出错，改评测（Evaluation）；员工不用，改用户体验或激励机制。加培训解决不了所有问题。

明确决策权，培养人才

把决策权（Decision Rights）写成四个级别：AI 提建议；AI 起草、由人审批；AI 处理标准案例、人看例外；系统在授权范围内自行执行，并接受抽查。涉及钱、人事、安全和声誉的工作，必须始终有能指名到人或岗位的负责人。不要只喊一句“人工把关（Human-in-the-loop）”，却不说清楚人要看什么、有几分钟时间。

写给开发团队 · 技术细节

主管要建立心理安全（Psychological Safety），让员工敢于质疑 AI，并奖励发现系统性错误的人。把专家从每次亲自救火的人，变成编写 Checklist、评测集（Evaluation Set）和知识库的人。设计 Reviewer、Process Owner、Knowledge Curator 和 Automation Champion 这样的成长路径，让分享知识不再意味着让自己失去价值。

辅导时可以问的问题

选这个答案的理由是什么？
看到什么证据会改变主意？
什么情况下必须停掉系统并转交？
哪个步骤应该直接砍掉，用不着去提速？
哪些知识应该变成团队的标准？

30 天改变管理方式的计划

写给开发团队 · 技术细节

第一周，选定一个结果目标，取消和系统重复的状态报告。第二周，做一个五项指标的仪表盘：Volume、Lead Time、P90、Quality 和 Exception。第三周，写好 Decision Rights 和升级处理（Escalation）规则。第四周，试行 Weekly Improvement Review，只挑一个 Root Cause 并跟进结果。

统计主管花在追进度上的时间，和花在辅导、客户、改进上的时间各有多少。如果省下来的时间又塞满了新的会议，结果不会有任何变化。让团队记录决策、所依据的假设和实际结果，目的是提高决策质量，不要把仪表盘变成盯每个员工的监控工具。

AI 时代的经理不必会写代码，但要看得懂工作系统，看得出数据的风险，讲得清责任归属，并带着团队走过不确定的阶段。有了这些能力，花在技术上的钱才能换回实实在在的产能。

MANAGER'S NOTE · 仪表盘没讲的事

数字变红，是在提醒您去现场看看

P90 变差时，先别急着问谁慢了。打开排在最后的五个案例看看，可能会发现团队在等客户的资料，或者几条特殊审批规则互相冲突。好的经理用仪表盘来决定去哪里观察，不会拿它代替面对面的沟通。

模拟案例：服务团队积压（Backlog）严重，主管以为是人手不够。可一看案例，发现 28% 的工作在等另一个部门答复。于是团队设定了负责人和内部 SLA，并让 AI 在转交前准备好背景信息。积压量下降了，人手却没有增加，因为解决的是瓶颈，没有去催前台团队加快。

一张结果卡（Outcome Card）

把结果目标、客户或接收方、质量护栏（Quality Guardrail）、负责人、P90 目标值和排名前三的例外情况写在一页上。每周开会都从这张卡开始。哪个议题和卡片对不上，就问一问这个会有没有必要开。

值得常说的一句话：“系统在哪些地方让决定变难了？”比“为什么不用系统？”好，因为前一个问题能暴露设计缺陷（Design Flaw），后一个问题多半只能换来防御性的回答。

DNA MAKER · SOLUTION BLUEPRINT

从知识到真正能解决问题的系统

问题的根源

经理要看到的是决策和例外情况，不该淹没在系统本可以自动汇总的状态报告里。

分步解决方案

定义结果约定，以及人和 AI 各自的决策权
设计例外仪表盘（Exception Dashboard），标明原因、负责人和下一步行动
把会议节奏改成每日例外会、每周改进会和每月价值复盘

做能帮主管做决定的界面，别做增加汇报负担的界面

设计经理驾驶舱（Manager Cockpit），第一步是讨论清楚三件事：哪些结果最重要，主管每天要做哪些决定，出现例外时缺了哪些数据。选什么图表是后面的事。DNA Maker 与管理层和团队主管一起，把这些思路转成人人看得懂的 KPI 词典（KPI Dictionary）、决策权和升级处理流程。业务目标由客户自己定，我们帮忙把目标一路连接到工作状态、证据和负责人，同时不让仪表盘变成监视员工的工具。

决策框架清楚之后，我们可以开发经理驾驶舱、决策仪表盘（Decision Dashboard）和 AI 智能体（AI Agent），用来汇总状态、指出瓶颈、会前准备简报（Brief），并把事项按正确的路径送到有权限的人手里。系统可以是面向整个组织的 Web 应用，也可以是给一线主管用的移动端体验，配有系统集成、告警、决策记录（Decision Log）和按角色分配的权限。DNA Maker 可以从工作坊、信息设计、原型，一直做到软件开发和持续改进。如果您手上报告很多，却还是答不出“今天要决定什么”，我们可以帮您把这些数据变成能推动行动的讨论。

SOFTWARE ENGINEERING GLOSSARY

软件工程术语表

这张表用不着背。它的用处是让管理层、工作负责人和开发团队沟通时，对同一个词不会有两种理解。请把释义、示例和右侧的问题一起看，这些问题常常能在开发开始之前，把隐藏的范围、风险和成本揭示出来。

术语	是什么	通俗示例	高管应问开发团队的问题
Dashboard	汇集数据、辅助决策的界面	主管在一个页面上看到有 SLA 风险的工作	用户看完这个界面，要做什么决定？
KPI	与目标挂钩的衡量指标	衡量结案时间，不统计邮件数量	这个数字和结果目标挂钩吗？大家用的定义一致吗？
Escalation	超出权限范围时，把事项上报给有权限的人	超出额度的金额转给经理处理	什么条件下转给谁？必须在多长时间内答复？
Decision Log	记录决策及其理由	记下为什么批准了这个例外	理由和证据要记录到什么程度？
Role-based View	按岗位职责显示不同的界面	管理层看全局，团队看自己的工作	每个角色需要看到多少数据，才能把工作做好？

明天就可以试试：把一场状态汇报会改成例外复盘会（Exception Review），然后看看团队花在做决定上的时间是否变多、花在汇报上的时间是否变少。