注意:Don Reinertsen是敏捷方法中最有影响力的声音之一。虽然Don本身不是软件专业人士，但他受到了广泛的尊重，并被许多撰写敏捷、DevOps和相关主题的作者引用。

唐Reinertsen
唐Reinertsen

唐的主要著作管理设计工厂而且产品开发流程的原则仍然是全球产品经理在数字和物理领域的首选读物。涵盖了流程、在工、变化、选项、排队和去中心化等关键主题，Don带来了精确的词汇和强大的分析工具集，以应对创建支持敏捷和DevOps的下一代运营模型的挑战性问题。

去年夏天，唐慷慨地为我的报告做研究。”你的运营模式必须支持创新，采访中有很多有价值的材料，其中一些(在他的同意下)我在这里转载，只是为了内容和流程做了少许编辑。下面，Don和我将讨论专业知识的问题，以及共享服务组织在管理专业知识作为服务方面是如何失败的。

查理:最近我在Forrester公司收到的询问中，如果是关于跨职能团队的，我们经常会遇到一些您在工作中提到的人员配置问题。例如，我们反复听到，“我们没有足够的数据库管理员(或网络工程师，或安全架构师)让每个团队都有一个。我们要么使用共享服务，要么面临人手短缺。”我们有很多团队需要专业人士的快速反应，但他们并不总是需要这样的人。

在你的书中，产品开发流程的原则，你提到海军船上的每个人都接受过消防等损害控制技能的培训。然而，拥有基本的损害控制技能与将开发团队中的每个人都培养成熟练的数据库管理员是非常不同的。

在开发过程中，我们经常需要既深入又稀缺的技能。当这些技能不可用时，我们可以创建昂贵的工作队列。我想知道，在这个运营模式越来越趋向于半自治、跨职能团队、越来越多的多面手而不是专家的世界里，如何处理技能稀缺的问题，你有什么见解吗?

唐:这听起来像是上世纪80年代的重演。1981年，IBM在博卡拉顿的一个完全自主的团队迅速设计出了第一代IBM个人电脑，震惊了世界。我与参与这个项目的一位员工交谈，他说:“如果我们使用标准的IBM组织和程序，我们将花费三年时间来交付一个空盒子。”这一成功让每个人都相信，最好、最快的开发方式是建立一个自主的、跨职能的团队。有一个巨大的运动追求自治团队的好处，后来，一个巨大的惊喜，当人们发现这样的团队有重要的缺点和他们的优点。

我记得我曾与一家医疗设备公司的制造工程经理进行过一次对话，该公司使用相对自主的跨职能团队。他告诉我:“上周我们的一款产品出了质量问题。我们的产品使用模压聚碳酸酯部件，连接到乙烯软管。无菌软管通常在使用前立即连接，并在操作结束时处理掉。这些部件的保质期很长，而且我们用这种方法从来没有出现过质量问题。这一次，团队决定将乙烯基软管预组装到连接点，但遇到了严重的质量问题。

“当乙烯基软管长时间连接到一些聚碳酸酯塑料部件上时，会出现一种微妙的故障模式。软管中的增塑剂渗入聚碳酸酯部分，使其变弱。如果聚碳酸酯部件在制造过程中有残余应力，它最终会破裂。因此，我们中的一些人了解到，任何与乙烯基软管长时间接触的聚碳酸酯部件都必须进行应力缓解。”

他指出，这种特殊的失败模式被反复发现，因为每个团队只知道自己的设计发生了什么。他说:“因为我接触了所有团队的工作成果，我已经成为组织在这个问题上的记忆。我似乎是唯一一个记得在这种情况下我们必须强调减轻这些部分的人。”

他的观点，我认为是非常重要的，就是你建立深厚专业知识的能力与你接触问题的次数成正比，尤其是有重要后果的低频问题。如果你在一个领域每周工作40个小时，你会比在同一个领域每周工作1个小时更快地获得经验。许多拥有跨职能团队的公司所创造的环境降低了具有专业技能的人员获得专业知识的速度，这削弱了公司的技能基础。

