В этой статье я хочу рассказать об опыте проектного управления в условиях Agile.
Проект, о котором я рассказываю, внедрен в Сбере два года назад. Я выбрал его в качестве примера во-первых потому, что он успешно внедрился, и опыт был признан заказчиками положительным, а во-вторых, на нем можно наглядно проговорить плюсы выделения независимого руководителя проекта.
Для упрощения восприятия сократил немного деталей, но с сохранением сути.
Представленные данные на экране СберБанк Онлайн – вымышленные.
Описание постановки задачи
Подразделением, отвечающим за улучшение клиентского опыта в СберБанк Онлайн (далее - СБОЛ), была поставлена задача «Отображать секции «Инвестиции» и «Сбережения и пенсии» в раскрытом виде, на экране «Накопления» с выводом текущего состояния счета и дохода по каждому из продуктов.
До этого момента секции экрана "Накопления" показывались в "схлопнутом" виде, (см. рис. 1)
Особенности проектирования реализации
Достаточно простая постановка задачи потребовала, однако, значительных усилий по реализации.
Делов том, что законодательство строго регулирует и банковскую и страховую и пенсионную деятельность, чем может заниматься обладатель соответствующей лицензии и чем — нет. В связи с этим, за развитие и сопровождение продуктов банковской деятельности отвечает ПАО Сбербанк (Сбер), за развитие небанковских продуктов отвечают генеральные партнеры группы Сбер, которые являются отдельными юридическими лицами со своей ИТ‑инфраструктурой.
Например, за пенсионные продукты отвечает Негосударственный Пенсионный Фонд Сбербанка, а за продукты страхования жизни — Страховая компания «Сбербанк страхование жизни».
С технической точки зрения раскрытая секция «Инвестиции» означает, что каждому пользователю СберБанк Онлайн, зашедшему на вкладку «Накопления», должны мгновенно отобразиться продукты и актуальное состояние счетов, причем независимо от того, целенаправленно пользователь зашел на эту вкладку или случайно.
Это означает, что ИТ-системы, хранящие информацию о продуктах должны поддерживать столько одновременных запросов, сколько одновременно клиентов в СБОЛ и отвечать со скоростью, которая диктуется требованиями СБОЛ (1-2 секунды).
Напомню, что часть продуктов хранится во внешней для Сбера ИТ‑инфраструктуре компаний‑партнеров, что означает, что если обращаться к данным партнеров напрямую, вся цепочка поставки данных должна была бы выдерживать нагрузку СберБанк онлайн по числу одновременных запросов. Так как мощности компаний‑партнеров не были рассчитаны на такую нагрузку и на них не возлагались такие высокопроизводительные задачи, изначально секции «Инвестиции» и «Пенсии» выводились в закрытом виде и если клиент кликал на раскрытие — вот тогда и только по кликнувшему клиенту и направлялся запрос к компаниям‑партнерам (см. рис. 1).
В ходе проектирования было выработано архитектурное решение, при котором продукты, необходимые для отображения в секциях «Инвестиции» и «Сбережения и пенсии» (см. рис. 2) сохраняются в контуре Сбера в высокопроизводительной ИТ‑системе в виде cache (далее - кэш) и СБОЛ обращается за продуктами к этой системе, а не к ИТ‑системам партнеров. В свою очередь, партнеры передают информацию по своим продуктам в эту систему‑кэша по мере их появления и изменения.
Управленческие вызовы и проектный подход
Исходя из архитектуры выше и требованиям к ИТ-доработкам, определились 22 команды из 5 разных юр. лиц, функционал которых должен был быть доработан.
При этом команды Сбера находились в четырех разных трайбах трех разных блоков.
Такое количество участников привело к следующим управленческим вызовам:
Ответственному менеджеру со стороны заказчика был необходим централизованный актуальный статус по задаче в целом, а не 22 разрозненных статуса от команд про "пуговицы";
Заказчику нужно было понимать, в какие сроки и к какой хотя бы примерно дате ожидать получения заявленного результата в целом, а не локальный результат от каждой из команд;
Необходим был единый план по реализации задачи в целом, который бы оперативно актуализировался в случае каких-либо изменений со стороны любой из 22 команд;
Нужен был кто-то в роли "независимого арбитра", который мог бы разрешать разногласия между командами и при этом не находиться на какой-либо одной из сторон. Которому бы доверяли все команды и, как следствие, объективно отчитывались и брали поручения со стороны проекта в целом.
Все эти вызовы были успешно разрешены после того, как Главный заказчик предложил управлять этой задачей как проектом и назначил руководителя проекта (РП) из внешнего для всех задействованных команд подразделения.
РП должен был:
Отвечать за достижение конечного результата в целевые сроки
Отчитываться на регулярной основе заказчикам высокого уровня о ходе проекта и необходимости управленческих решений с их уровня
Вести актуальный план проекта, содержащий ключевые вехи, и который согласован со всеми командами и ключевыми участниками
Управление задачей на дистанции
Первый этап такого проекта – «бурлячка», т.е. попытка фиксации детального скоупа работ, архитектуры, состава участвующих команд. Это – не формализуемый процесс, состоящий из большого числа встреч, брейнстормов, фиксации договоренностей о скоупе. В задачу любого РП входит максимально возможное сокращение по срокам такого периода, но избежать его совсем – невозможно.
По окончанию бурлячки установился следующий набор регулярных коммуникаций:
Дейли.
Короткий статус с участием ключевых менеджеров (5-7) и аналитиков команд по оперативным задачам. В календаре был запланирован три раза в неделю по утрам, но, как правило, одна или две из этих встреч по ситуации отменялась, а все три за неделю проходили только в очень горячий период.Еженедельная менеджерская.
Проходила 1 раз в неделю с участием всех менеджеров всех команд + ключевых заинтересованных лиц – на ней сверялся общий план и, при необходимости, вносились изменения, причем в присутствии всех.
Разница между этой встречей и Дейли – в том, что для ряда оперативных задач не требовалось собирать всех менеджеров, и обсуждались на ней горящие точечные вопросыОтчетная встреча с руководителями и стейкхолдерами.
Происходила раз в месяц или раз в две недели, на ней в презентационном формате представлялась дорожная карта (или план) проекта, общий статус, достижения, риски, требующие внимания высокого руководства.
Результат: все менеджеры и ключевые участники на каждом уровне информированы о текущем статусе проекта, рисках и ближайших шагах.
Особенности управления проектными задачами в Agile
От РП не требовалось управлять ресурсами и бюджетом, т.к. это управлялось на стороне команд и трайбов;
РП становился чуть ли не единственным участником рабочей группы, который полностью понимает end-to-end скоуп работ на уровне бизнес-требований;
Использовался облегченный процесс управления изменениями, с учетом того, что Agile подразумевает, что они случаются довольно часто. Это означало безусловную фиксацию каждого изменения и согласование влияния на работы других команд, однако не требовало избыточной бюрократии по утверждению каждого из таких изменений на каком-либо коллегиальном органе;
Детальное планирование полностью делегировалось командам. В задачи РП входило выровнять планы команд по срокам и ключевым вехам, а также уметь быстро и просто представить единый план всем командам. Для этого использовался Confluence и встречи в SberJazz с демонстрацией экрана, на котором был единый план в понятном всем формате;
РП не достаточно было провести интервью с командами и получить детальный план работ от каждой – необходимо было так же добавить в план централизованные и интеграционные работы, без которых проект не был бы внедрен, но команды могли о них не знать или не держать в фокусе (как пример: сквозное интеграционное тестирование и подготовка общих для всех тестовых данных);
РП максимально избавлял команды от избыточной бюрократии, замыкая ее на себя там, где это было возможно;
РП становился единственной точкой входа для внеших участников и только РП мог отвечать за даты вех по задаче в целом
Для РП в Agile презентационные и коммуникационные навыки намного важнее, чем классические для РП навыки детального планирования и управления ресурсами
Результат проекта
Проект был успешно внедрен в согласованные с стейкхолдерами сроки. Получена благодарность от стейкхолдеров и ключевых участников проекта.
В ходе проекта срок внедрения дважды пересматривался в сторону увеличения по внешним для проекта причинам, при этом своевременное информирование стейкхолдеров и согласование плана корректирующих мероприятий позволило управлять ожиданиями всех сторон и сдвиги сроков были приняты и согласованы.
Вовлеченные команды так же считали проектный опыт успешным, т.к. увидели, что их усилия привели к конечному результату, а не ушли в песок.
Выводы
Без руководителя проекта даже в Agile никак, если:
задача проектного типа, то есть определен относительно конечный скоуп работ и желаемые сроки для задачи в целом
в задаче принимают участие несколько (более двух) команд из различных Agile-иерархий
есть заказчик у независимого централизованного статуса по задаче в целом.
Без выделенного РП вполне можно обойтись, если:
В задаче участвуют 1-2 команды одного или двух смежных трайбов – менеджеры этих команд могут договориться между собой, если только между ними нет непреодолимых разногласий, требующих внешнего арбитра
Задачи предпочтительно решать в Agile-фреймворке (протестировать гипотезу, пропилотировать функционал и принять решение о развитии и т.д.)
RUN-задачи и иные задачи не проектного типа.
Подпишитесь на канал «Мысли менеджера», если интересны обучающие материалы в формате сообщений Telegram-канала, а так же менеджерские мемы.
