Спасибо, что написали этот КОММЕНТ. Я уж думал, что только мне так показалось. На первом же "совете" про авторитет зажмурился, ибо чем громче ты кричишь про свой авторитет, тем он меньше. Авторитет — это не про шум и "я теперь твой капитан", а про навыки, доверие и коммуникацию.
Проблемы, описанные выше, не специфичны для IT, и стандарты управления проектами позволяют таких проблем избегать.
Если нет заказчиков, то приходится браться за любой проект в обход принятых в индустрии стандартов и методик. Если заказчики есть, то стоит придерживаться стандартов управления проектами.
Бизнес-аналитика ("изучение бизнеса"), составление проектной документации, оценка проекта стоят денег. Если заказчик не согласен см. 1.
Этапы приёмки (и оплаты), матрицы ответственности, change management были придуманы не просто так. Вся цепочка бизнес-требования->продуктовые требования->функциональные и нефункциональные требования с прописанными критериями приёмки существуют и работают. Да, это работа менеджера проекта под капотом. Это не нравится CEO? - Пусть мучается дальше бытийными вопросами "почему множество ИТ-проектов проваливается?". Не нравится разработчику? - Дайте хлебнуть административки, коммуникаций с клиентом, отсутствие процессов на новом проекте. Не нравится заказчику - см 1.
Фотограф - коллега, начальник управления, отвечающего за расследование нарушений ТБ в ООО «Норильскникельремонт».
и на фото нарушение ТБ:) Спасибо за отличную статью! Ожидания и критика важны для любого проекта, спасибо что не боитесь публиковать свои наработки и внятно ограничивать сферу применения изделия. Будет потребность, будут и приводы, будет и джетпак :)
мы должны измерять ценность, которую проект приносит бизнесу. Но у нас есть и проекты, которые не приносят прямых количественных эффектов
Бизнес-ценность необязательно связана с количественными эффектами, они могут быть и качественными, и косвенными, главное - измеримыми. Иначе резонно встанет вопрос cui bono, лат. "нахрен такое делать" :)
Мне описание вашей комбинированной методики/фреймворка напомнило SAFe, который отлично подходит для управления программами/портфолио/проектами энтерпрайзов. Почему сразу не переняли?
Как вы понимаете что для проектов, аналогов которым в истории не было (и сравнить данные не с чем) PM не завышает сроки, чтобы в них попасть?
Ощущение, что следующий логичный шаг высчитывать не только попадание в сроки, но и business value ÷ effort = roi
Ваш бизнес пока не начал спрашивать за деньги/эффективность?
Для энтерпрайза вроде как стандарт работа продактов + проджектов (а при больших масштабах программ, портфолио и команд, добавляются деливери менеджеры). Более того, существует антипаттерн "PO, подрабатывающий PM" или наоборот - страдает и проект (сроки, качество, бюджет, команда) и продукт со своими продуктовыми метриками. Это для кричащего заголовка противопоставление и вывод, что "оказывается" так делать надо? Раньше у вас было не так?
"с февраля 2023 года, СберМаркет вырос по количеству проджектов в два раза. Это означает, что у компании есть потребность в таких сотрудниках" - одно для стороннего читателя в виде меня не означает другого. Можете поделиться, каким раньше был Lead Time, почему не Cycle Time (если речь о команде), какие проблемы были и стали очевидны для бизнеса настолько, что решили открыть проектный офис?
Учился на продакта, интересно просчитывать продукт, работает проджектом. Это антипаттерн для обеих ролей и известный плачевный результат.
Мой личный "красный флаг": поездка летом 2022 года в Крым. Что там с оценкой рисков? Прогулял тему? :)
Про математику, программирование у ПМ-а: холивар, конечно, но мой опыт говорит о том, что навыки (вот прям уметь кодить) нужны тогда, когда пытаются ПМ-ом заткнуть отсутствие чей-то роли: архитектора, тимлида и т.д. Математика не мешает, но мне больше пригождались прикладные методы статистики и социологии. А при выборе отличные навыки коммуникации vs отличные навыки математики по моему опыту важнее и полезнее первое.
Попытка "замкнуть коммуникации на себя" — потенциальный красный флаг. ПМ должен выстраивать коммуникацию между участниками проекта (поэтому не люблю матрицы ответственности: она предполагает пассивность ролей и не показывает как "роли" принимают решения), фасилитировать, фиксировать договорённости и делать себя заменяемым, а не "необходимым настолько, чтобы проект без него развалился". Впрочем, если это сложившийся коллектив и короткий проект, бывает проще быть связующим звеном, чем переставать коммуникацию и учить договариваться участников.
Всем кто пишет про бесполезность пм-ов и" в лучшем случае не мешают" я желаю сначала покодить, совмещая с административным функциями (вот эти все отчёты, метрики проектов для стейкходеров/инвесторов, ответы на вопросы заказчику почему офигенный разраб Вася про**ал в очередной свою же оценку, риски), а потом поработать на проекте сложнее мобилки-каленжаря с действительно полезным пм-ом (ну тем, что вы строил процессы, коммуникацию, получает ответы на свои вопросы из трекера или с дейликов и не мешает умным людям работать вопросами вижа "ну что, когда будет готово" :)
Простите, дед скрам коуч ПМ в треде.
Задумка клёвая, но реализация с "соплежуй" и "скорострел"? Эээээмммммм, это пассивно-агрессивно и токсично. Бывает, наверное, феноменально сработанная команда, когда вы можете постебывать друг над другом (даже называя скорострелом и/или соплежуем) и при этом не получать по лицу собственному и не видеть фейспалмов коллег, но нет. Я видимо ценю свои команды и никогда ни себя не позволю так называть, ни сам не буду. Ну и если бы назвал заболевшего сотрудника соплежуем, вряд ли бы уважающий себя сотрудник вышел с больничного обратно в эту компанию.
p.s.
Показал другим скрам-мастерам с богатым опытом (не Wrike, у вас явно своя атмосфера): они тоже в изумлении.
Разработчики, мы не все такие "инновационно-эффектианые", честно.
Автор, и прям работает и пассивная агрессия не мешает и люди терпят?
Уважаемый автор!
Спасибо за обстоятельную академическую статью. Вопросы будут тоже академическими:
Вы упомянули 2 школы кризисного менеджмента. Можно узнать какой школы и каких методологий менеджмента придерживается лично Вы?
В статье, как мне показалось, прослеживается основной мотив "сохранения процессов", и только вскользь "сохранения людского ресурса" в контексте основного средства производства IT-компаний. Есть ещё множество факторов, да и в целом стратегии управления сконцентрированные вокруг продуктов компании, монетизации этих продуктов. Вы полагаете, что управление процессами первично (поменяем их, останутся и люди, и продукты будут деньги приносить)? Можно узнать в какой сфере более применим такой подход (есть гипотеза, что не во всех)?
Ещё раз спасибо!
Спасибо, что написали этот КОММЕНТ. Я уж думал, что только мне так показалось. На первом же "совете" про авторитет зажмурился, ибо чем громче ты кричишь про свой авторитет, тем он меньше. Авторитет — это не про шум и "я теперь твой капитан", а про навыки, доверие и коммуникацию.
Проблемы, описанные выше, не специфичны для IT, и стандарты управления проектами позволяют таких проблем избегать.
Если нет заказчиков, то приходится браться за любой проект в обход принятых в индустрии стандартов и методик. Если заказчики есть, то стоит придерживаться стандартов управления проектами.
Бизнес-аналитика ("изучение бизнеса"), составление проектной документации, оценка проекта стоят денег. Если заказчик не согласен см. 1.
Этапы приёмки (и оплаты), матрицы ответственности, change management были придуманы не просто так. Вся цепочка бизнес-требования->продуктовые требования->функциональные и нефункциональные требования с прописанными критериями приёмки существуют и работают. Да, это работа менеджера проекта под капотом. Это не нравится CEO? - Пусть мучается дальше бытийными вопросами "почему множество ИТ-проектов проваливается?". Не нравится разработчику? - Дайте хлебнуть административки, коммуникаций с клиентом, отсутствие процессов на новом проекте. Не нравится заказчику - см 1.
и на фото нарушение ТБ:) Спасибо за отличную статью! Ожидания и критика важны для любого проекта, спасибо что не боитесь публиковать свои наработки и внятно ограничивать сферу применения изделия. Будет потребность, будут и приводы, будет и джетпак :)
Бизнес-ценность необязательно связана с количественными эффектами, они могут быть и качественными, и косвенными, главное - измеримыми. Иначе резонно встанет вопрос cui bono, лат. "нахрен такое делать" :)
Мне описание вашей комбинированной методики/фреймворка напомнило SAFe, который отлично подходит для управления программами/портфолио/проектами энтерпрайзов. Почему сразу не переняли?
Как вы понимаете что для проектов, аналогов которым в истории не было (и сравнить данные не с чем) PM не завышает сроки, чтобы в них попасть?
Ощущение, что следующий логичный шаг высчитывать не только попадание в сроки, но и business value ÷ effort = roi
Ваш бизнес пока не начал спрашивать за деньги/эффективность?
Александр, спасибо за статью, успехов!
Ольга, спасибо за статью!
Две мысли:
Для энтерпрайза вроде как стандарт работа продактов + проджектов (а при больших масштабах программ, портфолио и команд, добавляются деливери менеджеры). Более того, существует антипаттерн "PO, подрабатывающий PM" или наоборот - страдает и проект (сроки, качество, бюджет, команда) и продукт со своими продуктовыми метриками. Это для кричащего заголовка противопоставление и вывод, что "оказывается" так делать надо? Раньше у вас было не так?
"с февраля 2023 года, СберМаркет вырос по количеству проджектов в два раза. Это означает, что у компании есть потребность в таких сотрудниках" - одно для стороннего читателя в виде меня не означает другого. Можете поделиться, каким раньше был Lead Time, почему не Cycle Time (если речь о команде), какие проблемы были и стали очевидны для бизнеса настолько, что решили открыть проектный офис?
Спасибо!
мысли вслух:
Учился на продакта, интересно просчитывать продукт, работает проджектом. Это антипаттерн для обеих ролей и известный плачевный результат.
Мой личный "красный флаг": поездка летом 2022 года в Крым. Что там с оценкой рисков? Прогулял тему? :)
Про математику, программирование у ПМ-а: холивар, конечно, но мой опыт говорит о том, что навыки (вот прям уметь кодить) нужны тогда, когда пытаются ПМ-ом заткнуть отсутствие чей-то роли: архитектора, тимлида и т.д. Математика не мешает, но мне больше пригождались прикладные методы статистики и социологии. А при выборе отличные навыки коммуникации vs отличные навыки математики по моему опыту важнее и полезнее первое.
Попытка "замкнуть коммуникации на себя" — потенциальный красный флаг. ПМ должен выстраивать коммуникацию между участниками проекта (поэтому не люблю матрицы ответственности: она предполагает пассивность ролей и не показывает как "роли" принимают решения), фасилитировать, фиксировать договорённости и делать себя заменяемым, а не "необходимым настолько, чтобы проект без него развалился". Впрочем, если это сложившийся коллектив и короткий проект, бывает проще быть связующим звеном, чем переставать коммуникацию и учить договариваться участников.
Всем кто пишет про бесполезность пм-ов и" в лучшем случае не мешают" я желаю сначала покодить, совмещая с административным функциями (вот эти все отчёты, метрики проектов для стейкходеров/инвесторов, ответы на вопросы заказчику почему офигенный разраб Вася про**ал в очередной свою же оценку, риски), а потом поработать на проекте сложнее мобилки-каленжаря с действительно полезным пм-ом (ну тем, что вы строил процессы, коммуникацию, получает ответы на свои вопросы из трекера или с дейликов и не мешает умным людям работать вопросами вижа "ну что, когда будет готово" :)
Простите, дед скрам коуч ПМ в треде.
Задумка клёвая, но реализация с "соплежуй" и "скорострел"? Эээээмммммм, это пассивно-агрессивно и токсично. Бывает, наверное, феноменально сработанная команда, когда вы можете постебывать друг над другом (даже называя скорострелом и/или соплежуем) и при этом не получать по лицу собственному и не видеть фейспалмов коллег, но нет. Я видимо ценю свои команды и никогда ни себя не позволю так называть, ни сам не буду. Ну и если бы назвал заболевшего сотрудника соплежуем, вряд ли бы уважающий себя сотрудник вышел с больничного обратно в эту компанию.
p.s.
Показал другим скрам-мастерам с богатым опытом (не Wrike, у вас явно своя атмосфера): они тоже в изумлении.
Разработчики, мы не все такие "инновационно-эффектианые", честно.
Автор, и прям работает и пассивная агрессия не мешает и люди терпят?
Уважаемый автор!
Спасибо за обстоятельную академическую статью. Вопросы будут тоже академическими:
Ещё раз спасибо!