«Зачем он лезет?»: как работать с клиентом-микроменеджером

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

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

Клиент-микроменеджер похож на родителя, склонного к гиперопеке. Обычный родитель предостерегает от глупостей в детстве и говорит малышу: «Не суй пальцы в розетку». Когда ребенок вырастает, родитель отпускает свой контроль и доверяет ему.
С «гиперопекуном» по-другому — он звонит пять раз в день уже взрослому сыну и спрашивает, не совал ли он пальцы в розетку и помнит ли, что так делать нельзя.
Миша, проектный менеджер Purrweb

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

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

вкладывает в проект все свои деньги;
не доверяет опыту и экспертизе менеджера проекта;
привык работать напрямую с разработчиками и дизайнерами;
обжегся, когда нанял команду на аутсорсе и доверился проектному менеджеру — и не хочет повторить ошибку ¯\_(ツ)_/¯

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

В некоторых случаях это работает — например, если в компании нет ПМ-а, и дизайнеры с разработчиками сотрудничают напрямую с клиентом. Или если проектом руководит молодой и неопытный специалист.

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

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

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

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

«Зачем он лезет?»: как работать с клиентом-микроменеджером

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

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

Деморализует команду. Заказчик-микроменеджер обычно не любит обсуждать правки с менеджером проекта. Ему кажется, что лучше доносить свои замечания напрямую дизайнерам и разработчикам: это быстрее (сложно поспорить!) и эффективнее (точно нет).

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

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

Чтобы сделать сотрудничество с клиентами-микроменеджерами эффективным, мы в Purrweb придерживаемся следующего алгоритма:

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

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

3. Договариваемся, в каком виде нужны отчеты. Это могут быть два созвона в неделю или ежедневное обновление статусов задач в приложении вроде Trello. Мы в Purrweb все проекты по разработке подробно ведем для себя в Jira. Для успокоения клиента можно указывать самые важные таски и критичные баги. Например, с одним клиентом мы работали в Monday. Сервисы очень похожи между собой, но в Monday интерфейс более простой — поэтому отлично подходит для отчетности.

<p>Так мы работаем в Monday с одним из заказчиков уже больше года. Система помогает избежать лишних микро-вопросов от клиента, а нам — соблюдать все сроки и поддерживать прозрачность</p>

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

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

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

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