我在中西部长大，那时我对高级餐厅的看法非常简单。首先，高级餐厅有高级服务员，他们不会让你用错餐具。其次，高级餐厅使用更高级的食材：菜单上可能包括肉眼牛排和龙虾，而不是汉堡和烤肉。但后来我搬到了加州，长话短说，一碗木薯粉竟让我落泪了。我才明白，伟大的餐厅是具有非凡创新性和艺术性的稀有机构。
大约在这个时候，我白天是苹果公司的实习生，晚上则在如饥似渴地学习高端烹饪技巧。我觉得这两个世界之间有很大的联系。在我职业生涯的那个阶段，它们共享一种必要的匠人（shokunin） 式的工艺：是的，发明很重要，但首先我们必须完美地呈现每个像素，精确地切割细丁（brunoise）。但是——这在当时对我来说是相当神秘的——这两个世界也都有一些实践者，他们思考着不可想象的事情，推动着他们的领域向前发展。这两个世界是如何并存的？这些团队是如何运作的？
在世界最好的餐厅，每晚提供出色的服务是不够的。这是一个竞争异常激烈的领域。坐以待毙意味着落后。苹果公司的情况也很类似：iPhone 可能是有史以来最令人惊讶的消费产品之一，但仅仅每天生产同样的设备是不够的。同样，世界上最好的餐厅在专门的研发业务上花费了大量资金，开发新的烹饪方法，采购和了解新的原料，发明令人惊讶的工艺改进，并发展餐厅独特的烹饪风格。
我相当羡慕 Vaughn Tan 为准备他的新书《不确定性心态》所花费的时间。他把自己置身于世界上一些最好的餐饮集团的烹饪实验室中，研究他们如何开设新店、解决问题、开发新菜品——并在马戏团帐篷下的泥地里召开了一次重要会议。从他的观察中，Vaughn 在这些团队的组织实践中提炼出几个共同但不寻常的特征。在阅读这本书时，我感到很震惊，因为这些做法与我在苹果公司的最佳经验是如此相似。我将分享其中的一些故事，以及它们与 Vaughn 的烹饪研发团队的故事之间的关系。尽管我对这本书感到兴奋，但我注意到它的做法似乎与我的经验不太一致，因为它们已经越来越多地转向研发的「研」方面。我也会试着描述这种演变的特点。
不断协商的角色
在初创企业中，角色是流动的。每个人都有很多头衔：重要的不是你的工作描述，而是需要解决的问题。不过，随着公司规模的扩大，抽象化变得很重要。如果没有明确的工作头衔和责任范围，管理成千上万的员工会非常困难。不过，至少在 iOS 的早期，苹果公司是这样做的。正如 Vaughn 所说，角色是「模块化和临时的」。我们为每一个新的问题流畅地组合起来，为那个特定的项目提供所需的技能。
我的头衔是「软件工程师」，但在实践中，这不是一个对组建团队有用的描述词。它既太宽泛又太狭窄。首先：是哪种软件工程师？最初，我的经验主要是在界面和 API 设计方面，但我最终发展了架构和系统工程方面的技能，这将使我被拉入一套完全不同的项目中。但更重要的是，我的角色演变为包括有意义的设计和产品管理工作，部分是为了满足项目的需求，部分是为了满足我的兴趣。这对我个人来说是很好的，它使我保持兴趣，但对组织来说也是很好的，因为像 parallax 这样的项目需要具有不同技能组合的跨学科的团队
Vaughn 认为，由于活动本身的不确定性，这种不断变化的角色定义对于团队的创新至关重要。考虑一下 el Bulli 著名的液体橄榄：一个看起来是橄榄的卵形体出现在你面前的勺子上，但当你把它放进嘴里时，你会发现它实际上是一个围绕着爆炸性橄榄汁的薄纸膜。为了制作这些球体，厨师们将橄榄汁滴入海藻酸钠溶液中，使其发生反应，从而形成精致的皮肤。想象一下，你正在为一个烹饪研发团队进行招聘，你想雇用发明这种技术的厨师。你在工作要求上写什么头衔？什么资格？材料科学？化学工程？糕点烹饪？当然，这个提示的前提是，你甚至能够将「发明液体橄榄」作为问题陈述——你不能这样做。这样一个团队的活动本质上是不确定的。这并不是说它们是危险的：危险是你可以理解、计划和管理的。相反，它们只是充满了未知的未知数。你的团队成员的角色必须处理这种固有的不确定性，而这种不确定性本身会随着时间的推移而变化。
演示驱动的开发
当然，并不是厨房里的每个角色都是如此模糊不清。你也会需要一支单纯的预备厨师队伍。同样地，苹果公司的绝大多数软件工程师仅仅只具有软件工程师的能力，也只需要大多数软件工程师仅仅作为软件工程师就能感到高兴。在苹果公司分离那些极不寻常的工程师的过程听起来非常像 Vaughn 描述的烹饪团队使用的过程。
我从一个简单的软件工程师转变为一个「演示驱动的开发」的过程，我的导师 Ken Kocienda 在《创意选择》（推荐！）中介绍了这个过程。我们的工作围绕着一个有规律的示范节奏进行。当我在 iOS 上研究从左到右滑动导航的手势时，我每隔一两天就会向设计师、工程师和高管演示我的工作。苹果公司软件工程主管 Craig Federighi 会到我的办公室来，玩玩这个手势，注意哪些地方可行，哪些地方不可行，提出建议。所有这些都有助于使手势本身良好。但它也有一个重要的组织目的：这些项目和演示作为正在进行的公共测试发挥作用。每个人都能看到我是如何处理（或未能处理）各种出现的问题的。当下一个项目来临时，这将有助于领导层组建更好的团队。因为我的同事们也参加了许多这样的演示，他们可以亲眼看到我在哪些方面做得很好或很差，这既可以为他们自己的工作提供参考，也可以在未来的项目分配中减少怨恨或困惑。
如果你要有一个不断协商角色的团队，你需要一个不断协商的背景。这些演示将「测试」与实际工作统一起来。Vaughn 描述了烹饪研发团队遵循类似的路径，通过要求团队成员在不同的操作配置中解决各种各样的问题，来测试他们的能力。每一天都在集体品尝中结束，就像我们的日子经常在集体演示中结束。
这种项目驱动的方法也为新员工创造了肥沃的培训土壤。不断的反馈是新团队成员学习公司「风格」的好方法。不同的指导合作可以被尝试和摒弃。这使得培训感觉有点杂乱无章——有时还相当紧张——特别是在追求开放式目标时，很难创建一致的正式培训计划，原因与在这种团队中很难精确规定任何人的工作职责一样。
绝望的项目
烹饪研发团队的另一个常见做法与我在苹果公司的经历有很大的重叠：战略性地使用绝望。摘自 Vaughn：
模式中的每一点都是这样的：对一个超出团队能力的项目作出承诺，团队中的每个人和集体一起发狂，疯狂地工作，最后以某种方式从失败中取得胜利，大大地松了一口气。我常常遇到这样团队的人。当他们处于这些项目的中间时，他们似乎很绝望：情绪和心理上都很疲惫，担心（用轻微的恐惧来描述往往更合适）事情不会成功，或者（更糟糕）会是灾难性的。这些团队似乎无法从错误中吸取教训，从而避免这些绝望的项目。事实上，他们一直致力于做这些项目。在成功时会松一口气，然后——下个月或下一年——找到其他的事情来做，再次陷入绝望。
最后，我开始理解，他们把自己置于这些可怕的境地，作为迫使自己创新的一种方式，这种绝望是有成效的，而不是破坏性的。尽管是绝望，但却是设计好的。
2012 年底，我在一次长途飞行后着陆，当我们 300 人同时关闭飞行模式时，我们共度了仪式性的一刻。转瞬之间，我的手机被在扑面而来的通知淹没。Scott Forstall（主要负责 iPhone 创造和最初几个版本的主管）被解雇了。以前只负责硬件设计的 Jony Ive 也将负责软件设计。11 月下旬，一个真正令人绝望的项目被宣布。Jony 想重新设计整个操作系统和我们交付的每个应用程序。我们将在 6 月初把它交到开发者手中。即使我们只打算改变操作系统的最外层皮肤，这也是一个疯狂的提议，但最初的野心，至少，远远超过了这个。
只是为了说明问题，我所做的一个项目是基于这样的观察：在物理世界中，白色的东西从来就不是真正的白色。这些物体总会带上周围环境的某些特征，随着视角和外部照明条件的变化而变化。也许我们可以开发一种特殊的材料——「数字白」，它将体现出类似的微妙的动态。我的设计原型是使用陀螺仪来创造一种微妙而鲜活的光泽，几乎就像书皮上的素压印。我们的想法是用它来表示屏幕上的可互动元素，因为我们正在剥去按钮的拟物设计束缚。我们最终放弃了这个想法，因为这种设计太耗电了，用 Jony 的话说，这个想法「有点......疯狂」。
但是，这仍然是我在那七个月中领导的至少半打类似的主要的、全系统的项目之一。我的日常工作很简单：每天，我醒来，翻身，拿起我的笔记本电脑，一直工作到睡觉前才放下来，天天如此，连续七个月。我们在深深的绝望中工作，但正如 Vaughn 所描述的，这绝对是我生命中最令人振奋，充满变化的时期之一。
解决问题和找寻问题
当我阅读 Vaughn 的书时，我感到我在苹果公司的经历，和他的烹饪团队的故事之间有很深的联系。但是，这种联系相比与我在可汗学院的经历相比要弱得多，而与我最近的研究相比则更弱。我无法完全描述这种差异，但我认为它可能建立在创新和发明，解决问题和寻找问题之间的区别上。
我和我的朋友 May-Li Khoe 一起加入可汗学院，她曾在苹果公司深度参与创新工作。我们一起成立了一个研发小组，希望将这种探索性的工作带到可汗学院。在我任职的五年中，这个小组的职责发生了很大变化，在这些变化中，我觉得注意到了 Vaughn 描述的工业研究的局限性。
对于我们的一些项目（如在线扩展开放式问题），我们的团队几乎就像组织中其他部门的内部顾问，为一些可以被模糊定义的问题创造解决方案。这在很多方面都与我在苹果公司的时候相似：是的，我们在创造有趣的新界面，但是是为了回应某种外在的问题表述。在这种情况下，问题表述基本上从来没有被完全定义过——项目的一部分是在商讨要解决的问题到底是什么，例如「撕毁简报」等等。项目之间的部分工作是为未来要解决的问题向高管进行游说。但问题表述的存在是项目的基础，它确定的项目的界限。定期的演示是有意义的，因为你可以在不断发展的问题表述的背景下评估它们。绝望可以施加有用的压力，因为你可以做出务实的权衡，也许可以牺牲一些大胆的艺术性来追求一些实用的解决方案。
但我们的一些项目（如 Cantor）更多的是在寻找问题而不是解决问题。没有明确的问题表述。没有一个真正的客户或顾客。事实上，要做的最重要的工作是确定一个强有力的问题表述——对于许多这样的工作，我们从来没有做到过我今天工作中有趣的部分大多是这种类型的。是的，有一些具体的问题需要解决，其中很多我已经在这里讨论过了，但我工作中最强大的力量是关于寻找问题。与我的其他经历相比，这项工作感觉与 Vaughn 的描述联系得更少。
与运动员和音乐家相比，为什么知识工作者对提高他们的基本技能似乎根本就不认真？我们如何才能创造出既能完成既定的工作，又能更积极地参与所希望产生的影响的环境？这些已经是非常不寻常的问题，仅仅提出这些问题就是一个重要的贡献。但是这些大视野的问题表述碎裂成一百个子问题，而我工作中的大部分进展来自于识别和改进这些子问题的表述。当然，实际解决这些问题也很重要，但那是下游工作。
在寻找问题的时候，理论和概念往往是行动的中心。快速迭代的演示和原型变得更难产生，而且在这个阶段，更不相关。至少在我的经验中，绝望变成了一种不太有用的力量。当我们还不可能清楚地表达出一个需要解决的问题时，在火上浇油只会产生胡乱的喷发。一天中往往需要漫长的散步思考和长达数小时的午餐讨论。
我承认我不太理解这种区别。我的经验表明，一定量的「演示」和一定量的绝望实际上对研究很有帮助。但我注意到，沃恩描述的大多数故事都是一个烹饪研发团队对外部定义的问题（尽管可能是一个模糊的问题）做出的反应：这个试吃菜单需要一个清口剂；这些通心粉的生产效率很低；这家餐厅需要帮助开业；等等。可以从一些蛛丝马迹发现问题，比如上面描述的 el Bulli 的液体橄榄，但这些并没有像其他的那样被清楚地记录下来，而且很明显也不清楚这些故事是否遵循了同样的原则。毕竟，据我所知，是 Ferran Adria 本人（主厨）开发了这项技术，而不是他雇佣的某个研发团队。
这就是发明和创新之间的区别吗？学术研究和应用研究？学术界和工业研发？这些界限很模糊，我并不敢说了解它们。在我度过的著作中，Vaughn 的书是讨论工业研发组织最有见解的！——现在我渴望了解更多，更多地关注研发这个方程式的「研究」方面，而不是「发展」方面！
感谢 James Cham，他向我推荐了这本书，并促使我将书中的观点与我自己的经验进行比较。
Thoughts Memo 汉化组译制
感谢主要译者 sword-qi
原文：Liquid olives and iPhones; problem-solving and problem-finding; The Uncertainty Mindset | Patreon 上的 Andy Matuschak