Репутація українського ІТ. Пройти опитування Асоціації IT Ukraine
×Закрыть

Из разработки в менеджмент, стоит ли?

Всем привет!
Спустя четыре года в роли java разработчика, появилось желание быть более вовлеченым в процессы проекта, больше коммуникаций (быть поближе к людям :-) ) надоела рутина связанная с разработкой, а именно фиксинг багов и рефакторинг. Наиболее подходящей возможностью сейчас видится позиция проджект менеджера.

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

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
софт скиллов

Этого достаточно.

понимания методологий

Не нужно, просто оттуда надергать умных словеев и юзать их, можно по рандому.

Вот недавно вбросили описание должностей
www.facebook.com/...​rmalink/2284183981676699

надоела рутина связанная с разработкой

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

быть более вовлеченым в процессы проекта

Почему именно PM, а не tech lead или software architect или product owner?
Они хорошо вовлечены в процессы.

больше коммуникаций

Больше всех коммуницируют эйчар, сейлз или например office manager.

Нет таких компаний, которые позволяют раз в год менять проекты)))

То есть хочется менеджить бакфикс и рефакторинг других разработчиков? И писать карточки в джиру и выяснять в переписке и на митингах все подробности о багах?

Помимо того, что здесь уже написали, с менеджерскими позициями есть следующие проблемы:
— Сложнее сменить работу/найти новую — компании предпочитают растить менеджеров сами
— Сложнее завести трактор — менеджер из другой культуры менее предпочтительней чем местный менеджер

компании предпочитают растить менеджеров

но в основном приходят почему-то со стороны

появилось желание быть более вовлеченым в процессы проекта, больше коммуникаций (быть поближе к людям :-) )

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

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

Значит, не научился в делегирование задач. Куда тебе в ПМ?

А может быть некому было делегировать. такое тоже бывает. В комментарии было указано что в команде в основном были джуны..

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

Овертаймы

это нормальная практика для продуктовых компаний, и их не победить!!!

Мне не попадались ни в продуктовых, ни в аутсорсе.
Рекомендую почитать статью, раз уж в ПМы интересно
dou.ua/...​enta/columns/overtimes-1
dou.ua/...​enta/columns/overtimes-2

неее спасибо! Нас и здесь неплохо кормят! Правда хотелось и бы и по-лучше...

Разовые случаи были, но на постоянной основе такого не видел.

Очень редкая.
Да, на ранних стадиях стартапов она возможна, но дальше или стартап тонет или становиться продуктовой и овертаймы прекращаются.
Я почти не работал на галерах в основном в продуктовых — овертаймы случались чрезвычайно редко. Кроме одной, но там не овертаймы были. Там просто немец владелец любил, чтобы славянские програмеры раньше 7 вечера из офиса не уходили, позже 9 утра не приходили и обязательно были в офисе в субботы до 2 дня. Кто на такое не соглашался, увольнял или не нанимал.

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

начальство беспокоит получить профит с джунов продавая их синьорами.

Ну ок, у каждого свои интересы. Начальству важно продать, работникам — получить больше а делать — меньше. Результат зависит от того, как каждая сторона умеет отстаивать свои интересы, и насколько легко разойтись.
Роль ПМа в этом:
1) Объяснить заказчику, что эти синьоры и так мегапродуктивны для настолько сложной задачи
2) Дать джунам небольшое повышение зп на 500 баков чтобы не убежали
3) Повысить рейт заказчику на 1000 баков, чтобы прокормить джунов
4) Объяснить заказчику, что проект настолько сложный, что синьоры разбегутся, если не повысить рейт
5) Выделить каждому джуну по 3 часа рабочего времени на самообразование
6) Объяснить заказчику, что программисты эффективны не более 4 часов в сутки
7) Объяснить каждому джуну индивидуально, почему его не повысят до мида, и что он должен быть благодарен конторе, что она его еще терпит
8) Удовлетворить всех ХР в процессе найма новых сотрудников на место уволившихся
9) Быть на всех собеседованиях
10) Назначать и проводить все митинги и стендапы

