她用一次“翻车”的设计协作，戳破了大公司最常见的敏捷幻觉

你以为协作失败是工具不行、流程不够“敏捷”？这场来自 Figma Config 的演讲给了一个更扎心的答案：真正拖垮产品的，往往是我们假装在协作。Olga Mishyna 用三段亲身经历，拆穿了设计、工程、业务之间那些被忽略的致命断层。

一个反直觉的开场：设计协作，和组织一次多人旅行没区别

演讲一开始，Olga 没有谈设计系统，也没有谈工具，而是抛出一个生活化到极致的场景：组织一次跨国家、跨偏好、跨限制的多人旅行。预算不同、时间不同、身体状况不同、期待完全不一致——听起来是不是比“做个产品”还复杂？她的结论很直接：这和设计协作本质上是同一个问题。

反直觉的地方在于，我们在谈用户同理心、用户研究，却常常默认“同事是透明的”。我们以为工程师懂设计的价值，产品经理自然理解取舍逻辑，管理层会自动尊重节奏。但现实是：如果不把需求、限制和期待说清楚，协作一定会失控。她点破了一句非常狠的话：“我们不是心灵感应者，也不会读心。”这句话对 AI 团队尤其刺耳——模型不会自动对齐，人也不会。

大公司不是慢，是“转向成本”高得可怕

Olga 用了一个极具画面感的比喻：创业公司像快艇，大公司像满载的货轮。快艇随时能调头，货轮一旦要转 180 度，代价巨大。她在一家银行推动敏捷转型时，学到的关键一课是：不要试图一次性改变整个组织。

他们采用了 Spotify 模型，从小团队（squad）开始，把设计师、工程师、产品放进同一个节奏里，甚至把设计任务直接放进 Jira，和开发一起估时。这一步非常“反设计直觉”——很多设计师不愿意被估时、被拆票。但结果是：设计第一次被当作真实的生产活动，而不是“前置艺术品”。

真正的转折点发生在一次用户测试。她邀请工程师旁观，看用户如何被一个“看似微小”的设计问题卡住。那一刻，工程师不再觉得设计是“改来改去”，而是开始理解设计决策的因果关系。她给出的实操建议很明确：别只展示设计结果，把过程摊开给非设计角色看。这对 AI 产品尤为关键——模型选择、prompt 设计、评估标准，如果只给结论，不给路径，永远得不到信任。

当“空降的完美方案”遇上开发者，为什么一定会爆炸

第二个故事几乎是行业灾难复盘。一个外部设计机构带着“现成的完美方案”进入银行：不和开发聊、不见用户、只交付静态设计。结果不是失败，而是“开发侧小规模暴动”。

问题不在于设计是否好看，而在于关系被彻底忽略。Olga 引用了关系的三根支柱：权力与控制、关心与靠近、尊重与认可。这个机构三项全输：决策不共建、情感不共担、努力不被承认。最终结果是更讽刺的：所谓的“新设计”因为无法落地，被拖了数年，最后被工程师和内部设计师“缝合”成一个 Frankenstein。

这对 AI 外包、算法咨询、平台方案输出是一个赤裸裸的警告：如果你的方案无法被共同塑造、共同估时、共同承担风险，那它注定活不久。她给出的解法很朴素，却很少有人真的做到：不管你是外部还是内部，尽早把工程师拉进来，哪怕只是一次设计冲刺式的共创，也比“单向交付”强得多。

真正高效的协作，不靠流程，靠关系密度

在她最新的团队实践中，最有意思的并不是工具升级，而是关系设计。他们把大型设计评审拆成 6-10 人的小组，每天短频快地讨论 UI、UX 和技术依赖；他们刻意邀请非设计角色参与；他们在远程办公下，保留“通话前后的几分钟闲聊”，替代办公室的随机咖啡时间。

有一句话非常值得 AI 团队记住：“两分钟的电话，比十封邮件高效得多。”在跨时区、跨背景的团队里，他们选择直接、坦诚，但前提是关系已经建立。来自朋友的尖锐反馈是帮助，来自陌生人的尖锐反馈只会引发防御。

她最后强调了两点：第一，改变是“进化”，不是革命，从一个人开始影响下一个人；第二，多样性不是口号，而是产品质量的放大器。不同背景、不同经验的人一起工作，才能避免模型、产品和决策陷入同质化盲区。

总结

这场演讲最有价值的地方，并不在于某个流程或模型，而在于它提醒我们：协作失败，几乎从来不是能力问题，而是关系问题。对 AI 从业者来说，这意味着不要只优化模型和指标，也要设计“人如何一起工作”。下一次产品卡住时，不妨问三个问题：谁没被真正邀请进来？谁只看到了结果却没看到过程？有没有一种更小、更安全的方式先试一次？真正跑得远的团队，靠的不是一次完美方案，而是持续对齐的能力。

关键词： 设计协作， 跨职能团队， 敏捷实践， AI产品开发， 组织转型

事实核查备注： 需要核查：演讲者姓名 Olga Mishyna 的拼写；演讲时间与地点（Figma Config Europe 2020）；Spotify 模型的基本结构描述是否准确；引用的关系三支柱是否有明确研究来源；引用的名言是否确认为丘吉尔原话