14 типов менеджеров, которые бесят разработчиков

Статья написана в соавторстве с Дмитрием Ховричем и Мэри Ротарь, Co-Founder IAMPM.

Недавно мы с Дмитрием проводили вебинар о том, что же бесит разработчиков в проектных менеджерах. В статье расскажем реальные истории из своей практики.

Сперва пару слов о нас. Я Front-end Developer в DataArt, в профессии 7+ лет. Дмитрий Ховрич также больше 5 лет работает в коммерческой Front-end разработке.

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

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

1. Митинг-мэн

Митинг-мэн — это менеджер, вся жизнь которого посвящена митингам. Он когда-то прочитал, что встречи помогают команде работать эффективнее, и возвел эту рекомендацию в абсолют.

С таким менеджером времени на работу просто не остается. Ежедневно как минимум пару часов уходит на всевозможные митинги, на которых присутствует вся команда, хотя по факту нужны 1-2 человека. Митинг-мэн считает своим долгом выслать инвайты всем членам команды, собрать их в переговорке и начать говорить с каждым по отдельности.

Как-то работал с таким персонажем, и поводы для встреч иногда бывали просто абсурдными.

Утром мы собрались, обсудили на стендапе задачи на день, выпили кофе, пообщались, сели за работу — и спустя час-два получаем инвайт на митинг. На митинге спрашивают: «Ну, что ты успел сделать? А что тебе мешало сделать больше? Может, тебе что-то нужно от коллег?» Так и хочется сказать: «Ну если нужно, то я подойду к коллеге и спрошу!» Если каждого в команде 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-а не справился, так как просто не вытягивал этот уровень задач. Пришлось продолжить поиски.

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

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

В завершение

Профессионализм еще никто не отменял: как со стороны разработчиков (привет, кривые эстимейты, после которых за овертаймы ты получаешь бесценный опыт вместо денег), так и со стороны менеджмента. На каждого хорошего специалиста найдется несколько антигероев, которые «посвятили свою жизнь скрамгайду» и вроде как делают все правильно... Но на деле оказываются глобальной катастрофой для команды. Эта статья — попытка показать наше отношение как разработчиков к тем или иным странным решениям менеджмента. Будем рады конструктивному диалогу в комментариях.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось4
До обраногоВ обраному16
LinkedIn

Схожі статті




Найкращі коментарі пропустити

Плохой менеджер достает микроменеджментом: ты уже закоммитил это таску? ты проапдейдил джиру? Хороший менеджер заказывает пиццу на команду, а в остальное время его не слышно 😂

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

Отличная статья, ребята, спасибо. Хороший чек-лист для самопроверки; время от времени полезна саморефлексия :)

Вы забыли еще один толстый вариант «Я этого не говорил делать, тебе послышалось». Можно частично отнести к ХЗ-мену

176 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

улыбно завершение

привет, кривые эстимейты, после которых за овертаймы ты получаешь бесценный опыт вместо денег

:)) хорошая статья! правда, как кто-то упомянул уже — чеклист для самопроверки :) и сразу по ходу прочтения столько историй из жизни вспоминается )))

Зачем нужны менеджеры? Словарный запас из трех фраз — когда закончишь задачу, что мешает закончить во время и чем я могу помочь ))) Разве эти фразы не стоят 1500 долларов. И поверьте для этого не стоит разбираться ни в ИТ ни в другой отрасли.

Работаю на удаленке, и практически каждое утро с 8 до 9 «Are you able to quick call?». Черт побери, Митинг-Мэн, я могу и ночью поднять трубку, но если ты хочешь конструктива дай хотя бы проснуться и позавтракать.

Не надоест,а перенесет на другое время

ахахах, хорошая идея!

просто взгляните сколько платят этим РМам- от 300 до 1500 баксов. Думаете за эти деньги туда пойдут работать толковые специалисты? Да и сами девы редко когда смеют перечить даже самому конченому РМу. Вот и маемо те что маемо(

А чего девы не перечат, если специалисты бестолковые и говорят фигню? Что мешает возразить?

Страх. Защиты ведь нет никакой.

Зажравшиеся вайтишники, ничего не знает плохо, все знает плохо, желание встречи-плохо, не желание -тоже плохо. Не угодишь)

О, очень классно написано).В последнее время очень подбешивают Митинг-мэны )

Спасибо :) да, вообще митинг больше двух человек должен быть скорее исключением чем правилом (если это не дейли или ретро)

