Сложные клиенты: что делать менеджеру

Статья написана в соавторстве с Мэри Ротарь, CEO IAMPM

Привет, меня зовут Александр Крючков. За 17 лет работы в аутсорсинге разработки ПО в качестве разработчика, а потом и менеджера, мне приходилось сталкиваться с разными типами заказчиков. Далеко не всегда это были люди из разряда «отлично, нам все подходит». Попадались очень трудные клиенты, и к каждому нужно было искать особый подход, ведь в сервисном бизнесе не получится сказать: «Мне сложно, ищите другого PM-а, а я буду работать только с легкими кейсами».

Со временем у меня сложилась своя типология трудных клиентов. В этой статье расскажу об основных типах. Все образы сборные и основаны на практических кейсах: моих или коллег-менеджеров.

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

Диктатор

Педантичен и требователен, не допускает возможности проблем в работе. Стиль общения — авторитарный. Клиент диктует свои требования, результат и детали реализации, не обращая внимания на мнение РМ-а:

— Мне нужны зеленые кнопки.

— Наш UX-дизайнер рекомендует синие.

— Делаем зеленые. Дальше: в команде будет достаточно одного тестировщика.

— Но исходя из оценки проекта, нам нужно три...

— Один вполне справится. Проект будем делать на Magento Community.

— А нужно бы на Enterprise.

— Не хочу платить лишние деньги. И еще: все фичи нужны к моему дедлайну — ни днем позже!

— Это же нереально!

Как работать с Диктатором

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

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

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

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

Если клиент настаивает, что к дедлайну нужно сделать «абсолютно всё», а оценки вашей команды заставляют сомневаться в реальности такого сценария, попросите заказчика четко задать приоритеты. Лучше это делать в стиле «Если мы успеваем сделать только 3 фичи из 5, то какие ты выберешь? Без чего невозможен релиз?»

Менеджер

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

Если вы, как PM, допускаете возможность, что со временем в проекте что-то может поменяться: понадобится больше ресурсов, не получится уложиться в срок, может не хватить бюджета, — то Менеджера это обычно возмущает.

Как работать с Менеджером

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

1. Fixed-Price:

• Клиент задает начало и конец маршрута (A → B);
• Тариф фиксирован;
• Маршрут выбирает таксист;
• Стоимость меняется только при изменении A и В (или добавлении новых точек).

2. Time-and-Materials:

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

3. Dedicated Team:

• Клиент платит за время водителя;
• Клиент предоставляет машину, карту и маршрут;
• Подрядчик гарантирует только уровень профессионализма водителя (категорию, водительский стаж и т.д.);
• Клиент напрямую влияет на качество поездки.

Обсудите с Менеджером в самом начале, по какому сценарию вы сотрудничаете, и напоминайте об этом в случае надобности. Клиент это оценит, так как понимает, что в совместной работе важно установить и соблюдать границы ответственности — если, конечно, он не хочет просто манипулировать вами с целью получения выгоды для себя — такое тоже случается.

Если на Менеджера такой способ подействует, то к клиентам с другим профессиональным бэкграундом нужно искать другой подход.

Бывший Разработчик

У такого клиента очень сильный технический бэкграунд. Из приятного в общении с Бывшим Разработчиком — задачи формулируются с помощью технических терминов. Если нужно, он даже подскажет, как именно лучше реализовать задачу. Объяснять требования с точки зрения бизнеса или пользователя такой клиент вряд ли захочет, а вот общаться по техническим вопросам напрямую с командой, напротив, будет весьма охотно. Иногда Бывший Разработчик даже сам заходит в систему контроля версий и правит код.

В компаниях, где топ-менеджмент состоит из разработчиков — нынешних или бывших — не до конца понимают, зачем вообще нужны остальные роли: PM-ы, BA и прочие «люди, которые не пишут код». PM-ам в таких компаниях работать сложно, потому что их воспринимают лишь как секретарей — даже самых опытных, уровня Senior.

Как договориться с Бывшим Разработчиком

Не пытайтесь работать по Fixed-Price, потому что заказчик будет диктовать детали реализации и менять их на ходу, и вам будет сложно спланировать проект, а тем более задать критерии приемки в бизнес-терминах. Это приведет к неоднозначностям, которые выльются в дополнительную работу и, как следствие, затраты со стороны вашей компании. Для такого клиента идеально применить аутстаф-модель или Time-And-Materials. Причина — если клиент генерирует бэклог исключительно в технических терминах, вам будет очень сложно построить бейзлайн скоупа и отслеживать прогресс проекта.

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

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

Перфекционист

Считает, что если ваша команда не может достичь идеального результата, значит вы просто недобросовестно работаете. То, что для вас мелочь, для Перфекциониста — катастрофа и повод для приема успокоительного. Надежда на человечество в таком клиенте просыпается, когда он думает, что после его «Вы же видите, что это некрасиво?» PM воскликнет «Точно! Срочно переделываем!» Однако эта надежда умирает сразу же после вашего вопроса «А что именно не так?», ведь в понимании Перфекциониста это очевидно. С таким клиентом приходится «жить» на звонках, тонуть в письмах и обороняться от эскалаций при появлении малейшего намека на несовершенства. «Пишите код сразу без багов» — это как раз про него.

