Почему заказчики микроменеджерят проекты
Клиент-микроменеджер — такой же клиент, как и все остальные. Он вежливо общается, не устраивает скандалы на пустом месте и соблюдает договоренности. Единственное отличие — повышенный контроль за всеми процессами, который может «задушить» команду.
Клиент-микроменеджер похож на родителя, склонного к гиперопеке. Обычный родитель предостерегает от глупостей в детстве и говорит малышу: «Не суй пальцы в розетку». Когда ребенок вырастает, родитель отпускает свой контроль и доверяет ему. С «гиперопекуном» по-другому — он звонит пять раз в день уже взрослому сыну и спрашивает, не совал ли он пальцы в розетку и помнит ли, что так делать нельзя.
Обычно клиенты микроменеджерят, когда им не хватает прозрачности. Они не понимают, действительно ли все заняты делом, правда ли задачи занимают именно столько времени и денег, а главное — движется ли проект в нужном направлении.
Почему с одной и той же командой некоторые заказчики чувствуют себя хорошо, а другие — страдают из-за непрозрачности? Причины могут быть разными: кому-то объективно не хватает информации от менеджера, кому-то просто тревожно. Так, клиент с большей вероятностью будет увлекаться контролем, если он:
- вкладывает в проект все свои деньги;
- не доверяет опыту и экспертизе менеджера проекта;
- привык работать напрямую с разработчиками и дизайнерами;
- обжегся, когда нанял команду на аутсорсе и доверился проектному менеджеру — и не хочет повторить ошибку ¯\_(ツ)_/¯
Как микроменеджмент вредит (и помогает!) проекту
У клиента-микроменеджера нет цели ухудшить сайт, приложение или другой продукт, который он заказал у компании. Наоборот: он уверен, что сверхконтроль подстегивает команду и не позволяет ей расслабляться.
В некоторых случаях это работает — например, если в компании нет ПМ-а, и дизайнеры с разработчиками сотрудничают напрямую с клиентом. Или если проектом руководит молодой и неопытный специалист.
Если же с менеджером проекта всё в порядке, но заказчик по-прежнему перехватывает управление, это может плохо повлиять на результат. Разберемся подробнее, как сверхконтроль клиента сказывается на работе.
Сковывает руки проектному менеджеру. Клиент с любовью к сверхконтролю, как правило, влияет на процессы, но не берет ответственность за результат. Получается хаос: проектному менеджеру нужно разруливать последствия действий, которые он не совершал.
Например, заказчик может настаивать на том, чтобы все кнопки в приложении были разных цветов, и переубедить его не удастся. При этом за неделю до релиза он увидит, что кнопки выглядят неопрятно — и отвечать за исправления придется проектному менеджеру, а не клиенту.
«У нас был один настолько недоверчивый клиент, что в какой-то момент он начал распределять задачи внутри команды, сам оценивать, сколько времени они займут, давать правки разработчикам. Получалось, что он исключал звено со мной, проектным менеджером — и как будто сам им стал. Проблема лишь в том, что клиент не был погружен в процесс разработки, не знал нюансов того, о чем просит. Многие его оценки времени и бюджета на задачи не совпадали с реальностью, в отличие от наших, — когда он это понял, то ослабил контроль над проектом».
Раздувает бюджет и дедлайны. Когда клиент пытается «рулить» проектом вместо менеджера, он может допустить много ошибок из-за незнания нюансов. В итоге работа растянется, в процессе появятся новые незапланированные таски — расходов станет больше.
«На одном из проектов клиент согласовал логику проекта, а потом, спустя время, попросил ее подправить. Ему казалось, что для этого нужна «всего одна строчка кода», и он настаивал, что команде обязательно надо этим заняться. На деле, чтобы выполнить просьбу, нам нужно было заново разрабатывать половину интерфейса. Конечно, это реально — но, в первую очередь, дорого для клиента. Чтобы донести это до заказчика, я составил таблицу со списком всех нужных изменений и расходами на них — это его убедило, и он отказался от своей идеи».
Деморализует команду. Заказчик-микроменеджер обычно не любит обсуждать правки с менеджером проекта. Ему кажется, что лучше доносить свои замечания напрямую дизайнерам и разработчикам: это быстрее (сложно поспорить!) и эффективнее (точно нет).
Если ему это удается, команда получает хаотичный список замечаний вместо четкого и согласованного порядка действий от менеджера. Это часто расстраивает дизайнеров и разработчиков, и они начинают выгорать на проекте — в итоге их приходится заменять другими и заново вводить на проект.
«Один из клиентов, с которым я работал, постоянно общался с разработчиками напрямую — ему казалось, что я некомпетентен. Не верил, когда я говорил, что «задача займет четыре дня». Возражал мне: «Что там делать четыре дня? Сделайте за два». Всё это долетало до команды, разработчики начинали торопиться — это сильно влияло на работу. Даже если задачу удавалось решить за два дня, ребята из-за этого сильно уставали, выгорали, и их приходилось снимать с проекта. Когда ситуация стала совсем критической, я договорился о разговоре с клиентом один-на-один и объяснил, что происходит: он «душит» команду, разработчики меняются, вводить новых — невыгодно для него самого, дорого и долго. В итоге он перестал оценивать часы на задачи, и у нас получилось решить конфликт».
Как повысить прозрачность, чтобы клиент перестал микроменеджерить
Чтобы сделать сотрудничество с клиентами-микроменеджерами эффективным, мы в Purrweb придерживаемся следующего алгоритма:
- Прощупываем почву. На вводном созвоне спрашиваем у клиента, какой подход он предпочитает в работе, с кем и как сотрудничал раньше, чем рискует, если проект «не взлетит». Это помогает сразу обозначить договоренности и выстроить процессы, удобные всем членам команды.
- Выясняем, насколько часто клиенту нужны новости от команды. Бывает, что заказчик требует такой высокий уровень прозрачности, что эмоциональные и трудовые затраты, увы, не окупают такое сотрудничество. Например, если нужно созваниваться по три раза в день на протяжении шести месяцев. В этом случае мы узнаем, зачем ему это нужно и находим компромисс, удобный всем.
- Договариваемся, в каком виде нужны отчеты. Это могут быть два созвона в неделю или ежедневное обновление статусов задач в приложении вроде Trello. Мы в Purrweb все проекты по разработке подробно ведем для себя в Jira. Для успокоения клиента можно указывать самые важные таски и критичные баги. Например, с одним клиентом мы работали в Monday. Сервисы очень похожи между собой, но в Monday интерфейс более простой — поэтому отлично подходит для отчетности.
- Если договоренности нарушаются, устанавливаем новые. Иногда оказывается, что соблюдать установленные правила не получается. Например, проектный менеджер не успевает обновлять статусы задач каждый день — и заказчик уже вполне законно пишет ему с вопросами в час ночи. Или, наоборот, клиент не выдерживает уровень тревоги и пишет разработчику напрямую. Если такое происходит, мы устанавливаем новые договоренности с учетом произошедшего.
Коротко: что делать, если заказчик — микроменеджер
Если клиент микроменеджерит, это не повод отказываться от интересного проекта и ставить на нем крест. Чаще всего можно наладить эффективное общение между заказчиком и командой, если:
- Узнать, из-за чего клиент микроменеджерит. Чаще всего ему тревожно из-за того, что не хватает прозрачности в процессах команды.
- Обсудить, как его микроменеджмент влияет на проект. Донести, что такой подход создает дополнительные расходы и растягивает сроки по задачам.
- Предложить альтернативу: выстроить систему, в которой заказчик будет наблюдать за статусами всех задач и получать своевременные обновления от команды. Договориться, что пока эта система работает, клиент не будет пытаться управлять проектом самостоятельно.
- Если команда или заказчик нарушают договоренности, проводить ретроспективу и устанавливать новые правила.