Ну,за дейли и ретро — да, там всё понятно.А , вообще, когда митинг ради митинга- вот бесит очень)

А где хорошие прототипы менеджеров? )))

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

О, а давайте сделаем такое, но тут нужна помощь тех, кто таких менеджеров встречал и истории за что таких менеджеров любят. Давай делать :). Расскажешь о таких?

Был у них в команде PM, который в силу каких-то своих убеждений не мог пользоваться Jira, Trello и другими таск-трекерами. Он создал Excel-ку, в которой были расписаны задачи и исполнители. А вместо того чтобы в Jira перенести таску в колонку «In Progress», нужно было подойти к менеджеру и попросить его внести изменения в таблицу.

Видимо секрет его убеждений состоял просто в нежелании осваивать инструментарий, а работа в IT отделе не IT компании это допускала.

На практике в использовании олдскульных инструментов и современных нет противоречия. Excel больше нужен менеджеру для структурирования для себя и для заказчика всего что происходит (то есть общая картина). Task-трекеры для работы с командой и оперативного управления (и истории выполненных работ в подробностях).

Кларк Кэмпбелл предложил вариант использования Excel и это работает. Вместе с тем сложно представить рабочий день и без Jira/Trello.

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

На эту тему у каждого найдется пара прохладных былин. У меня был менеджер, номер 6 («а давайте так») и номер 13 («контрол-фрик») в одном флаконе. Он считал что много знает, но это было не совсем так, особенно в моей области специализации. Он предлагал «идеальные» с его точки зрения решения, которые не работали, но совсем не доверял моему опыту. Однажды позвонил мне около 9 вечера уже домой, чтобы сказать «мы сегодня обсуждали, и я все таки уверен что надо сделать так». Не отпускало пацана целый день, что его решение не работает.
Однажды мне нужно было поработать из дома неделю, на что я получил отказ с формулировкой «как я узнаю, что ты действительно работал». Парень реально считал, что контроль работы с его стороны — это стоять у меня за спиной и смотреть в монитор.

Я из-за такого ушел с проекта, когда тимлидил. Предлагалось всей командой делать фигню, которая не взлетит.

А есть где-то ссылка на вебинар из статьи?

Классный стиль изложения, взглянул бы на вебинар в 1.5 скорости.) без крутых менеджеров тяжело работать, особенно когда 13-й тип считает что он прав. Идеальных менеджеров нет в любом случае, но вы молодцы что знаете какими быть не стоит :)

Можно челендж себе придумать.
Из описаний прям сделать таймлайн себе на 14 недель и пробовать каждую роль. Или пробовать вообще не использовать один из подходов.

Интересно) Но все же, в чистом виде нет ни одного такого менеджера. Как правило встречается комплекс из этих «навыков».

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

Я не знаю, как разработчиков, а меня больше всего бесит именно № 1. Вспоминается одна работа, где замечательно было очень многое, если бы не эти гребаные митинги — буквально — каждый день. Большие и маленькие, нужные и не очень, но под лозунгом «коммуникация очень важна» они жутко отвлекали от работы.

И тем не менее, всему есть мера. В роли PM мне довелось самому работать под руководством старшего менеджера, который отнимал у меня и моих коллег ежедневно из 8 часов рабочего времени до 3-4 часов. Ежедневно. А кроме него были и другие совещания. Модель управления была Waterfall , и для этой модели свойственны длинные совещания. Но все прочие рабочие процессы стали просто уходить на второй план. Анализ, планирование, закупки, оценка прогресса текущих работ... Работа стала значительно затруднена. Что и стало одной из важных причин моего ухода из компании. Упомянутый в пункте #1 тип менеджера может развалить всю команду сверху.

Человек был хороший. Но из категории #1 митинг-мэн. Это действительно стало трагедией.

Административная система была массивная, но PMов таки TOP-менеджеры вывели в прямое подчинение CTO, который доверял и давал широкие полномочия каждому PMу под проект. Два года все работало благополучно, пока между CTO и PMами не оказался митинг-мэн, который активно взялся устанавливать ежедневный мониторинг всего и вся.

Я только рад, если между CTO и офисом PMов, например, есть директор этого офиса PMO. За карьеру посчастливилось работать под руководством двух прекрасных директоров PMO, талантливых. Мы бед не знали.

Интересно, кто из них наиболее безвреден? Как по мне — Инкогнито. Вполне себе рациональный подход)

