Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

О плохих и хороших PM’ах

[Об авторе: Дима Малеев — в прошлом .NET Developer, сейчас пишет на JS. С 2014 года — директор Lviv Code School]

Давайте сразу к делу — хороших PM’ов мало. Их практически нет. За 10 лет, которые я в IT, на пальцах одной руки можно пересчитать PM’ов, с которыми я бы хотел попасть на еще один проект. Попасть к хорошему PM’у на проект — как найти подкову от мамонта. Сразу думаешь: «Нифига себе, так бывает?! Ах вот оно как может быть!». Это как найти женщину, которая хороша собой, вкусно готовит, может прекрасно поддержать беседу на практически любую тему и после которой на Сашу Грей смотришь как на выпускницу швейного техникума. Просто джекпот.

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

Плохой PM

Чтобы понять, что значит хороший PM, просто спросите программиста — что же делает менеджер на его проекте. Поверьте, в 80% ответов вы не услышите ничего, кроме: «Пишет письма, иногда с заказчиком говорит».

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

А огромная часть обязанностей PM’а — это наведение порядка в команде и слежение за ним. Чудес не бывает, потому программист-PM будет забывает высылать отчеты, записывать, о чем говорят на многочисленных митингах, следить за выполнением самого проекта. Зато когда проект близиться ко дну, он любит приходить в команду со словами: «Да я ж PM, и даже я понимаю, что это техническое решение — не верное. А ну, мальчишка, отодвинься, ща батя покажет как мы кодили лет 5 назад!» И медленно, но уверенно, размеренными нажатиями пальцев по клавиатуре начинает загонять последний гвоздь в гроб проекта. Парадокс в том, что самый крутой PM, из всех с которыми мне приходилось работать, — как раз выходец из программистов.

Работа над ошибками

Если вы видите хорошо выглядящего, отдохнувшего PM’а, который с оптимизмом смотрит в будущее и мило шутит — скорее всего, это провал.

Наша индустрия прощает очень многое людям, которые в ней работают. Особенно PM’ам. Суть проста:
— Провалил проект;
— Послушал, как его обкладывает письками руководство, руководство руководства и клиент;
— Скрылся за статистикой того, что 90% проектов в IT — провальные;
— Подбили итоги, определили, что программисты не допрограмировали, тестировщики не дотестировали, и вообще оценка проекта в самом начале была неправильная. А PM что? Ну да — не доследил, в следующем проекте буду умнее;
— Сделав выводы, PM всем говорит, что стал сильнее. И вообще ошибаться в нашей индустрии — это даже почетно. Потому как это знания, а знания — это опыт, а опыт не пропьешь;
— Начинаем следующий проект, делая вид, что помним былые шишки.

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

Утопить и вытащить

Одна из самых нелогичных ситуация в IT — это когда PM, о котором разработчики говорят, что с ним работать не возможно, внезапно добивается невиданных высот. Представьте ситуацию: есть проект, за которым не досмотрели. Докатился до дна. Пришел PM, начал кодить и даже выкопал небольшую ямку на дне. Менеджмент начинает разбор полетов, команда пашет на износ. Молитвами, матами и скотчем выкатывает проект в продакшен. Завершили — и слава Богу. В результате: у клиента осадочек остался, команда утомленная и все друг друга не любят, PM собирает уроки, которые, возможно, когда-то, да и начнет учитывать.

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

Понимаете? Чтоб показать что ты отличный менеджер — надо в начале проект утопить, а потом напрячь всех, чтоб проект выплыл.

Хороший PM

Кто ж тогда хороший PM? Когда-то я услышал фразу: «PM — это человек, который бегает команде за водкой». Фраза дурная, но отлично показывает то, чего хочет команда от PM’а. Главное в работе менеджера — не мешать работать. И не давать никому другому мешать работать.

Человек в компании — это ресурс. Даже позиция есть — ресурсный менеджер, вроде как с картошкой, но с людьми. Такой себе Лукашенко комнатного масштаба. Потому работа менеджера напоминает жизнь в коммунальной квартире. Прозевал, и у тебя уже пельмешков с кастрюли попробовали. Не заметил, не уследил — а твоего программиста уже забрали на другой проект, просто посмотреть, а вдруг чем поможет. Вот и работаешь в окружении, где сотрудников всем не хватает, и даже самого хворного могут утащить в лес. Есть еще клиент, который по поводу и без повода собирает митинги и в течении двух часов пытается выяснить, почему заданий на два часа в день меньше делается.

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

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

Хороших PM’ов мало. А плохие — плавучие. Еще и тренинги читают. Тьфу!

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

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

Схожі статті




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

Из наблюдений, о слабых менеджерах:

