Привет! Я Любовь Тимошенко. Руковожу менеджерами проектов в «Лайв Тайпинге», веду блог, который помогает управлять другими и собой: без насилия, пожаров, сорванных дедлайнов и выгорания.
На рынке сложилось двоякое мнение о том, каким должен быть менеджер проектов. С одной стороны — работодатели, которые хотят, чтобы менеджер умел читать (и делать!) API, отличал монолит от сервисной архитектуры и мог принимать решения, что лучше на проекте, писал ТЗ, делал презентации, полноценно развивал команду и при этом работал на одной стороне с клиентом. С другой — разработчики, дизайнеры и аналитики, для которых менеджер — это человек, который «мешает» работать, докидывает требования и лезет в оценки, а проект потом всё равно горит.
Я вижу причинно-следственную связь этих явлений. Чтобы её доказать, я опросила 20 разработчиков — знакомых, знакомых знакомых и подписчиков — и собрала семь реальных ситуаций, когда менеджер бесит так, что аж горит. В этой статье объясняю, почему такое горение часто следствие того, что менеджер занимается не своими обязанностями. А про свои — забывает.
1. Менеджер кидает разработчика в чат с клиентом, чтобы разработчик отвечал клиенту на технические вопросы
Уровень горения: 🔥
Почему это вредно. Добавление в чаты с клиентом — это ситуация, на которую разработчики обычно реагируют так:
В моменте кажется, что чаты не мешают работе, даже наоборот, разработчики получают от клиента больше контекста. Специалисты рады помочь и пообщаться вместо менеджера. Но каждая переписка в чатах — это отдельная задача. Получается, что добавляя разработчика в чат, менеджер ставит сотруднику пачку дополнительных задач, но в спринте их не учитывает. В итоге разработчик должен два часа общаться, а потом делать задачу на восемь часов. Когда он будет это успевать — непонятно.
Скрытая проблема. Дополнительные задачи, которые менеджер перекладывает на разработчика, — коммуникационные. Не все разработчики умеют общаться с клиентом, и это нормально, потому что не входит в их обязанности. Но получается, что человек, у которого по профессии должны быть скиллы коммуникации, перекладывает свои задачи на человека без таких скиллов. От этого страдает и качество выполнения задачи, и скорость. К тому же в чате с клиентом разработчик не может увернуться от фидбэка. Клиент переживает за свой продукт, он включён в него эмоционально, поэтому может негативить, если что-то идёт не так. Скорее всего разработчик не сумеет защититься от этих эмоций и примет их на свой счёт.
Как справляемся мы. Мы в «Лайв Тайпинге» можем добавить лид-разработчика или аналитика в отдельный чат с техническими специалистами со стороны клиента. Это требуется, когда дело касается сложных интеграций и разработчикам нужно работать сообща. В остальных случаях мы так не поступаем, потому что хотим уберечь разработчиков от лишних задач. Менеджер — это буферная зона между клиентом и командой. Все процессы должны проходить через него. Во-первых, потому что менеджер умеет пользоваться коммуникацией эффективно и знает, как объяснить клиенту действия разработчика с позиции пользы. Во-вторых, потому что менеджер должен защищать свою команду от эмоций клиента.
2. Менеджер поставил задачу. Разработчик задачу сделал, но его решение не подошло, поэтому всё пришлось переделывать
Уровень горения: 🔥
Почему это вредно. Менеджер ставит задачу, кидает ссылку на техзадание, объясняет, что нужно сделать, но не говорит, кто и как потом будет этим пользоваться. Руководитель или не подумал о том, что нужно погрузить разработчика в контекст, или пользуется логикой «чья задача, тот и носится». Без контекста специалист выбирает решение, которое — при недостатке информации — кажется ему верным. Но это решение может не подойти конкретному проекту, и задачу придётся переделывать, тратя дополнительные деньги и время.
Скрытая проблема. В команде нет доверительных отношений. Когда что-то идет не так, разработчик не может подойти к руководителю и потребовать от него информации или действий. Вместо этого специалист пользуется логикой «как сказали, так и сделаю». Потом выясняется, что сказали не все и нужно переделывать.
Как справляемся мы. Если менеджер хочет, чтобы всё было сделано правильно, то ему нужно или написать для разработчика чёткие пошаговые инструкции, или сформировать у него в голове образ результата. Мы выбираем второй вариант — ставить задачи через результат, потому что хотим работать с людьми, у которых навык принимать самостоятельные решения и нести за них ответственность не заменяется навыком следовать инструкциям. Когда наши менеджеры ставят задачу, они погружают специалиста в контекст, говорят, какие есть ограничения и что должно получиться в итоге. Так они направляют разработчика по верному пути и дают ему свободу решать задачу тем способом, который он считает правильным.
3. Менеджер не доверяет оценке разработчика и считает, что задачу, на которую тот заложил 4 часа, можно сделать за 2
Уровень горения: 🔥🔥
Почему это вредно. Для разработчика это вредно потому, что его помещают в режим горения: скидывают часы с оценок, а потом требуют уложиться в изначально сжатый дедлайн.
Скрытая проблема. Если менеджер спорит с разработчиком об оценке задачи, то скорее всего менеджер как руководитель не умеет управлять приоритетами и выяснять контекст. Он подменяет функцию коммуникации функцией контроля, из-за чего отношения в команде могут накаляться. Снова возникает проблема доверия: между менеджером и разработчиком не сложилось таких взаимоотношений, в которых они могли бы верить друг другу на слово.
Как справляемся мы. Устанавливать время решения задачи — это ответственность исполнителя, потому что именно он будет делать её. Если менеджер не доверяет оценке, то разработчик объясняет, из чего складывается оценка, и помогает руководителю проекта увидеть те же самые ограничения, которые видит он. Но мы учим своих менеджеров не ждать, пока разработчик сам придёт, а подходить первыми и задавать правильные вопросы: не «почему так долго?!», а «помоги мне понять, почему на эту задачу нужно столько времени». Если задачу по каким-то причинам нужно сделать срочно, то мы не просим специалиста работать быстрее, а спрашиваем, можно ли упростить задачу, чтобы оценка тоже сократилась.
4. Менеджер с техническим бэкграундом лезет в код: проверяет, критикует, помогает или навязывает свои решения
Уровень горения: 🔥🔥
Почему это вредно. Менеджер с бэкграундом разработчика — это классно. Он глубже понимает ограничения и в переговорах с клиентом может объяснить технические вещи простым языком. Если же менеджер со своими знаниями начинает лезть в код, то он не даёт разработчику ошибаться и учиться на этих ошибках. Как итог — разработчик не прокачивает свои компетенции, не растёт в скиллах, не становится экспертом и через год получает ровно такую же зарплату, как и получал.
Скрытая проблема. На проекте самый ограниченный ресурс — это время. Его нельзя компенсировать. Если менеджер тратит рабочие часы на код, то ему не хватит времени, чтобы спланировать и организовать проект. И привет, пожары перед релизом! Если у менеджера всё-таки получится совмещать и свою, и чужую работу, то очень скоро он выгорит сам. Когда это случится, менеджер будет пытаться скидывать с себя задачи и ныть, что «команда без пинков и подсказок ничего сама не умеет». Но как команда чему-то научится, если менеджер принимал решения за неё и не давал быть самостоятельными?
Как справляемся мы. Мы пришли к выводу, что хотим набирать менеджеров без навыков разработки. Во-первых, чтобы разработчикам было веселее подшучивать над менеджерами, что они гуманитарии. Во-вторых, так менеджер позволяет специалисту становиться специалистом, потому что руководитель — это человек, который не должен делать работу исполнителя за него. Если сотруднику нужна поддержка, менеджер должен не давать советы, а организовать обучение: найти техлида, который поможет решить задачу на проекте. Кроме этого есть тимлиды и ревьюеры, которые тоже обучают и дают сотруднику релевантные технические знания.
5. Менеджер превращается в чайку перед дедлайном: суетится, закидывает всех задачами, наводит панику
Уровень горения: 🔥🔥🔥
Почему это вредно. Если дедлайн поджимает, а задачи не закрываются, неопытные менеджеры превращаются в чаек. Суетятся, «поджигают» разработчиков, хаотично накидывают задачи. Менеджер побегал, покричал, и ему кажется, что он всё разрулил. Но на самом деле он только демотивировал команду во время закрытия важного этапа.
Синдром чайки — это стиль управления, при котором руководитель сначала удаляется от повседневных управленческих задач, перекладывая ответственность на исполнителей, а потом возвращается и критикует решение команды затем, чтобы снова исчезнуть и оставить всех в тревоге — прилетел, наорал, нагадил и улетел
из книги Ицхака Адизеса «Управление жизненным циклом корпорации»
Скрытая проблема. Если перед дедлайном атмосфера на проекте накаляется, это говорит о том, что менеджер не спланировал проект, не расставил приоритеты и не предвидел риски.
Как справляемся мы. Менеджер не успевает научиться планировать, пока занимается чужими задачами, например помогает разработчику писать код. Поэтому мы за то, чтобы каждый занимался своей работой. Разработчики — кодили, менеджеры — планировали, и никто не нарушал чужие границы. Если у нас перед дедлайном вылезают баги или выясняется, что остались незакрытые задачи, менеджеры не начинают сеять панику — они оценивают ситуацию и делают новое планирование, учитывая текущее положение дел.
6. Менеджер не продумывает нагрузку разработчиков: первую половину месяца специалисты остаются без задач, а вторую — горят
Уровень горения: 🔥🔥🔥
Почему это вредно. Создаётся дисбаланс в рабочем режиме. Сначала разработчики устают от скуки — потом выгорают от работы с утра до ночи. Все это приправляется мотивирующими рассказами о важности проекта, из-за которой нужно поработать на выходных. Первые два релиза в это ещё веришь, а потом уже не очень. Если релизы на выходных повторяются систематически, возникает желание сменить команду или коллектив.
Скрытая проблема. Менеджер не может спланировать время разработчика, потому что не контролирует ход проекта и не знает, какие задачи когда случатся.
Как справляемся мы. Чтобы люди не перерабатывали, мы планируем время разработчиков на три месяца вперёд. Если появилась потребность работать в выходные, мы относимся к ней как к маячку, который говорит, что мы допустили ошибку в планировании. Если так получается, мы не заставляем разработчика жертвовать днями своего отдыха. Вместо этого переделываем планирование, а менеджер вступает в переговоры с клиентом, чтобы обозначить новые сроки.
7. Менеджер продавливается под клиента, принося команду в жертву его интересам
Уровень горения: 🔥🔥🔥
Почему это вредно. Когда менеджер встаёт на сторону клиента, в команде происходит раскол: разработчики могут отказаться работать с таким руководителем. Однажды мы делали приложение по дизайну клиента. В какой-то момент оказалось, что в дизайне используется семь оттенков красного: один для кнопки, второй для ошибки, третий для такой же ошибки на другом экране… С клиентом была договоренность, что итоговая вёрстка будет полностью соответствовать макетам. Но разработчикам было неудобно верстать семь разных цветов, потому что пришлось бы отказаться от использования классов дизайна. Клиенту было неудобно переделывать макеты, так как нужно было заново привлекать дизайнера. Если в такой ситуации поставить в приоритет интересы клиента, то не остается ничего, кроме как сказать команде: «Ребята, ничего не знаю. Как с клиентом договаривались, так и делайте».
Скрытая проблема. Менеджер не умеет коммуницировать. У него не хватает навыков, которые помогли бы ему отстаивать интересы команды. Если менеджер скидывал коммуникацию на разработчика, когда нужно было ответить на вопрос клиента, он лишал себя возможности прокачивать скиллы коммуникации, и теперь за это отдувается вся команда.
Как справляемся мы. В «Лайв Тайпинге» менеджеры действуют и в интересах клиента, и в интересах команды — это партнерские отношения. Как только мы видим перекос в какую-то из сторон, мы это озвучиваем и ищем мирное решение. Я никогда не говорю своим специалистам «как договаривались, так и делайте». В кейсе с дизайном я передоговорилась с клиентом, объяснила, почему использовать семь разных оттенков одного цвета вредно и разработчику, и самому клиенту (так будет сложнее поддерживать продукт), и мы отменили правило «должно соответствовать макетам».
Как выстроить нормальные отношения между менеджером и разработчиком
Я вижу решение в том, чтобы каждый занимался своим делом: разработчик — писал код, менеджер — руководил. Если роли будут смешиваться, то ни один из специалистов не сможет нести ответственность за результат. Тут менеджер покодил, тут разработчик пообщался с клиентом — в итоге ни один из них не прокачал те навыки, которые необходимы для профессионального роста.
В «Лайв Тайпинге» менеджеры тратят внимание на свои прямые обязанности. Этим они создают для всех остальных специалистов условия, в которых те могут заниматься своим делом в спокойном режиме, без пожаров и нервных срывов. Менеджеры прокачивают скиллы коммуникации, поэтому знают, как ставить задачи специалисту и клиенту так, чтобы можно было быстрее договориться. Умение планировать помогает менеджерам держать проект под контролем, чтобы на головы разработчиков падало меньше внезапных задач, которые выбивают их из колеи и приводят к выгоранию
Если ситуации, о которых я рассказала, знакомы вам, — напишите в комментариях, как вы с ними справлялись. Там же можно рассказать, какие ошибки допускают ваши руководители проектов и вместе попробовать найти решения для любого спорного вопроса.
