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