Его багтрекер не отражает реальность. Сотни тикетов висят незакрытыми «потому что». Workflow тикета не отражает процесса разработки. По этой причине PM часто подходит к девелоперу в неподходящий момент чтобы всего-лишь спросить «что ты делаешь». Не отпускает поработать дома («как же я проверю, что ты действительно работаешь?»). Присваивает результаты общего труда("за год моей работы у нас релизнулось, повысилось, улучшилось...«). Забывает или скрывает важную информацию — от клиентов утаивает опоздания по срокам, от команды утаивает реальные сроки, забывает задокументировать митинг, не делает публичными изменения в эстимейтах или требованиях. Давит авторитетом по всем вопросам, даже тем, которые заведомо находятся в компетенции других. Управляет реакционно — «пришло новое требование — быстро всё побросали и делаем его». Не делает попыток защитить команду от активного клиента с богатой фантазией на новые фичи. Считает, что в рабочем дне — 8 рабочих часов, не учитывает риски, не закладывает эстимейты на тестирование и рефакторинг, не учитывает в оценке «известные неизвестные» и «неизвестные неизвестные».

Если говорить о поняшах и единорогах, то сильный манагер:

Коммуникатор уровня 80. Знает 3 языка, умеет и любит говорить по телефону, емейлу, скайпу, языком жестов и дымовыми сигналами. Собирает требования, напрягает клиентов, аналитиков выдать максимум информации о проекте, напрягает команду проанализировать, задать вопросы. Доводит информацию до всех участников проекта. При этом следит за направлением коммуникации — не допускает чтобы решения от клиента шли прямо к разработчику («а сделай-ка быстро эту фичу быстро, но чтобы никто не узнал»). Устраняет ненужные связи и зависимости в коммуникации, не ограничивая горизонтальную коммуникацию.

Делает эстимейты, принимает решения вместе с командой и защищает мнение команды перед клиентом. Доверяет техническим решениям, предложенным командой. Команда видит, что эстимейты реалистичны и верит в успешное завершение проекта. Время отведенное на митинги планирует заранее, не дергая людей «срочно сейчас всё бросили и пошли митинговать».

Поддерживает документацию проекта в актуальном состоянии, форсирует стандарты документирования и правильный workflow в багтрекере. Состояние и фичи система всегда отражены в документации, утверждение «реализовано как описано, и описано как реализовано» в любой момент времени должно быть верным. Максимально документирует требования, митинги, эстимейты. Изменения требований и эстимейтов проводит не в одиночку, а с тимлидами и клиентом. Все ради того, чтобы все были «on the same page». Команда всегда знает что делать сегодня, завтра, через неделю-две.

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

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

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

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

Та не, то разве джекпот? Джекпот, это если она при этом еще и хороший PM (^o^)

Хороший PM — как подкова мамонта, очень меткое сравнение. Вкратце — от него должна быть польза, а не только видимость и СС в письмах. Девелоперам не хватает жесткости, чтобы отказывать PM-ам, когда те им говорят «не надо мыть руки перед операцией, надо по-быстрому». vashsovet.com.ua/...diki-nikolaj-pirogov.html

Было бы разумно, если бы PM был реально заинтересован в качестве проекта, а не только сроках, это сразу видно, когда он пытается устранить проблемы. Говнокодить со скоростью света могут «не только лишь все», рано или поздно надо расхлебать технический долг и добавить новую фичу уже не 4 часа, а 40ч и все вокруг недовольны «какие плохие девелоперы».

Если команда говнокодит под давлением сроков — будь готов к такому развитию событий. Каждую фичу добавить все дороже и проект может рассыпаться. Нужен долгосрочный живой проект — будь добр выделить время на рефакторинг, написание тестов, тот же investigation узких мест и bottle-neck-ов.

Last but not least — команда должна понимать, что делает что-то важное и нужное, а не просто отсижывает попо-часы, иначе проект полюбому уйдет в штопор.

Нельзя купить мерседес за 5 грн, но в ИТ-сфере все думают что можно.

Дима, какая-то печальная картина из аутсорсинга «в коротких штанах», где пм — смесь недо-скрам-мастера + официант + велосити-учетчик + говорящая голова с заказчиком.

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

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

Кстати, хороший пм не будет объяснять сотруднику, что компания любит и ценит именно его за то, что он клевый. Это вранье потом «вылезет боком» самоу пм-у. Задача тут объяснить, что компания зарабатывает вместе с сотрудником, и все эти кофе-с-плюшками, плей-стейшн, корпоративы, тренинги, медстраховки — это та часть, которую компания вкладывает в сотрудника в том числе потому, что сотрудник выполняет свою работу. На которую был нанят и за которую получает з/п.

Интересно, если PM начнут писать о хороших и плохих программистах...

181 коментар

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

Дефициц не только в хороших/опытных PM-ах, сейчас у опытного PMа выигрывает junior лишь только потому что у него advanced English VS intermediate у опытного!
У меня более 12 лет опыта и вот уже почти пол года, я не могу найти работу, а все ответы после многочисленных собеседований ровно укладываются на две стопочки, где в одной стопке «у вас не хватает английского», в другой «вы слишком оверскил и мы боимся что через два месяца вам станет у нас скучно»...
Поэтому я предпологаю что дефицит в культуре и целостном видении которое наши IT компании должны транслировать сваим заказчикам, потому как сейчас заказчик выбирает себе PM исключительно по уровню английского!
А тем кто посоветует мне учить английский, скажу спасибо, вы правы и вы наверняка знаете что это не месяц и не два, в течении которых вам нужно еще и что-то кушать кроме английского...

По описанию можно просто разделить проще на: РМ-ов и Скрам Мастеров, именно СМ являются помощниками команды и их обязанность следить, чтобы команде всего хватало.

хороший, плохой... вспоминается избитое: хороший человек — не профессия.
это все оценочные категории. При этом не объективные, а субъективные. Стильно одет, не грузит вопросами, понимает особенности кодирования — это бесплатные бонусы, не более.
А у профессионального ПМ (будь то скрам, аджил, канбан, просто водопад) есть его пресловутый треугольник «бюджет-сроки-расписание» и его производная ОГОВОРЕННОЕ содержание проекта (ну, или качество).
Если отклонение по этим граням «в пределах», то у вас ПМ с добавленной стоимостью на проекте, если нет, то это Муму, которому и камня на шею не нужно — сам утонет и вас утопит.

«основное различие плохого PM’а от хорошего — это то, что он часть команды, а не ее владелец.»
Не правда это всё. Ни то, ни другое. ПМ не должен быть просто частью команды или «своим парнем».
Он должен быть !главным!, но при этом уметь наладить коммуникацию (например с автором этой статьи) так, чтобы казалось, что он свой человек и чтобы все выполняли как надо свою работу и не чувствовали дискомфорта. Звучит конечно гротескно, но такова реальность.

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

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

Пропадать — вопрос. Тк пмы обычно помнят с кем они в будущем хотят иметь дело, а с кем — нет.

Я же по-русски написал вроде.

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

Интересно, если PM начнут писать о хороших и плохих программистах...

Отвечу кратко — для PM-ов не бывает плохих и хороших — бывают только эффективные и неэффективные :))

Дадада. Вообще-то классика управления проектами в сферическом вакууме — это набирать новую супер-кроссфункциональную команду под каждую задачу. А не пытаться при помощи врученных тебе сверху верстальщиков тащить джава энтерпрайз проект. Отсюда и растут ноги у «эффективности» и «неэффективности».

Вот ты, как программист, уже плохой. Ибо в твоем мозгу нет парадигмы «ошибаются все», есть только «ошибаются менеджеры». И я так подозреваю, то же касается QA, BA, HR и прочих, только не программистов, не так ли ? =)