最终，你的组织结构会影响你培养专业技能的速度。在技术和市场需求变化缓慢的领域，这可能不是一个问题，但当您使用前沿技术生产先进系统以满足快速变化的市场需求时，这是极其重要的。虽然自主的、跨职能的团队带来了重要的好处，但关键是要意识到他们削弱了什么，并针对他们的缺点采取相应的对策。

我们常常错误地认为多面手可以解决我们所有的问题。通才是必要的，但复杂的系统总是将其与专门化结合起来。像人体这样的多细胞生物的设计就是一个很好的类比。在人体中，不是每个细胞都要做所有的事情。相反，身体被组织成专门的器官系统，因为器官以不同的化学物质运作，并且经常完成依赖于规模的任务。胃酸的低pH值如果被吸入肺部会造成严重破坏。

大多数复杂的系统都具有重要的专门化作用。有时我们在产品开发中可以naïve。几乎每次有人告诉我，他们正在使用一个完全自主的跨职能团队时，当我深入研究时，我发现他们必须建立一种机制，以创造不频繁但快速的深入专业知识。虽然拥有广泛技能的通才非常有价值，但如果每个人都什么都做，那么我们就不需要专家的想法显然会失败。我们知道这一点，因为它对人们来说已经失败了，他们已经想出了聪明的变通办法来克服缺点。问题是，他们仍然在阐明与他们真正做的和真正有效的不匹配的教条。

值得注意的是，共享服务模式的最大问题之一已经存在了至少40年。人们根本不理解如何衡量共享服务的性能。他们naïvely假设，既然他们花钱生产产出，他们就应该衡量每单位产出的成本。如果您以每单位产出的成本来衡量共享服务，那么您将最小化服务中的空闲时间，从而实现高水平的利用率。不幸的是，如果将高利用率和波动的需求结合在一起，就会产生严重的排队问题，从而导致长时间且不可预测的响应时间。

不幸的是，由于排队问题与专家的存在相吻合，公司通常认为是专业化本身导致了排队问题。事实上，排队问题并不是因为你有专家。当你有专家，同时用错误的指标衡量和激励他们时，就会发生这种情况。

选择不当的度量标准会有意或无意地导致共享资源的利用率过高。多年来，我发现团队通过要求直接控制这些资源来应对过度使用的共享资源的长延迟和慢响应时间。他们要求专家加入他们的团队。奇怪的是，当共享资源具有高容量、持续低延迟和快速响应时间时，没有人想要管理一个较小的本地资源来取代性能令人满意的共享资源。

因此，我认为人们实际上是将问题误诊为组织结构的问题，而实际上，问题在于你不明智地管理一个共享的专家小组。

查理:正确的。它是专家的操作模型及其相关的绩效衡量标准。

唐:是的，人们不断来找我说，为了让他们的项目达到预期的结果，他们需要直接控制影响结果的每个人。他们会说:“我的团队需要采购人员;我的团队里需要有制造工程师;我的团队需要有质量保证。”

所以，我问他们:“你为什么需要他们?”他们会说:“因为他们的工作很重要，它会影响我获得好结果的能力。”然后我说，“你需要在你的团队中有工资单功能吗?”他们会说:“不，我为什么需要这个?”我说:“工资很重要吗?人们不喜欢按时收到支票吗?”他们会说:“是的，这很重要，但工资单做了他们的工作——他们做了他们应该做的事情。”

所以我说，“在一天结束的时候，你不需要一打额外的技能来管理你的团队。您需要使这些共享资源响应您的实际需要。当您使用响应迅速、符合您的期望的共享资源工作时，您真正的服务标准也得到了满足，那么您就不会想要管理另一组专家的额外头痛。您需要关注如何度量共享资源的性能，以及如何使人们能够实现这种性能。解决了这个问题，你就不会有兴趣让他们加入你的团队。”

唐可以通过Reinertsen & Associates．