Сложные клиенты: как защитить от них свою команду

Я работаю менеджером проектов в компании Лайв Тайпинг. В прошлом году мы в своём корпоративном блоге писали о том, что если дедлайн срывается, то главное — не делать из этого неожиданность и предупредить клиента. Но чем дольше мы работаем, тем больше понимаем, что хуже сорванных дедлайнов могут быть только сложные, эмоциональные клиенты и выгоревшие под их напором команды.

Те компании, что за время работы обзавелись парой-другой постоянных клиентов, знают, как отсеивать подозрительных лидов ещё на этапе первого звонка, и могут это себе позволить. Молодым же студиям в погоне за опытом и заработком, увы, без таких клиентов не обойтись.

Прежде чем попасть в десятку всевозможных отраслевых рейтингов, наша компания поработала с клиентом, который демотивировал команду настолько, что из компании начали уходить люди. В силу причин, о которых я расскажу ниже, мы сошлись с клиентом снова. Под страхом нового кризиса отношений я выработала специальную тактику менеджмента, чтобы сохранить команду в целости и здравии. Ведь найти классного разработчика — сложно, а обучение и и адаптация нового сотрудника стоят дороже, чем удерживать старого. К тому же специфика аутсорса такая, что после этого проекта разработчики возьмут следующий, и важно, чтобы они делали его с невыжженными дотла мозгами.

О том, как у меня это получилось, читайте в статье.

Клиента я по понятным причинам буду называть просто «клиент». Даже на проекте при повторном сотрудничестве мы внутри команды никак иначе его не называли. Почему? Об этом ниже.

Предыстория

Два года назад к нам пришёл проект. Перед тем, как попасть к нам, над ним работало около пяти команд, и он накопил порядочный legacy-код.

Отношения клиента с предыдущими командами были далеки от партнёрских, поэтому с нами он решил автоматически занять наступательную позицию и отгородиться стеной недоверия.

Чтобы ускорить коммуникацию и разработку, первый менеджер проекта сделал общий для клиента и команды чат в Slack — приложение разрабатывалось не нами и вызывало много вопросов, которые надо было оперативно направлять клиенту. В большинстве случаев такая методология ускоряет передачу информации между членами команды, но наш клиент не отказывал себе в возможности делать грубые замечания либо в чате, либо в личке конкретному человеку.

Клиент переходил на личности, что выливалось в открытые конфликты, а его имя было на слуху даже у непричастных. В итоге компания потеряла как минимум одного сотрудника, который не смог мириться с таким отношением, а ещё несколько ушли через пару месяцев. Формальные причины для ухода вроде как были другими, но мы-то знаем.

Когда у клиента закончились деньги, мы расстались. Деньги, стоит заметить, уходили в том числе на поддержку legacy-кода и разработку функциональности ради функциональности.

Позже клиент вернулся. Он убедил нас, что хочет разработать приложение с нуля, отказавшись от устаревшего кода, сократив функциональность и коммуницируя в другом стиле. Мы приняли его, но через какое-то время история начала повторяться.

Клиент не доверял нашим оценкам и предложениям. У него было своё представление о том, как должен работать продукт. У нас тоже было понимание, как нужно, но клиент не воспринимал аргументы и вместо партнёра с экспертизой в разработке приложений он видел в нас лишь рабочие руки, которые превращают его хотелки в жизнь. Причин, по которым клиент поставил себя в такую позицию, мы точно не знаем и строить догадки не будем.

Ситуация накалялась. Вспомнив, как развивались события в прошлом, мы расставили приоритеты в непривычном для нас порядке: в первую очередь нужно сберечь команду, а уже потом удачно закрыть проект и по возможности сохранить лояльность клиента.

Тактика защиты от сложных клиентов

А теперь разберём приёмы, которые помогли нам достигнуть своей цели, ошибки, которые вам не стоит повторять, и выводы, которые вы можете использовать в своей работе.

Объясните ценность проектирования

Итак, проект начался с нуля. В контексте этого решения возникло предложение делать MVP и оплачивать нашу работу по модели fix price. Это казалось логичным, ведь если нет чужого кода, то и рисков с ним нет.