Отвечу по

Какое отношение это имеет к

Самое прямое. Эффективными и неэффективными бывают не только ПМы, а еще и программисты. Точка. Если для тебя только

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

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

По относительным показателям. И потом, я, во-первых, сказал «крайне смутное», а не «никакого», а во-вторых, ПМов и прочей администрации — но не программистов =)

А я вот уже привык, что программисты, задавая вопросы, формулируют его как вопрос и в конце ставят соответствующий знак, а не — про себя подумал что-то, то же и написал, и, оказывается, ответа ждет =).

KPI работы команды, меня, отдельного программиста? Их есть у меня. Ты меня на работу сейчас собеседуешь? Нет. Соответственно, и ответа на этот вопрос я давать не буду.

Тарас, не стоит тратить свое время на энергетических вампиров, тролей, и прочих ни плохих ни хороших, ищущих только негатив блоггеров/форумчан. Для них есть своя ниша. Направьте свою энергию на улушение собственной и командной эффективности.

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

Просто утрировал. Более часто встречающаяся ситуация — когда тебе спускают разработчиков несоответствующего задаче уровня. А так, повторюсь — просто гипотетическая ситуация.

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

Если из девелоперов и тестировщиков РМ-ы «не оч», то из кого же выйдет достойный?

смотришь как на выпускницу швейного техникума.
что не так с выпускниками швейного техникума?

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

www.youtube.com/watch?v=1CmbsUkkNic

Довольно таки грустная статья. Судить по наличию не более чем 5 руководителей, да и при отсутствии опыта руководства у самого, довольно таки глупо. Просто хотя бы потому, что во многих фирмах отсутствует элементарная культура программирования. Например на собеседованиях спрашивают о SOLID, но по факту мало кто использует. Или TDD или еще чего. Зачастую ПМ находится между двух огней. С одной стороны на него давит руководство зачастую пытаясь необосновано ускорить процесс разработки, с другой тупое недовольство от разрабов, которые зачастую не воспринимают весь тот спектр психологической нагрузки. А так как у нас нету определенных критериев подготовки ПМ, то маємо те що маємо. Причем, по моим ощущениям, по бОльшей части нужна именно психологическая подготовка — чувствовать настроение клиента/начальства, чувствовать настроение в подконтрольном коллективе, знать когда стоит подчиниться, а когда продавить свою идею, вовремя понять и устранить недовольство. Не говоря о всяких там Фаулерах/Эвансах....

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

Очень познавательно, спасибо.

Во вашему, не выспавшийся, измученный 80 часовой седьмой рабочей неделей подряд, упоротый валеьянкой руководитель проекта способен принять трезвое взвешенное решение на непроверенных данных в сжатые сроки, и способен мотивировать команду?
(Не спорю есть и такие, но это единицы --- гвозди бы из таких людей делать)
Я бы из них не гвозди делал, а тихо душил по переулкам :-) Они создают ощущуение что такой график ВОЗМОЖЕН и он даст результат. В целом, на мой взгляд, правильнее сознательно сорвать несколько этапов, но согласовать с «бизнес-группой» нормальный график работы и объективные ресурсы. Любой подвиг является следствием слабой организации и планирования. Поэтому «измученный РП» должен спать и думать что изменить, а не принимато гениальные решения под лошадиной дозой транквилизаторов. Ну личное мнение конечно!

Давайте определимся :-) Я РП в Comodo на большом проекте :-) Я могу себя поставить на свое место легко :-) Я не говорю об умышленных срывах сроков, но я принципиально не вывожу команду на овертайм. Любой овертайм — ошибка менеджеров. Я готов принимать удар, но программеры должны работать по 6 эффективных часов и не больше.
Мне кажется что часть моей работы состоит в том чтобы объяснить реализовавшиеся риски, предвидеть их и показывать зависимость сроков от рисков.
Мне интересен мой проект и з/п не самоцель. Я предпочту рискнуть и создать конфликт на начальном этапе проекта, чем поддерживать «авралы» и завалить проект чуть позже :-)

Задержанная на 2 месяца з\п будет самое легкое последствие для вас и вашей команды

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

следует вести себя профессионально и не опускаться для детсадовского «не пустили гулять» --- «сломаю игрушку»

То есть, вы НЕ считаете профессиональным поведением своевременное предупреждение руководителя проекта о том, что поставленные сроки недостижимы (разумеется, после проведения всех необходимых расчётов и планирования)?

И если «ту сторону стола» при озвучивании этих предупреждений внезапно одолевает глухота, то, по-вашему, в этом виноват руководитель проекта?

кажется ты путаешь продуктовые компании и стартапы, которые хотят ими стать

Вы ваша команда совершает умышленную диверсию против компании

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

Как правило, это не диверсия, а неопытность руководителя, который на собственном опыте еще не прочувствовал, что сказать «нет» сразу обернётся меньшей болью, чем давать заведомо нереалистичные обещания.

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

Вы, очевидно, ни разу не встречались с ситуацией, когда срок действительно берётся «с потолка», и никакие расчёты ПМа, показывающие абсолютную нереальность этих сроков, никого не интересуют.

Голословное утвеждение.
Вам, коллега, апломб не жмёт?
17 лет только сроки «с потолка» и видел. Пока не начал делать расчеты сроков сам.

Здесь мне любопытно, что означает слово «пока». За мои 12+ лет опыта, руководитель проекта всегда делал расчёт сроков, более того — в двух сценариях: наиболее реалистичном и оптимистичном.

Но как это страхует от ситуации, когда по расчётам руководителя проекта получается, что проект будет делать пол-года полноценная команда из 5 человек, а большие боссы требуют, чтобы сделано было, образно говоря за четыре месяца тремя имеющимися в наличии джунами?

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

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

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

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

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

