The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
当我们向客户解释项目第一天起他们将完全获得源代码的访问权限时，大多数客户都感到非常惊讶。我们让他们看到项目中发生的一切，包括Git代码库、错误报告、程序员之间的讨论、持续集成失败等等。他们经常告诉我，其他软件开发外包团队会将这些信息保留在内部，仅在最终发布时才交付源代码。
我理解为什么其他开发人员尽可能隐藏这些信息。给一个项目赞助商完全访问开发环境并不容易。下面是我们遇到的问题以及我们的解决方案的摘要。我希望它们能帮助您诚实地向客户展示所有项目内部，并仍然保持他们的支持。
这是我们与新客户面临的最常见问题。一旦他们获得开发环境的访问权限，他们就试图直接向程序员发布指令，绕过我们现有的流程。“我在付钱给这些家伙，为什么不能告诉他们该做什么？”这是一种非常典型的思维方式。这样的客户不会通过我们的标准变更管理机制提交请求，而是直接找其中一个程序员，告诉他应该修复什么、如何修复以及何时修复。这是最糟糕的微观管理形式。我们经常看到这种情况。我们该怎么办？
首先，我们试图弄清楚为什么会发生这种情况。最简单的答案是客户是个白痴。有时确实如此，但这是罕见的情况。更常见的情况是，我们的客户并不那么糟糕。那么是什么原因呢？为什么他们不能遵循流程并遵守规定？有几种可能的原因。
也许规定没有解释清楚。这是最常见的根本原因——客户不清楚工作规则。他不知道为了提交请求并使其得到实施应该做什么。为了防止这种情况发生，我们在项目开始时努力教育客户。我们甚至为客户编写指导手册。大多数客户都乐意阅读并了解我们的工作方式，因为他们明白这是与我们合作取得成功的最佳途径。
也许我们的管理混乱，客户正试图通过明确的指令来“组织”我们的工作。我们以前见过这种情况，并一直试图从中吸取教训。一旦我们发现客户试图对我们进行微观管理，我们就会问自己：“我们的流程是否足够透明？我们是否向客户提供足够的里程碑、风险、计划、成本等信息？”在大多数情况下，这是我们自己的问题，我们正在努力学习和改进。如果是这样，那么在客户变得过于咄咄逼人之前，及时做出反应非常重要。一旦他对“微观管理”上瘾，将非常难以使他重新回到正常的流程中。
也许客户没有太多事情要做，有很多空闲时间，他愿意用来下指令并分散你的团队的注意力。我见过这种情况很多次。解决办法是让他忙起来。让他成为团队的一员，指派他一些与文档和研究相关的任务。根据我的经验，大多数客户愿意做这样的工作并帮助项目。
一个对技术敏感的客户会让建筑师的生活变成噩梦，不断要求解释每一个技术决策，从“为什么选择PostgreSQL而不是MySQL？”到“为什么这个方法不会抛出一个已检查的异常？”不断回答这些问题会把一个项目变成一个编程学校。即使他付费我们的时间，那也不代表我们应该教他如何开发软件，对吧？另一方面，他对他的软件是如何开发和运行的感兴趣。这是一个合理的要求，对吧？
我相信这个问题有一个*双赢的解决方案。以下是我们如何处理它。首先，我们要求客户提出所有请求，并创建一个新的工单，清楚说明哪些地方不清楚，期望在解释中提供多少细节。
其次，我们积极看待这些请求——它们是软件中某些不一致性的良好指标。如果客户不清楚为什么使用PostgreSQL而不是MySQL，那是我们建筑师的错误。他没有记录他的决策，也没有解释它是如何做出的，考虑了哪些其他选项，应用了什么选择标准等等。因此，客户的请求就是我们免费得到的一个缺陷。所以，我们积极对待它。
最后，我们向客户收费来回答这些问题。每一个提交为一个工单的问题都需要经过完整的流程，并计费，就像任何其他工单一样。这种做法防止客户提出过多的问题。他意识到我们愿意解释他想要的任何东西，但他需要为此付费。
这个问题比之前的问题还要严重。一些客户认为他们足够精明，可以与我们的架构师和程序员争论软件应该如何开发。他们不仅仅是询问为什么使用PostgreSQL，还告诉我们应该使用MySQL，因为“我知道这是一个很好的数据库；我的朋友在用它，他的生意正在增长！”有时情况会更糟，建议甚至直接针对每个类或者方法，比如“你应该在这里使用单例模式！”
我们的第一选择是同意并按他的要求做。但这是一条通向无底深渊的道路。一旦你这样做了，你的项目就被毁了，你应该开始考虑与这个客户解约。你的整个团队将迅速变成一群被有钱人微观管理的编码猴子。这是一个非常错误的方向，甚至不要考虑去那里。
第二选择是告诉客户去管好自己的事，让我们来做我们的事。他雇佣我们是因为我们足够专业，能够根据他的要求开发软件。如果他质疑我们的能力，他可以自由地改变承包商。但在那之前，他必须相信我们的决策。这样行得通吗？我怀疑。这等于是给他竖了中指。他会感到冒犯，而你将一无所获。
解决方案是将客户的需求转化为项目需求。其中大部分将在这个过程中丢失，因为他们无法形成一个好的需求。其他一些将被记录、估算，并由客户自己划掉，因为他会意识到这些需求是无意义或者太昂贵的。只有少数几个将幸存下来，因为它们足够合理。它们将有助于项目的进行。所以这也是一个双赢的解决方案。
例如，他说“你应该使用MySQL，因为它很好。”你告诉他项目需求文档并没有限制你选择任何你喜欢的数据库。应该吗？他说当然！好吧，让我们试着记录这样一个需求。它会是什么样子？比如，“我们应该只使用好的数据库？”听起来正确吗？如果是的话，那么PostgreSQL满足这个需求。问题解决了；让我们继续做我们的工作。他将很难想出如何以一种不允许使用PostgreSQL但允许使用MySQL的方式来书写需求。在大多数情况下这是不可能的。
然而，有时候这样做是有道理的；例如，“我们应该使用一个能理解我们遗留数据的MySQL格式的数据库服务器。”这是一个完全合理的需求，满足它的唯一方法就是使用MySQL。
因此，我的建议是永远不要直接按照客户的要求执行，而是先使用它们来修改需求文档。即使你没有这样的文档，也可以创建一个简单的一页纸的文档。与客户达成一致，你按照这个文档来工作，当有人想要改变某些东西时，你首先必须修改文档，然后让你的团队确保软件满足它。这种纪律将被任何客户接受，并会保护你免受突然而分散注意力的更正。
当源代码对客户开放，并且他具备技术阅读能力时，有可能有一天他会告诉我们我们的代码糟糕，我们需要学会更好地编程。在我们的项目中已经有很多年没有发生过这种情况，但在我们没有将静态分析作为持续集成流程中的强制步骤之前，这种情况确实发生过。
另一个有趣的可能性是当客户将源代码展示给“朋友”，他给出的“专业”意见听起来像是“他们不知道他们在做什么”。一旦这样的意见传到客户的耳朵里，项目就面临着被关闭的重大风险。很难，几乎不可能，说服客户不听取“朋友”的意见并继续与你合作。这就是为什么大多数外包商愿意在项目的最后付款时才公开他们的源代码。
我认为一个“朋友”出现并给出负面意见是无法预防的。如果发生了，就发生了。你无法避免。另一方面，如果你认为你的代码是完美的，你的团队只有才华横溢的程序员编写出了优秀的软件，这也不能保护你。从“朋友”那里得到的意见不会客观，只会非常个人化，这就是为什么它非常可信。他是客户的朋友，他每周不向客户寄账单。他为什么要撒谎呢？当然，他是发自内心的说的！（我是在讽刺。）所以，无论你的架构和源代码多么美丽，这个“朋友”总是对的。
在我看来，防止这种情况或减少其后果的唯一方法是组织定期和系统的独立技术审查。这将给客户信心，让他相信团队没有对产品质量和内部做出的关键技术决策进行欺骗。
总之，我坚信与每个客户保持诚实和开放是非常重要的，无论有多么困难。尽量从与每个客户的冲突中学习，并改进您的管理流程和工作原则。隐藏源代码不是专业的做法，会让您在客户和整个行业中显得不好。
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-27 at 10:51
