Charles Humble与Team Topologies的共同作者Manuel Pais进行了交谈。他们讨论了在DevOps和云计算变得无处不在的情况下，寻求新的竞争优势的公司如何快速采用团队拓扑结构；将软件工程思想应用于组织设计；在远程环境下跨团队协作的挑战；以及将团队拓扑结构模式用于远程工作。
关于采访对象
曼努埃尔-派斯是《团队拓扑结构：组织业务和技术团队实现快速流动》一书的共同作者。Manuel被TechBeacon评为DevOps思想领袖，他是一名独立的IT组织顾问和培训师，专注于团队互动、交付实践和加速流程。Manuel也是LinkedIn的持续交付讲师。
提到的资源
远程团队互动工作手册
Susanne Kaiser关于连接Wardley映射、领域驱动设计和团队拓扑之间的点
团队拓扑学院
团队拓扑书籍
WTF is Cloud Native?推荐阅读列表 2021
完整的文字记录
简介
Charles Humble:
大家好，欢迎来到 "黑客组织 "的第三集，这是集装箱解决方案公司的 "WTF is Cloud Native team? "的播客。我是Charles Humble Container Solutions的主编，在这一集里，我请到了Manuel Pais。Manuel是一名独立的IT组织顾问和培训师，专注于团队互动、交付实践和加速流程。他也是LinkedIn的持续交付讲师，但他最出名的可能是与Matthew Skelton一起合著的《团队拓扑》一书。他们两人刚刚出版了一本新的远程团队互动工作手册，以其中的一些思想为基础，将其置于一个新的远程工作环境中。团队拓扑结构是一本被我们之前的嘉宾苏珊娜-凯泽和兰迪-舒普参考过的书。这本书也在Container Solutions的推荐阅读书目中，我将在节目说明中提供一个链接，这也是我们Container Solutions在自己的客户项目中经常参考的一本书。我非常高兴曼努埃尔今天能和我一起在播客中谈论这本书。和新的远程互动书。曼努埃尔，欢迎来到节目。
曼努埃尔-派斯。
谢谢你，查尔斯。我也很高兴来到这里。我们已经认识很多年了。谈话总是很愉快的，谢谢你的精彩介绍。
是什么推动了团队拓扑结构的快速采用？
查尔斯-汉博。
很高兴。说实话，我对团队拓扑的概念被采纳的速度和范围感到惊讶。
曼努埃尔-派斯。
我也是。
查尔斯-汉博。
我很好奇，为什么你认为这可能是。我想，在我们的行业中，一个东西被接受得这么快是不寻常的。
曼努埃尔-派斯。
是的，我们真的不知道这本书会受到多大的欢迎，我们觉得有必要更加明确如何思考组织、演变，不仅仅是团队和互动的类型，这是书中的基本模式，而是更广泛的，我们如何演变组织，使我们适应我们周围的所有挑战。而可能感兴趣的部分原因是，显然，在过去的几年里。这本书是在2019年年底出版的，我们有很多变化和社会政治，等等，因此，这甚至更加强调组织需要快速适应，而正在发生的是现有的模式，虽然有用，但还不够。而团队拓扑可能是不够的，我们需要不断发现更多关于组织如何工作，我们如何帮助人们提高生产力，以及我们如何围绕这一点组织我们的团队？
曼努埃尔-派斯。
因此，我认为在过去几年中的挑战的组合，加上缺乏真正的更具体的或分析性的知识体系的组织。因此，当然有Spotify模型和敏捷，DevOps，但没有一个结构化的观点，我们能做什么？我们可以考虑哪些构件？好吧，如果我们有这些问题或组织中的这些挑战，我们可以做什么来处理它，我们不依赖于有时不能很好地扩展的解决方案--比如我们只是想，"哦，我们只是要雇用更多的人。"这通常不能很好地扩展。这可能不是调整组织的最有效方式。所以我认为这些是一些原因，可能还有一些我们不知道的原因。我还想说IT革命做得很好。出版商，因为他们的目标受众，他们也举办了DevOps企业峰会会议。因此，他们真的有一个很好的听众，听我们所说的和他们所出版的其他书籍。
Charles Humble:
我也想知道，这是否可能部分归因于公司在寻求下一个竞争优势。有这样一种想法，即早期采用事物的公司和那种创新者/早期采用者阶段，他们这样做是因为他们在寻找竞争优势。DevOps和公有云的情况也是如此。很明显，它因行业和地点而有所不同。但总的来说，在这一点上，采用的范围足够广泛，不一定有竞争优势。在Container Solutions公司，我们谈到了Cloud Native的概念，它与你的组织的工作方式一样，都是关于技术--容器等等。因此，我想知道你是否认为，实际上文化或公司组织是下一个竞争优势的来源，然后这可能反过来解释了我们所看到的推动团队拓扑结构快速采用的一些原因。
曼努埃尔-派斯。
是的，事实上，不仅仅是我同意，去年，DevOps的状态报告，Puppet实验室的报告出来了，我想是去年6月，2021年。他们有这样的结论，他们正在研究不同的组织，基本上那些更多的技术方面，"是的，我们需要拥抱云。我们需要采用DevOps实践，等等。"就像你说的，这些天是一个基准线。它们不会产生巨大的差异。他们将帮助你与其他组织竞争，但实际上，组织结构的清晰度，特别是团队的清晰度，团队的任务是什么，他们之间的关系如何？我们是否清楚，当我们遇到某种问题时，我们需要向谁求助。我们如何以一种明确的方式进行互动，使之更有成效，我们有更少的冲突，我们有更多的共同方法来做整个组织的事情，这就是我们今天看到的一些竞争优势，就像你说的。
曼努埃尔-派斯。
尽管 "团队拓扑 "已经得到了很好的评价，当然，这需要时间，特别是在大型组织中，让这些想法在整个组织中得到采纳，因此，这也是他们报告的结论之一，事实上。因此，我们可以预期，可能在5年或10年后，这将不再是一个优势了。但在目前，是的。
在最初的《团队拓扑学》一书中，你是否希望你能更聪明或更强调一些东西？
查尔斯-汉博。
只是对团队拓扑结构的广泛采用多想了一下。我认为，当一些东西被如此迅速和广泛地接受时，难免会有一些误解或误读，或者你希望你在书中更清楚或更强调的事情。你有这样的想法吗？
曼努埃尔-派斯。
如果你没有讨厌的人，那么你就不够成功。我们很幸运，没有很多。只要是尊重，我们就会尝试辩论观点，尝试理解不同的观点。而且，团队拓扑结构实际上不一定适用于每个组织，但确实适用于很多。是的。但在一些特定的情况下，如果你更专注于研发，也许并不是所有的东西都适用，尽管我们仍然希望可能走得快，有结果快。但直接回到你的问题，你永远不可能拥有这一切。因此，我认为这本书的吸引力在于，当我们谈论团队互动的类型时，以及我们谈论一些限制因素，如认知负荷、康威法则等等，所有这些东西都相当容易理解，人们可以很快将其与自己的经验联系起来。
曼努埃尔-派斯。
所以我想这也是为什么这本书被迅速采用的原因。我仍然认为缺少的部分是进化部分。因为我认为有时人们会从一个讲座或一些文章中得到主要的模式。所以他们只是关注团队互动的类型。但是这本书的第三部分都是关于演变的。它不只是在某一时刻说，"好吧，我们应该有这个流线型的团队。我们应该有这个平台，等等"。最关键的是，特别是对互动而言，我们如何利用它来发展，发现新的差距，发现新的挑战，然后进行调整。因此，这也许是我们本可以放在最前面的东西，但它在书的最后部分。但也许我们应该在书的早期就把这个问题提请人们注意，这样人们就会意识到这不仅仅是核心模式，尽管这也很重要。但是，随着你变得越来越富有，事情也在不断发展，它们会呈现出其他的形态，这也是正常的。
你如何避免重组疲劳的出现？
查尔斯-汉博。
是的，从我多年的从业经历中，我学到的东西是，显然大规模的公司重组是非常复杂的，而且很难做到正确。我曾在很多组织中工作过，这些组织已经完成了，而且是灾难性的。我想听这个播客的每个人都可能熟悉持续交付和软件的想法，以及为什么它通常是一个比大爆炸式的方法更好的方法。我认为Team Topologies在组织层面上倡导同样的想法，但在实践中如何运作？你如何避免重组疲劳的出现？
曼努埃尔-派斯。
所以，当我们的组织真正进入团队拓扑结构时，这是一个困难。事实上，这可能看起来很奇怪，但实际上这就像试图让他们慢下来一点。因为我们不希望他们再做一次大的重组。我认为这也是一个规模的问题。我们已经看到一些例子，在明显的初创公司，但在一定的规模下，规模扩大。如果你让人们加入进来，你可以更快、更广泛地做事情。我们的网站上有一些公司的例子，如PureGym或Wealth Wizards，这些公司处于规模扩大阶段，他们能够对组织进行更广泛的变革，并且相当成功。但是对于大型组织，我们有效地试图告诉他们......而回到这个进化的想法，就像当你在改变时，是的，你可能会采用团队拓扑的一些想法，你仍然需要学习。这并不是说这些是绝对的真理，你只要应用它们，一切都会好很多。
曼努埃尔-派斯。
你必须试着敏捷地进行转变，把这个应用到也许是少数的团队中。尝试获得实际的模式，所以当你读这本书的时候，让团队了解，我们是什么团队，我们应该如何与他人发生关系，这可能看起来比实际要容易。然后逐步改变这些东西，改变团队互动的方式，使之更有目的性，在 "我们为什么要进行这种互动？我们如何知道我们是否达到了这种互动的目标？如果我们没有，那说明了什么？"因此，即使你试图改造组织，也总是有一个学习的过程。
曼努埃尔-派斯。
因此，从某种程度上说，这将是一个缓慢的过程，因为你不是一下子把这个大的变化应用于整个组织，但你会得到更快的反馈。这和DevOps告诉我们的想法以及其他 "获得快速反馈 "的运动一样。因此，我们从小事做起，快速得到反馈，这是否有效？是否有我们需要调整的东西，以使它适合我们？因此，你采取较小的步骤，然后当你得到验证，你也得到内部的内部胜利，你可以显示 "我们尝试了这个，我们有这个好处"，然后就更容易把它带到组织的其他部分，最好是让组织的其他部分对它感兴趣。这就是我们所看到的，即使在相当大的组织中，我们没有直接参与，但我们甚至从他们增加兴趣的方式中看到，例如，在我们的在线培训中，我们看到这是在该组织内部成长，这很好。这意味着它是更加有机的，是的。被组织的其他部分所接受
你能谈谈将软件工程思想应用于组织设计的问题吗？
Charles Humble。
更广泛地说。我认为这本书让我非常喜欢的一点是，你是如何将软件工程的思想应用于组织设计的。你能不能多谈一点？
曼努埃尔-派斯。
是的，这是有意为之的，因为我和马修都有软件工程的背景。事实上，在一开始，我们看到更多的软件工程类型的人拿起这本书。现在，我们看到更多的人正在阅读。所以是的，一些核心原则，围绕松散耦合的软件工程。如果你想能够快速发展，你需要松散的耦合，高内部凝聚力。这些原则我们也可以应用于团队，这不仅仅是关于软件。因此，当我们把这些应用于团队时，我们有松散的耦合，但这也给我们带来了，"好吧，我们有松散的耦合是什么？"那么，我们需要了解什么是价值流。
曼努埃尔-派斯。
我们需要了解在价值流中，什么是实际的产品，甚至是子价值流，然后我们可以调整团队。因此，当我们做这种调整时，我们开始让团队有更清晰的目标，谁是他们的客户，他们的任务是什么，等等。但是，当你退一步讲，我们正在应用这些松散耦合的原则和团队内部的高凝聚力。这些都是帮助我们思考如何组织团队的有用原则。
不要重复自己和耦合
Charles Humble。
我认为这实际上是一个非常有趣的子点，我已经看到了几次。当我开始在IT行业工作的时候，在面向对象的术语中，有一个巨大的重点是拥有共同的组件。整个不要重复自己的事情。虽然我认为这可能是可以避免的，但我们曾经倾向于最终出现巨大的团队耦合，每个人都难以置信地依赖少数人维护这些通用组件，然后在整个软件组织的其他部分使用。然后，我们转向了自主团队，我想部分是受到了丹-平克《驱动力》一书的启发。这使我们能够更快地前进，但这也意味着许多共同的功能在组织的不同地方被反复编写。我很想知道你是如何看待这个问题的，以及你如何看待这个问题在组织层面上的表现。
曼努埃尔-派斯。
所以不要重复自己是很有趣的。我是作为一个非常相信这一原则的人说的，我认为这有不同的含义。我确实相信，10年前，我们应该始终以 "不要重复自己 "为目标。但我认为，就像你说的，在实践中，我们已经看到了很多问题，这些问题来自于试图广泛地应用这一原则。而且根据我自己的经验，我开始意识到，好吧，我们需要对这个原则有明确的范围。如果我们谈论的是一个服务，甚至是一个基于软件系统的系统。是的，我们可能想避免重复，我们想避免在多个地方复制小的代码，然后变得非常难以测试，甚至无法理解这一切来自哪里？
曼努埃尔-派斯。
所以我们绝对不希望出现这种情况。所以我认为在服务甚至系统的单元......是的，你不希望重复自己。但是，当我们看向组织的层面时，实际上可能有非常合理的理由，我们可能有重复的功能，如果你喜欢的话。例如，公司在世界各地的存在越来越多。因为他们的障碍较少，等等。真正想在不同市场取得成功的组织的一件事是了解世界不同地区的客户，期望以非常不同的方式进行互动。因为他们的文化，也因为技术，尽管这已经变得不再是一个区别因素。我们知道在像亚洲这样的地区，更多的是移动优先，尽管现在基本上全世界都是这样，但过去是不同的。
曼努埃尔-派斯。
但即使从文化的角度来看，世界上不同地区的人想与你的品牌、你的服务互动的方式也是不同的。因此，如果我们有一个遍布全球的公司，你的团队提供非常类似的服务，非常类似的功能，可能是有意义的。比方说，在美国或在北美和亚洲，但你实际上需要非常不同的方法。你需要这些团队了解谁是我们在这个地区的目标客户，他们想如何消费我们的服务，等等。这只是一个例子。还有更多的例子，特别是对我们这些软件工程师来说，这似乎是违反直觉的。我们是在重复事情。是的。但这是有价值的，我们可以看到它，因为我们能够为组织带来更多的利益。
曼努埃尔-派斯。
这只是我们必须接受的事情。我认为问题总是偶然的，在一个系统的层面上，这可能是在一个组织的不同部分。如果它是有意的，因为我们知道为什么我们需要做这样的重复，因为我们有不同的市场，或者我们有不同类型的客户或法规，等等，那么只要我们能显示出价值，就应该没有问题。当它是偶然的，我们只是没有注意，事情被技术债务等搞得一团糟。那么显然这不是一件好事。
你如何让跨团队协作在远程环境下工作？
Charles Humble。
现在你提到了这本书在2019年年底出炉，显然这是在大流行之前。因此，大流行发生后，每个人都转向远程工作。而现在我们正处于一个在我自己的国家进行一些辩论的时刻。我认为更广泛地讨论这是否是一件好事。我一般认为它是。我认为一些反驳意见是无稽之谈。有一种说法是，"如果不在办公室，懒人就不会工作"，但懒人在办公室和在家里看起来一样忙。
查尔斯-汉伯。
所以，你要做的是衡量你的团队的产出，然后你可以知道人们是否真的在工作，然后他们在哪里并不重要。我认为这是一个愚蠢的说法，但不可否认的是，远程工作存在着挑战。我认为其中一个挑战是，在一个团队内进行协作是非常简单的，但要让跨团队的互动发挥作用就难得多。你同意这一点吗？如果是这样，你对此有什么想法或建议吗？
曼努埃尔-派斯。
这就是我们写这本工作手册的部分原因...。嗯，在欧洲，现在刚出来的5月底，实际上就是你刚才说的那样。这是在大流行病的开始。然后花了比我们想要的更长的时间才把工作手册拿出来。但是，即使在大流行病开始时，我们就开始讨论在远程环境下的有效问题，这对许多组织来说是新的。通常在一个团队中，就像你说的，你可以很快弄清楚，我们要如何工作？我们想使用什么--聊天工具还是视频通话？以及何时等等，因为这些人经常在一起工作。但就像我说的，在不同的团队之间，它变得更加复杂。这并不是说在办公室里，实际上很容易或很清楚，但几乎就像你在办公室里，有时事情会浮出水面，有时几乎是意外的，但你会浮出某些问题或某些事情，...。嗯，实际上，我们需要聚在一起解决这个事情。
曼努埃尔-派斯。
这绝不是理想的，但你确实有一些接触点，而现在你在远程环境中却没有。但另一方面，它使这些问题暴露出来，我认为这是一件好事。现在很清楚，我们需要更有意识地考虑我们如何进行远程工作？我们应该何时互动？团队之间这种互动的目的是什么？我想你正在谈论专注于组织、设计和结构等方面的竞争优势。我认为在这种远程背景下，它甚至更多。我认为会很清楚，那些只是采用了一些聊天工具的组织，基本上改变了他们的安全设置，所以人们可以从家里访问系统。让我们不要说出任何名字。当然，你需要采取一些步骤，但这只是你需要做的基本事情。
曼努埃尔-派斯。
然后你需要考虑，当团队需要相互交谈时，我们如何真正帮助他们相互交谈？我们如何减少噪音，因为当你有这个巨大的虚拟工作空间，可能有数百个通道时，也会有很多噪音，人们会说，"我甚至不知道我应该看哪里。"因此，作为人类的自然反应，他们会更加关注自己的团队，并试图远离他们周围组织中的其他世界。如果我们想帮助团队在这种远程环境中真正有效，我们需要更多考虑如何组织虚拟工作空间和工具，就像你说的，在团队技术中要有一个团队第一的方法。
你如何看待远程环境下的协作？
查尔斯-汉伯。
实际上，有几件非常有趣的事情，我想接下去说说。所以你说，你已经看到了一些东西，我也确实看到了，就是公司会把基本的工具放进去。因此，你会得到像视频通话和聊天之类的东西，但然后每个人都被留在那里继续使用。在我看来，在许多方面，工具是最不重要的部分。我的意思是，是的，你需要到位的工具，但这很简单。你如何看待在远程环境下的协作？
曼努埃尔-派斯。
就像你说的，工具，我们需要工具，我希望会有更好的工具。事实上，我们已经与一些公司和初创企业进行了接触，他们想创造更好的工具。这更多的是以团队为中心，特别是远程通信，但我们还没有真正达到这个目的。但你仍然可以做得更好，利用工具化对你有利。因此，你特别提到的协作的事情之一，在即将推出的工作手册中，这些事情不是火箭科学，例如，为你的聊天频道采用一些命名惯例，无论是Slack或Teams或其他东西，我们可以，例如，如果我们知道两个团队需要合作解决一些问题或弄清楚我们要怎么做，我们可以为这种合作创建一个临时频道。这是一个非常简单的例子，我们澄清这两个团队在一段时间内的合作。
曼努埃尔-派斯。
这就是我们期望大部分的同步通信发生在这个通道里。这是最简单的例子，我们正试图减少噪音，促进有清晰度。当然，我们不希望过于规范，说："好吧，告诉每个团队你需要完全这样做"，但我们可以提供一些有用的想法和常见的做事方式，让团队可以采用来改进。这就是我们所看到的，只要我们不是强制性的，而是说 "看，这里有一种方法，可以帮助把事情弄清楚"，团队一般都很乐意接受。他们一般很乐意使用这种方法，因为他们现在感受到了所有这些渠道的痛苦，所有这些噪音的发生。而我们并不真正知道我们如何融入其中。还有其他方面的信任。
曼努埃尔-派斯。
还有你如何在这个虚拟环境中建立信任，等等。所以，这些都是我们可以通过应用一些简单的模式和常见的方法来帮助解决的，比如使用我们在《团队拓扑》一书中谈到的团队API来跟踪团队之间的依赖关系的命名惯例。现在我们在工作手册中给出了一些如何应用团队API的例子，以实际发展互动，明确渠道，明确沟通模式。所有这些事情都将是持续需要的，就像重组一样，这不是一步到位的转变，我们不断地改进事情。我们不断识别，"嗯，这里仍然有一个问题。我们能做什么来解决这个问题？"它是持续的。
你如何在远程环境中尽量减少团队的额外认知负荷？
查尔斯-汉伯。
在书的早期，你谈到了远程团队需要过度沟通，也谈到了远程需要强大的书面文化，这也是我也说过不少的东西。但是我看到在远程环境中反复发生的事情是，你最终会有太多的聊天信息、即时信息成为干扰，而且你在书中也提到，缺乏问题的背景。所以你不得不一直在寻找原始信息。在管理方面，你有什么建议？
曼努埃尔-派斯。
是的，事实上，发生的情况是我们增加了团队在沟通方面的认知负荷。不仅是他们通常有太多的认知负荷，只是为了做他们的日常工作和提供他们的服务或软件，如果是这样的话，但现在我们也在增加沟通上的认知负荷，因为有太多的缺乏背景，或有太多的信息，太多分散的注意力。我们真的不知道如何集中注意力，或者如何处理所有这些正在发生的不同的东西。因此，我认为我的建议是，首先从你和你的团队开始，假设你的团队内部已经有相当好的工作实践，就开始关注外部，开始关注其他团队需要了解我们什么？我们如何才能使之明确？我们如何澄清他们如何与我们沟通？
曼努埃尔-派斯。
你可以使用团队API或其他人工制品，或者只是采用一些一致的方式，你在这里帮助其他团队与你沟通。因此，他们明白如果他们对你的团队有要求，或者如果他们需要与你的团队合作，应该使用哪些渠道，他们应该如何要求等等？就像我之前说的，这将会发展。随着时间的推移，你会发现，"嗯，实际上我们也需要澄清这个。我们需要澄清这一点，并不断发展，无论你使用团队API还是其他东西，你向他人展示你的团队的方式。所以，这是我想说的起点，你将不得不有点促进，你自己的工作方式给别人和沟通。
曼努埃尔-派斯。
它不会从一天到另一天，每个人都是如此。哦，好的。我们要看一下你的团队API，把这个问题弄清楚。所以你需要做一点营销，如果你喜欢的话，或者促进和发展你的工作方式，以及你如何与他人互动。然后在这之后，希望我们看到然后其他团队也开始采用类似的方式来澄清他们的沟通，他们喜欢如何被联系，等等。这是最理想的情况。这是非常有机的，你看到你开始，也许其他团队已经开始，你开始看到这一点，因为团队意识到这是有帮助的。我们开始做得更多，但你也可以提议，"为什么我们不采用一些共同的命名惯例？"特别是，当你发现问题时，你看到有太多的噪音，太多的信息。
曼努埃尔-派斯。
显然，你可以，取决于你在组织中的位置，但要把它带到表面，说 "让我们找出一个更好的方法来处理这个问题"，但当然，你需要在组织中关注这些原则，即减少沟通的认知负荷，减少噪音，确保事情更可预测，更容易发现，互动更明确。这些是你需要掌握的原则，以便在远程环境中寻找更好的沟通方式。
你现在对团队拓扑结构有什么想法？
查尔斯-汉伯。
我认为这些都是很好的建议。我想再补充一点，这来自于书的第一章，就是让信息自成一体的想法。我非常喜欢这一点，部分原因是...我们之前说过，团队拓扑结构是如何将软件工程思想应用于组织结构的，以及在这种情况下的沟通。我只是觉得这很有趣。所以在书中，你举了一个例子，而不是说你怎么想，这需要一个上下文切换，也许需要滚动来回答我对什么的看法这个问题。像这样的问题，"你认为我们应该从组件A切换到组件B，因为我们看到了组件A的性能问题？"......给问题的读者提供了背景，他们不必在聊天线程中寻找原始问题。我真的很喜欢这一点，因为...再次，另一个建议。所以让你的信息自成一体。我认为这非常酷。你的下一步是什么？你现在对团队拓扑结构有什么想法？
曼努埃尔-派斯。
我们正在努力的主要事情之一......事实上，我昨天刚和参与这个项目的人通了电话，实际上是为了有更好的、更有基础的方法来评估认知负荷和测量团队的认知负荷，这样我们就可以随着时间的推移来测量，看看我们为改善和减少认知负荷所采取的行动是否成功。因此，我们实际上是在与英国的一家公司合作做这件事，他们有合适的人，有心理学的学术背景，但他们也有组织设计的经验。所以找到他们是一种偶然，但这确实是一个很好的条件。因此，我们正在采取团队认知负荷的想法，并使其更加结构化。希望我们会有一些人们可以开始使用的工具。我们希望在今年年底前有一个第一版，然后发展它，看看它是否有帮助，我们如何改进它。
查尔斯-汉伯。
听起来非常令人兴奋。我期待着看到这一点，我将确保链接到远程团队的工作手册，我相信在我们的记录中，它即将问世。我想下周就会出来了。
曼努埃尔-派斯。
我想下周在欧洲。实际上我已经看到了来自美国的人。我在一个电话里，他们手里拿着书，我说："我没有......"
查尔斯-汉博。
你还没有，这对作者来说有点不公平！"。
曼努埃尔-派斯。
我想我现在应该有一个副本了，但它只是...由于目前的供应链，等等，以及所有这些事情。所以，是的，在欧洲，我想实体版将在5月底上市。顺便说一下，我们的另一个项目，正在进行中，我们去年开始的是团队拓扑学院，在那里我们试图浓缩我们的...不仅仅是书中的知识，还有我们之后获得的经验和对在线培训的新见解。对我来说，同样令人兴奋的是，我们也开始有了客座讲师。所以它从我们自己的团队拓扑相关课程开始，现在我们将有一些人带来他们在其他领域的经验，比如领域驱动设计或世界性的映射，以及如何与团队拓扑重叠。你如何能将两件事情或更多的事情结合起来使用，甚至实际得到更好的结果？我只想说，在项目方面也有一些让我相当兴奋的东西。
查尔斯-汉博。
是的。有趣的是。我们上个月请了苏珊娜-凯泽上节目。
曼努埃尔-派斯。
是的，她很了不起。
查尔斯-汉博。
是的。她真的是。她正在谈论她正在写的书，其中结合了团队拓扑结构、领域驱动设计和Wardley映射。与她的对话非常吸引人，真的推荐你去看那一集。但我也非常期待她的书出版。更广泛地说，我认为看到这个领域正在发生的工作让我非常兴奋。在组织设计和远程组织设计方面所进行的大量思考，我认为是非常令人兴奋的。我很感谢你在这个月和我一起参加《黑客组织》的这一集，来自WTF作为云原生的团队？容器解决方案的团队。
曼努埃尔-派斯。
谢谢你邀请我，查尔斯。这很好。
3359
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