Я думаю, ХЗ-мен. Так как по идее он хоть что-то делает.

Без привязки к степени — любой из них :)

Читал и во мне боролись 3 эмоции)))
Как автор так точно прописал?)
Крутое оформление)
Гордость, что знаком с IAMPM

Помню, как работал в одной компании удаленно и менеджер вроде был нормальный, но доставало, когда ты работаешь, а тебя в скайпе начинают отвлекать, чтоб срочно оценить какие-то новые задачи. Еще очень напрягало заполнять время, чем я занимался поминутно. Бывало так, что я в конце дня уже не помнил, чем занимался утром, но приходилось сидеть и вписывать какой-нибудь бред в потраченное время.
Еще очень напрягало, когда объявляли совещание на какое-то время, я под это время старался подстроиться, а в итоге все про совещание забывали.
Еще помню, как попросили оценить проект. Я сказал три месяца. В итоге они посчитали сумму для заказчика и боялись ему озвучить, чтоб не сбежал. В итоге меня попросили пересмотреть время. Я сказал два месяца, чтоб отстали. В конце концов я заложил основу проекта и ушел из компании (по другим причинам). Делали они его месяца 4.
Но в целом компания была хорошая.

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

Невероятно бесит, делайте ежедневный отчет о проделанной работе и отправляйте на почту/в слак/в гугл док (нужное подчеркнуть). Когда спрашиваешь «На кой черт тебе джира дана?» отвечает «Я же не могу каждого по отдельности проверять». Приходится копировать список сделанных тикетов из джиры, для таких ПМов

Ну с некоторыми может быть совсем некомфортно работать :(

Коллеги, предлагаю готовить ответку! :)

Какие разработчики, маркетологи, HRы — и вообще все остальные — бесят менеджеров? ))) Этот список может быть бесконечным ))))

Больше всего убивает «инкогнито» менеджер, ну лично меня. Они обычно сводят программистов и заказчика и больше не появляются на проекте до того момента, пока бюджет не исчерпается на середине проекта.
И мотивация у сотрудников такого менеджера всегда на нуле, жалко обычно такие команды.
Но вообще статья ТОП.

Вас убивает «инкогнито» менеджер, вероятно потому-что Вы другой вид «активного» менеджера)

4. Задрот-мэн

Побольше бы таких.

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

Типа окошко ввода логина нарисовать? Остальное можно не делать, что там для секурити нужно?

Дык там же написано, что «ломается логин». То есть, он уже был нормально реализован, но что-то пошло не так. В этой ситуации, действительно, логично его фикс воткнуть как первоочередную задачу на прямо сейчас. И, кстати, никто не говорит, что этот фикс надо делать «тяп-ляп, лишь бы побыстрее». Говорят о том, что его надо сделать в первую очередь.

Как-то на одном из проектов жили год без PM-а. Да и такое было и ничего справлялись xD

А сколько человек было в команде?

Хороший ПМ и баню организует, и водку холодную найдёт ©

не мое, водку не понимаю, но бро зрит в корень.

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

зависит от того, какая водка, и какой результат нужен)

Статья просто топчик)))
Зачитывался)

Не могли подождать до пятницы?

А чего до пятницы то?

в пятницу можно меньше поспать

Звучит классно) а есть где-то вебинары с похожим материалом ?)

Ну вот был как раз вебинар по которому писалась статья.

Вы забыли еще один толстый вариант «Я этого не говорил делать, тебе послышалось». Можно частично отнести к ХЗ-мену

Бывает и зеркальный вариант: «ты этого не говорил, это я придумал» :)))

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

Особенно когда о повышении зарплаты)

Только один вопрос — они все инопланетяне или засланные?)

Мне она нужна на английском. Спасибо =)

Она в смысле статья?

+1 годнота, как PM говорю, нужно на дефолтном языке, хотя так художественно трудно, да

спасибо за линк! забрал себе)

Ох, статья потрясающая! Особенно тем, что узнаешь себя в нескольких пунктах сразу.
Спасибо, теперь знаю что исправлять.

А сколько всего типов менеджеров?
14?

14, в изначальном варианте было 15, но мы два объединили

Заголовок

14 типов менеджеров, которые бесят разработчиков

Вопрос

А сколько всего типов менеджеров?
14?

Следовательно

Все типы менеджеров бесят разработчиков

Хахахаха :). Теперь поняла вопрос. Нет, конечно, сли так говорить, типов менеджеров многим больше.

