处理敏捷项目中的客户/开发人员文化不匹配

敏捷的宗旨之一是...

客户合作而非合同谈判

...另一个是...

个人与流程和工具之间的互动

但是从我的角度来看，至少在与客户互动方面，存在一个基本问题：

客户的想法与软件工程师的想法不同

是的，这可能有点概括。可以说，在某些业务领域中，这不一定是正确的，尽管这些领域很少而且相去甚远。但是，在许多领域中，典型的客户是：

1. 对日常运营问题感兴趣-短期策略...不一定是策略；
2. 可以理解，仅关注即时解决方案；
3. 实际的思想家，而不是抽象的思想家；
4. 与考虑解决方案将如何支持未来的问题相比，对“完成工作”更感兴趣。

另一方面，理想情况下，实践敏捷的软件工程师是：

1. 大量考虑质量的人；
2. 欣赏一些前期工作可以节省大量精力的个人；
3. 经验丰富的分析思想家。

因此，似乎存在文化差异，倾向于抑制“客户合作”。

解决此问题的最佳方法是什么？

但是，在许多领域中，典型的客户是：

• 对日常运营问题感兴趣-短期策略...而非策略；
• 只关注即时解决方案；
• 通常是一维的，非抽象的思想家；
• 最初对“完成工作”感兴趣，而不是提出一种持久的高质量解决方案。

坦率地说，他们通常有充分的理由进行这样的思考。首先，他们正在经营一项业务，该业务应该在今天和明天产生收入，而不是在遥远的将来。其次，他们不是技术专家-他们不知道什么是可能的，什么是不可能的，以及特定体系结构/设计/实现选择的后果。这就是我们所知道的。

因此，答案是-毫不奇怪- 沟通。

您需要进行大量交流，互相教育，使对方至少在基本水平上理解对方的观点。您需要向他们解释可能的替代方案的短期和长期后果。并且您需要使用他们理解的语言。

• 如果您说“这将是hack，这会使代码的可读性和可扩展性降低”，那么他们会说：“是的，随便什么”。
• 如果您说“这将是一个短期修复，这将使长期的开发和维护成本更高，并增加引入错误的风险”，那么他们会说“啊，让我们考虑一下”。
• 并且，如果您说“此解决方案现在将花费您100美元，但会引入500美元的技术债务，您早晚必须偿还利息； OTOH，另一种解决方案现在使您花费400美元，并且不留下技术债务；请选择一个想要”，他们说“现在我们在说话！” 。

OTOH他们可以教我们有关业务角度的一两件事。业务需要可用且足够好 -几乎不完美 -解决方案。他们可能比任何人都更清楚“完美是善的敌人”。因此，您需要记住，我们的工作是为客户的问题提供解决方案，而不是生产技术上完美的软件。有时这两个会收敛到相同的位置，但更多时候却不是。许多人可能会认为这很可悲，但这是商业现实。对我而言，如果我设法解决了客户的问题，并且发现这样做使他们的生活明显变得轻松了，那么我和他们一样快乐。OTOH如果我设法实现了我心目中的完美设计，但是该公司在下周破产了，那对任何人来说都很难赢吗？

明智的企业主将理解-如果您使用他们自己的语言解释它们-为什么保持软件清洁，编写单元测试，重构等重要的原因。即使这些似乎在短期内并没有直接贡献，对于长期维护至关重要。明智的客户确实关心他们的业务的长期可维护性，因此，当他们看到投资产生的价值时，他们肯定会愿意投资。但是，它们的资源和时间都是有限的，因此您需要确定优先级并专注于最重要的事情。但是，只有对你们两个都重要时，它才重要。

您可能需要重构模块A，因为其中的代码简直太糟糕了，并且您有一个绝妙的主意，如何使用刚刚阅读的设计模式将代码重构为简洁，优雅和简洁。但是，如果该模块已经使用多年，并且运行可靠，那么您最好将注意力集中在模块B上，该模块将在下周通过一项非常重要的新功能进行扩展，其中包含大量错误已经。

您的客户如何看待自己：

• 我有一个项目需要尽快完成
• 我知道我的业务需求
• 我需要以不会破坏当前业务实践的方式解决问题
• 我确实有有限的预算来完成这项工作。

另一方面，他们将您的群组视为：

• 那些不明白他们是在从我的预算中吸钱的家伙。
• 不了解我们业务的需求
• 想要重新设计所有内容，即使这将使在业务上实施起来更加困难。
• 当我所有的预算都有效且有效时，想要一个巧妙的解决方案。

您的主要问题似乎是你们俩都不了解对方的需求。

好吧，首先，敏捷不是解决项目中所有问题的解决方案。

客户的想法与软件工程师的想法根本不同

是。有时候是真的。甚至在某些情况下，客户也不知道自己想要什么和想要什么（即，要求不清楚）。无论如何，如果您很敏捷，那么每次冲刺（例如2周）之后都会得到结果，并且您有机会获得客户的反馈，并确保所有信息都在同一页面上。这有助于及早发现并解决问题，这将在内部帮助建立信任。

还有一种说法，用户就像疯了的孩子一样，因此，当他们要枪时，如果您知道它并不安全，则可以考虑使用玩具枪使他们平静下来。

解决此问题的最佳方法是什么？

正如我已经告诉过的，没有魔术棒可以解决所有这些问题。您需要更多地与客户互动，以便对彼此的行为有很好的了解。促进实地考察，开放反馈等

确保您的产品所有者和利益相关者参加sprint演示，并提出宝贵的建议以改进产品。

如果您没有客户的支持，那么敏捷几乎是不可能的。

通过买入，我的意思是每周或每月获得一定比例的客户代表时间。该百分比将因项目而异。

显然，他们有自己的日常工作，因此，这不仅取决于客户代表本身，还取决于他们的管理人员为他们腾出时间。

因此，要征得客户管理层的同意是解决此问题的关键

请记住，敏捷并不意味着客户参与日常的站起来或其他一些日常的敏捷方面。从客户的角度来看，敏捷与沟通有关。这并不意味着他们正在与工程师就实施细节进行沟通。

客户与产品负责人合作以获得并给出不断的反馈。主题是功能，但不是功能的实现方式。您是否提供适当的功能？你按计划吗？他们有需要适应的变化需求吗？

敏捷帮助您和您的客户回答这些问题。