Программисты — люди достаточно безалаберные: забывают обновлять отчеты, трекать баги, оставлять комментарии в коде и еще кучу вещей, которые напрямую не связанны с программированием.
вот некоторые думают что это бред, а некоторые убеждаются что таки истина
Менеджмент начинает разбор полетов, команда пашет на износ. Молитвами, матами и скотчем выкатывает проект в продакшен. Завершили — и слава Богу. В результате: у клиента осадочек остался, команда утомленная и все друг друга не любят, PM собирает уроки, которые, возможно, когда-то, да и начнет учитывать.
Это категория неуспешных проектов для компании, когда побед ана проекте дается любой ценой, в часности — выгоранием команды. Особенно в крупных аутсорсинг компаниях с матричной структурой и активным ресурсным менеджментом, приближающим бенч к нулю.
Не заметил, не уследил — а твоего программиста уже забрали на другой проект, просто посмотреть, а вдруг чем поможет.
Ну не то чтобы просто так забрали, но бывает, что потребности другого проекта получили больший приоритет и бизнес-импакт

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

И еще — Leadership and Management надо различать и гармонично использовать в работе.

«Программисты — люди достаточно безалаберные: забывают обновлять отчеты, трекать баги, оставлять комментарии в коде и еще кучу вещей, которые напрямую не связанны с программированием.» — что за бред вообще. Вообще некоторые комментарии поумнее, чем сама статья)

Керував колись командою хоча б з десятка девелоперів?

Я сам дев, работал на разных проектах с разным количеством людей. Какая в этом разница.

Ох не везёт Вам с Project’ами...)))
Елена, а эта ситуация Вас преследовала на всех проектах и во всех компаниях (за over 5 лет-то опыта в разработках)?

Тут вот написали, что PM все-таки не руководитель проекта)

Очень полезный фидбек о менеджерах! Менеджер может становится лучше, только , если его команда ему говорит о том, что в его управлении не так. Если у команды и менеджера нет понимая и слаженности в работе, каждый проект будет тяжкий. В конце концов, каждый сотрудник — это человек, который может выручить менеджера (если тот затупил). Команду свою надо любить и тогда она будет только помогать!
Но, если команда молчит, значит все ок, менеджер просто душка )) Вот только какие-то непонятные обиды за глаза и просра**е сроки ))
В общем, полезно, хотя все индивидуально.

если его команда ему говорит о том, что в его управлении не так

Это называется так «не учите маму делать детей» :)

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

Зачем тогда ПМ если разработчики и без него знают как нужно делать его работу?

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

в таком случае все совсем иначе

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

И да и нет. Формализация процессов и большое количество формальных политик требуют их соблюдения, что повышает KPI безалаберности в сравнении с ситуацией, когда формальные процессы и политики отсутствуют. В итоге, в такой профессии чаще/легче выявить безалаберность.

В итоге, в такой профессии чаще/легче выявить безалаберность.

Среди электриков такого не выявишь, у них только одна (первая) попытка :(

Хороший РМ определяется очень просто — сколько успешных проектов у него за душой и сколько провальных. (и конечно с какой историей эти проекты, какие причины успеха и провала проектов, РМ должен знать всю историю проекта).

А в целом больше читать и работать :) и скилы будут улучшаться :)
www.pmi.org/...nance-practice-guide.ashx

Из наблюдений, о слабых менеджерах:

Его багтрекер не отражает реальность. Сотни тикетов висят незакрытыми «потому что». Workflow тикета не отражает процесса разработки. По этой причине PM часто подходит к девелоперу в неподходящий момент чтобы всего-лишь спросить «что ты делаешь». Не отпускает поработать дома («как же я проверю, что ты действительно работаешь?»). Присваивает результаты общего труда("за год моей работы у нас релизнулось, повысилось, улучшилось...«). Забывает или скрывает важную информацию — от клиентов утаивает опоздания по срокам, от команды утаивает реальные сроки, забывает задокументировать митинг, не делает публичными изменения в эстимейтах или требованиях. Давит авторитетом по всем вопросам, даже тем, которые заведомо находятся в компетенции других. Управляет реакционно — «пришло новое требование — быстро всё побросали и делаем его». Не делает попыток защитить команду от активного клиента с богатой фантазией на новые фичи. Считает, что в рабочем дне — 8 рабочих часов, не учитывает риски, не закладывает эстимейты на тестирование и рефакторинг, не учитывает в оценке «известные неизвестные» и «неизвестные неизвестные».

Если говорить о поняшах и единорогах, то сильный манагер:

Коммуникатор уровня 80. Знает 3 языка, умеет и любит говорить по телефону, емейлу, скайпу, языком жестов и дымовыми сигналами. Собирает требования, напрягает клиентов, аналитиков выдать максимум информации о проекте, напрягает команду проанализировать, задать вопросы. Доводит информацию до всех участников проекта. При этом следит за направлением коммуникации — не допускает чтобы решения от клиента шли прямо к разработчику («а сделай-ка быстро эту фичу быстро, но чтобы никто не узнал»). Устраняет ненужные связи и зависимости в коммуникации, не ограничивая горизонтальную коммуникацию.

Делает эстимейты, принимает решения вместе с командой и защищает мнение команды перед клиентом. Доверяет техническим решениям, предложенным командой. Команда видит, что эстимейты реалистичны и верит в успешное завершение проекта. Время отведенное на митинги планирует заранее, не дергая людей «срочно сейчас всё бросили и пошли митинговать».

Поддерживает документацию проекта в актуальном состоянии, форсирует стандарты документирования и правильный workflow в багтрекере. Состояние и фичи система всегда отражены в документации, утверждение «реализовано как описано, и описано как реализовано» в любой момент времени должно быть верным. Максимально документирует требования, митинги, эстимейты. Изменения требований и эстимейтов проводит не в одиночку, а с тимлидами и клиентом. Все ради того, чтобы все были «on the same page». Команда всегда знает что делать сегодня, завтра, через неделю-две.

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

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

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

Ваш комментарий на порядок ценнее оригинальной статтьи. +1

Может быть, но именно статья подтолкнула к откровениям :)

Очень крутой каммент! Но есть нюансы.

Делает эстимейты, принимает решения вместе с командой и защищает мнение команды перед клиентом.

Это можно применить к проектам, в которые вовлечено небольшое количество людей. Если проект крупный и много тим — уже не получится. Надо масштабироваться как-то.

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

За чей счет эти еффорты? Написание FDS очень времяемкий процесс. Если вы имеете ввиду, что ПМ сам свое время тратит на спецификацию, то это странно.

