如何做到诚实守信

当我们向他们解释他们从项目第一天就可以完全访问源代码时，大多数客户都感到非常惊讶。 我们让他们看到项目中发生的一切，包括Git存储库，错误报告，程序员之间的讨论，持续集成失败等。他们经常告诉我，其他软件开发外包团队将这些信息保留在内部，仅提供最终信息。发布，很少与源代码一起发布。

我理解为什么其他开发人员试图尽可能地隐藏。 让项目发起人完全访问开发环境绝非易事。 这是我们遇到的问题和解决方案的摘要。 我希望他们能帮助您诚实地向客户展示所有项目内部情况，并仍然让他们参与其中。

Jan Kounen制作的99法郎（2007年）

他正在打破我们的程序

这是我们新客户面临的最普遍的问题。 一旦他们获得了开发环境的访问权，他们就会尝试直接向程序员提供指令，并逐步执行我们现有的流程 。 “我要付这些人钱。 我为什么不能告诉他们该怎么办是一个非常典型的心态。 这样的客户无需直接通过我们的标准变更管理机制提交请求，而是直接去一位程序员那里，并告诉他应该确定哪些问题，如何解决以及何时解决。 它是最坏形式的微观管理。 我们经常看到它。 我们做什么

首先，我们尝试了解它为什么会发生。 最简单的答案是客户是白痴。 有时候确实是这样，但这是罕见的。 很多时候，我们的客户并没有那么糟糕。 之后怎么样了他们为什么不能遵循流程并遵守规则有一些可能的原因。

也许规则解释得不好 。 这是最流行的根本原因-客户的工作规则不够清晰。 他只是不知道要提交请求并实现该请求应该做什么。 为防止这种情况，我们尝试在新项目开始时就培训客户。 我们甚至为客户编写指导手册。 他们中的大多数人都很高兴阅读它们并了解我们的工作方式，因为他们知道这是与我们合作时取得成功的最佳途径。

也许我们的管理混乱了 ，客户试图通过给出有关最重要任务的明确指示来“组织”我们。 我们之前已经看过它，并且我们一直在努力学习。 一旦发现客户正在尝试对我们进行微观管理，我们就会自问：“我们的流程是否足够透明我们是否向客户提供有关里程碑，风险，计划，成本等的足够信息在大多数情况下，这是我们自己的错，我们正在尝试学习和改进。 如果是这样，在客户的命令和指示变得过于激进之前，快速做出反应非常重要。 一旦他的血液被“微观管理”，将很难护送他回到正常过程。

也许客户不够忙，有很多空闲时间 ，他很乐意通过下订单和分散您的团队来度过。 我已经看过很多次了。 一个解法让他忙。 将他变成团队成员，并为他分配一些与文档和研究相关的任务。 以我的经验，大多数客户都乐于完成这项工作并为项目提供帮助。

他要的太多了

精通技术的客户可以通过不断要求建筑师解释每个由“为什么用PostgreSQL代替MySQL来做改为“为什么此方法不引发检查异常不断回答这些问题可以使一个项目变成一门编程学校。 即使他为我们付出了时间，但这并不意味着我们应该教他如何开发软件，对吗另一方面，他有兴趣了解他的软件是如何开发的以及它是如何工作的。 这是一个公平的要求，不是吗

我相信有一个双赢的解决方案。 这是我们的管理方式。 首先，我们正式提出他的所有要求。 我们要求客户为每个请求创建一个新票证，正确解释不清楚的地方以及期望解释的详细程度。

其次，我们积极地看待此类请求-它们很好地表明了软件中某些不一致之处。 如果客户不清楚为什么要使用PostgreSQL，而不是MySQL，那是我们的架构师的错。 他没有记录自己的决定，也没有解释该决定是如何做出的，考虑了哪些其他选项，应用了哪些选择标准，等等。因此，来自客户的请求是我们免费获得的错误 。 因此，我们积极地看待它。

最后，我们向客户收取给出的答案。 以票证形式提交的每个问题都将贯穿整个流程，并像其他票证一样收取费用 。 这种方法可以防止客户要求太多。 他意识到我们已经准备好解释他想要的任何东西，但是他会为此付费。

他讲的太多了