А как же "Забиваха"/"Передаст"? Стыкался с таким, еще в бытность в ДСЗ — типа назначили РМом, к счастью не для нас, а для кучки прогеров с которыми мы взаимодействовали, и он по идее должен был решать вопросы взаимного понимания между нами (типа деплойерами) и разрабами. Но в итоге чувак реально кидал куоты в вайбере и скайпе от разрабов, а на совместных митингах сидел и задротил енгри бёрдс, перед нашим общим высшим руководством.

Ох, и долго он смог продержаться на работа?

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

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

Впрочем, тут нужно добавить, что сама сборка проектных менеджеров в отдельный офис под руководство директора PMO есть естественный процесс в весьма крупной компании. Если директор PMO талантливый — то гармония сохраняется и скоро начинаешь думать «а как мы вообще работали без столь эффективной структуры». Если же не повезет, то, поверьте, сами проектные менеджеры проклянут и митинги, и ручной менеджмент.

как говориться «хороший человек» не профессия ^_^

Извините, а что простое «пошёл на хер» отменили?

И почему же? Я сейчас работаю в составе интернациональной команды. Менеджер добавляет таски в джиру распределяет и устанавливает приоритет — всё. Да, он модет попросить выйти в выходные, да он модет спросмть когда ты ожидаешь закончить эту таску. Но это всё оплачивается и происходит редко. + Я разработчик тулзов

Нет, я из дому. Просто работу делают независимые контракторы, их много

Притча из жизни:
Благодаря одному TechLead, однажды отправившему ПМа по данной короткой формуле на три (немножко другие) буквы, вся его команда шесть (6) месяцев разгребала проблемы работы железа, которое было куплено без учёта их интересов. Не со зла. Бюджет был недостаточный, и их потребности встали в последнюю очередь. Ребят надо было выручать, и мы таки нашли бюджет по другому проекту чтобы исправить ситуацию (но только через пол года). Закупили на этот раз то, что они рекомендовали. Но кто ж мешал выслушать ПМа и помочь ему вовремя?

P.S. а Tech Lead уволился тогда почти сразу, оказалось, он уже нашел другую позицию. «Спасибо» ему и от его команды, и от ПМа.

Плохой менеджер достает микроменеджментом: ты уже закоммитил это таску? ты проапдейдил джиру? Хороший менеджер заказывает пиццу на команду, а в остальное время его не слышно 😂

Плохой разработчик не коммитит без напоминания и не меняет статусы без пинка. Если хороший — ПМа не слышно :)

Круто когда менеджменту удалось настроить процесс коммуникации так, что на большую часть вопросов отвечает документация (уже созданная или создаваемая) или сам заказчик (если компетентен и доступен) — так сказать прямой канал. Задача менеджмента в такой структуре поддерживать эти каналы чистыми, открытыми, вседоступными и понятными, но и по возможности не забывать про blameless, чтобы как раз было и желание и возможность задать вопрос. И только иногда вмешиваться, когда обсуждение задачи-модуля-стори убежало не в ту сторону (опять же тогда и сам менеджер должен быть и компетентен и в курсе)...все мы люди и это норм и всякое бывает ^_^

Отличная статья, ребята, спасибо. Хороший чек-лист для самопроверки; время от времени полезна саморефлексия :)

Круто расписали все составляющие ПМа :)
По отдельности выглядит страшно.
Но если это все вместе сложить, вот и будет опытный ПМ который раньше делал по всякому, а теперь может на своих ошибках строить правильный менеджмент на проекте))

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

Тот факт, что манагер предпочитает какой-то олдскульный инструментарий вместо стильного-модного-молодежного сам по себе не делает его плохим менеджером. Смысл всех этих таск-трекеров и тому подобного инструментария заключатеся именно в обеспечении управляемости, «чтобы манагеру хватало одного взгляда чтобы разобраться в ситуации на проекте», а вовсе не в том, чтобы сделать кодеркам приятно.

Очень слабая аргументация: 15 минут в день — это мизер, «45 минут вспоминать чем он занимался» откровенно притянуты за уши, мелкий шантаж на тему «кодерки разбегутся». Так вам слона джиру манарегу-олдфагу не продать :)

Ну ладно еще Гугель Эксель, но однопользовательский Excel.
Он выходит не манагер, а Оператор ПК. Ты ему квитанцию, а он клац-клац.

