PM-весна в Днепропетровске

Кто был, тот знает, а кто не попал, тем не менее, может собрать впечатления о прошедшем мероприятии от участников #Dnepr PM club.

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

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

Спасибо информационному партнеру Ruby Garage и Владимиру Воробьеву, в частности, за расширение нашего менеджерского сознания. Владимир выступил для всех с презентацией об идеологических принципах компании Yammer и организации работы их PO. Англичане не перестают нас удивлять своими жизненными и профессиональными принципами и у них, однозначно, есть чему поучиться. Впечатляющими оказались принципы тотального доверия, неограниченной свободы и высокого уровня самоорганизации и ответственности, как обратной стороны осознанного менеджмента.

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

1. Работа с требованиями: сбор, анализ, предварительные переговоры с клиентом;
2. Распределение задач и контроль их выполнения;
3. Формирование команды: отбор и найм специалистов.

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

Судя по тому, как выступали Алексей Черноволод, Клавдия Заика, Дмитрий Бочоришвили, Виктор Сергиенко, Максим Копейка, Кирилл Зотин, независимо от отсутствия или наличия у них технического опыта, менеджеры в IT стараются опираться на свои сильные стороны и разносторонне повышают свою менеджерскую экспертизу.

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

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

Фото с прошедшего мероприятия можно посмотреть здесь.

Участвовать в онлайн дискуссиях и отслеживать анонсы последующих
мероприятий сообщества возможно, присоединившись к закрытой FB группе:
www.facebook.com/groups/dpmanagers

До новых ближайших встреч!

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Тема 23-х летних ПМ-ов не раскрыта. ;-)

Интересный диалог и аргументы. Если смотреть в уровни оценки зрелости компании/проекта по рекоммендациям CMMI: нетехнический ПМ на проекте — +1, технический ПМ на проекте тоже +1. Другой вопрос в том, потянет ли бюджет проекта двоих ПМов. В случае средних и больших проектов — да, в случае маленьких — нет.
Опять таки, возьмем пример классической маленькой аутсорсинговой компании, где на ПМа навалено куча потоков информации и действий, привязанных к разным проектам. Справится с ним техничский ПМ при наличие 5, 10, 15 одновременных проектов? Скорее всего нет, а для классического ПМа — это опыт и перспектива переквалификации в programm manager. С другой стороны — интересно ли классическому ПМу сидеть на одном проекте? Нет, с точки зрения операционной активности и получения качественного опыта. Это более подходит для технического ПМа.
Поэтому оценки "лучше"/"хуже", как по мне, неуместны — каждый должен делать ту работу, в которой у него больше опыта, и это определяется в каждом индивидуальном случае непосредственно процессом и/или проектом.

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

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

Если интересно послушать аргументы из первых рук, добро пожаловать в наше сообщество!Присоединяйтесь к нашей группе в Fb www.facebook.com/...ups/dpmanagers

«Технический бекграунд ПМ: помогает или мешает?»
Серьезно? Хотел бы послушать аргументы о «мешает». Равносильно:
«Знания технического устройства автомобиля, помогают водителю или мешают?».
ПМ без тех. бекграунда для меня вообще что-то из области фантастики.

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

В приведенных двух комментах-аргументах ниже, я лично не вижу ничего, что говорило бы о том что наличие «технического опыта» хуже, чем его отсутствие.
Вы написал о каких-то потенциальных ошибках человека на этой позиции (да и впринципе).
Эти ошибки (как и многие другие) никакого отношения к аргументам не имеют, ИМХО.
Можно написать сотни ошибок, которые может допустить человек и без тех. опыта, и не зависимо нет.
Любой PM должен иметь технический безграунд. Его отсутвие — катострофа (или уже сейчас, или через пару месяцев жизни проекта)
PM — это человек, который на одном языке говорит и с заказчиком, и с командой, и с боссами (старшими менеджерами, например).
Если он может говорить на одном языке только с одной стороной — он плохой ПМ и именно из них вырастают «ничего не делающие и только мешающие ПМ-ы, которые проводят тупые и бессмысленные митинги» в глазах программистов и других членов команды.
Если же ПМ неадекватно оценивает свой/команды опыт и скиллы, не знает на что можно/нельзя комититься, не знает что умеет он/его команда, не даёт людям реализовать свой потенциал или не правильно его оценивает,.. — он просто плохой ПМ. Наличие или отсутствие тех. опыта тут ни при чем.

Основной для меня аргумент в следующем. Если ПМ имеет технический бекграунд — в среднем понятно, каким путем он добился должности и какие скилы у него развиты. Если же он в прошлом не был разработчиком/тестером, то пришел в ПМы с помощью других скилов, как-то: менеджмента, ораторства, продаж и пр.
Сравниваем «средних» ПМов. Само собой, нет речи о замкнутых в себе хороших разработчиках, которых руководство пропихнуло в менеджеры, ибо больше некого. И не о вчерашних сейлах, не знающих, как организован процесс разработки. Без крайностей. Но. Если я больший технарь, то я меньший продажник, чем мой коллега. Ведь мало из нас потомков Да-Винчи, у которых превосходно развиты многие навыки.
И вот именно тут возникают вопросы: а что важнее для ПМа, продавать заказчику или заниматься микроменеджментом команды?

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

не забывайте, что технический бекграунд != бинарное мышление :)
это совершенно разные категории — тип мышления и накопленный опыт

Утверждение «совершенно разные» как раз является прекрасным примером, извините, бинарного мышления. Простите, совершенно не имею цели задеть вас лично, хотя звучит на то похоже. Я считаю, что есть корреляция, достаточная, чтобы не называть их «совершенно разными». Как вы считаете, каков коэффициент корреляции? 0? 0.1? 0.5? 0.9? 1?

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

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