Как формировать структуру команд под запросы бизнеса - часть 2
Продолжу пост про структуру команд, в котором поговорю про проектный менеджмент. Мне кажется, что каждый менеджер должен уметь работать в рамках проекта, который PMI (Project Management Institute) определяет как
Project is a temporary endeavor undertaken to create a unique product, service or result Из этого определения сразу видны ключевые характеристики проекта, а именно:
- Уникальность продукта или сервиса (функциональность)
- Ограничение по времени (сроки)
- Ограничение по ресурсам, которые так или иначе конвертируются в деньги (стоимость) Эти ключевые характеристики можно изобразить графически в виде треугольника ограничений: функциональность - сроки - стоимость. И обычно можно выбрать и уложиться в любые два ограничения из трех:)
Проекты удобно применять для старта какой-то инициативы, на которую можно собрать профессиональную команду и на выходе получить первую версию продукта, которую уже можно использовать и дальше дорабатывать в продуктовом подходе. Другой удобный случай - это синхронизация большого количества продуктовых команд, которые в едином порыве должны сделать общее усилие, например, редизайн мобильного приложения или миграцию с Siebel на что-то свое:)
В Тинькофф у меня было достаточное количество возможностей для применения проектного подхода и я расскажу про оба варианта на примере
1) Проект переезда web привлечения на новую версию Tinkoff.ru (примерно 7 лет назад) С этого проекта началась моя карьера в Тинькофф
- Проект переезда на новое решение к моему приходу длился уже больше года
- Над ним работало 50+ человек
- Моя зона ответственности была только в страницах привлечения и формах привлечения, над которыми работало 3 человека
- До переезда оставалось 3 месяца, а на новом решении не работали ключевые вещи: не работал SSR (кто-то ошибся с расчетом нагрузки), не работала аналитика (SPA приложения требовали переделать трекинг), не работали многие механики на формах, а также релизы занимали недели из-за ручного регресса.
Мы сделали этот проект в авральном режиме, успешно переехали и дальше начали развивать приложение как продукт. За три года наши страницы привлечения выросли до всей публичной части Tinkoff.ru, включая все продукты, а команда до 50 человек в 7+ командах. Многие ребята, с которыми мы затянули этот проект и развивали продукт до сих пор со мной. Подробнее про этот проект, переросший в продукт, можно посмотреть в моем выступлении на ArchDays 2019
2) Проект запуска отдельных продуктовых команд и процессов в мобильном банке Тинькофф (примерно 4 года назад) Этот проект стал вызовом для меня - именно с ним я вышел за границы привлечения.
- Проект перехода на продуктовую структуру команд от одной команды в 50 человек длился уже полгода, но шел с пробуксовкой
- Запрос был в том, чтобы повторить для мобильного банка путь по разъезду на отдельные продуктовые команды, который я проходил в web.
- Здесь вызовом было то, что команда была сложившаяся и требовалось гораздо лучше уметь в change management.
Проект изменений мы запустили за три месяца, но я в это время проводил в среднем по 3 интервью в день, не считая разнообразные синки. Так как эти первые три месяца я работал в режиме привлеченного руководителя, то я почувствовал как сложно идут изменения, когда ты работаешь из позиции консультанта, пускай и внутреннего. Этот проект тоже перерос в большую продуктовую историю, про которую я рассказывал в нескольких частях
- В апреле 2021 года "Как мы меняли разработку лучшего* мобильного банка под требования бизнеса"
- В сентябре 2022 года "Канал. Продукт. Платформа” или эволюция подходов к развитию мобильного банка Тинькофф"
Подводя итоги, я думаю, что проектный менеджмент - это удобный инструмент, у которого есть своя область применимости, где он достаточно эффективен. А в следующем посте поговорим про продуктовую разработку:)
#Management #Leadership #Project #ProjectManagement #SoftwareDevelopment #Software