Комментарии 90
“если ты гуманитарий, а в QA идти не хочется, то есть один путь – в менеджеры проектов”.
Я таких манагеров - каждый день вижу.....
Классически - подписываюсь под каждым словом.
Сорри, не могу яростно заплюсовать. Но если хоть один из , выбирающий путь в IT прочтет , задумается и решит не выбрать путь менеджера проектов - спасибо и от меня лично.
Я вообще не понимаю - как можно назначать на управляющие должности неженатых/незамужних/etc. вчерашних выпускников ускоренных курсов ? Но это сплошь и рядом и уже тренд.
Результат предсказуем - **** **** и в продакшн (с)
Я вообще не понимаю - как можно назначать на управляющие должности неженатых/незамужних/etc
Не рожал - не ПМ?
А можно без штампа в паспорте, но состоящему в отношениях?
Тогда только Scrum-master'ом))))
Не умеешь договариваться с детьми, как сможешь с разработчиками?
А вы уверены что с взрослыми людьми надо договариваться также как с детьми?
А это работает в обратную сторону? Если я могу договориться с разработчиком, то я хороший семьянин и воспитатель?
Да. Если уж смог понянчить разработчиков, то с детьми проблем вообще не будет.
Сарказм работает и в обратную сторону, конечно.
А кто сказал что разработчики взрослые люди?
Скажу так, когда у меня появились дети, я начал гораздо лучше договариваться с коллегами. Потому что с одной стороны, после детей с ними проще. А с другой - дети дают чистейшие, как в учебниках, эмоциональные реакции, и начинаешь видеть их у взрослых людей тоже.
Ну вообще я могу сказать, что опыт работы ПМ с, как один же мой коллега и высказался, капризными айтишниками (с опытом мидл +), более чем замечательно вывезла работу с ребёнком на руках (в декрете не сидела). Тут речь не только о договориться с ребёнком, а в целом иметь хорошую стресоустойчивость и оперативно переигрывать планы, когда вокруг неопределённость.
Если вы можете договориться с разработчиком – вы умеете пасти котов.
Я бы уточнила: нужно уметь договариваться не с просто детьми (у каждого возраста свои прелести), а с подростками. Это особая категория. И на своем опыте я вижу, что мальчики-разработчики выходят из подросткового возраста примерно к 31-32 годам. До этого они мало чем по степени вредности и суждений отличаются от шестнадцатилеток. И тогда при управлении приходится давить, пусть и мягко, пусть и с подробным объяснением, зачем нам нужно выполнить то или иное действие. Особенно интересно смотреть, как эти великовозрастные подростки взрослеют на твоих глазах, и с каждым годом приходится объяснять все меньше, зачем и почему.
Впрочем, иногда я чувствую себя и воспитателем из детского сада.
Не выходим :-)
Поверьте моему опыту, выходите, только не замечаете этого)))
Не так давно общались с сотрудником, с которым работаем уже бок-о-бок 6 лет, и с которым все это время бодались. Да, я его старше на целых 8 лет. Спрашиваю: "А ты понимаешь, почему тебе кажется разумным то, что я говорю?". Он: "Почему?". Я: "Мое мнение не изменилось за годы нашей работы, а вот ты - вырос и понял". Посмеялись)
Разве все родители умеют договариваться с детьми? :)
Я вообще не понимаю - как можно назначать на управляющие должности неженатых/незамужних/etc.
Я вообще не понимаю, как можно допускать в IT родившихся в СССР?
(Аналогия намеренно такая же тупая, без негатива)
ну вы б еще сказали, что перед работой над проектом команда с ПМом должны совместно переклеить обои с минимумом излишков материала, при это не передраться и не более, чем с 3 поездками в магазин за стройматериалами и инструментами :)
Кстати, если подумать, это было бы неплохим тимбилдингом, и пониманием способны ли люди сработаться в нестандартных ситуациях.
Тимбилдинг неплохой, совместный ремонт, особенно долговременный, один из самых коротких путей к разводу, я просто к тому, можно придумать что-то не менее безумное и не относящееся к разработке, но все равно более релевантное, чем опыт брака у ПМа.
Так то да, натягивать сову, в виде договороспособности с членами семьи на навыки ПМ это странно, конечно, но какие-то софт скиллы прокаиваются, факт :)
А по поводу ремонта и жены - хорошая проверка на прочность, если ремонт ставит на грань развода так может и нужен такой брак на долгосрок. Хотя когда он прямо на годы растягивается вялотекуще - это я бы скорее от такого сбежал первый :)
Нормально руководить проектом может только техлид/архитектор, да и то - только если он вдобавок обладает навыками менеджера.
Только человек, который как видит весь проект целиком, так и понимает работу каждого фрагмента, может адекватно оценивать сроки, качество работы разработчиков, бюджеты, потребности. Если этого всего нет - РП превращается в говорящую куклу, вызывающую у всех досадливое отвращение: работы и так навалом, а тут ещё этот за штанину дёргает и чего-то клянчит. И единственная роль РП в этом случае - выступать мальчиком для битья в разговорах с заказчиком, да и то - только если заказчик технически неграмотен и сам не понимает происходящего.
Спорное утверждение. У тех.лида /архитектора своих дел тьма, а тут ему еще управление проектом накидывать... Если тех.лид /архитектор погружается в менеджерскую часть(планы, бюджеты, общение с заказчиком, со смежниками, отчетная часть и тд) месяца через 3-4 его экспертная составляющая просядет, а если еще и бюрократизации компании большая так вообще пу - пу - пу. Понятное дело, что на начальном этапе РП с опытом работы разработчиком будет эффективнее(больше понимает, меньше времени на коммуникации), но спустя небольшой период времени, чистый РП(без опыта разработки) погрузится в проект достаточно, что бы разница между ним и РП с опытом разработки была несущественной.
но спустя небольшой период времени, чистый РП(без опыта разработки) погрузится в проект достаточно, что бы разница между ним и РП с опытом разработки была несущественной.
Спустя большой период времени, лет 5, управляя только IT командами использующими примерно один стек, думаю, да. Не меньше.
Какой уровень понимания проекта Вы ожидаете от РП? 5 лет это бОльшой срок, за это время можно и разработчика вырастить из вчерашнего студента.
Я уже 10 лет как техлид/архитектор. И в гробу я видал управление проектом.
Да и вообще, вы где-нибудь в серьезном месте видели должность PM/Architect ?????
p.s. Я даже совмещение архитектурной должности с тимлидской о-о-очень не люблю
Можно не совмещать, но иметь адекватный бэкграунд. Видел ПМ-а по банковским решениям с опытом ИТ-директора в нескольких банках и опытом разработчика. Вот там да, человек вменяемо мог и часы посчитать, и разработчикам всё объяснить, и заказчика размазать тонким слоем по столу и убедить в необходимости выделения бюджетов. Просто потому, что сам был на всех этих должностях.
В противном случае ПМ в лучшем случае будет играть роль секретарши, пригодной только организовать встречу заказчика с исполнителем.
вы где-нибудь в серьезном месте видели должность PM
Угу, в "Газпроме". У человека на визитке было написано
"Руководитель отдела планирования проектирования" :)
Да и вообще, вы где-нибудь в серьезном месте видели должность PM/Architect ?????
Называется Delivery Manager - помесь архитектора с проектным и ресурсным менеджером. Очень популярно нынче на западе. Нюанс заключается только в том, что хороших специалистов такого профиля я видел крайне мало, но это можно сказать в принципе про любую специальность.
У нас delivery был чем-то между scrum и pm без бюджета
я про реальность , а не то что на бумажке написано.
У каждого она своя эта реальность и бумажка своя. Я знаю крутых парней, которые могут и в архитектуру и в технику, и в проектный менеджмент, и в управление персоналом. Не всё идеально, но они одназначно хороши. И они кайфуют когда решают сложные задачи в какой бы сфере эти задачи не были. Но таких людей можно по пальцам токаря 6го разряда пересчитать.
Люто плюсую. Тут только одна проблема, если ты архитектор или разраб с помидорскими лычками (нормальными, а не сеньер ангуляр девелопер с 2 годами опыта), то тебе все эти должности квазиначальника не сдались совсем. Вертикаль власти в айти это натурально человеческая многоножка - хорошо тому только, кто сверху, остальные едят го**о. Лиды, ПМ, продакты, руководители департамента - это всё тот головняк, из-за которого технарь выбирает уютную разработку. Это те места, где за каждый $1 прибавки отымеют на $2, а то и на $3. А что потом на собесе будешь говорить? Как круто руко водил, как потел в зуме за всю команду? ))
В целом пусть берут кого берут, ковид показал, кого веслом под зад в первую очередь за борт)
Согласен, прибавка за начальничество относительно сеньорства мизерная а то и вообще убавка, тоже отбиваюсь - не приносит удовольствия процесс руководства. Иногда джунов наставляю и хватает.
А про ковид не понял - в основном как раз наоборот "балласт" нанимали.
Это может быть шагом к своему бизнесу, например. Потому что на одних технарских навыках далеко не уедешь, надо уметь продать себя и продукт, нужно уметь организовать разработку и добиться результата - а это как раз навыки хорошего ПМ.
А вот сочетая то и другое уже можно и на вольные хлеба идти, если есть желание.
Работаю РП уже болле 5 лет, только не IT. Всё что написано чистая правда. Книжки по управлению проектми уже читаю как фантастику, к реальности они не имеют никакого отношения. С опытом до меня дошло понимание что этои есть нормальное состояние в управлени проектами и что так будет всегда.
Я работал там где все по книге делалось. Ну в смысле вот глобальная корпорация на 300000 сотрудников по всему миру. Там спец люди переписали все pmbok в фирменные sop с учетом специфики закупочного процесса в компании и специфики индустрии. И все на местах, особенно в русской провинции, готовы может быть и забить и все делать лишь бы побыстрее, но сука несколько раз в год из Европы приезжают аудиторы и смотрят, как вы там следуете сопам и все ли проектные документы подготовлены и согласованы и если были изменения в проекте, соблюдена ли процедура чендж-контроля. Проекты делаются года по три, да.
Не путайте должность и профессию. Если в компаниях, где выработали, норм оставаться на рабочем месте до 11 часов вечера, в других это может быть не так.
Потому что в разных организациях в понятие ПМ вкладываются очень разные вещи. Где-то это человек который имеет полномочия и ресурсы в рамках своего проекта, а где-то (чаще) фактически администратор, который пытается уцелеть сводя концы с концами между перекрёстными требованиями заказчиков, стейкхолдеров, разработчиков и прочих важных людей.
Жму руку и подписываюсь под каждым словом!
Иногда РП напоминает свадебную лошадь, голова в цветах, а ж... па в мыле:)
Считаю, то ряд стрессовых проблем ПМа вытекает из того, что он думает, что он пришел на agile проекты. Руководство этого ПМа тоже так думает, нанимая agile-менеджера. А по факту - в компании иерархичная, с примесью матричной, структура. Все спецы в основном узкоспециализированны. Т.е. вам скорее всего придется работать по agile в компании, где этой гибкости особо и нет. Но есть ритуалы из скрама, канбана, создающие иллюзию гибкости. А на самом деле - лишь инструменты контроля. Чтобы клиенту легче было принимать решения, а начальство видело общую картину по проекту. Ведь не менеджер проекта решает, что делать, и даже не команда, а владелец продукта.
Может где-то и по-другому. В продвинутых продуктовых компаниях, где команда очень квалифицированна и имеет значительное влияние на принятие решений. Когда команда работает, выдает результат, а начальство думает, как ему распорядится этим результатом.
Иногда, у меня складывалось ощущение, что под agile во многих компаниях имеется в виду гибкость самого менеджера проекта))) Слуга трёх господ: клиента, начальства, команды. Как там это по-модному называется? Лидер-слуга?))
Согласен, сам думал примерно в том же ключе. Scrum сейчас это "стандарт" и если даже говоришь, что делаешь проекты не по Agile, а просто по классическому итеративно-инкрементальному подходу, то на тебя смотрят как на еретика, который оскорбил Бога Гибкости и втайне поклоняется идолу Водопада :) Но Скрам притом что он так широко распространен не стал серебряной пулей, которая решает все проблемы даже близко (такие надежды ходили в 2016-2017 годах, когда он появлялся в России), более того, он легко может при неправильном применении создать новые проблемы на ровном месте.
Насчет лидера-слуги улыбнуло, интересно было бы на широкой выборке узнать как и чего у РП / Скрам Мастеров происходит в реальности и как у них внутри их структур всё происходит.
Зачем вообще смешивать эти понятия. Проджект не нужен в Scrum по определению - там есть место только продакту и полнофункциональной команде. И продакт != проджект. У них сильно разные цели и методы. Хотя описанное в статье явно выдает боли и того и другого сполна. Просто потому что бизнес тоже в большинстве случаев сам себе не злобный буратино и ситуативно производит подмену понятий.
Я тоже не знаю зачем смешивать)) Может не понимают? Это нормальная ситуация.
Если не нужен проектный менеджер в скраме, значит нужен скрам-мастер. Но многие компании зачем-то же ищут проджекта. Наверное, потому что скрам-мастер != проджект? И по какому определению команде скрам нужен только продуктовый менеджер? Продуктовый менеджер начнет заниматься задачами проджекта? А кто его работу делать тогда будет? Или следует отдать все на откуп полнофункциональной команде? А кто в ней будет отвечать за сроки? Кто будет контролировать бюджет? Спринты планировать, ревью и ретро проводить? Фасилитировать на встречах, процессы улучшать. Фулстак разработчик? Сознательный аналитик? Тестировщик? Или все разом?)) Хотя… Точно! Команда же полнофункциональна, значит у нас каждый участник - это и жрец и на дуде игрец. Отвечать будут все! Т.е. никто. Ведь тот же скрам менеджер - не отвечает за проект.
P.s. В реальности таких супер команд почти не встречается. Только в продуктовых компаниях, где команда это творец (типа openAI в том периоде, когда она еще не превратились в коммерческий стартап, а была командой энтузиастов-исследователей)
Да хоть бы Гантта умели делать, понимая что это... И на том спасибо) шучу, на самом деле - всё по делу.
Все эти ужасы, слёзы, горящие задницы, адские переработки и нервные срывы - это спутники тех, кто не умеет работать.
Главная черта пм - это железобетонная самодисциплина и планирование. Если Вы не обладаете этими качествами/навыками - не ходите в ПМ.
В чём проблема? Есть задача от бизнеса. Бьём ее на релизы, на спринты итд. Если меняется требование от бизнеса, ну извините, придется подвинуть и спринт или перенести в другой. Надо уметь и бизнесу отвечать "нет" , когда они порят чушь. Иначе просто загонят и ПМ и команду и все разбегутся - и кому это надо?!
Проблема, видимо, в исполнителях
Конечно может быть у нас разный опыт, но в проектах к которым был причастен декомпозировать задачу до отдельных дискретных элементов-задач разработчику - на грани нереального. Ну или удвоит период проекта. Сначала программирование "на бумаге", а потом, при реализации - корректировки и переделки, так как "забыли про овраги".
Истина где-то посередине между водопадом и agile.
Если ПМ на своем проекте и заказчик, и разработчик, и на дуде игрец, то да, безусловно, железобетонная самодисциплина и планирование гарантируют успех. Во всех остальных случаях они разве что сберегут немного нервных клеток и помогут не усугубить и без того разваливающуюся ситуацию.
Соглашусь про дисциплину и планирование. Был опыт работы в команде, где продактов было 3 одновременно, руководство пыталось видимо количество перевести в качество. В результате было трое менеджеров, которые не понимают, что происходит и вносят неразбериху, вместо одного
Согласен с вами, но можете раскрыть акцент на необходимости железобетонной самодисциплины? Самодисциплина - всем нужна во взрослом возрасте. А "железобетон" ПМ зачем?
Если ПМ не проблемно - ориентированный, то успех в проекте возможен в случае сильной команды разрабов со своим лидом + сильной команды аналитиков со своим лидом + умение ПМа не лезть туда :-)
Да все проще - не надо сильно париться, просто разбираешься по ходу дела и всё. 100% если компания не мизерная , то будут и тех Лиды и Тим Лиды и другие, с кого можно спросить! Задача руководителя - создать вокруг себя команду ответственных и с них спрашивать
Верно. Нужно уметь делегировать, грамотно использовать имеющиеся ресурсы в виде доступных специалистов, тогда достаточно будет лишь выстроить процессы, с учетом реалий на местах, и следить чтобы эти процессы не развалились. И останется лишь роль координатора. Но на практике задача эта не простая, люди не любят изменений, и активно будут противодействовать попыткам выстроить процессы. Нужны крепкие нервы, упертость, навыки убеждения и ведения переговоров. Толковых руководителей немного, но у кого получается, те идут далеко и ярко.
Согласен. Я и сам не очень люблю когда руководитель навязывает изменения.. Надо собирать обратную связь с разрабов, пытаться им донести какую проблему мы решаем и почему предложенный вариант поможет ее решить..
Так считаю что нельзя сильно загонять разработчиков бесконечными задачами - они не роботы! Нужно обязательно учитывать дни "разгрузки", чтобы люди могли отдохнуть. Я жёсткий противник потогонки...
Я бы ещё добавила, что ПМ, хоть и не должен знать глубокие технические детали вся и всего, но должен уметь вникнуть (причём быстро) в какие-то детали, что бы иметь представления о дальшейшем планировании и, если необходимо, перепланировании.
Встречала коллег по цеху, которые реально считали, что их зона ответственности - раз в N дней собрать статус, поругаться (мягко или не очень), что что-то не в срок, и сидеть и ждать, что вот сейчас все будет как надо. И им как дятел повторяли - мы не можем это доделать пока вон те не сделают свой кусок, но нет, каждый раз одно и тоже - "не готово? Почему? А когда будет готово? А вы уверены, что вам надо их ждать? Ну ок.", и через неделю по новой.
А так да, ПМ чаще всего не всегда может влиять на состав команды. Из серии - работай с тем, что имеем. Да, эскалировать проблему с кем-то из команды можно (и порой нужно), но надо понимать, что никого не уволят просто потому что тебе трудно с человеком работать. А если чудо и произойдёт, то минус один человек в команде, пока не найдут нового, пока этот новый не войдёт в нужный тем работы. И все это дополнительная головная боль.
ИМХО ПМ должен обладать богатым жизненным опытом, умением договариваться с людьми, выявлять ключевых личностей в процессах, находить к ним подход, может становиться другом (вместе пиво пить и обсуждать начальство). Если действовать по протоколу, то это прямой путь к неудачам, тебе твои же коллеги начнут палки в колеса вставлять, не тот это путь.
"Войти в IT проджект менеджером" - невозможно.
Почему? Потому что это говно.
Я бывший проджект
У нас недавно поставили менеджера над двумя отделами, один какой-то фантомный, который состоит из одного человека,который и есть начальник в этом отделе и наш. Чел просто каждый день втыкает, сидит ничего не делает, часами может просто в дуолинго тыкаться. Всё по факту решает ,как и решал ранее, наш начальник, который теперь под этим менеджером по структуре. Иногда он проводит совещания, я не являюсь каким-то классным спецом, но я понимаю, что чел просто несёт какую-то чушь, пытается выглядеть будто что-то понимает, но нифига не понимает абсолютно.
Чел даже письма связанные с какими-то теми же финансовыми вопросами проекта не может составить для высшего руководства. Всё ему рисуем мы и наш начальник.
Чел как депутат, только воздух сотрясает, и дальше дел никуда не идёт. Перед тем как его утвердили, тоже много чего тут нёс, мы ему объясняли,что этого не будет, потому что это невозможно, и объясняли причины, но он говорил, что будет так как он решил.
Ну и как итог, чел же маленькие проблемы не у состоянии решать. Обидно,что при всё при этом он получает очень большую зп.
До этого он был на другом проекте,тоже в нашей компании, который закончился ничем.
Опять гуманитарием называют человека, не способного быть технарём. Но ведь такой обычно и гуманитарий так себе.
Сроки (особенно на важные для компании фичи) устанавливаются руководством и часто «несдвигаемые», чтобы им соответствовать приходится действовать креативно.
Под креативно, я так понимаю, сделать все "тяп-ляп", игнорируя мнение исполнителей по качеству такого труда ради своего KPI? Практически повсюду одно и тоже дерьмо с этими менеджерами, не имеющими серьезный тех. бэкграунд...
Очень хорошо это можно наблюдать на примере серьезных провалов с продажами множества технически сложных продуктов, когда ради попадания в "сроки" приносится в жертву либо функционал, либо что еще хуже - тестирование и отладка, из-за чего они становятся не конкурентно способными.
Хороший менеджер и старший по разработке, это в первую очередь люди, которые умеют определить такие сроки реализации, чтобы иметь серьезный запас. Тогда в случае нормального контроля за продуктом, если все шло без проблем, выпуск идет раньше сроков, что в т.ч положительно сказывается на премиях, т.к все идет по плану. Если вы или ваш начальник, не умеете в адекватную оценку сроков (что бесспорно часто сложная задача, но за это вам и платят много), то что вы вообще тут забыли?
P.S сам временами, будучи разрабом, промахиваюсь по срокам к сожалению, но поэтому то я и не лезу в управление, т.к задачка так просто в лоб не решается бывает ... особенно когда стоит вопрос о серьезном ресерче и использовании непроверенного софта (и об этом прямо говорится начальству), в котором недостаточно компетенций, документации, поддержки или всего сразу
Да, я со своими 5 детьми могла бы быть отличным проект менеджером оказывается) хотя бы зарплату за это получала бы))
Если человек не пишет код проекта хотя бы пару часов в день, то он не имеет права быть менеджером этого проекта, в противном случае он будет только всех раздражать.
Всем привет!
В ИТ пришел эникеем —> админил —>CIO - перехал в Спб—> зам. CIO—> РМ —> BDM
BDM - считаю логичным следующее развитие РМ. Тут либо в сейлы, либо в CIO.
Как считаете?
Считаем, что PM - это бездельники ничего не делающие, что даже эникейщики могут выполнять их функции и прочие случайные люди, например гуманитарии, не знающие таблицы умножения и никогда не видевшие компьютера. Тим лид должен быть руководителем, а PM должен быть в разряде обслуживающего персонала с зарплатой в разы меньше чем у программистов.
Я несколько раз разжигал этот огонь. Это непередаваемое ощущение!
Как раз отхожу от неудачного опыта работы (1 год) проджектом в небольшой айти-компании. Начинала с аккаунт-менеджмента, имея схожий пятилетний опыт в другой сфере. Считала себя стрессоустойчивой и прокачанной на кризис-манагерстве, не (!) без базовых знаний в разработке. В итоге выгорела в попытках соблюсти тот самый баланс, а проект, где заказчик оказался, мягко говоря, офигевшим, просто добил. Жаль, что всё ещё и усугубилось тем, что от руководства не было никакой поддержки (впоследствии только упрёки), а на сложном проекте попался фронтендер, за которым пришлось подчищать огромное количество гов... косяков. Теперь ловлю вьетнамские флешбеки и думаю о том, что менеджмент это вообще не моё, увы
Being a Project Manager is Easy. It's like riding a bike Except the bike is on fire and you are on fire and everything is on fire and you're in hell.
И если человеку не в кайф быть в таком аду, то и лезть туда нет особого смысла. Опыт в данной профессии появляется быстро, ошибки неизбежны. Главное любить постоянный пожар и уметь создавать из него годные продукты.
Я аналитик. Проджекты реально ни на что не могут повлиять, но это такие люди, которые должны быть постоянно в курсе всего и с пачкой разработанных мер как "такого" больше не допускать))
"Попугай научился говорить "ну что там?" и был повышен до проджект-менеджера. "
Работа проджекта -это синхронизация задач в команде + быть прокладкой между этой командой и остальными ,которые решают граничные задачи. Да ,это про так называемые софтскиллы ,но при хреновом понимании темы -разрабы и прочие ,своей и чужих команд -будут такого проджекта просто игнорировать .
Почему вам лучше не работать проджектом