Часто слышу от людей, которые только хотят войти в IT, что “если ты гуманитарий, а в QA идти не хочется, то есть один путь – в менеджеры проектов”. Им кажется, что рабочий день выглядит так: провел 2-3 встречи, выпил 3 чашки кофе, построил Гант, промотивировал команду и можно идти домой.
Я уже больше 10 лет работаю менеджером проектов и видел много коллег, которые бросали профессию и уходили заниматься всем чем угодно, только лишь бы потушить вечно горящую задницу. Я утешал рыдающих коллег-проджектов, меня выгоняли охранники из офисного здания заказчика с фонариками, потому что оно закрывалось в 11 вечера, а мне надо было еще работать.
Данная статья это попытка рассказать тем, кто хочет попробовать стать менеджером проектов о изнанке профессии и проблемах, с которыми вы точно столкнетесь и о которых лучше знать заранее.
Парадокс проджекта
На бумаге и на курсах по проектному управлению проджектов представляют адептами Святого Треугольника (бюджет/сроки/содержание), которые ежедневно управляют этими тремя составляющими и при этом неуклонно следят за Качеством — сердцем треугольника. Так‑то оно так, но зачастую проджекты в IT сталкиваются на практике со следующим:
Нет прямого контроля над бюджетом: вы получаете на него разработчиков (аутсорс или внутреннюю команду), но они не ваши подчиненные, у них есть свои начальники. Следствие: вы зачастую не можете заменить, уволить или депремировать сотрудника напрямую, и не всегда руководитель сотрудника будет на вашей стороне даже в случае срыва сроков.
Сроки (особенно на важные для компании фичи) устанавливаются руководством и часто «несдвигаемые», чтобы им соответствовать приходится действовать креативно.
Содержание имеет свойство раздуваться до невообразимых размеров, но уложить всё в сроки нельзя и нужно договариваться на конкретные фичи в MVP.
Это значит, что вы зачастую будете управлять на проекте всем, по факту не управляя напрямую ничем, придется много словом и делом пытаться удержать проект внутри граней треугольника. Особенно сложно, когда у вас мало опыта и вы тратите много времени на изучение инструментов и лучших практик управления проектами, многое приходится узнавать «на лету».
Поэтому не обольщайтесь насчет требованиям к профессии: если профессия не требует хард‑скиллов вроде программирования, то это автоматически означает высокие требования к софт скиллам и планированию.
Какие же вещи наиболее стрессовы и с которым точно столкнется начинающий проджект?
Неопределенность
Одна из главных задач руководителя проектов – уменьшать долю хаоса в системе, но вселенная будет постоянно подкидывать задачи: ваши разработчики будут болеть, приоритеты меняться, требования переписываться, задачи разрабатываться дольше, чем планировалась. На каждое проектное испытание нужно реагировать, искать решения, идти на компромиссы и зачастую конфликты с окружающими.
Я знаю людей, которые нервничают, если им надо выбрать бар на вечер, если вы один из них — в выборе карьеры подумайте еще раз:)
Чтобы управлять неопределенностью вы должны научиться: собирать непротиворечивые требования у бизнеса, писать подробные ТЗ, управлять ожиданиями заказчиков. Избавится от стресса совсем вряд ли получится, задумайтесь об регулярной физической активности в жизни, это очень сильно снижает напряжение.
Работа с командой и заинтересованными сторонами
Зачастую именно вы будете отвечать за успех проекта, а если учесть парадокс проджекта из пункта выше, то у вас не будет полного контроля над ситуацией.
С командой, особенно на первых этапах, скорее всего будут сложности. Команда ожидает от менеджера, что он будет максимально не допускать возникновения проблем: раздутых требований, радикального изменения требований, “горящих” сроков и всего того, что провоцирует стресс. Если вы решаете их проблемы, вас будут любить и уважать. Что для этого нужно: изучать процессы, искать способы их улучшить и внедрять совместно с командой, не забывая про хорошее планирование.
С заказчиком ситуация немного другая, потому что их интересы зачастую противоположны интересам команды разработки – сделать побольше в кратчайшие сроки и с возможностью изменения требований в любой момент времени. Если вы не будете укладываться в сроки или делать плохо, то будете иметь конфликты, вплоть до агрессивных разговоров (бывает и такое).
Чтобы разруливать всё грамотно, то нужно будет балансировать между интересами сторон, находить компромиссы, укреплять горизонтальные и личные связи со всеми участниками, налаживать процессы и устранять «узкие горлышки» в них. Очень поможет, если у вас есть прокачанные технические знания, что позволит доносить запросы заказчика сразу в нужной форме до разработчиков, так потери информации будут минимальны.
Знания в смежных областях
Очень часто придется заниматься не только управлением проектом, но и другими задачами и направлениями деятельности, включая изучение смежных областей знаний: дизайна, бизнес-анализа, аналитики и даже программирования. Нет, программировать не надо, но понимать основное необходимо: переменные, операции, отличать фронтенд от бекенда.
Специфика любой IT специальности – это как иностранный язык со своими терминами, грамматикой и логикой. Вы не сможете эффективно управлять людьми, если не сможете разобраться в этом хотя бы на базовом уровне. Приятный побочный эффект изучения иностранного языка: носителям будет приятно с вами общаться, отношение станет лучше, а результата будет достигнуть проще.
Развиваться в этом можно бесконечно, лучше всего читать/смотреть видео про предметные области и общаться со специалистами в процессе вашей работы, вникая в суть того что они делают.
Послесловие
Не думайте, что проджект – это легкий вход в IT, вам придется выучить много вещей помимо диаграммы Ганта, чтобы стать полноценным специалистом. Но с другой стороны, смотреть на работающий проект, на который потрачено несколько месяцев кропотливого труда десятков людей это зрелище на уровня горящего огня :)
Если у вас есть опыт работы проджектом и вы уже сменили профессию, либо наоборот, влюбились в неё еще больше – оставляйте комментарии, интересно послушать ваше мнение о профессии. А если хотели бы читать подобные материалы и немного больше, то присоединяйтесь к моему Телеграм каналу, будет познавательно и весело.
Комментарии (68)
scarab
10.10.2024 06:34Нормально руководить проектом может только техлид/архитектор, да и то - только если он вдобавок обладает навыками менеджера.
Только человек, который как видит весь проект целиком, так и понимает работу каждого фрагмента, может адекватно оценивать сроки, качество работы разработчиков, бюджеты, потребности. Если этого всего нет - РП превращается в говорящую куклу, вызывающую у всех досадливое отвращение: работы и так навалом, а тут ещё этот за штанину дёргает и чего-то клянчит. И единственная роль РП в этом случае - выступать мальчиком для битья в разговорах с заказчиком, да и то - только если заказчик технически неграмотен и сам не понимает происходящего.
BuHHTuK
10.10.2024 06:34Спорное утверждение. У тех.лида /архитектора своих дел тьма, а тут ему еще управление проектом накидывать... Если тех.лид /архитектор погружается в менеджерскую часть(планы, бюджеты, общение с заказчиком, со смежниками, отчетная часть и тд) месяца через 3-4 его экспертная составляющая просядет, а если еще и бюрократизации компании большая так вообще пу - пу - пу. Понятное дело, что на начальном этапе РП с опытом работы разработчиком будет эффективнее(больше понимает, меньше времени на коммуникации), но спустя небольшой период времени, чистый РП(без опыта разработки) погрузится в проект достаточно, что бы разница между ним и РП с опытом разработки была несущественной.
olezh
10.10.2024 06:34но спустя небольшой период времени, чистый РП(без опыта разработки) погрузится в проект достаточно, что бы разница между ним и РП с опытом разработки была несущественной.
Спустя большой период времени, лет 5, управляя только IT командами использующими примерно один стек, думаю, да. Не меньше.
BuHHTuK
10.10.2024 06:34Какой уровень понимания проекта Вы ожидаете от РП? 5 лет это бОльшой срок, за это время можно и разработчика вырастить из вчерашнего студента.
lnkiseleva
10.10.2024 06:34Не смотря на замануху обучающих курсов таки не из каждого студента можно вырастить разработчика.
olezh
10.10.2024 06:34Речь же об одинаковом уровне понимания проекта у ПМа без образования и тимлида перешедшего в ПМы?
Ivan22
10.10.2024 06:34Я уже 10 лет как техлид/архитектор. И в гробу я видал управление проектом.
Да и вообще, вы где-нибудь в серьезном месте видели должность PM/Architect ?????
p.s. Я даже совмещение архитектурной должности с тимлидской о-о-очень не люблю
scarab
10.10.2024 06:34Можно не совмещать, но иметь адекватный бэкграунд. Видел ПМ-а по банковским решениям с опытом ИТ-директора в нескольких банках и опытом разработчика. Вот там да, человек вменяемо мог и часы посчитать, и разработчикам всё объяснить, и заказчика размазать тонким слоем по столу и убедить в необходимости выделения бюджетов. Просто потому, что сам был на всех этих должностях.
В противном случае ПМ в лучшем случае будет играть роль секретарши, пригодной только организовать встречу заказчика с исполнителем.
Komrus
10.10.2024 06:34вы где-нибудь в серьезном месте видели должность PM
Угу, в "Газпроме". У человека на визитке было написано
"Руководитель отдела планирования проектирования" :)
Mephistophele
10.10.2024 06:34Да и вообще, вы где-нибудь в серьезном месте видели должность PM/Architect ?????
Называется Delivery Manager - помесь архитектора с проектным и ресурсным менеджером. Очень популярно нынче на западе. Нюанс заключается только в том, что хороших специалистов такого профиля я видел крайне мало, но это можно сказать в принципе про любую специальность.
pavelsc
10.10.2024 06:34Люто плюсую. Тут только одна проблема, если ты архитектор или разраб с помидорскими лычками (нормальными, а не сеньер ангуляр девелопер с 2 годами опыта), то тебе все эти должности квазиначальника не сдались совсем. Вертикаль власти в айти это натурально человеческая многоножка - хорошо тому только, кто сверху, остальные едят го**о. Лиды, ПМ, продакты, руководители департамента - это всё тот головняк, из-за которого технарь выбирает уютную разработку. Это те места, где за каждый $1 прибавки отымеют на $2, а то и на $3. А что потом на собесе будешь говорить? Как круто руко водил, как потел в зуме за всю команду? ))
В целом пусть берут кого берут, ковид показал, кого веслом под зад в первую очередь за борт)
Dmitry_604
10.10.2024 06:34Согласен, прибавка за начальничество относительно сеньорства мизерная а то и вообще убавка, тоже отбиваюсь - не приносит удовольствия процесс руководства. Иногда джунов наставляю и хватает.
А про ковид не понял - в основном как раз наоборот "балласт" нанимали.
scarab
10.10.2024 06:34Это может быть шагом к своему бизнесу, например. Потому что на одних технарских навыках далеко не уедешь, надо уметь продать себя и продукт, нужно уметь организовать разработку и добиться результата - а это как раз навыки хорошего ПМ.
А вот сочетая то и другое уже можно и на вольные хлеба идти, если есть желание.
AADogov
10.10.2024 06:34Работаю РП уже болле 5 лет, только не IT. Всё что написано чистая правда. Книжки по управлению проектми уже читаю как фантастику, к реальности они не имеют никакого отношения. С опытом до меня дошло понимание что этои есть нормальное состояние в управлени проектами и что так будет всегда.
masuk0
10.10.2024 06:34Я работал там где все по книге делалось. Ну в смысле вот глобальная корпорация на 300000 сотрудников по всему миру. Там спец люди переписали все pmbok в фирменные sop с учетом специфики закупочного процесса в компании и специфики индустрии. И все на местах, особенно в русской провинции, готовы может быть и забить и все делать лишь бы побыстрее, но сука несколько раз в год из Европы приезжают аудиторы и смотрят, как вы там следуете сопам и все ли проектные документы подготовлены и согласованы и если были изменения в проекте, соблюдена ли процедура чендж-контроля. Проекты делаются года по три, да.
GritsanY
10.10.2024 06:34Не путайте должность и профессию. Если в компаниях, где выработали, норм оставаться на рабочем месте до 11 часов вечера, в других это может быть не так.
Alex_Skosyrev Автор
10.10.2024 06:34Всё верно, я хотел подсветить то, что бывают и крайние случаи. Не знаю как сейчас у новичков проджектов, но когда я начинал работать в заказной разработке такое происходило довольно часто (из-за того, что ты еще по сути был тестировщиком, это было в дремучие десятые годы).
wolodik
10.10.2024 06:34Потому что в разных организациях в понятие ПМ вкладываются очень разные вещи. Где-то это человек который имеет полномочия и ресурсы в рамках своего проекта, а где-то (чаще) фактически администратор, который пытается уцелеть сводя концы с концами между перекрёстными требованиями заказчиков, стейкхолдеров, разработчиков и прочих важных людей.
Alex_Skosyrev Автор
10.10.2024 06:34Да, всё абсолютно так. Это важно понимать и прямо на собеседовании выяснять какая степень влияния на процессы и ресурсы будет, потому что везде ситуация уникальна.
Ansapo
10.10.2024 06:34Жму руку и подписываюсь под каждым словом!
Иногда РП напоминает свадебную лошадь, голова в цветах, а ж... па в мыле:)
WebPeople
10.10.2024 06:34Считаю, то ряд стрессовых проблем ПМа вытекает из того, что он думает, что он пришел на agile проекты. Руководство этого ПМа тоже так думает, нанимая agile-менеджера. А по факту - в компании иерархичная, с примесью матричной, структура. Все спецы в основном узкоспециализированны. Т.е. вам скорее всего придется работать по agile в компании, где этой гибкости особо и нет. Но есть ритуалы из скрама, канбана, создающие иллюзию гибкости. А на самом деле - лишь инструменты контроля. Чтобы клиенту легче было принимать решения, а начальство видело общую картину по проекту. Ведь не менеджер проекта решает, что делать, и даже не команда, а владелец продукта.
Может где-то и по-другому. В продвинутых продуктовых компаниях, где команда очень квалифицированна и имеет значительное влияние на принятие решений. Когда команда работает, выдает результат, а начальство думает, как ему распорядится этим результатом.
Иногда, у меня складывалось ощущение, что под agile во многих компаниях имеется в виду гибкость самого менеджера проекта))) Слуга трёх господ: клиента, начальства, команды. Как там это по-модному называется? Лидер-слуга?))
Alex_Skosyrev Автор
10.10.2024 06:34Согласен, сам думал примерно в том же ключе. Scrum сейчас это "стандарт" и если даже говоришь, что делаешь проекты не по Agile, а просто по классическому итеративно-инкрементальному подходу, то на тебя смотрят как на еретика, который оскорбил Бога Гибкости и втайне поклоняется идолу Водопада :) Но Скрам притом что он так широко распространен не стал серебряной пулей, которая решает все проблемы даже близко (такие надежды ходили в 2016-2017 годах, когда он появлялся в России), более того, он легко может при неправильном применении создать новые проблемы на ровном месте.
Насчет лидера-слуги улыбнуло, интересно было бы на широкой выборке узнать как и чего у РП / Скрам Мастеров происходит в реальности и как у них внутри их структур всё происходит.
AlexDestiny
10.10.2024 06:34Зачем вообще смешивать эти понятия. Проджект не нужен в Scrum по определению - там есть место только продакту и полнофункциональной команде. И продакт != проджект. У них сильно разные цели и методы. Хотя описанное в статье явно выдает боли и того и другого сполна. Просто потому что бизнес тоже в большинстве случаев сам себе не злобный буратино и ситуативно производит подмену понятий.
TheActiser
10.10.2024 06:34Да хоть бы Гантта умели делать, понимая что это... И на том спасибо) шучу, на самом деле - всё по делу.
Scott_Leopold
10.10.2024 06:34Все эти ужасы, слёзы, горящие задницы, адские переработки и нервные срывы - это спутники тех, кто не умеет работать.
Главная черта пм - это железобетонная самодисциплина и планирование. Если Вы не обладаете этими качествами/навыками - не ходите в ПМ.
themen2
10.10.2024 06:34В чём проблема? Есть задача от бизнеса. Бьём ее на релизы, на спринты итд. Если меняется требование от бизнеса, ну извините, придется подвинуть и спринт или перенести в другой. Надо уметь и бизнесу отвечать "нет" , когда они порят чушь. Иначе просто загонят и ПМ и команду и все разбегутся - и кому это надо?!
Stiger_slan
10.10.2024 06:34Конечно может быть у нас разный опыт, но в проектах к которым был причастен декомпозировать задачу до отдельных дискретных элементов-задач разработчику - на грани нереального. Ну или удвоит период проекта. Сначала программирование "на бумаге", а потом, при реализации - корректировки и переделки, так как "забыли про овраги".
Истина где-то посередине между водопадом и agile.
ElDark
10.10.2024 06:34Если ПМ на своем проекте и заказчик, и разработчик, и на дуде игрец, то да, безусловно, железобетонная самодисциплина и планирование гарантируют успех. Во всех остальных случаях они разве что сберегут немного нервных клеток и помогут не усугубить и без того разваливающуюся ситуацию.
lnkiseleva
10.10.2024 06:34Соглашусь про дисциплину и планирование. Был опыт работы в команде, где продактов было 3 одновременно, руководство пыталось видимо количество перевести в качество. В результате было трое менеджеров, которые не понимают, что происходит и вносят неразбериху, вместо одного
Stiger_slan
10.10.2024 06:34Согласен с вами, но можете раскрыть акцент на необходимости железобетонной самодисциплины? Самодисциплина - всем нужна во взрослом возрасте. А "железобетон" ПМ зачем?
duke_alba
10.10.2024 06:34Если ПМ не проблемно - ориентированный, то успех в проекте возможен в случае сильной команды разрабов со своим лидом + сильной команды аналитиков со своим лидом + умение ПМа не лезть туда :-)
themen2
10.10.2024 06:34Да все проще - не надо сильно париться, просто разбираешься по ходу дела и всё. 100% если компания не мизерная , то будут и тех Лиды и Тим Лиды и другие, с кого можно спросить! Задача руководителя - создать вокруг себя команду ответственных и с них спрашивать
0x131315
10.10.2024 06:34Верно. Нужно уметь делегировать, грамотно использовать имеющиеся ресурсы в виде доступных специалистов, тогда достаточно будет лишь выстроить процессы, с учетом реалий на местах, и следить чтобы эти процессы не развалились. И останется лишь роль координатора. Но на практике задача эта не простая, люди не любят изменений, и активно будут противодействовать попыткам выстроить процессы. Нужны крепкие нервы, упертость, навыки убеждения и ведения переговоров. Толковых руководителей немного, но у кого получается, те идут далеко и ярко.
themen2
10.10.2024 06:34Согласен. Я и сам не очень люблю когда руководитель навязывает изменения.. Надо собирать обратную связь с разрабов, пытаться им донести какую проблему мы решаем и почему предложенный вариант поможет ее решить..
Так считаю что нельзя сильно загонять разработчиков бесконечными задачами - они не роботы! Нужно обязательно учитывать дни "разгрузки", чтобы люди могли отдохнуть. Я жёсткий противник потогонки...
zuekliza
10.10.2024 06:34Я бы ещё добавила, что ПМ, хоть и не должен знать глубокие технические детали вся и всего, но должен уметь вникнуть (причём быстро) в какие-то детали, что бы иметь представления о дальшейшем планировании и, если необходимо, перепланировании.
Встречала коллег по цеху, которые реально считали, что их зона ответственности - раз в N дней собрать статус, поругаться (мягко или не очень), что что-то не в срок, и сидеть и ждать, что вот сейчас все будет как надо. И им как дятел повторяли - мы не можем это доделать пока вон те не сделают свой кусок, но нет, каждый раз одно и тоже - "не готово? Почему? А когда будет готово? А вы уверены, что вам надо их ждать? Ну ок.", и через неделю по новой.
А так да, ПМ чаще всего не всегда может влиять на состав команды. Из серии - работай с тем, что имеем. Да, эскалировать проблему с кем-то из команды можно (и порой нужно), но надо понимать, что никого не уволят просто потому что тебе трудно с человеком работать. А если чудо и произойдёт, то минус один человек в команде, пока не найдут нового, пока этот новый не войдёт в нужный тем работы. И все это дополнительная головная боль.
Faxfox
10.10.2024 06:34ИМХО ПМ должен обладать богатым жизненным опытом, умением договариваться с людьми, выявлять ключевых личностей в процессах, находить к ним подход, может становиться другом (вместе пиво пить и обсуждать начальство). Если действовать по протоколу, то это прямой путь к неудачам, тебе твои же коллеги начнут палки в колеса вставлять, не тот это путь.
Zhmirka_Pupirka
10.10.2024 06:34У нас недавно поставили менеджера над двумя отделами, один какой-то фантомный, который состоит из одного человека,который и есть начальник в этом отделе и наш. Чел просто каждый день втыкает, сидит ничего не делает, часами может просто в дуолинго тыкаться. Всё по факту решает ,как и решал ранее, наш начальник, который теперь под этим менеджером по структуре. Иногда он проводит совещания, я не являюсь каким-то классным спецом, но я понимаю, что чел просто несёт какую-то чушь, пытается выглядеть будто что-то понимает, но нифига не понимает абсолютно.
Чел даже письма связанные с какими-то теми же финансовыми вопросами проекта не может составить для высшего руководства. Всё ему рисуем мы и наш начальник.
Чел как депутат, только воздух сотрясает, и дальше дел никуда не идёт. Перед тем как его утвердили, тоже много чего тут нёс, мы ему объясняли,что этого не будет, потому что это невозможно, и объясняли причины, но он говорил, что будет так как он решил.
Ну и как итог, чел же маленькие проблемы не у состоянии решать. Обидно,что при всё при этом он получает очень большую зп.
До этого он был на другом проекте,тоже в нашей компании, который закончился ничем.
0x131315
10.10.2024 06:34Без обид, но это уже попахивает коррупцией. Очень странно что за него еще и кто-то его работу делает.
aamonster
10.10.2024 06:34Опять гуманитарием называют человека, не способного быть технарём. Но ведь такой обычно и гуманитарий так себе.
CalcuJIator
10.10.2024 06:34Сроки (особенно на важные для компании фичи) устанавливаются руководством и часто «несдвигаемые», чтобы им соответствовать приходится действовать креативно.
Под креативно, я так понимаю, сделать все "тяп-ляп", игнорируя мнение исполнителей по качеству такого труда ради своего KPI? Практически повсюду одно и тоже дерьмо с этими менеджерами, не имеющими серьезный тех. бэкграунд...
Очень хорошо это можно наблюдать на примере серьезных провалов с продажами множества технически сложных продуктов, когда ради попадания в "сроки" приносится в жертву либо функционал, либо что еще хуже - тестирование и отладка, из-за чего они становятся не конкурентно способными.Хороший менеджер и старший по разработке, это в первую очередь люди, которые умеют определить такие сроки реализации, чтобы иметь серьезный запас. Тогда в случае нормального контроля за продуктом, если все шло без проблем, выпуск идет раньше сроков, что в т.ч положительно сказывается на премиях, т.к все идет по плану. Если вы или ваш начальник, не умеете в адекватную оценку сроков (что бесспорно часто сложная задача, но за это вам и платят много), то что вы вообще тут забыли?
P.S сам временами, будучи разрабом, промахиваюсь по срокам к сожалению, но поэтому то я и не лезу в управление, т.к задачка так просто в лоб не решается бывает ... особенно когда стоит вопрос о серьезном ресерче и использовании непроверенного софта (и об этом прямо говорится начальству), в котором недостаточно компетенций, документации, поддержки или всего сразу
Anastasia_Oko
10.10.2024 06:34Да, я со своими 5 детьми могла бы быть отличным проект менеджером оказывается) хотя бы зарплату за это получала бы))
Dmitry_604
10.10.2024 06:34Уважение, это реально работа похлеще этих наших айти, бездетным не понять. Мне (и жене в большей степени) двоих за глаза. :)) Мне кажется 5 детей - это уровень "детского" CTO уже а не какого-то PM.
Konstantin1978
10.10.2024 06:34Если человек не пишет код проекта хотя бы пару часов в день, то он не имеет права быть менеджером этого проекта, в противном случае он будет только всех раздражать.
AngryWhack
10.10.2024 06:34Всем привет!
В ИТ пришел эникеем —> админил —>CIO - перехал в Спб—> зам. CIO—> РМ —> BDM
BDM - считаю логичным следующее развитие РМ. Тут либо в сейлы, либо в CIO.
Как считаете?
rinace
Я таких манагеров - каждый день вижу.....
Классически - подписываюсь под каждым словом.
Сорри, не могу яростно заплюсовать. Но если хоть один из , выбирающий путь в IT прочтет , задумается и решит не выбрать путь менеджера проектов - спасибо и от меня лично.
Я вообще не понимаю - как можно назначать на управляющие должности неженатых/незамужних/etc. вчерашних выпускников ускоренных курсов ? Но это сплошь и рядом и уже тренд.
Результат предсказуем - **** **** и в продакшн (с)
AndreySitaev
Не рожал - не ПМ?
А можно без штампа в паспорте, но состоящему в отношениях?
BuHHTuK
Тогда только Scrum-master'ом))))
Hardcoin
Не умеешь договариваться с детьми, как сможешь с разработчиками?
Shersh
А вы уверены что с взрослыми людьми надо договариваться также как с детьми?
А это работает в обратную сторону? Если я могу договориться с разработчиком, то я хороший семьянин и воспитатель?
Hardcoin
Да. Если уж смог понянчить разработчиков, то с детьми проблем вообще не будет.
Сарказм работает и в обратную сторону, конечно.
Perfecti-ist
А кто сказал что разработчики взрослые люди?
DummyBear
Скажу так, когда у меня появились дети, я начал гораздо лучше договариваться с коллегами. Потому что с одной стороны, после детей с ними проще. А с другой - дети дают чистейшие, как в учебниках, эмоциональные реакции, и начинаешь видеть их у взрослых людей тоже.
zuekliza
Ну вообще я могу сказать, что опыт работы ПМ с, как один же мой коллега и высказался, капризными айтишниками (с опытом мидл +), более чем замечательно вывезла работу с ребёнком на руках (в декрете не сидела). Тут речь не только о договориться с ребёнком, а в целом иметь хорошую стресоустойчивость и оперативно переигрывать планы, когда вокруг неопределённость.
aamonster
Если вы можете договориться с разработчиком – вы умеете пасти котов.
SunnyUnwon
Я бы уточнила: нужно уметь договариваться не с просто детьми (у каждого возраста свои прелести), а с подростками. Это особая категория. И на своем опыте я вижу, что мальчики-разработчики выходят из подросткового возраста примерно к 31-32 годам. До этого они мало чем по степени вредности и суждений отличаются от шестнадцатилеток. И тогда при управлении приходится давить, пусть и мягко, пусть и с подробным объяснением, зачем нам нужно выполнить то или иное действие. Особенно интересно смотреть, как эти великовозрастные подростки взрослеют на твоих глазах, и с каждым годом приходится объяснять все меньше, зачем и почему.
Впрочем, иногда я чувствую себя и воспитателем из детского сада.
aamonster
Не выходим :-)
Fenzales
Разве все родители умеют договариваться с детьми? :)
ExternalWayfarer
Я вообще не понимаю, как можно допускать в IT родившихся в СССР?
(Аналогия намеренно такая же тупая, без негатива)
Komrus
Старшее поколение, получившее ИТ образование в СССР годы так в 1970е, работавшее в ВЦ, а в 1990х - открывавшее ИТшные внедренческие и программистские кооперативы - смотрит на Ваше высказывание с недоумением...
Gryphon88
ну вы б еще сказали, что перед работой над проектом команда с ПМом должны совместно переклеить обои с минимумом излишков материала, при это не передраться и не более, чем с 3 поездками в магазин за стройматериалами и инструментами :)
Dmitry_604
Кстати, если подумать, это было бы неплохим тимбилдингом, и пониманием способны ли люди сработаться в нестандартных ситуациях.
Gryphon88
Тимбилдинг неплохой, совместный ремонт, особенно долговременный, один из самых коротких путей к разводу, я просто к тому, можно придумать что-то не менее безумное и не относящееся к разработке, но все равно более релевантное, чем опыт брака у ПМа.
Dmitry_604
Так то да, натягивать сову, в виде договороспособности с членами семьи на навыки ПМ это странно, конечно, но какие-то софт скиллы прокаиваются, факт :)
А по поводу ремонта и жены - хорошая проверка на прочность, если ремонт ставит на грань развода так может и нужен такой брак на долгосрок. Хотя когда он прямо на годы растягивается вялотекуще - это я бы скорее от такого сбежал первый :)