Видит разницу между интровертами и экстравертами — не трогает одних и шевелит других.

Когда уже меня перестанут тянуть в корову играть на всяких-разных корпоративах :(

Если проект крупный и много тим — уже не получится. Надо масштабироваться как-то.
Масштабироваться через иерархию, лучше общаться с 5 тимлидами, каждый из которых руководит 5 человеками, чем общаться с 30 разработчиками. Все сталкивались с ситуацией, когда организовать на поход в кино толпу из 5-8 человек еще можно, а из 10-15 уже сложнее на порядок.
За чей счет эти еффорты?
Если ПМ не поспевает, надо нанять помошника. Но делать эту работу нужно. Могу судить по опыту, эмпирически тксзкть — слишком часто видел ситуацию, когда неполная, устаревшая документация не просто бесполезна — она вредит проекту. Устаревшее состояние багтрекера скрывает истинное положение проекта («я думал ты уже закончил — а я думал это не моя куча тикетов»). Устаревшее состояние документации означает, что разработчик (особенно новый) может закодить что-то не работающее («я закодил как в доке написано» — «да там фигня написана, пойти у Васи спроси как надо, он недавно кодил похожее»). Устаревший план версий приведет к анархии на деплое («ты зачем вылил туда 3.1.2-alpha-V2, туда надо 3.3.1-uat-V3», «клиент ожидал увидеть А, а увидел Б»).

+ не существует.

Главное в работе менеджера — не мешать работать

Согласен.

«Руководить — это значит не мешать хорошим людям работать.»
―Сергей Петрович Капица
Человек в компании — это ресурс.
Это к сожалению подход 50-летней давности «там», но у нас еще долго будет «вроде как с картошкой, но с людьми» :((
Вот и тратит основное время на работе хороший менеджер на то, чтобы решить вопросы, которые можно решить самостоятельно, без команды
Я не вполне понял этой фразы: а какой смысл решать вышеперечисленные вопросы без команды? Как на меня, основная работа ПМ-а — это конфликт-менеджмент, разрешение х-вой тучи противоречий между заказчиком и командой, проектом и бизнесом, работником и компанией, между людьми на его проекте, между хотелками людей и суровой прозой жизни на проекте, etc. Вот и получается, что хороший менеджер — это тот, у кого таких менингитов минимум, т.е. ничто не мешает команде работать :)

правильней не конфликт-менеджмент, а риск-менеджмент — НЕдопущение и НЕдоведение до появления «issues»

Нет, риск-менеджмент — это отдельное; это важно, но как на меня в работе ПМ-а больше конфликтов чем рисков. Вы попробуйте изначально не доведите до появления противоречия между стремлением бизнеса заплатить минимальные налоги при максимальной прибыли, клиента — получить максимальное качество за минимальное время и бабло, работника наоборот — получить максимальное бабло за минимально время. Еще проще — попробуйте рассадить тим в комнате так, чтобы всем хватало света и не дуло в спину, или установить справедливый порядок дежурства при саппорте продукта :8)

Колеги, поправте, якщо помиляюсь.
З власного досвіду виокремив спостереження, що хорошим ПМом може стати людина яка все ж спробувала програмування, зікнулась із труднощами у розробці, і наприклад, як мінімум відчуває, підкреслюю, відчуває (а не просто розуміє) для чого потрібні юніт тести (функціональні, інтеграційні тд).
Далі, на якомусь моменті людина усвідомлює, що керувати процесами (дотягувати результат до 100%) а також налагодження групових комунікацій, разом із розумінням групової динаміки дається ефективніше аніж написання коду. Тож вирішує податись у менеджмент.

ПМ, який на «своїй шкурі» НЕ відчув з чим мають справи деви, може стати тренером для команди, яка тренера не потребує. Відсутність технічного бекграунду створюватиме перешкоди у комунікації. З іншої сторони людина повинна мати організаційні здібності, аби на собі не завязувати процеси які є виключно сферою розробника. Аби не вийшло ситуації, коли технічні завдання роздає ПМ, що має брак достатнього розуміння технологій проекту. Якщо все ж ПМ не має технічного бекграунду, то єдиним варіантом є виокремлення у команді Тімліда (або Tech ліда) і комунікувати з командою по техніних питаннях через вибрану персону.
З іншої сторони, проблема, коли ПМ сідає кодити сам, чудово описана у статті.

хорошим ПМом може стати людина яка все ж спробувала програмування
З мого досвіду, хорошим ПМ-ом частіше стає людина, яка працювала QA і вже має критичний погляд на програмування зі сторони :8)

Хорошему ПМу специфика индустрии мешать не должна.

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

Господа, я тут вижу очень много забавных комментариев:) Дайте объяснить: сама статья не может претендовать на статью — монолит, которая рассуждает обо всем со всеми деталями. Статья — глава книжки, создание которой является челенджем для меня в этом году. Там еще много всякого будет, и много размышлений про айти мир.

Максим Ищенко увидел статью в ФБ и предложил запостить в нашем уютном чятике. Я не являюсь ПМом, и сама статья просто мои наблюдения, и консьюмерские чуства того, чего хочет программист от ПМа на проекте:)

Спасибо за понимание.

Интересная статья. Плохой PM очень точно описан. И это наводит меня лишь на один вывод. «Плохой PM» на данный момент это стандарт IT индустрии в Украине. Хороший PM — это больше аномалия или исключительный случай.

С другой стороны. Дмитрий вроде и пишет, что такое «хороший PM», мол часть команды и не мешает работать. Но ведь это даже не прямые обязанности PMа. И «...отчеты, графики и танцы с огнями перед клиентом» тоже вроде как лишь малая часть задач, которые должен решать менеджер. Я описывал основные обязанности и роль PMа. Почитать можно тут: pmbasics101.com/...ies-of-a-project-manager

Но суть не в этом. Это очередная статья, которая говорит, что менеджер должен. Должен быть частью команды, понимать каждого работника и заботиться о нем, не мешать его работе. А что в этом аспектом должен работник?:) Работнику все мешают, даже менеджер...

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

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

Хороший PM — как хороший программист. Мало их. Но не будем сгущать краски.

