14 типов менеджеров, которые бесят разработчиков
Статья написана в соавторстве с Дмитрием Ховричем и Мэри Ротарь, Co-Founder IAMPM.
Недавно мы с Дмитрием проводили вебинар о том, что же бесит разработчиков в проектных менеджерах. В статье расскажем реальные истории из своей практики.
Сперва пару слов о нас. Я Front-end Developer в DataArt, в профессии 7+ лет. Дмитрий Ховрич также больше 5 лет работает в коммерческой Front-end разработке.
Дисклеймер: проектные менеджеры нужны, важны, бывают очень крутыми ребятами, и без них работать было бы тяжело, а порой и невозможно. Но за 12 лет суммарного опыта у нас накопилась достаточно негативных кейсов, о которых сегодня и поговорим. Истории, написанные от первого лица, случались с кем-то из нас в далеком (или не очень) прошлом.
Наши супергерои — это не конкретные люди, а собирательные образы, воплощение деструктивных моделей поведения, которые присущи некоторым проектным менеджерам. Иногда в своем PM вы можете узнать сразу нескольких антигероев из статьи — или, если повезет, ни одного. В общем, все персонажи вымышлены, а совпадения случайны...
1. Митинг-мэн
Митинг-мэн — это менеджер, вся жизнь которого посвящена митингам. Он когда-то прочитал, что встречи помогают команде работать эффективнее, и возвел эту рекомендацию в абсолют.
С таким менеджером времени на работу просто не остается. Ежедневно как минимум пару часов уходит на всевозможные митинги, на которых присутствует вся команда, хотя по факту нужны
Как-то работал с таким персонажем, и поводы для встреч иногда бывали просто абсурдными.
Утром мы собрались, обсудили на стендапе задачи на день, выпили кофе, пообщались, сели за работу — и спустя час-два получаем инвайт на митинг. На митинге спрашивают: «Ну, что ты успел сделать? А что тебе мешало сделать больше? Может, тебе что-то нужно от коллег?» Так и хочется сказать: «Ну если нужно, то я подойду к коллеге и спрошу!» Если каждого в команде 5+ человек поспрашивать на митинге — уже, считай, минус час-полтора времени, которое можно было потратить на разработку.
Бывали случаи, когда кто-то работал удаленно по причине плохого самочувствия. И даже если конкретно сейчас вопросов к коллеге не было, а его присутствие на митинге было излишне, такой менеджер все равно дозванивался до человека и заставлял зайти в скайп и включить камеру: «Чтобы мы тебя видели!» Это выглядит немного странно, но это тоже особенность Митинг-мэна — достать даже мертвого из могилы и добавить его на колл.
Еще один особый талант Митинг-мэна — не прерывать в процессе командной встречи диалог двоих разработчиков, которые решили углубиться в свои проблемы. Это же удлиняет митинг, ура! Нужно больше митингов богу митингов!
2. Инкогнито
Менеджер по факту не особо вникает в процессы. Общение идет напрямую по схеме «разработчик-клиент». Появляется Инкогнито, только когда какие-то вопросы решились в обход менеджера по причине его отсутствия на проекте или пинга длиною в вечность.
Я работал в проектах, где менеджер — что есть, что нет. Обычно это выглядит так: тебя знакомят с клиентом и менеджером, показывают все инструменты, дают доступы, все хорошо. Когда начинается работа, ты понимаешь, что клиент, как правило, пишет тебе напрямую. Ты, если нужно что-либо спросить, спрашиваешь клиента, потому что PM обязательно пропадает на три часа и появляется, когда ответ уже неактуален, потому что вы с клиентом успели обсудить все детали.
В итоге смысл феномена проектного менеджмента проявляется, только если на проекте что-то идет совсем не по плану — часто как раз из-за невключенности PM. В этом случае Инкогнито еще и недоумевает, почему с ним никто не советовался раньше. Да потому что работа стоит, тебя нет на связи, а ее надо делать! При знакомстве с менеджерами типа Инкогнито возникает вопрос: зачем они вообще нужны, если можно назначить главным лида, и все будет хорошо?
3. ХЗ-мэн
Это менеджер, который не знает, как правильно формулировать задачи и какие для них существуют критерии оценки. Под формулировкой задачи мы подразумеваем создание таска в Jira (или другой системе контроля задач) и его грамотное описание.
Практически каждый разработчик сталкивался с таской, которая состоит из одного title, например, «implement login». Смотришь на этот title и не понимаешь: что вообще нужно сделать?! Менеджер подразумевал фронтенд, бэкенд или вообще дизайн? Работа над такими задачами — это гадание по хрустальному шару.
К сожалению, ХЗ-мэны достаточно распространены. Поэтому, чтобы разработчики не впадали в ступор, когда они видят задачу, существуют такие проверенные временем подходы, как написание Acceptance Criteria и Definition of Done.
Кто-то может сказать, что DoD — это общие требования к качеству, а не обязанность менеджера, и тем не менее, позаботиться о том, чтобы этот список DoD был хотя бы прикреплен к задаче и формализован, а разработчик об этом попросту не забыл — все-таки должен PM. Если в компании DoD-a нет, PM-у стоит позаботиться об его организации. Менеджер может, как минимум, пнуть самого умного разработчика, чтобы он это сделал. Как бы то ни было, DoD на проекте должен быть, иначе работать сложно.
4. Задрот-мэн
Это звание получают менеджеры, которые пытаются натянуть методологию на глобус. Понять, кто такой Задрот-мэн, лучше всего поможет реальная история, которую я слышал от коллег.
Есть проект, довольно крупное мобильное приложение (количество пользователей исчисляется сотнями тысяч). Разработка ведется по Scrum: стандартные двухнедельные спринты, планирование, эстимейты — все, как положено в лучших домах Лондона и Парижа.
Внезапно в середине спринта ломается логин. Заказчик прибегает к менеджеру: «У меня 100К пользователей, и никто не может войти в систему, что делать? Давайте, ребята, почините». Менеджер: «У нас скрам! Все распланировано, мы не можем просто так взять и починить логин! Если ты хочешь, чтобы мы его починили, то давай сперва сядем, посмотрим бэклог, выберем задачу, которую выкинем из этого спринта, а вместо нее поставим задачу по фиксу логина».
Заказчик в шоке, так как не понимает, зачем вместо того, чтобы прямо сейчас сидеть и фиксить проблему, из-за которой бизнес теряет деньги, нужно тратить время на Scrum-игры.
Вывод: не стоит безоговорочно и неукоснительно следовать всем постулатам одной методологии как законам (особенно если вы поняли ее слишком буквально). Любая методология должна учитывать ситуации, когда что-то пойдет не так, и придется принимать быстрое решение.
5. Эстимейт-мэн
Разновидность Задрот-мэна. Такой менеджер просит эстимировать каждый чих и очень болезненно реагирует на любые отступления от оригинального эстимейта.
Чаще всего эти ребята встречаются на проектах с жесткой почасовой оплатой, где каждая таска должна быть оценена, потому что по этому количеству времени позже выставляется счет. Но проблема в том, что процесс разработки проекта (особенно большого и сложного), трудно прогнозируем, когда в каждой команде есть по N разработчиков (хотя бы пять фронтов, пять бэкендов и пара дизайнеров).
Чтобы разработчик мог адекватно оценить задачу, он должен хорошо знать проект, плюс иметь опыт реализации схожего функционала ранее, и даже в такой ситуации сложно учесть, к примеру, какие-то обновления библиотек и проблемы с API-интеграцией.
Если вы оказались в ситуации, когда горят сроки, сломался деплой — часто вместо того, чтобы следовать техникам, методикам и подходам, надо просто брать и делать. И когда в такой ситуации Эстимейт-мэн начинает давить, требуя конкретный эстимейт, на этой почве и возникают конфликты.
Что делать: давать вилку минимум-максимум. Когда речь идет о какой-то более-менее объемной таске, можно выделить подзадачу на ресерч. Обычно время и деньги на ресерч выделяются, когда планируется реализация какого-то нового нетривиального функционала, и нужно понять, какие инструменты уже есть, что подходит и не подходит. Возможно, вам вообще ничего не подойдет, и придется пилить собственный инструмент с нуля.
6. А давайте так-мэн
Разработчики — птицы гордые. Никто не любит, когда им указывают, что и как делать, а уж тем более — когда говорят, какие технологии и фреймворки использовать. Разработчик может прислушаться к мнению другого более опытного коллеги, но не проектного менеджера, который сам не понимает, о чем говорит.
Всю прелесть работы с таким персонажем испытал на своей шкуре. Я тогда был новичком в компании и выполнял одну из своих первых тасок. Менеджер подошел ко мне и попросил показать конкретно в коде, что я сделал. Я показал код и объяснил, что мне нужно было создать еще одну таблицу в базе данных для хранения этих новых сущностей. Он мне говорит: «А почему ты создал новую таблицу? У нас же есть другая таблица». Я ответил, мол, эта таблица не подходит, потому что здесь немножко разные сущности. Менеджер начал утверждать, что сущности одинаковые. Спорили полчаса, пока я его не переубедил. Зачем я тратил свое время на этот спор, так и останется загадкой.
У моего товарища была ситуация, когда они полгода писали CRM-ку на Angular, в проекте были некоторые проблемы, которые менеджер планировал решить переписыванием всего на Vue через полгода разработки! Как это может решить проблему — непонятно, но команда была «в восторге».
Менеджер имеет право рекомендовать технологический стек на основе своего предыдущего опыта, но, опять же, не стоит забывать, что его голос должен быть совещательным, и окончательное решение о технологиях, которые стоит использовать, остается за разработчиками. Тут можно сделать небольшую поправку на случай, когда в команде одни джуны, а PM имеет хороший технический опыт — в таком случае команда должна прислушиваться к мнению менеджера.
У моих коллег был опыт с адекватным менеджером. Разработчики стояли перед выбором, как развивать проект, написанный на старом Angular. Пришел новый PM, предыдущий опыт которого был с командой, которая использовала Vue, поэтому он предложил: «Ребята, у нас в прошлой команде достаточно неплохо работал Vue. Давайте, может быть, тоже попробуем?» Общение шло в дружеском ключе, своего мнения он не навязывал. Разработчики подумали, попробовали и решили продолжать проект на Vue.
7. Криворукий джира-мэн
Практически в любом проекте есть какой-то таск-трекер (Jira, Trello), который за счет определенных инструментов позволяет выстроить flow разработки, тестирования и учета задач.
Трекер криворукого джира-мэна — один большой todo-шник с кучей тасок. Они не настроены: ни фильтров, ни категорий — ничего. Ты просто пытаешься хоть что-то откопать, зарываясь в эту кучу... тасок.
Менеджер просто усложняет работу программистов и своими криворукими действиями откладывает срок релиза. Лечится такой недуг пониманием принципов работы таск-трекера и обсуждением с командой, в каком виде и формате им было бы комфортнее получать таски, чтобы не тратить дополнительное время на трактовку и расшифровку.
8. Да, конечно-мэн
Думаю, каждому хотя бы один раз в жизни приходится столкнуться с менеджером, который всегда принимает сторону клиента. Он соглашается на любые запросы, не посоветовавшись с разработчиками о том, насколько запрос адекватен, можно ли его реализовать и насколько это долго/сложно.
Рано или поздно заказчик может сесть на шею и свесить ножки. Если он попадает на такого менеджера — ищите другой проект. Лечится проблема максимально подробным планированием задач.
9. Таска-мэн
Менеджер, который не в состоянии оценить сложность задачи и время на ее выполнение, а в качестве бонуса неравномерно распределяет задачи в рамках команды.
По-хорошему, в эстимейте должны участвовать как менеджеры, так и разработчики. Но бывают проджект-менеджеры, которые считают себя достаточно компетентными для самостоятельного эстимейта. В эту категорию попадают те, кто раньше были разработчиками, возможно, совсем недолго, но они уверены, что уже знают, сколько времени уйдет на каждую задачу. С одной стороны, спасибо — никто из разработчиков эстимировать не хочет, и когда менеджер действительно разбирается в теме и берет эту задачу на себя, мы ему очень благодарны.
Если же менеджер не такой эксперт, как ему кажется, и оценивает задачу слишком оптимистично, у команды могут возникнуть проблемы. Еще один минус неправильной оценки задач — неравномерное распределение их в рамках команды. В итоге одна часть ребят жестко овертаймит, в то время как вторая уходит с работы на два часа раньше.
10. Додо-мэн
Однажды я работал в компании, у которой есть свой офлайн-бизнес, допустим, по производству тапочек. В один прекрасный момент они решают построить IT-отдел. Раз есть отдел — нужен РМ. Руководство чешет репу и решает назначить Васю, который до этого был начальником в ООО «Рога и копыта».
Вася проект не менеджил от слова «совсем». Не потому, что он — плохой человек, а оттого, что в душе не ведал, что такое IT и как с ним быть. Так и «работали» до момента, когда мне надоело, что человек не понимает, где он, что здесь делает, и фактически мешает нашей работе. Я напечатал на листике пункты, по которым мы принимаем в работу задачи, положил Васе на стол и ушел. После этого у нас с ним состоялся непродолжительный диалог-разъяснение содержимого листика. Благо, Вася понимал, что ни черта не разбирался в разработке, и после беседы решил алгоритмом воспользоваться. Но такие «менеджеры» сильно демотивируют, и это приводит к утечке кадров.
11. Excel-мэн
Историю рассказал мой товарищ, который работал в достаточно крупной компании со своим внутренним IT-отделом. Программисты разрабатывали для компании интернет-магазин, внутренние CRM-ки и прочие программные штуки, которые упрощают продажу и дистрибуцию товара.
Был у них в команде PM, который в силу каких-то своих убеждений не мог пользоваться Jira, Trello и другими таск-трекерами. Он создал Excel-ку, в которой были расписаны задачи и исполнители. А вместо того чтобы в Jira перенести таску в колонку «In Progress», нужно было подойти к менеджеру и попросить его внести изменения в таблицу.
Как вы понимаете, такой процесс был удобен только менеджеру, которому одного взгляда на Excel хватало, чтобы разобраться в ситуации на проекте. С точки зрения команды все было крайне печально.
12. Копипаст-мэн
Менеджер не заморачивается с описанием стори/тасок. Просто копирует текст от клиента из письма/мессенджера и вставляет в описание в Jira. Разработчики сами разберутся.
Одна из ролей менеджера — услышать клиента и привести услышанное в понятный для разработчиков вид, а этот менеджер не проверяет текст на понятность, выполнимость и отсутствие бреда. И конечно, снова никаких тебе acceptance criteria.
13. Контроль-фрик
В отличие от Эстимейт-мэна, заморачивается на предмет того, на что вообще разработчик тратит время.
Я сталкивался с менеджером, который просил в отдельной таске фиксировать время, потраченное на code review. С одной стороны, его можно понять. С другой стороны, мне вообще не хочется запоминать, сколько времени я потратил на код ревью, а сколько — на саму задачу, и фиксировать все это в разные тикеты. Это совсем не воодушевляет.
Еще один пример не настроенных от слова «совсем» процессов — когда ребята неделю работали, а в пятницу трекали четыре часа рабочего времени в специальную таску, которая так и называлась: «Трекинг».
Понятное дело, менеджер должен контролировать ситуацию на проекте, но становиться надзирателем не нужно. Объясните команде причины, по которым вам приходится отчитываться перед заказчиком за каждую секунду разработки (вы ведь поэтому дергаете людей, правда же?), и вместе придите к адекватному решению, которое всех устроит.
14. Потому что-мэн
Ситуация, когда после собеседования и фидбэка менеджер пушит кандидата, который менее подходит на вакансию, потому что... потому что.
Реальный кейс: в компанию прособеседовали семерых кандидатов. В результате разработчики выдвигают свою кандидатуру, которая, по их мнению, больше всего подходит на указанную должность. А в один прекрасный момент менеджер непонятно почему (бюджет/диалог с клиентом/интуиция) предлагает взять другого. Почему? Потому что!
Чем менеджер руководствовался, предлагая такое решение — большой вопрос. В итоге кандидат PM-а не справился, так как просто не вытягивал этот уровень задач. Пришлось продолжить поиски.
Если есть объективные причины: «У нас ограниченный бюджет, нужно взять хоть кого-то» — это нормально. Но что мешает их озвучить команде — большой вопрос.
Я сталкивался и с другой, весьма специфической ситуацией, где лид-разработчик уходил с проекта, и ему долго не могли найти замену. Когда лиду оставалось работать пару дней, появился кандидат, который в принципе подходил на его роль. Не идеально, но подходил. А других не было. У менеджера был напряженный график: надо было зарелизить много фич, и сидеть без разработчика он себе позволить не мог. В этом кейсе менеджер вполне оправданно стал настаивать на замене, и все его поняли.
В завершение
Профессионализм еще никто не отменял: как со стороны разработчиков (привет, кривые эстимейты, после которых за овертаймы ты получаешь бесценный опыт вместо денег), так и со стороны менеджмента. На каждого хорошего специалиста найдется несколько антигероев, которые «посвятили свою жизнь скрамгайду» и вроде как делают все правильно... Но на деле оказываются глобальной катастрофой для команды. Эта статья — попытка показать наше отношение как разработчиков к тем или иным странным решениям менеджмента. Будем рады конструктивному диалогу в комментариях.
