Комментарии 7
божечки... вы б лучше рассказали как подружить инфраструктуру и затертый богами agile
Улучшаем процессы. Мы являемся основными держателями практик по процессу разработки, постоянно оптимизируем бизнес-процессы, обеспечивая гибкость и эффективность масштабирования бизнеса
Практику должны держать те, кто непосредственно занимается этой практикой - т.е. разработкой иначе получется как в известной поговорке про "хотели как лучше".
Субъективный опыт пока таков, но проектные офисы по каким-то причинам заполонили все достаточно крупные компании. В теории красиво, на практике не очень.
Ну так разработка понятие более широкое, чем кодирование, описанное в статье тоже часть разработки. Другой вопрос,какова реальная эффективность такой толщины менеджерского корпуса, на что направляется масса этой махины. Я понимаю, что есть конторы которые просто могут себе это позволить без особых рефлексий. Но одно дело - развивать многоуровневый ит менеджмент потому что ты получишь с этого прямой мультипликативный эффект на рынке, другое - что тебе по любому с каждой транзакции по квитанции за ЖКХ капает денежка, адские ипотеки при господдержке и т.п., и ты просто можешь развести у себя много модного ит по книжкам (а потом ещё и самому начать их писать). И какой из этих двух вариантов имеет место быть в отдельном случае мне кажется стейкхолдеры знают не всегда)
Ольга, спасибо за статью!
Две мысли:
Для энтерпрайза вроде как стандарт работа продактов + проджектов (а при больших масштабах программ, портфолио и команд, добавляются деливери менеджеры). Более того, существует антипаттерн "PO, подрабатывающий PM" или наоборот - страдает и проект (сроки, качество, бюджет, команда) и продукт со своими продуктовыми метриками. Это для кричащего заголовка противопоставление и вывод, что "оказывается" так делать надо? Раньше у вас было не так?
"с февраля 2023 года, СберМаркет вырос по количеству проджектов в два раза. Это означает, что у компании есть потребность в таких сотрудниках" - одно для стороннего читателя в виде меня не означает другого. Можете поделиться, каким раньше был Lead Time, почему не Cycle Time (если речь о команде), какие проблемы были и стали очевидны для бизнеса настолько, что решили открыть проектный офис?
Спасибо!
Добрый день)
Да, раньше роль проджект менеджера была не была распространена, а деливери менеджеров не было.
Конкретными цифрами поделиться не могу, в lead time мы включаем время от старта discovery, до конечного вывода в прод. Отдельно Cycle time внутри команды тоже смотрим, но это уже составная метрика. Также как смотрим Waste time и время потраченное на блокировки.
Ольга, спасибо за статью, очень интересно!
Зачем нужен проектный офис, если компания работает в продуктовом подходе?