Как стать автором
Обновить

Зачем нужен проектный офис, если компания работает в продуктовом подходе?

Время на прочтение8 мин
Количество просмотров8.9K
Всего голосов 15: ↑12 и ↓3+10
Комментарии7

Комментарии 7

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

Улучшаем процессы. Мы являемся основными держателями практик по процессу разработки, постоянно оптимизируем бизнес-процессы, обеспечивая гибкость и эффективность масштабирования бизнеса

Практику должны держать те, кто непосредственно занимается этой практикой - т.е. разработкой иначе получется как в известной поговорке про "хотели как лучше".
Субъективный опыт пока таков, но проектные офисы по каким-то причинам заполонили все достаточно крупные компании. В теории красиво, на практике не очень.

Ну так разработка понятие более широкое, чем кодирование, описанное в статье тоже часть разработки. Другой вопрос,какова реальная эффективность такой толщины менеджерского корпуса, на что направляется масса этой махины. Я понимаю, что есть конторы которые просто могут себе это позволить без особых рефлексий. Но одно дело - развивать многоуровневый ит менеджмент потому что ты получишь с этого прямой мультипликативный эффект на рынке, другое - что тебе по любому с каждой транзакции по квитанции за ЖКХ капает денежка, адские ипотеки при господдержке и т.п., и ты просто можешь развести у себя много модного ит по книжкам (а потом ещё и самому начать их писать). И какой из этих двух вариантов имеет место быть в отдельном случае мне кажется стейкхолдеры знают не всегда)

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

Ольга, спасибо за статью!

Две мысли:

  1. Для энтерпрайза вроде как стандарт работа продактов + проджектов (а при больших масштабах программ, портфолио и команд, добавляются деливери менеджеры). Более того, существует антипаттерн "PO, подрабатывающий PM" или наоборот - страдает и проект (сроки, качество, бюджет, команда) и продукт со своими продуктовыми метриками. Это для кричащего заголовка противопоставление и вывод, что "оказывается" так делать надо? Раньше у вас было не так?

  2. "с февраля 2023 года, СберМаркет вырос по количеству проджектов в два раза. Это означает, что у компании есть потребность в таких сотрудниках" - одно для стороннего читателя в виде меня не означает другого. Можете поделиться, каким раньше был Lead Time, почему не Cycle Time (если речь о команде), какие проблемы были и стали очевидны для бизнеса настолько, что решили открыть проектный офис?

    Спасибо!

Добрый день)

  1. Да, раньше роль проджект менеджера была не была распространена, а деливери менеджеров не было.

  2. Конкретными цифрами поделиться не могу, в lead time мы включаем время от старта discovery, до конечного вывода в прод. Отдельно Cycle time внутри команды тоже смотрим, но это уже составная метрика. Также как смотрим Waste time и время потраченное на блокировки.

Ольга, спасибо за статью, очень интересно!

Зарегистрируйтесь на Хабре, чтобы оставить комментарий