Если пытаться натянуть рамки, можно обратиться к привычным местным лычкам, и транлитерировать заголовок: «О junior и senior PMах». Вроде понятнее стало. Как минимум, понятнее что между начинающими и гуру, съевшими большого лохматого мамонта, есть огромнейшая прослойка «мидлов» — и вот они есть стандарт индустрии.

Так что всё вполне неплохо.

Интересная статья. Плохой PM очень точно описан. И это наводит меня лишь на один вывод. «Плохой PM» на данный момент это стандарт IT индустрии в Украине. Хороший PM — это больше аномалия или исключительный случай.

Аутсорс в Украине растет несмотря ни на что, владельцы богатеют, эти владельцы зачем-то ПМ-ов нанимают, и не так чтобы много увольняют, хотя работа такая, что первый на вылет. Откуда вывод, что в Украине плохие ПМы? Вот Product Manager’ов не хватает, и это видно, потому что с продуктами все так себе.

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

Ох уж эти статьи про менеджеров ))
Действительно СССР уничтожил профессиональных управленцев как класс, заменив их паразитами и скользкими рыбами. Поэтому и появляются всякие мнения типа «без менеджеров было бы лучше».
На самом деле хороший PM = хороший менеджер + понимание IT процессов и технологий.
А вот кто такой «хороший менеджер» можно почитать у всяких известных американцев типа Ицхака Адизеса и Питера Друкера.

Может быть когда нибудь напишу статью об этом на ДОУ ))

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

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

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

Ни в коем случае. Я впитаю, как губка ту информацию, что ты сейчас поведаешь о классе профессиональных управленцев эпохи «до СССР». Даже друзьям буду рассказывать. Улыбаться будем вместе. Давай, жги, чертяка ))) Может, мы все что-то новое узнаем от человека, который совок знает по наслышке, но так пафосно глаголет ))))

Дружище, когда СССР развалился, тебе было 11 лет. Ты хочешь сказать, что знаешь совок не по наслышке? Видел, как там дела делались?
Ты знаешь, я люблю поспорить и будь у меня интересный оппонент, с удовольствием написал бы свое мнение. Но с тобой как-то не интересно.
Поменьше пафоса, дружище.

молодец, мальчик, насмешил ))))))) ожидания оправдал. что-то такое я от тебя и ожидал ))))

А я вот от тебя большего ожидал. Скучно.

уничтожил профессиональных управленцев как класс, заменив их паразитами и скользкими рыбами
Как-то мне повезло и украинские управленцы показали себя отлично, а вот некоторых их коллег из капиталистической Америки как раз можно назвать вышеуказанным термином.

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

А Уолтер оказался более успешнім ПМом чем Гус :)

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

в моєму досвіді програмісти в основному педанти, і проблема більше в тому, що інколи занадто педанти.

а взагалі, чисто суб’єктивно, мені здається, чим менше компанія надуває щоки перед клієнтами (читай — є люди з тайтлами «principal VP of delivery blabla bullshit»), тим менше там всякого корпоративного bs і процесів лизання задів начальства, тим більша імовірність здорового колективу і хорошого ПМа на проекті

У Вас очень интересный и не стандартный опыт (это я про педантичных и исполнительных программистов). Искренне завидую Вам!
Относительно бюрократии (что не всегда есть надувательство щёк) — все

bs і процес
’ы намного проще внедрить и откатать на этапе становления компании, чем “ломать” людей постфактум и загонять их в какие-то рамки. А рамки эти будут точно необходимы, как только компания пересечёт психологический рубеж в кол-ве сотрудников/комманд, до которых уже нельзя будет дотянутся руками.

Мне кажется вы говорите не о проджект менеджере а о тим лидере. PM вообще занимается бюджетами, перепиской, общением с топ менеджментом, проекцией целей компании на тим лидеров.

Если PM делает только это, то он не нужен. Тем более занятие такой абстрактной ерундой как <«blockquote> проекцией целей компании на тим лидеров» . Цель любой компании, за исключением благотворительных, рубить бабло, все остальное — мишура и средства достижения главной цели.

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

Та не, то разве джекпот? Джекпот, это если она при этом еще и хороший PM (^o^)

Та не, то разве джекпот? Джекпот, это если она при этом еще и хороший PM (^o^)
Вкусно это когда все в меру.....а если добавить больше, то или приторно или пересолено.....
и уже не вкусно....:)))
а если добавить больше, то или приторно или пересолено
согласна, пункт про «вкусно готовит» стоит изъять ;)
согласна, пункт про «вкусно готовит» стоит изъять ;)
где тут заныкались любителя борща.....:))))
....они будут не согласны :)

а по факту.....для женщины уметь готовить....must have :)))

потешил, однако) согласна, только с таким раскладом: если мужчина — в клубе 18+ (мы ж не за возраст, да?)) Otherwise...http://i.imgur.com/Lj19PZ2.jpg

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

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

долго точно не буду.
очень правильно :))))
который себе даже жрать приготовить не могёт)
он то может и могет.... :)))
но какой от фроляйн в доме профит, если все надо делать самому ? :)))
любофф приходит и уходит...:)))

тот же вопрос и к вам, сударь, — какой в вас профит? Оба работают, предположительно, что оба умные-прекрасные и талантливые аки порнозвезды, а как жрать готовить — то сразу Ж? Ну-ну, удачного плавания в океане иллюзий :Р

что оба умные-прекрасные и талантливые аки порнозвезды, а как жрать готовить — то сразу Ж
Вы путаете функции людей на работе и дома...:)))
То что Вы офигенно можете «тащить» работу..... дома на жаль не котируется :)))
Ну-ну, удачного плавания в океане иллюзий :Р
нет никаких иллюзий, кроме тех что Вы себе сами придумали :))))

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

тот же вопрос и к вам, сударь, — какой в вас профит?
видимо есть таковой :))))

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

нет никаких разборок :)))
обмен мнениями онли :)))
и по факту это не мне нужно кого то нанимать :)))

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

девушка тоже будет кричать ты ведь мужик если нужно будет гвозь забить или тв на стену прикрепить.
а так и есть.... просто у детей детские представления о семейной или совместной жизни.... видимо из Дом-2 :))))

а реальная жизнь......ОНА ВСЕМУ НАУЧИТ :)))

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

