Адский заказчик: инструкция по выживанию для PM-а
Представь, ты проводишь демонстрацию части функциональности заказчику, ты основательно подготовился ко встречи, подготовил идеальную презентацию в твоей голове ты - Стив Джобс. И тут заказчик тебя перебивает и говорит: "Это не то, что нам нужно? Что за идиоты у вас в команде? Нужно всё переделать немедленно!". Знакомо? Добро пожаловать в мир “адских” заказчиков.
Конечно, головная боль PM-а не в том, что кого-то назвали идиотом. Настоящая проблема – как организовать работу так, чтобы подобные страсти не сжигали ресурсы команды и твои нервы.PM – это архитектор коммуникации и процесса, а не почтальон и мальчик для битья. Чтобы себя обезопасить от подобных инцидентов я подготовил несколько базовых правил, которым стоит следовать при выработке плана по взаимодействию с любым заказчиком, без них даже самый адекватный клиент превратится в “адского”.
Сценарии и алгоритмы действий
1. Заказчик, который бесконечно вносит правки
Что делать:
- Собери и приоритизируй правки. Назначь встречу или созвонись и получи один сводный список комментариев от клиента.
- Заявляй границы. Объясни: "Чтобы реализовать эти правки, нам нужно скорректировать сроки и, возможно, бюджет, потому что…" – и покажи расчёт. Например: "Если взять эти пожелания, дата запуска сдвинется на неделю, а бюджет вырастет на 10%".
- Договорись о доработке. Если запрос слишком велик, предложи доп. соглашение. Например: "Я рекомендую выпустить текущую версию, собрать отзывы, а эту доработку включить в следующий релиз". Можно оформить новый пункт в договоре или акте.
- Фиксируй всё письменно. Любые изменения согласовывай письменно. Укажи, что вы сделали, и попроси клиента подтвердить: "Отлично, эти пять правок мы берем в работу. Остальное пока оставляем на следующую итерацию".
Профилактика:
- Тщательно проработай ТЗ. Подробное техническое задание – твой щит от бесконечных переделок. Пропиши в нём цели проекта, ограничения, этапы, дизайн, функционал, а главное – условия внесения правок. Если проект сложный и есть сомнения, то лучше сделай вместе с бизнес или системным аналитиком.
- Подпиши договор/доп.соглашение. Не начинай работу, пока заказчик не утвердит ТЗ. Тогда он не сможет в конце сказать: "А я думал, это будет совсем по-другому".
- Оговори сколько циклов/правок включено в договор, и зафиксируй стоимость дополнительных доработок. Если клиент знает: "после X раундов мы берём доп. оплату", – глупостей будет меньше с его стороны.
- Чеки. Запланируй промежуточные демонстрации или прототип (MVP). Чем раньше клиент увидит результат, тем менее критичными будут правки в финале.
2. Заказчик молчит неделями, а потом устраивает пожар
Что делать:
- Договорись о дедлайнах. На старте проекта чётко запиши: "Если ты не ответишь на правки или уточнения в течение N дней, мы не сможем соблюдать сроки". Проинформируй: "Если обратной связи не будет, считаем задачу принятой".
- Напоминай о сроках. Если ты ждёшь ответ, напомни клиенту за день-два до нужной даты: "Напоминаю, что до пятницы нам нужно твое решение по дизайну". Делай это вежливо, но настойчиво.
- Организуй резервное время. Планируй проект так, чтобы можно было переключиться на другие задачи, если клиент пропал.
- Пауза при отсутствии ответа. Придерживайся правилу: "Если от клиента нет ответа 3 дня, ставим проект на паузу". При этом заранее предупреждай его об этом. Факт паузы – повод для притормозившего клиента срочно вернуться в проект.
Профилактика:
- Согласуй SLA на коммуникацию. В договоре укажи, сколько времени у клиента есть на ответы. Например: "Все правки и комментарии мы ожидаем получить в течение 48 часов после задания" или "без ответа задача считается принятой".
- Установи каналы связи. С самого начала договорись, через какой канал клиент будет давать фидбэк: почта, корпоративный мессенджер, отчёты. Если он молчит, не теряйся: ты знаешь, куда стучаться.
- Обозначь ответственность заказчика. Назначьте ответственного со стороны клиента. Пусть даже это будет его руководитель или PM-координатор. Тогда в моменты тишины есть кому звонить и напоминать о блокерах.
3. Токсичный заказчик ("что за идиоты у вас в команде?")
Что делать:
- Не вступай в перепалку. Если заказчик начинает ругаться или оскорблять команду, отвечай спокойно: "Понимаю, что вы расстроены, давайте разберёмся по фактам". Не обвиняй в ответ – просто переводи разговор на конкретику.
- Структурируй диалог. Предложи перейти в письменную переписку или созвон с руководством: "Мне важно решить проблему. Может, обсудим это вместе со всеми стейкхолдерами?".
- Проси сменить тон. Спокойно скажи: "Я готов выслушать все замечания, но давай без оскорблений". По практике поддержки, лучше не наказывать матами, а напомнить, что "говорить в таком ключе неуместно".
Профилактика:
- Установи правила общения. На старте договора или первого звонка сразу обозначь: "Мы работаем в конструктивном ключе: давайте обсуждать только проект".
- Эскалируй в спонсора. Если известно, что у проекта есть проблемы с контактным лицом со стороны заказчика, то не стесняйся подсвечивать это своему спонсору проекта и спонсору проекта со стороны заказчика.
4. Заказчик, который не знает, чего хочет, но точно "не это"
Что делать:
- Задай много уточняющих вопросов. Построй беседу вокруг целей, а не решений. Выясни: "Какая главная цель этого проекта? Какой результат вы хотите видеть?" (например, рост продаж, узнаваемость бренда и т.д.). Часто человек не знает конкретики просто потому, что ему не хватает информации.
- Покажи варианты. Подготовь несколько макетов или прототипов, каждый с разными подходами. Пусть заказчик "на ощупь" поймёт, что ему нравится, а что нет. MVP и эскизы особенно полезны – правки на раннем этапе дешевы.
- Фиксируй обратную связь. Переводи каждое "не то" клиента в конкретные характеристики: цвет, текстуру, расположение. Лучше писать: "Вы считаете, что цвет слишком яркий? Предлагаю сделать …".
- Делегируй анализ. Если заказчик не может сформулировать задачу, иногда полезно привлечь дизайнера или бизнес-аналитика для прямого диалога с ним. Они могут лучше вытащить из клиента реальные предпочтения.
Профилактика:
- Глубокий брифинг. На старте потрать время на вопросы: цели, ЦА, любимые примеры, сроки и бюджет. Чем больше узнаешь заранее, тем меньше сюрпризов в процессе.
- Детальное ТЗ. Зафиксируй общие пожелания так, чтобы заказчик заранее воскликнул "нет, это не то". Если ТЗ есть – его пересмотреть всегда можно, но это уже запрос на изменения.
- Прототип/MVP. Предложи сначала черновой вариант: пусть клиент "пощупает" результат на реальном прототипе, который может решить основную проблему клиента.
- Ограничь правки в договоре. Позаботься, чтобы "10 небольших поправок" — не были бесплатными. Если клиент знает: "после трёх итераций – доплата", он более взвешенно подойдёт к уточнениям.
5. Контрол-фрик: отчёты каждый час, сидит на всех митингах, перепроверяет каждую задачу
Что делать:
- Установи единый канал коммуникации. Предложи заказчику вести детальный контроль через ваш трекер задач или доску: "Все новые задачи попадают в Jira, мы туда заносим статус. Можешь смотреть там, а по срочным вопросам писать заранее в чат".
- Определи формат отчётов. Вместо "сегодня я приму всё в 12:00" договоритесь: "каждый день в 10:00 – готов автоматический отчёт по задаче/статусу, а митинг – раз в неделю". Чем чётче расписание, тем меньше перманентной тряски.
- Раздели роли. Напомни, что клиент – спонсор, а профессионалы решают как. Скажи: "Мы учли ваше желание следить за процессом. Давайте распределим: вы участвуете в планировании итерации и демо, а технические детали мы знаем, как делать".
Профилактика:
- Согласуй отчёты. Ещё в начале уточни: "Как часто ты хочешь видеть статус? Что для тебя нормально: ежедневный свод или еженедельный звонок?". Зафиксируй эти договорённости.
- Доступ к инфо. Дай ему возможность видеть ход работы самостоятельно: прямой доступ к Jira, таск-трекеру или внутреннему чату. Когда он видит "что случилось", он меньше требует устных рапортов.
- Подсвети правила разумного контроля. Отметь: "Чем чаще отвлекают команду – тем больше работа занимает. Лучше дать нам четыре часа на создание, а потом провести ёмкий обзор, чем проверять каждую деталь раз в 15 минут".
Типичные ошибки PM при работе с проблемными заказчиками
- "Промолчать, когда надо было зафиксировать на письме." Каждый критичный запрос или договорённость фиксируй письменно. Иначе потом получите: "Я же говорил, а ты не записал!" – и мучайся потом, доказывая обратное.
- "Обещать доделать к пятнице, чтобы отстали." Ни в коем случае не ставь задачу на завтра просто чтобы угодить. Лучше скажи правду: "Сейчас я не уверен, что успеем. Давайте лучше реально оценим сроки". Ложные обещания только оттянут пожар на неделю вперёд и сожгут тебя сильнее.
- "Играть в психолога вместо менеджера." Помоги клиенту найти слова или успокоиться – это хорошо, но не лезь в мозги другого человека. Твоя работа – управлять проектом, а не лечить клиента.
- "Извиняться за каждый чих команды." Никому не поможет, если ты будешь брать вину на себя. Лучше сообщи о проблеме и пути её решения.
Выводы
Работать с "адским" заказчиком — нормально. Это тест на твою систему и нервную систему. Твои доспехи — чёткие правила, прозрачность и документация. Если фиксировать всё, говорить прямо и предлагать варианты, даже самый капризный клиент становится предсказуемым. Ты — PM, а не эмоциональный пожарный: сохрани спокойствие, ставь границы и не исчезай из поля зрения клиента. Тогда выжить и довести проект до результата можно с минимальными потерями.
Начать дискуссию