在你导入技术或 AI 之前，先问团队三个问题

当一家机构找我们谈一套新的技术方案或一个 AI 项目时，第一个问题通常都跟技术有关。

「我们该用哪个工具？」
「要做网页应用还是手机应用？」
「AI 可以帮我们做这件事吗？」

这些都是合理的问题。它们也是最后才该回答的问题。

在设计与创新这条路上做了二十年，我更希望团队先回答另外三个问题。每一个都从不同的角度切入：领导者、团队，以及被服务的人。大多数卡住的项目，至少在其中一个问题上答得不清楚。

1. 谁为成果负责？

这是领导者那一侧的画面。

作为外部伙伴，我通常已经和机构里的某一个部门有合作关系——可能是 IT、策略、营运、人力资源、市场、学习发展，或是创新团队，看是谁找上我们。

他们每一个都握着真实的一块。业务知道为什么这件事重要。技术知道什么做得到、什么是安全的。营运知道工作实际上是怎么跑的。设计知道它对人来说好不好用。学习发展知道缺的是什么能力。

麻烦从哪里开始？当其中一个部门默认地把整件事扛了下来。

• 只有策略，你会拿到路线图和简报，地面上几乎没有改变。
• 只有技术，你会拿到一堆找问题的工具。
• 只有变革管理，你会拿到一场替没人需要的东西做的宣传。
• 只有培训，你会拿到证书，而工作方式原封不动。

所以问题不是「谁管 AI？」或「谁管技术？」，而是：谁为这件事要改善的那个结果负责？

那个人不需要什么都做。他需要的是把对的人聚在一起、以及在优先次序打架时拍板的权限。

作为外部伙伴，我们可以协助推动改变。我们无法为结果负责。那必须坐在机构里面。

2. 团队准备好换一种方式工作了吗？

一位目标清楚的负责人，仍然需要一群做得动改变的人。那需要的不只是 AI 技能。

一组混合的能力。 团队要能管理利害关系人、生出点子、把点子变得看得见、把它讲出来，并且跨部门合作。

一次心态的转变。 这是比较难的部分，而且会让人不太舒服。

• 从「我们已经掌握所有资讯」，到保持好奇。
• 从「先想公司或产品」，到先想人。
• 从「需要明确指示」，到能和还不清楚的状态共处。
• 从「我们不能失败」，到从失败里学东西。
• 从「只有一个正确答案」，到容得下好几种观点。

AI 项目对这一点的要求更高。当一个工具几秒钟就交给你一个漂亮的答案，你会很想跳过理解问题那段慢工。

一个准备好的团队，知道什么时候该相信 AI 的输出、什么时候该质疑它，以及什么时候根本不该动手做。

3. 什么才值得做？

这一题关乎理解被服务的人的需要。

AI 让「做」变得非常便宜。一个人一个下午就能做出一个能跑的原型。当你是替自己做的时候，这是一份礼物。

当机构里每一个人都能这样做，它就变成风险。你会得到一堆各自都说得通的小工具，合在一起却很难管理。

AI 建造者悖论：做起来越容易，决定什么值得做就越重要。

有三个步骤能帮团队对齐。

1. 先对服务有共识，而不是对软件。 每一群人真正想完成的是什么？今天它在哪里卡住，而谁在默默承担那个代价？
2. 把服务画出来。 画面是最小的一块。大部分成本与风险都在它后面——纪录、审批、数据，以及让这一切运作的人。
3. 从成果往回推。 从最要紧的那个结果开始，列出挡在前面的东西，再去衡量选项；并且记得，有些缺口是靠改流程或改角色补上的，不是靠加软件。

做完这些，「网页还是手机？」这类问题通常会自己有答案。平台跟着使用者的需要走——他们在哪里，以及当下在做什么。

为什么三个要一起看

每一个问题，少了另外两个都会失效。

• 有负责人、没有准备好的团队：一个没人做得动的授权。
• 有准备好的团队、没有负责人：好点子背后没有决策权。
• 两者都有、却看不清要做什么：往错的方向加速。

转型是同一段旅程的三个侧面：谁负责、谁动手、以及它为了谁。

AI 让「做」变便宜了。它没有让「决定」变容易。

所以在下一个项目开始之前，和团队试试这三个问题。

谁为成果负责？
我们准备好换一种方式工作了吗？
什么才值得做？

这三个之中，哪一个在你的机构里现在最难回答？