Хороший PM — как подкова мамонта, очень меткое сравнение. Вкратце — от него должна быть польза, а не только видимость и СС в письмах. Девелоперам не хватает жесткости, чтобы отказывать PM-ам, когда те им говорят «не надо мыть руки перед операцией, надо по-быстрому». vashsovet.com.ua/...diki-nikolaj-pirogov.html

Было бы разумно, если бы PM был реально заинтересован в качестве проекта, а не только сроках, это сразу видно, когда он пытается устранить проблемы. Говнокодить со скоростью света могут «не только лишь все», рано или поздно надо расхлебать технический долг и добавить новую фичу уже не 4 часа, а 40ч и все вокруг недовольны «какие плохие девелоперы».

Если команда говнокодит под давлением сроков — будь готов к такому развитию событий. Каждую фичу добавить все дороже и проект может рассыпаться. Нужен долгосрочный живой проект — будь добр выделить время на рефакторинг, написание тестов, тот же investigation узких мест и bottle-neck-ов.

Last but not least — команда должна понимать, что делает что-то важное и нужное, а не просто отсижывает попо-часы, иначе проект полюбому уйдет в штопор.

Нельзя купить мерседес за 5 грн, но в ИТ-сфере все думают что можно.

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

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

IMHO

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

Чудес не бывает, за все надо платить.

@Oleg Kariakin,
давайте всё-же разделять:
1)

вообще не выйдет в продакшен
Это будет действительно проблема менеджмента

2)

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

Впринципе, тема для обсуждения здесь очень глубокая:
Ведь стоит смотреть на проект в разрезе планов компании: если компания планирует «срубить бабла» и собственники/управленцы уверены, что сейчас зайдёт Проект Мечты, на котором и будет жить компания — то можно и подождать.
Если же компания понимает, что имидж компании, это не «HR Brand», а большой набор успешных References — то ждать нельзя и необходимо «вылизывать» каждый проект.

В любом случае любой проект зажат в рамки: Бюджет-Сроки-Качество, в которые и надо вписываться. Если раздувается одна сторона треугольника — страдают остальные. Вот тут и заключается мастерство PM’ов (причём как Project, так и Product Manager’ов) — балансировать на этих гранях.

Вы меня не слышите или намеренно не хотите понимать. Я как технический специалист честно предупреждаю: «проект уходит в штопор, are you OK with that? » Дальше идут ваши треугольники и прочией байки и сказки.

Олег,
я прекрасно Вас слышу и, как мне кажется, даже понимаю что Вы хотите мне донести.
Не хотелось бы переходить на личности (

треугольники и прочией байки и сказки
).
Задача любого PM’а недопустить ухода проекта в штопор и предупредить эту ситуацию. Но, ведь согласитесь, понятие штопора и цели проекта у нас может быть разным?
Вы, как значительная часть разработчиков — идеалистов видите цель в создании идеального продукта, но, очень часто, Заказчик не видит ценности в этом продукте и не разделяет Ваших идеалов. Я уверен, что с помощь зеркалки, ноутбука, ЖК-панели, игровой приставки и простого моб.телефона с большой батареей можно добится намного большего, чем с современным смартфоном. Но ведь многие выбирают смартфон?!? Этим многим достаточно 5″ экрана для просмотра FB и размещения там фотографий обработанных во встроенном редакторе...

Вы понимаете куда я Вас веду?

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

@Дмитрий,
простите, а какая часть моего сообщения натолкнула Вас на эту мысль:

А вы разработчиков оцениваете не по скорости набора?

:))))

З.ы. возможно тег <sarcasm> был упущен!?)

Я считаю, что кроме стремления к технической идеальности, всё-таки стоит не забывать о интересах «бизнеса». К сожалению, очень часто Заказчик не заинтересован «смотреть на шаг вперёд», а продавец не может «продать» ему это. В этой ситуации приходится
вот эта часть. В случае конфликта когда разработчики против а заказчик какраз за вы как я понимаю принимаете сторону заказчиков. Понимаете очень сложно работать с ПМ который находится в состоянии конфликта со своей технической командой. Предполагается что ПМ поддерживает ценности разрабов или по крайней мере понимает и принимает их.

Не совсем понятно о каком конфликте идёт речь.
Если конфликт связан с тем, что команда (а чаще кто-то «избранный») предлагает добавить в проект «блек-джек и шлюх», а ТЗ не предполагает этого и Заказчик уверен, что ему это не нужно — соответственно платить за это он не будет, то ДА, я встану на сторону Заказчика.

Если же в согласованном со всеми участниками проекта ТЗ написано, что нужен в проекте 5 карточный покер, а Заказчик, хорошенько подумав, уверяет, что Пасьянс намного увлекательней и будет пользоваться большей популярностью, при том, что 80% покера уже написано — то я встану на сторону команды и также буду ссылаться на ТЗ. НО я, конечно же, согласовав с командой, предложу Заказчику добавить ещё и Пасьянс в этот проект, но уже следующим этапом...

Есть ещё масса ситуаций, которые могут подразумевать разнообразные конфликты, но стоит помнить, что платит Заказчик — соответственно и окончательное решение всегда за ним. А изменения могут быть только путём согласования дополнений/изменений в ТЗ и проектной документации...

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

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

брррр....вот тут и я запутался)

Давайте по-порядку:
1)

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

вот тут не понял, если заказчик прав и команду всё удовлетворяет, зачем что-то кому-то предлагать?

2)

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

Если я Вас правильно понял, когда Вы говорите про PM’а, в этом абзаце, Вы подразумеваете команду?

3)

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

Этот абзац, если честно, совсем не понял :)

Простите что вам пришлось поставить знаки препинания.
1) Дискуссия началась с аргумента про говнокод под давлением менеджмента и вашу критику идеализации. Это предполагает неучтенные интересы команды разработки.
2)В случае конфликтных ситуаций

