该文本由 Miguel Carruego 与 IT 和翻译 Yuna 合作撰写。产品文化破裂的症状 — 第 1 部分这是>的翻译。作者 米格尔·卡鲁埃戈是一位位于巴塞罗那的首席运营官，在连接业务目标和用户需求方面拥有卓越的专业知识。本文是不良产品文化的症状的第 1 部分，探讨组织经常面临的主要问题。以下第 2 部分介绍了解决这些问题的实用策略。
经作者许可翻译，文中链接均按原文标明。
不良产品文化的症状第 1 部分
如果我每做出一个糟糕的管理决策就能得到一分钱，那么我现在就很富有了，我就不会写这篇文章了。不开玩笑了，我从短暂但强大的产品领导经验中学到的教训之一就是关于危险信号。当时我没有看到，但现在回头看却能清楚地看到。本文来自陈文森的《大规模产品变革我受到这篇文章的启发并写下了它。这篇文章给了我很大的启发，并帮助我整理了我的想法。要涵盖的主题有很多，因此本文将重点讨论该问题，并在下一篇文章中讨论解决该问题的策略。
紧急灭火
每家公司都有比其员工有时间处理的更多问题。最好的结果可能来自于可以忽略小问题的环境。但在最坏的情况下，您最终会耗尽继续响应紧急问题所需的资源。经理和工程师甚至没有完成一项任务就跳到下一个问题。
尝试解决问题最终成为毫无意义的权宜之计，团队的生产力急剧下降。工作管理变成了一场无休止的杂耍游戏，选择当前需要解决哪些问题，而决定将过度劳累的员工安置在哪里也成为一个巨大的挑战。
在阿根廷，它被称为“焦糖果酱”（焦糖酱）据说表达为“船中划行”。如果这种情况听起来很熟悉，那么您的组织 赶紧把火扑灭 存在的可能性很大。您可能经历过以下症状：
- 没有足够的时间来解决所有问题。 需要解决的问题已经超出了能够妥善处理的问题解决者（工程师、经理或知识工作者）的数量。
- 该解决方案是不完整的。 很多问题只是暂时解决，并没有从根本上解决。表面现象解决了，但根本原因没有解决。
- 问题再次出现或蔓延。 不完整的解决方案通常会导致现有问题再次出现或在组织的其他地方产生新问题。
- 紧急性优先于重要性。 正在进行的解决问题的努力和长期活动（例如开发新流程）被反复中断或推迟。这是因为你别无选择，只能先集中精力处理眼前的问题。
- 许多问题发展成为危机。 问题会在截止日期前堆积起来并爆发。因此，需要付出巨大的努力来解决这个问题。
- 性能受到影响。 随着未解决问题的堆积和失去机会的增加，组织的整体绩效急剧下降。
这种情况下最大的问题是，工程师在应急响应过程中别无选择，只能想出快速粗暴的解决方案，而不是找到高效的解决方案。因为没有足够的时间找出问题的根本原因，所以我会直观地诊断它，然后临时更改代码，然后再进行验证。如果一个简短的修复不能完全解决问题（而且通常是不明确的），我会保留更改并尝试不同的方法。没有按照这种方式系统地处理问题，最终导致了解决问题失败的局面。创可贴解决方案不仅比系统性解决问题花费的时间更长，而且也没有解决问题的根本原因。
终于 临时解决方案有毒。暂时解决的问题会产生新的问题，已经解决不了的问题还会不断出现。出现的许多问题都是老问题又重新出现。工程师的工作环境变得越来越混乱，进行实验并清晰地发现问题变得越来越困难。它甚至可能导致组织解决问题的能力彻底崩溃，导致整体绩效大幅下降。
<출처 : 《停止救火》作者：罗杰·博恩 —《哈佛商业评论》>
以 IT 为中心的思维与以产品为中心的思维
正如 Marty Kagan 所解释的那样，以 IT 为中心的公司尝试管理以用户为中心的产品技术，例如内部 IT 技术。但这种方法不仅会导致糟糕的客户体验，还会给组织带来挑战。
那么为什么以用户为中心的产品与IT产品不同呢？原因有很多。 IT产品是员工必须在公司指导下使用的工具。另一方面，用户产品 每个用户都会做出自己的购买决定。 如果用户不想要它，就不会使用它。此外，虽然IT产品可能需要企业提供培训课程、手册和专业服务，但以用户为中心的产品必须能够立即被用户理解和使用。否则，您只需单击一下即可转向竞争对手。
IT 产品以数百为单位衡量用户规模和并发用户数。另一方面，以用户为中心的产品面向数十万，有时甚至数百万人。此外，如果IT产品出现问题，员工必须解决它。然而，当用户产品遇到服务中断等问题时，它会迅速影响销售并成为立即引起首席执行官注意的严重问题。
事实上，大多数以用户为中心的产品在定义、设计、实施、测试、部署和支持方面比IT产品需要更高的标准。这通常也反映在工资水平上。寻找具有您所需的产品经验的人员比寻找具有 IT 经验的人员困难得多。
两种思维方式的区别可以概括如下。
以 IT 为中心的思维
以产品为中心的思维
缓慢的结果
准确地说，用敏捷的术语来说，在使用 Scrum 方法的团队中， 速度它表示 Scrum 团队在冲刺期间完成的平均工作量，将产品待办列表中的工作项转换为可交付给客户的表单。这通常是 燃尽图它被测量为 .速度的问题之一是它可能会混淆工作量和计划的准确性。
例如，如果团队保守地估计工作量，则费率可能会被夸大。如果一个团队估计某项任务需要 4 小时，而实际需要 2 小时，或者将该任务的分数设置为 4 而不是 2，那么该团队的速度就会显得更高（这通常称为分数膨胀）。因此，速度本质上没有好坏之分。
终于 只注重输出速度而不注重结果的问题从客户的角度来看没有任何意义。无论您的持续集成/持续交付 (CI/CD) 流程多么出色，如果它不能直接提高客户从您的产品中获得的价值，那么它就毫无意义。
取得成果既需要改进现有方法的创新，也需要推动根本性变革的创新，具体取决于具体情况。但并非所有组织都准备好对需要根本性变革的创新做出快速响应。
日程混乱
不良产品文化的另一个明显症状是 日程不断变化的情况没看到。如果每次环境发生变化时，您都感觉自己的优先事项和日程安排发生了动摇，那么是时候考虑一下了 产品愿景是时候检查一下了。
此问题通常有两个根本原因之一：一是没有清晰、扎实的产品愿景，二是产品愿景太弱，无法承受商业环境。缺乏远见不仅会导致日程安排混乱，还会导致一些问题，包括定义团队结构、建立业务领域、调整优先级以及设置 OKR（目标和关键结果）。
使用以下清单来审查您的产品愿景。
- 是以客户为中心吗？
- 具有挑战性但不现实？
- 它能让您从竞争对手中脱颖而出吗？
- 你在展望未来吗？
但缺乏远见并不是所有问题的唯一原因。持续的日程变化可能是由于流程效率低下、决策结构不明确或组织文化问题造成的。因此，要解决问题，您不仅必须检查产品愿景，还必须检查组织的流程和文化。
破碎的信任
由于上述所有问题，产品组织正在失去信任。利益相关者将流程、产品经理、产品设计师和其他一切视为进步的障碍。正如您所知，软件开发组织因无法提供真正的价值而享有负面声誉，信任在提高公司效率方面发挥着关键作用。为了使人与人之间能够进行公开和诚实的沟通，必须建立一定程度的信任。员工之间无效的沟通会减慢工作流程、降低生产力并增加成本。
发生这种情况的最大危险信号之一是利益相关者试图完全绕过产品经理或传统的变更请求流程，直接与工程师沟通以将他们的工作融入到产品中。
结论
我们还没有明确定义产品文化到底是什么。产品文化既不是一系列一次性的团队建设活动，也不是一种适用于所有情况的“产品方式”答案指南。这不是某人可以开出处方的东西，而是你必须发现的东西。最重要的是我们可以共同创造一种产品文化。现在，我不能确定什么是产品文化，但至少我已经解释了它不是什么。
因此，如果您在组织中发现以下迹象：
- 解决紧急消防问题
- 以 IT 为中心的思维
- 缓慢的结果
- 日程混乱
- 破碎的信任
现在可能是采取行动的时候了。在下一部分中，我们将更深入地讨论解决这些问题的策略和策略。
<참고>
<원문>
上述译文的原始版权属于Miguel Carruego，受版权法保护，未经授权禁止复制、复制、分发等。
#繁忙产品急于救火的问题