Блииннн вы все время идеальные картины рисуете...В жизни все намного хуже и страшнее...РМ-ка- это девочка лет 24-28, не всегда красивая, но всегда на взводе.40-летних РМ не видел...Про РМ-ов вообще можно отдельную ветку организовать и где можно писать всю правду и коменты не удаляются потом...

получается ПМ это не та позиция где можно комфортно встречать старость ?)

Если ПМ с золотым парашютом, то можно. А иначе ПМ такой же пахарь, как и програмеры, только еще и с баночкой вазелина в кармане всегда.

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

такая роль думаю мне б была комфортна, но судя по комментариям ниже, не так однозначно все, как впринципе и везде.

Какая наивность. Ты хоть представил реализацию эти 10 пунктов???

Объяснить каждому джуну индивидуально, почему его не повысят до мида, и что он должен быть благодарен конторе, что она его еще терпит

Прям вьетнамский флэшбэк испытал.

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

Прям вьетнамский флэшбэк испытал.

www.youtube.com/watch?v=eEVL9irXj0g (первое попавшееся видео для примера)

Я думал, ты про Самсунг...

Джуны — самые выгодные ребята в аутсорсе. Даже без продавания их как сеньоров маржа огромна. Сеньора за 5к продал, 4к заплатил синьору. Джуна за 3500 продал, 500 баксов заплатил джуну. Поэтому и впихуют в команду джунов, вэнэвэр посибл.

Выгодные, но проблемные...Была девушка джун...Хотел понять, почему она пишет так код, так и не понял( хотя и пытался поставить себя на ее место).Пишет так пишет...
Вообще то джунами должны специалисты заниматься т.е. сеньорные ребята, а на практике получается, что заниматься приодеться тебе...

хотя и пытался поставить себя на ее место

Вот это напрасно и даже странно :)

И ты хочешь быть пиэмом в этом блядском цирке?

Это не цирк а галеры, цирк начнется, когда придет пора сдавать проект!Наверное на РМ-ов где то учат, только я не знаю где...
www.youtube.com/watch?v=U4hSbh4Sww8

уже смотрю альтернативы, тут могут привести информативные доводы )

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

Где об этом сказано в комментарии? Да, там написано про доделывание за джунами, но не то, что их там много было.

Но жопу то твою иметь будут, а не делегированного.

Представь тимлида, который не умеет кодить — это ПМ :) и за это ему приходится расплачиваться...

куча головняка ввиде доделывания задач у джунов

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

Это не от компании , а от проекта зависит...

У других начальников другого головняка не меньше. Наименьшее количество головняка у програмеров и тестеров.

ПМ та Engineering Manager то різні речі. Як згадаю в якому пеклі жили мої ПМи в українських аутсорсах, то навіть страшно уявляти себе на їхньому місці. А от Eng Manager десь в продукті — дуже навіть нічого(хз, мої спостереження). Чи можливо навіть Product Manager.

так, цілком різні речі. Engineering Manager це вже коли людина має єкспртну думку, та дужу дуже багато досвіду за плечіма.

Значит досматриваю последнюю серию Мистера Робота, и вижу Эллиот берет со стола книги, в числе прочих «Dilbert Principle», дай, думаю, почитаю что это такое.
Оказывается в соотвествии с ним, если тебя не промоутят в руководящие должности, значит ты еще не достиг «уровня некомпетентности».))

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

Тебе хочется туда потому что тебе кажется, что там прикольно, или ты там уже работал?
Это разные вещи.
В прожект менеджменте ничего крутого нету — в основном ты будешь страдать от общения с гуманитариями. ПиЭм во многих случаях — просто фигура для битья от бизнеса, который транслирует удары команде, сопровождая это все истеричными всхлипами и корпоративной культуре и дедлайнах.
Встречаются и другие ПМ, но к этому нужно иметь способности, и там все равно много попаболи.
Лучше иди куданибудь в архитекты/ит-консультанты.