Говнокодить со скоростью света
и закрывать проекты с техническим долгом, переступая через себя.
IMHO
вы именно как ПМ предлагаете как я понимаю.
3)В дискуссии мы обсуждали проекты которые или не доходят до продакшена в принципе или работают с костылями. Возможно мы разные вещи предполагаем но редко в таких случаях редко виновен кто-то один из разработчиков и его «блекджек со шлюхами». Ну просто потому что он спросит как сделать правильно и ему помогут. P.S. В нашем случае мы с вами прямо противоречим друг другу и кто-то должен сказать что он не прав или конфликт будет продолжатся. Так же можем начать избегать взаимодействия или эскалировать конфликт. Скажем так. Разработчик, конечно, обязан сделать то что хочет ПМ но счастливым от этого он не будет.

Дмитрий,
мы противоречим друг-другу только в том, что смотрим на одни и те же понятия под разным углом.
Давайте остановимся на тезисах, которые мы, вроде как, принимаем и понимаем одинаково:
1) В провале любого проекта никогда не может быть виноват разработчик или команда. Вся ответственность лежит на PM’е. И если PM пытается спрыгнуть с этой ответственности — то грош цена такому руководителю проекта.
2) Разработчик или команда на проекте должны действовать в рамках правил, которые создаются PM’ом (естественно PM обязан обсудить и согласовать эти правила с каждым членом команды, для того чтобы «быть на одной волне»).
3) Счастье разработчик может искать в сторонних проектах, например OpenSource, но деньги то он зарабатывает в коммерческих — соответственно вынужден работать в рамках правил. Многим эти правила не нравятся, их можно и нужно изменять для достижения консенсуса, НО эти изменения не могут проводится в середине проекта, а должны обсуждаться на входе в проект...

Предлагаю сойтись хотя бы на этих пунктах:)

Дмитрий?

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

в говнокоде виноваты в 90% случаев сами разработчики, а фразы «не было времени сделать нормально» это обычная отмазка

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

какие юнит тесты? здесь даже нет времени спецификацию написать, а Вы говорите юнит тесты... все agile :)

вас на проекте заставляют палками писать гавнокод? или написание юнит теста карается увольнением?

добавить новую фичу уже не 4 часа, а 40ч и все вокруг недовольны «какие плохие девелоперы»
если ПМ окей с тем что новую фичу запилить 40ч, то если потратить дополнительный час на то чтобы код не был таким гавняным никто не умрет
в говнокоде виноваты в 90% случаев сами разработчики
остальные 10% это когда требуется запилить прототип «на поиграться/проверить», который не будет смержен в мастер ветку, оказывается что все же уже не прототип, а полноценная фича и ее нужно смержить в том виде в каком оно есть — тут уже вина лежит на эффективных менеджерах
вас на проекте заставляют палками писать гавнокод? или написание юнит теста карается увольнением?
В рабочее время разработчик должен делать то что говорит ПМ потому что часы оплачиваются. В нерабочее на чистом энтузиазме сложно вообще-то и опасно переутомлением

Да кто же сказал, что говнокод это всегда плохо!?
Ланос, как по мне, это худший из автомобилей доступных в Украине, но, посмотрите на статистику: nv.ua/.../48-avto-2015_ua_site.jpg

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

О плохих и хороших PM’ах
При этом на картинке к статье оба персонажа м*ки. =)

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

Дима, какая-то печальная картина из аутсорсинга «в коротких штанах», где пм — смесь недо-скрам-мастера + официант + велосити-учетчик + говорящая голова с заказчиком.

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

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

Кстати, хороший пм не будет объяснять сотруднику, что компания любит и ценит именно его за то, что он клевый. Это вранье потом «вылезет боком» самоу пм-у. Задача тут объяснить, что компания зарабатывает вместе с сотрудником, и все эти кофе-с-плюшками, плей-стейшн, корпоративы, тренинги, медстраховки — это та часть, которую компания вкладывает в сотрудника в том числе потому, что сотрудник выполняет свою работу. На которую был нанят и за которую получает з/п.

Оно то да. Только «не аутсорсинга» в нашей стране как-то мало. И что-то мне подсказывает, что с подходом наших властей, больше его не станет. Потому маемо шо маемо.

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

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

Интересно есть ли в Украине школа, где можно обучиться качественно менеджменту?

есть хороший знакомый, айтишник и препод, собирается в скором времени вести курс для ПМ — не только менеджерские лайфхаки, а давать понимание техскиллов, чем занимается каждый член команды на проекте

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

Вот еще такой блог недавно появился:
dou.ua/forums/topic/15853

Spider Ukraine (PMP), KMBS MBA (MBA)

хороший PM: пытается объяснить человеку, который всего лишь винтик в компании, что компания любит и ценит именно его
это совместно делают ШР и ресурсный менеджер по идее. Для проектного менеджера важен проект, а не ЧСВ программистов, которые на нем работают :)

Ну по хорошему статью стоит переименовать в «Что программист хочет от ПМа».

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

ну в общем ни а чем статья :)

Скорее чего не хочет

по-моему вы немного смешиваете team leading и project management
потому что на проекте может быть больше чем одна команда

ну замени «команда» на «команды» и все пофиксится

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

Привет:) Ну вообще это просто мои размышления, которые не претендуют на правильность во всем мире. Я в этом честно признался, что выражаю только потребительское отношение как участник команды:)

та мало ли что там написано не важно кем управлять одним человеком, командой или несколькими командами

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

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

почему-то те же скрам мастера постоянно вырождаются в менеджеров и забывают как открыть ИДЕ
потому что скрам мастер это не профессия
а программисты без пинка джиру(ралли) не апдейтят и на коллы к клиенту ходить не хотят
я такого еще не встречал

Текст приятный, но про чтение тренингов = хреновый ПМ было обидно

Ну зачем принимать близко к сердцу «просто размышления...» директора о тех далеко ушедших временах, когда он «был частью команды». Задним числом все умные, грамотные и правильные, все остальные — тлен. А так автор #просто_разместил_объяву.

а вот сейчас обидно стало, я так то до сих пор часть команды:)

Если обидел — прошу прощения. У меня просто чуйка на когнитивный диссонанс: если Вы часть команды, то позвольте спросить в какой роли Вы выступаете сейчас ??? ^_^

тим лид:) вообще это шуточные размышление писанные для книги:) но авторы ДОУ его в ФБ увидели, и попросили разрешения перепостить. Я понимаю что без контекста оно выглядит так, но в плане размышлений — имхо очень ок:)

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

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