Минус fix price как модели оплаты в том, что она лишает проект гибкости: пока внедряется функциональность, о которой стороны договорились в техническом задании, рынок может поменяться и результат работы перестанет решать актуальные пользовательские проблемы. Разрабатывать MVP по fix price можно, только если вы заранее и очень тщательно проверили все гипотезы, спроектировали технические характеристики и написали подробную документацию. Наш клиент проектированием как раз пренебрёг, а вернее, взял его на себя.

Показательной является история с выбором сервиса для чатов. Клиент исследовал возможные технические решения сам, а нам дал на выбор несколько сервисов: «Какой лучше?». Мы выбрали сервис А, потому что он подходил проекту по набору методов API, а с точки зрения разработки и интеграции был лучше, чем сервис Б. Мы не проектировали работу сервиса с нашей инфраструктурой и кроме этих формальных критериев больше ничего не проверяли: ни стабильность работы, ни скорость отклика, ничего — не было бюджета. Чат в итоге отзывался медленнее, чем мог, если бы было время на проверку.

Не ведитесь на манипуляции в духе «Если это нужно для выполнения задачи, делайте это бесплатно! Вы же должны сделать хорошо!», если такие будут: суть аустсорс-разработки — решать проблемы клиента за деньги клиента.

Проектировать должен аналитик. Он обладает теми знаниями, которые позволяют ему понять и чётко сформулировать, что именно нужно клиенту в финале, и сконструировать общую системную архитектуру: какие сервисы будут в продукте, есть ли интеграции со сторонними системами, как между сервисами ходят запросы, где хранится информация, как она доставляется и т. д. Это нужно, во-первых, чтобы продукт клиента работал быстро и надёжно, а во-вторых, чтобы советовать, на чём можно сэкономить, а на чём точно не стоит.

Сделайте смысл понятия MVP одинаковым для всех

Что MVP значило для нас:

• мы договариваемся об основной функциональности приложения и шлифуем до идеала только те фичи, которые её касаются. Остальные фичи должны работать так, чтобы не возникало желания закрыть приложение;
• мы делаем минимум функциональности, нужной для решения бизнес-задачи, и никаких задизайненных админок;
• мы откладываем кастомизации на потом, то есть используем в дизайне компоненты, которые можно переиспользовать на нескольких экранах, отказываемся от сложных для вёрстки элементов и упрощаем дизайн, если нужно.

Но клиентами MVP интерпретируется по-разному. Что это значило для нашего:

• минимальная функциональность за минимальные деньги.

В дальнейшем как-то так вышло, что остались «минимальные деньги» и добавилась позиция «мы знаем, как надо, поэтому делайте так, как мы скажем».

Такая позиция угрожает нормальному партнёрству. Снять угрозу можно только проектированием и функциональным заданием, где прописано всё, что должно уметь приложение. Поступают новые незафиксированные требования и предложения? Ссылайтесь на ФЗ и предлагайте докупать время. Может, это формализм и не про клиентоориентированность, но справедливо по отношению к вашей компании.

Ещё раз: MVP сочетается с фиксом тогда, когда есть проектирование. У нас его не было, а у вас должно быть.

Дайте разработчикам спорить с вами

И никогда не работайте с незафиксированным дизайном от клиента, как работали мы.

Разработчики чаще всего люди подневольные: как поставлена задача, так и сделают. Но на проектах с ограниченным бюджетом выполнение каждой потенциально сложной задачи нужно ставить под сомнение, чтобы пофлексить её и уложиться в срок.

Источником таких задач неожиданно стал дизайн, которым занимался дизайнер на стороне клиента. Нашим разработчикам сказали, что если они попросят какие-то правки, то их оперативно внесут, поэтому мы начали работать не со статичной версией дизайна, а в редакторе Figma, где этот дизайн и создавался. Разработчики дали оценку и взялись за работу.

И тут один за другим в дизайне начали появляться элементы, которых не было изначально — в этом можно было убедиться по резервной копии, которую я сделала на всякий случай. Но перед началом разработки невозможно проверить, не поменялся ли конкретный кусок дизайна — как минимум потому, что разработчик берёт задачи в удобном для себя порядке.

Выявить нестыковки помогла та самая свобода слова. Разработчик мог подойти ко мне и обжаловать не только элементы, которые быстро не заверстать, но и элементы, которые есть в дизайне клиента — оно и понятно, ведь дизайнер их сам туда втайне вносил,— но нет в нашей копии. В оценку эти элементы не закладывались, а значит, и заниматься ими за свой счёт мы не должны.