Как работать с Перфекционистом

Нужно понимать самому и объяснять клиенту, что на каждом этапе разработки продукта допустим разный уровень качества. Это помогает сэкономить деньги. На начальных стадиях проекта, особенно если речь идет о стартапе, команда часто разрабатывает функциональность в рамках проверки разнообразных гипотез, не все из которых окажутся валидными. Соответственно, не все фичи в реальности пойдут в продакшн. На данном этапе мелкие ошибки некритичны, их вполне можно будет устранить после того, как будет принято окончательное решение о скоупе релиза. А пока стоит сфокусироваться на чем-то более важном — например, архитектурно значимых функциях, которые будет сложно и дорого изменять потом.

Тщательно готовьтесь к демо — старое доброе правило «изучить, куда лучше не кликать» работает здесь максимально эффективно. На этом этапе все еще могут быть недоработки, которые пока нет смысла исправлять, но Перфекционист может не понимать этого. Проводя демо, обращайте внимание клиента на важные аспекты и по возможности не сбивайте его кликами «не туда» и вашим «Это будет доработано, планируем сделать вот так, но пока как есть».

Договоритесь о приоритетах. Этот совет всегда был хорош, а в случае с Перфекционистом особенно. Для него очень важно исправление каких-то внешних дефектов, чтобы показать прототип инвесторам или потенциальным пользователям, например. Баги на бэкенде пусть поживут еще немного. Иметь дефекты в незарелизенном продукте — нормально. Можно потратить бесконечное количество денег на бесконечное качество, а можно утвердить стандарт качества: severity дефектов и их количество, которое допустимо для разных стадий проекта — до приемки, после, на этапе выхода в продакшн и т.д. Подробнее об этом — здесь.

Запланируйте отдельный период, во время которого будете стабилизировать и «чистить» продукт. Это обязательно для любого проекта, но при работе с Перфекционистом очень важно объяснить клиенту, что в жизненном цикле проекта будет отдельный этап, главным фокусом которого будет качество.

Промышленник

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

Промышленник работает с материальным продуктом, он ему понятен. Этот тип клиента не знает о разновидностях контрактов, такому клиенту не получится быстро объяснить то, как устроена проектная работа. Контракты в IT внешне выглядят очень схоже, и человеку не из IT сложно объяснить разницу между ними и принцип работ с каждым из них. Та же аналогия с такси для такого клиента работать, скорее всего, не будет.

Как работать с Промышленником

Любой контракт должен восприниматься исключительно как Fixed-Price: закладывайте буферы, обеспечьте четкий процесс управления изменениями скоупа, изначально детально прописывайте требования. Тем более, Промышленник вряд ли закажет что-то большое. А если закажет, скорее всего вы будете иметь дело уже с представителем корпоративного мира, описанным выше.

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

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

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

Еще один совет — «ведите» клиента! Для такого заказчика разработка ПО — совсем новая область. В вашем лице ему нужен человек, который не просто даст правильные рекомендации, но и остановит при попытке неправильного выбора. Поэтому нужно общаться не с позиции «Как ты хочешь чтобы мы сделали продукт?», а с позиции «Скажи какую проблему тебе нужно решить, и мы расскажем как это правильно сделать». Вы не должны рассказывать клиенту, как вести его бизнес, но вот в том, как делаются IT-проекты, он должен положиться на вас.

CEO не из IT и его ассистент Product Owner

CEO владеет успешным бизнесом. Он умеет продавать — собственно, на этом он и сделал карьеру. Он не любит вникать в детали, для него адаптер, контроллер, API, выявление требований, регрессия — белый шум. Его интересует, когда будет готов проект. Любит писать эскалации. Ведение дел обычно передает своему подчиненному, доверенному лицу — назовем его Product Owner.

Product Owner приходит к вам с описанием фич, знает, что и когда нужно делать — это его главное отличие от CEO. В IT Product Owner разбирается на уровне «чуть-чуть». Обычно это человек очень ответственный, трудолюбивый и внимательный, хотя иногда и забывает донести важные детали до CEO.

Как работать с такими клиентами

Переводите термины на понятный язык и возьмите за правило: избегать IT-словаря в разговоре с «не-айтишниками». Например, вместо «интеграции между системами», скажите проще — «перенести информацию о заказах в другую систему».

В общении с CEO старайтесь быть конкретными и задавать вопросы узкой направленности: «Ты собираешься открывать магазины? Если да, может быть тебе сделать еще POS-систему?»

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

С CEO лучше не обсуждать «цвет кнопок», а говорить о вещах, которые реально значимы для бизнеса: какой объем получится сделать к дедлайну, сколько это будет стоить. CEO — занятой заказчик, поэтому всю коммуникацию лучше вести с его ассистентом. Тем не менее не нужно пренебрегать встречами с CEO по ключевым вопросам, ведь если все переложить на Product Owner-а и между CEO и Product Owner-ом произойдет недопонимание, — пострадаете вы. Лучше воспользоваться возможностью тесного общения с владельцем продукта, и сделать его «своим человеком» в чужой компании.

Вместо вывода

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