Не вижу противоречия между использованием олдскульных инструментов и современных. Excel больше нужен менеджеру для структурирования для себя и для заказчика всего что происходит (читай — общая картина). Task-трекеры для работы с командой и оперативного управления, плюс лог выполненных работ (в подробностях).

Кларк Кэмпбелл предложил вариант использования Excel и это работает. Вместе с тем сложно представить рабочий день и без Jira/Trello.

Или не везет, или на себя нужно посмотреть

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

Может быть, но зато есть за что уважать.

Да. Иначе проект тянулся бы дольше.

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

Вот поэтому живем без юнит тестов)

Кагбэ 3 года в продакшне

Ну вот я обновил Nokia 1100 до iPhone SE. Ниче, вроде, в карман влазит. Что с ним не так?

Покатился я еще в августе, и решил, что интернет бывает полезным.

Просто плохо без интернета, когда надо что-то решить. И это — самый мелкий по размерам смартфон сейчас.

Видел нормальный 4-дюймовый китаефон? Этот стоит 300 баксов, но, может, не развалится воттаксразу.

Как называется?

Кажись, уже разобрали. И он 150 баков в украине стоил.

Вот я пошел на розетку и хотлайн, вбил < 5″, почитал отзывы, и получилось, что только один сейчас есть нормальный. И в англоязычных обзорах мелких смартфонов — то же самое.
+ напрягает, когда андроиды начинают показывать рекламу на тему, о которой только что говорили.

Лопату не хочу — в карман не влезет.
По блеквью отзывы плохие.
hotline.ua/...​ck/discussion/#discussion

То есть, я хотел купить и забыть на несколько лет.

Часто це від відсутності знань. Матчасті їх не вистачає
Він був просто офігенним пацаном, що від весілля та похорони, але життя вайке... і він пішов в ІТ.

Ну так можно же и нужно подтягивать матчасть, даже если ты свитчер. Че сидеть и ждать, пока ты всех выбесишь?

«Ни даже если», а в принципе) подтягиваешь матчасть и сразу становится легче жить!

Реальный кейс: в компанию прособеседовали семерых кандидатов. В результате разработчики выдвигают свою кандидатуру, которая, по их мнению, больше всего подходит на указанную должность. А в один прекрасный момент менеджер непонятно почему (бюджет/диалог с клиентом/интуиция) предлагает взять другого. Почему? Потому что!

Бывают ситуации, когда выбранный разработчиками (техническими интервьюерами?) кандидат или оказывается слишком дорог, или же сам отказывается от вакансии именно в этой компании или команде, он пособеседовался, задал вопросы, и понял, что он не хочет работать здесь на предложенных менеджером условиях. Должен ли менеджер говорить об этом команде (он дорог для нас, он не хочет работать у нас)? Уже сильно зависит и от менеджера, и от команды.

Согласен. Все сильно зависит от процессов в компании и того как выстроены отношения между менеджером и командой. Но отсутсвие какой-либо внятной (даже надуманной) мотивации решения менеджера может привести к тому, что члены команды начнут сами придумывать эти причины и в итоге может так получится, что кто-то придумает себе причины, по которым можно бы начать искать себе новое место работы, к примеру. Так на всякий случай, а то вдруг и меня по какой-то такой причине уберут из проекта/компании.

Пример сферический в вакууме, но отсутствие ясности часто приводит к тому, что люди начинают придумывать причины и к каким выводам это их приведет сложно предугадать.

Лучший вариант держать нормальную мораль на проекте — гласность.

Согласен. Но не все менеджеры с этим согласны.

И такое бывает. Забавно :)

Ещё как бывает)) главное самому таким не стать ^_^

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

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

Да, полагаться только на здравый смысл рисковало.

Я говорил о помощи здравого смысла в определении необходимой меры каждого из описанных элементов, а не в выборе цели. Определение целей — это совсем другой обширный вопрос.

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

Возможно, просто не объяснил, зачем.

Да, статья именно об этом, об ошибках в коммуникации внутри команды.

Так можно в ответ написать о 14 плохих типах программистов. Нет ведь никого совершенного

Да, конечно. Мы писали чтобы в юморной форме отобразить частые проблемы в коммуникациях. Чтобы люди прочитали, улыбнулись и не делали так :)

И на этом спасибо :)

Нет смысла отвечать текстом когда вас троллят)

В том, что отвлекает разработчиков от работы

Підписатись на коментарі