我是Live Typing的项目经理。 去年，我们在公司博客中写道，如果截止日期未能完成，那么最主要的事情就是不要让它感到惊讶并警告客户。 但是，我们工作的时间越长，我们越会意识到，比截止日期更糟的情况只会变得更复杂，情感上的客户和团队在压力下会精疲力尽。
那些在工作期间获得了几个常规客户的公司，即使在首次致电的阶段，也知道如何过滤可疑线索，并且负担得起。 las，追求经验和收入的年轻工作室，las，离不开此类客户。
在进入各个行业的前十名之前，
Live Typing与一位客户合作，这让团队非常沮丧，以至于人们开始离开公司。 基于以下原因，我们再次与客户达成了一致。 由于担心新的关系危机，我制定了一种特殊的管理策略来保持团队的安全和健康。 毕竟，要找到一个优秀的开发人员很困难，而且培训和适应新员工要比留住老员工贵得多。 此外，外包的细节使得在该项目完成后，开发人员将接手下一个项目，而且重要的是，他们必须动脑筋才能做到。
关于我的操作方法，请阅读文章。
出于明显的原因，我将客户简称为“客户”。 即使在项目中，经过反复合作，我们团队内部也没有其他要求。 怎么了 关于它下面。
背景知识
两年前，一个项目来到了我们。 在找到我们之前，大约有五个团队进行了工作，他积累了不错的旧代码。
客户与以前的团队的关系远非合作伙伴，因此他决定自动采取进攻立场，用不信任的墙围住自己。
为了加快沟通和开发速度，第一位项目经理使Slack的聊天对于客户和团队来说很常见-该应用程序不是我们开发的，因此提出了很多问题，这些问题必须尽快解决。 在大多数情况下，这种方法可以加快团队成员之间的信息传递，但是我们的客户并没有否认自己有机会在聊天中或针对特定人员的粗鲁评论。
客户求助于个性，这导致了公开冲突，甚至没有参与的人也听到了他的名字。 结果，该公司损失了至少一名无法忍受这种态度的员工，几个月后又剩下了几名。 离开的正式原因似乎有所不同，但我们知道一些事情。
当客户的钱用光时，我们分手了。 值得一提的是，这些钱包括了对遗留代码的支持以及为功能而开发功能。
客户后来返回。 他说服我们，他想从头开始开发应用程序，放弃过时的代码，减少功能并以另一种风格进行交流。 我们接受了，但是一段时间后，这个故事开始重演。
客户不信任我们的评分和报价。 他对产品应如何运作有自己的想法。 我们对如何使用也有一定的了解，但是客户并没有理解这些争论，他没有在应用程序开发方面拥有专业知识的合作伙伴，而是在我们看来只有将自己的愿望清单变成现实的手。 我们不知道客户为何将自己置于这样的位置并且不会进行猜测。
局势正在升温。 回顾过去事件的发展方式，我们以不寻常的顺序为我们分配了优先级：首先，您需要挽救团队，然后才能成功关闭项目，并在可能的情况下保持客户忠诚度。
针对复杂客户的保护策略
现在，让我们看一下有助于实现目标的技术，不应该重复的错误以及可以在工作中使用的结论。
解释设计的价值
因此，该项目从头开始。 在此决定的背景下，提出了一项建议，即按照固定价格模型进行MVP并为我们的工作付费。 这似乎是合乎逻辑的，因为如果没有其他人的代码，则没有任何风险。
固定价格减去付款方式就是它失去了项目的灵活性：在实施功能（各方在技术任务中达成一致）的同时，市场可能会发生变化，并且工作结果将不再解决实际的用户问题。 仅当您已经彻底且彻底地检验了所有假设，设计了技术规格并编写了详细的文档后，才可以以固定的价格开发MVP。 我们的客户只是忽略了设计，或者说是把设计交给了自己。
选择聊天服务的故事具有指示性。 客户亲自调查了可能的技术解决方案，并为我们提供了多种服务的选择：“哪个更好？” 我们选择服务A是因为它适合于一组API方法上的项目，并且从开发和集成的角度来看，它比服务B更好。我们没有将服务设计为可与我们的基础架构一起使用，并且没有检查这些正式标准以外的任何内容：既没有稳定性，没有响应速度，什么都没有-没有预算。 聊天最终的响应速度比没有时间检查的速度慢。
不要本着“如果您需要它来完成某项任务，请免费进行！ 您必须做得很好！“如果有这样的话：外包开发的实质是解决客户资金问题。
分析人员必须设计。 他拥有的知识使他能够理解并清楚地阐明客户最终到底需要什么，并构建一个通用的系统体系结构：产品中将包含哪些服务，是否与第三方系统集成，请求如何在服务之间传递，信息在哪里存储，如何使用首先，这是必要的，这样客户的产品才能快速可靠地工作；其次，就可以节省的成本以及不值得的成本提出建议。
使MVP的含义对每个人都相同
MVP对我们意味着什么：
- 我们同意该应用程序的基本功能，并仅将与之相关的功能完善为理想状态。 其他功能应该起作用，以便不希望关闭应用程序。
- 我们仅提供解决业务问题所需的最少功能，并且没有设计的管理区域；
- 我们将定制推迟到以后，也就是说，我们在设计中使用可以在多个屏幕上重用的组件，拒绝复杂的布局元素，并在必要时简化设计。
但是MVP客户有不同的解释。 这对我们意味着什么：
将来，由于某种原因，仍然存在“最低限度的钱”，并且增加了“我们知道该怎么做，按我们所说的去做”的立场。
这样的职位威胁正常的伙伴关系。 只能通过设计和功能性任务来消除威胁，该任务说明了应用程序应该能够执行的所有操作。 是否有新的未提交的要求和建议？ 请参阅《联邦法律》并提出购买时间的建议。 也许这是形式主义，而不是关注客户，但这对您的公司而言是公平的。
再一次：在设计时将MVP与修复结合在一起。 我们没有，但您应该拥有。
让开发人员与您争论
而且永远不要使用客户未提交的设计来解决我们的工作方式。
开发人员最常被束缚：一旦确定任务，他们就会这样做。 但是在预算有限的项目中，必须对每个潜在的复杂任务的执行情况提出质疑，以便灵活执行并在截止日期之前完成。
这些任务的来源出乎意料地是客户端设计师要处理的设计。 我们的开发人员被告知，如果他们要求进行更正，将立即提交它们，因此我们开始不使用设计的静态版本，而是在创建该设计的Figma编辑器中进行工作。 开发人员进行了评估并开始工作。
然后，在设计中一个接一个地出现原来不是的元素-从备份中可以看出这一点，我以防万一。 但是，在开始开发之前，不可能检查特定设计是否已更改-至少因为开发人员以自己方便的顺序执行任务。
识别不一致有助于同样的言论自由。 开发人员可以向我求助，不仅吸引那些不能快速组成的元素，而且吸引客户设计中的元素-这是可以理解的，因为设计师本人秘密地将它们引入那里，而不是在我们的副本中引入。 这些要素未包括在评估中，这意味着我们不应自费处理。
在健康发展的世界中，固定价格不允许增加工作量并在旅途中改变条件。
让客户远离团队
上一次我们直接与开发人员和客户建立联系-有些团队认为经理首先应该监控条款和预算，而不应该充当客户要求的传递者。
这是一种很棒的方法，其优点是：双方的反应更快，团队更好地理解业务任务，其权限不断增长，经理不会死为传送带。 但是知道客户可以变得个性化之后，我将他与团队隔离了。 聊天中只有客户，客户经理和项目经理，也就是我。
它给了我们什么？ 我主持了交流活动，不允许个人关系破坏工作常规。 在客户批评团队时，我回答说，我们将采取行动并惩罚员工。 观察表明，为了使某些客户放心，即使为了娱乐也要牺牲团队中的某个人，因此员工继续保持镇定，甚至不知道自己受到了惩罚。
如果您怀疑服务对象烦躁不安，那么至少不要让团队陪伴他一会儿，直到您确信相反的情况为止。
重新制定从客户到团队的反馈
在持续的不信任和批评的气氛中，团队不再设法以其到达的形式来处理反馈，客户开始认为团队只是出于邪恶意图而工作-体现了它们。
该经理怎么办？ 装饰性的编辑不会造成伤害：我从反馈中删除了人格评估，只留下了错误的措词，而没有失去意义。 而且，由于您没有得到客户的任何好评，因此我也不会忘记给团队提供我自己的反馈-对于那些没有提出疑问的任务，这意味着从客户的角度来看，这些工作表现出色。
那是：
“该应用程序无法付款。 你做了什么手？变成了：
“伙计们，应用程序需要付费，客户要求弄清楚，这是屏幕截图。 一周前的动画滞后了，一切都很好。”不要急于获取错误
从客户那里收到错误后，立即将错误输入到任务管理器中。 带着挑剔的眼光，经理将帮助节省开发人员和测试人员的时间。 只需与客户交谈或要求回放导致错误的操作并录制视频，您就可以了解该错误不是优先事项，也不是因为客户做错了事而出现-现在，您不再需要对其进行编辑。 因此，我筛选了四分之一的传入错误，另一部分与集成服务支持服务有关-该项目上有足够的第三方SDK。
不要提及客户名称
也许是最重要的见解。 根据团队中一部分成员的旧记忆，讲出客户的名字会激起对他的任何评论的偏见，无论这是多么充分。 然后我提出将客户称为客户，这减少了负面影响。 似乎每个人都知道他们在谈论谁，但请相信我-这种细微差别改善了项目的生态。
结论
为了清楚起见，我决定将以上所有内容简化为“如何不做以及如何做”原则的表格。
但是，如果负责与公司中的新客户合作的人员或客户经理在协商阶段发现客户缺陷，我们的建议将对您有所帮助。
以下是我们现在要注意的一些重点：
- 客户对前承包商的看法（如果有）。 如果他对他说的话很消极，就有可能他除了自己的意见外不会听见其他任何意见，并会强加自己的决定。
- 客户是否具有IT经验。 对于有经验的客户，开发过程中提出的问题更少。
- 他是否会讨价还价。 客户对少付的欲望越高，他就越愿意和更顽固地争论。
我希望本文对某人有用。 如果您已经在我的位置，请告诉我们您如何解决这样的困难客户。