Одноклассник побывал всеми (QA->QA lead->dev->dev lead->PM->BA). На PM заработал проблемы со здоровьем, пару раз уволили, в результате уже несколько лет BA и радуется. Может, и Вам туда посмотреть, если кодить надоело — там тех скиллы пригодятся.

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

поводу BA это вы сейчас серьезно? меня отговаривали от подобной темы, сколько людей, столько мнений)

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

Основная функция БА — «снять» задачу, перевести ее с языка предметной области на «формализованный» язык. После реализации «сдать» эту задачу представителю заказчика.

И где здесь дедлайны заложены?
БА не отвечает за сроки выполнения, не отвечает он также и за качество выполнения, не отвечает за просранные дедлайны. Это головняк ПМа.

у БА получаются дедлайны в любом случае

Та ясенкрасен что у каждого есть свой личный срок выполнения своей задачи.
Разница в том, что БА отвечает за свой дедлайн, а ПМ — за чужие дедлайны. Т.е. по факту, ПМа могут сношать за чужое разгильдяйство, и его задачи — вытирать сопли и переставлять ноги всем вокруг, а БА просто делает свою работу, а не надзирает за выполнением чужой.

Считаю ее сильно недооцененной (если действительно делать работу, а не быть «номинально» ПМом).

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

А че БА не вложится? У него всегда есть ответ, что понабирали тут тупых джунов, что ничего не умеют, а он все расписал для джунов.

Не знаю, у нас БА это БА, а СА это СА...

Может и так...По мне так каждый должен заниматься своим делом...Хотя на практике и приходится иногда помиксовать...

Я как-то греб на проекте где БА и КА были сотрудники компании, которые пользовались апликухой для своей обычной работы — там своя особо дроченная бизнес логика была, они там годами вникали в нее и разделение по направлениям было.

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

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

У меня не редко уходило около недели только на то чтобы окончательно выяснить что ж именно надо пофиксить или запедалить. :-)

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

У БА есть четкие обязанности, а ПМ должен удовлетворять всех, иначе — он всегда крайний. А то, сколько этих всех, и насколько они знают толк в извращениях — зависит от кармы.

А быть синьор девелопером еще и выгоднее в денежном плане)))

Похоже, зависит от квалификации.

на архитектора опыта/знаний маловато, ит консультант это что саппорт? как то сильный декласс получится)

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

на архитектора опыта/знаний маловато

Ну так и расти в это направление. Сам же ответил.

Да, только есть две проблемы:
— skills
— Имя(которое нужно заработать)
Беря во внимание специфику местного рынка — локально IT consultants не востребованы, т.е. имя нужно заработать на глобальном рынке, а это очень трудно и долго(в 99% случаев — нереально)
А без Имени на этом поприще делать нечего

потому что штатной команде не хватает опыта в критической ситуации

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

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

Успехов!

смотря какая контора, ит отдел продуктовая компания...Вообще если честно, то погонщиков нигде не любят...Скорее терпят, и держат в душе камень на тебя!смотря сколько за это заплатят...

да, копнул глубже, неожидал столько негатива о пмах (погонщиков).

быть более вовлеченым в процессы проекта, больше коммуникаций (быть поближе к людям :-)

это про QA Senior/(?)Lead(?), у них самые крутые product vision/experience (по факту). что о них думают «разработчики» — см.итальянское, но в отличии от PM’ов в глаза такое им редко говорят)

Англійська, переговори, PMBOK, презентації, методології розробки і найголовніше — знати, як поводитись із людьми. Комунікації буде багато і не завжди будуть показувати себе з кращого боку. Як підлеглі, так і керівництво та клієнти.

все тут — dou.ua/...​rums/topic/26975/#1569107
если ты «готов это как-то решать» — ок, следующий шаг «конфликтные переговоры» (неожиданно, тумс)

бэкграунд в разработке

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

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

создается впечатление что пмы самая хэйтерская позиция в айти

это не впечатление)

сам пересекаюсь с ними каждый день, подобных конфликтов / наездов не встречал

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

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

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

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

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