这个问题比上一个更大。 一些客户认为他们很聪明，可以与我们的架构师和程序员讨论如何开发软件。 他们不仅问为什么要使用PostgreSQL，还告诉我们应该使用MySQL，因为“我知道这是一个很棒的数据库；我知道它是一个很好的数据库。 我的朋友正在使用它，他的业务正在增长！” 当建议针对每个类甚至某个方法时，有时甚至变得更糟，例如“您应该在此处使用Singleton模式！”

我们的第一选择是同意并做他想做的事情。 但这是一条无路可走的路。 完成此操作后，您的项目就毁了，您应该开始考虑与该客户离婚。 您的整个团队将很快变成一组编码猴子，由拥有现金的人进行微管理。 这是一个非常错误的方向。 甚至都不考虑去那里。

第二种选择是告诉客户注意自己的生意，然后让我们来做。 他之所以雇用我们，是因为我们足够专业，可以根据他的要求开发软件。 如果他质疑我们的能力，他可以自由更换承包商。 但是在那之前，他必须相信我们的决定。 这样行吗我对此表示怀疑。 就像给他手指一样。 他会被冒犯，而你一无所获。

这里的解决方案是将客户的需求转化为项目需求。 它们中的大多数将在此过程中丢失，因为它们不够理智以形成良好的需求。 客户会自己记录，估算和删除其他项目，因为他会意识到这些项目毫无意义或过于昂贵。 由于它们足够合理，因此只有少数能够生存。 他们将帮助该项目。 因此，这也是一个双赢的解决方案。

例如，他说“您应该使用MySQL，因为它很棒”。 您告诉他项目需求文档并没有限制您选择喜欢的数据库。 应该是他说是的，当然！ 好的，让我们尝试记录一下这样的要求。 听起来如何怎么样，“我们应该只使用出色的数据库听起来正确吗如果是这样，则PostgreSQL满足此要求。 问题解决了; 让我们继续做我们的工作。 他将很难弄清楚如何以不允许PostgreSQL但允许MySQL的方式编写需求。 在大多数情况下，这根本不可能。

但是有时候，这是有道理的。 例如，“我们应该使用能够理解MySQL格式的旧数据的数据库服务器”。 这是一个完全合理的要求，满足此要求的唯一方法是使用MySQL。

因此，我的建议是永远不要将客户的需求直接执行，而要先使用它们来修改需求文档。 即使您没有此类文档，也可以创建一个简单的一页文档。 同意客户对本文档的要求，当任何人想要更改某些内容时，您首先必须修改该文档，然后让您的团队确保该软件能够满足要求。 这类纪律将为任何客户所接受，并将保护您免受突然而分散注意力的纠正。

他在质疑我们的技能

当源代码对客户开放时，并且他有能力阅读该源代码时，很有可能他有一天会告诉我们我们的代码是废话，我们必须学习如何更好地编程。 多年来，这在我们的项目中从未发生过，但是在我们没有将静态分析用作持续集成流程中的强制性步骤之前，这已经发生过。

另一个有趣的可能性是，当客户将源代码显示给“朋友”时，他给出了“专业”意见，听起来像是“他们不知道自己在做什么”。 一旦您的客户听到了这样的意见，该项目就有关闭的巨大风险。 要说服客户不要听“朋友”并继续与您合作，将是非常困难的，几乎是不可能的。 这就是为什么大多数外包商宁愿将其资源保密，直到项目的最后阶段，即最终发票付清后。

我认为，带有负面意见的“朋友”的偶然出现是无法避免的。 如果发生，它就会发生。 你无法避免。 另一方面，如果您认为您的代码是完美的，并且您的团队只有才华横溢的程序员编写精美的软件，那么这也不会保护您。 来自“朋友”的观点不是客观的。 这将是非常个人的，这就是为什么它非常可信的原因。 他是客户的朋友，他每周都不寄账单给他。 他为什么要说谎当然，他发自内心地说话！ （我很讽刺。）因此，无论您的体系结构和源代码多么漂亮，“朋友”总是对的。

我认为，防止这种情况或最大程度地减少其后果的唯一方法是组织定期和系统的独立技术审查 。 他们将使客户确信，团队没有对产品质量和内部关键技术决定对他撒谎。

总而言之，我坚信无论面对多么困难，与每个客户保持坦诚和开放很重要。 尝试从与每个客户的每次冲突中学习，并改善您的管理流程和工作原则。 隐藏源代码并不专业，这会使您在客户和整个行业的眼中显得很糟糕。

翻译自: https://www.javacodegeeks.com/2015/01/how-to-be-honest-and-keep-a-customer.html

来源：danpu0978