В мире здоровой разработки fix price не даёт увеличивать объём работ и менять условия на ходу.

Не подпускайте клиента к команде

В прошлый раз мы соединили разработчиков и клиента напрямую — есть команды, где считается, что менеджер в первую очередь должен следить за сроками и бюджетом, а не служить передатчиком клиентских требований.

Это отличная методология со своими плюсами: реакция каждой из сторон быстрее, команда лучше понимает бизнес-задачу, её авторитет растёт, а менеджер не умирает в роли передатчика. Но зная, что клиент может перейти на личности, я изолировала его от команды. В чате остались только клиент, аккаунт-менеджер и проджект-менеджер, то есть я.

Что это нам дало? Я модерировала коммуникацию и не позволяла, чтобы личностные отношения отравляли рабочую рутину. В моменты, когда клиент в своей манере критиковал команду, я отвечала, что мы примем меры и накажем сотрудника. Наблюдения показывают, что для успокоения некоторых клиентов достаточно принести кого-то из команды в жертву даже понарошку, так что сотрудник продолжал спокойно работать и даже не знал, что он наказан.

Если у вас подозрения, что клиент беспокойный, то не сводите с ним команду хотя бы какое-то время, пока не убедитесь в обратном.

Переформулируйте фидбэк от клиента команде

В атмосфере постоянного недоверия и критики у команды уже не получается обрабатывать фидбэк в том виде, в котором он поступает, а клиент начинает думать, что команда приходит на работу только со злыми намерениями — и воплощает их.

Что с этим делать менеджеру? Не помешает косметическая редактура: я убирала из обратной связи оценку личности, оставляя только формулировку ошибки без потери смысла. И раз от клиента не дождёшься похвалы, то я не забывала давать команде свой собственный фидбэк — на те задачи, которые не вызвали вопросов, а значит, выполнены хорошо с точки зрения клиента.

Было: «В приложении не работает оплата. Какими руками вы это делали?».
Стало: «Ребята, в приложении что-то с оплатой, клиент просит разобраться, вот скрины. А с анимациями, которые лагали неделю назад, всё стало хорошо».

Не спешите заводить баги

Заносить баги в таск-менеджер, как только они были получены от клиента — это от неопытности. Вооружившись критическим взглядом, менеджер поможет сэкономить часы работы разработчиков и тестировщика. Просто поговорив с клиентом или попросить воспроизвести действия, приводящие к ошибке, и записать видео, можно понять, что баг не приоритетный или появился потому, что клиент что-то делал не так — и вот, править его уже не нужно. Так я отсеивала четверть входящих багов, а ещё часть относилась к службе поддержки интегрированного сервиса — сторонних SDK на проекте было достаточно.

Не упоминайте имя клиента

Пожалуй, самый главный инсайт. По старой памяти у части команды озвучивание клиентского имени вызывало предвзятое отношение к любому замечанию с его стороны, сколь бы адекватным оно ни было. И я придумала называть клиента просто клиентом, что снижало негатив. Вроде бы все понимают, о ком речь, но поверьте — этот нюанс улучшил экологию на проекте.

Вывод

Для наглядности я решила свести всё вышесказанное в таблицу по принципу «Как не надо и как надо делать».

Но наши советы пригодятся вам по минимуму, если человек, ответственный за работу со входящими клиентами в вашей компании, или аккаунт-менеджер выявит изъяны клиентского характера ещё на стадии переговоров.

Вот несколько важных моментов, на которые мы теперь обращаем внимание:

1. Что клиент говорит о предыдущем подрядчике, если он был. Если он говорит о нём негативно, есть вероятность, что он не воспринимает никакое мнение, кроме своего, и будет навязывать свои решения.
2. Есть ли у клиента опыт работы в IT. У клиента с опытом процесс разработки вызывает меньше вопросов.
3. Торгуется ли он за каждую копейку или нет. Чем выше желание клиента заплатить меньше, тем охотнее и упрямее он спорит.

Надеюсь, статья будет для кого-то полезной. А если вы уже были на моём месте, то расскажите, как вы разруливали таких сложных клиентов.