CC BY
189
Возможности каскадирования целей организации среди участников Agile-проектов
В статье рассмотрена сущность Agile-подхода, которым начинает активно использоваться не только ИТ, но и прочие бизнес-компании в качестве особой формы организации проектной деятельности в организации. С учетом новых требований к организации деятельности участников Agile-проектов становится актуальным вопрос: как в подобном подходе, который является новым для организационной практики, можно управлять целеполаганиемработников?Для описания особенностей Agile рассмотрен опыт Сбербанка, который в числе первых отечественных компаний начал масштабно использовать Agile в своей деятельности, смог по-новому организовать работу сотрудников розничного и ИТ-блоков, внедрил инструменты системного каскадирования целей и задач, стоящих перед Agile-организацией, от руководителей к непосредственным исполнителям проектной работы.
Ключевые слова: инновации, управление проектами, Agile, гибкая методология разработки, проектная деятельность, целеполагание, управление командами.
Р. А. Долженко,
д.э.н., зам. проректора по научной работе, зав. кафедрой экономики труда и управления персоналом, Уральский государственный экономический университет
snurk17@gmail.com
Введение
Конкуренция как ключевой двигатель рыночной экономики не статична, она также развивается, проявляет себя в разных аспектах, заставляя бизнес постоянно пересматривать акценты в своих целях. Скорость изменений — вот тот показатель, на который вынуждены ориентироваться успешные компании. Для этого они используют различные подходы к увеличению этой характеристики своего бизнеса. Не просто разовые инновации, но целая инфраструктура, подходы, механизмы, инструменты реализации постоянных инноваций. Одним из таких подходов к максимально быстрой, гибкой разработки продуктов и осуществления услуг является гибкая методология разработки или как ее упрощенно называют, Agile-методология. Изначально она появилась в ИТ-области, однако, в настоящее время Agile рассматривают как особый подход к реализации проектной деятельности в организации. В какой-то мере, можно говорить об Agile-империализме, связанном с продвижением Agile-методологии сначала в смежные, связанные с ИТ, затем в более отдаленные области. За счет своих преимуществ ее пробуют использовать в области бизнеса, в проектной деятельности, в образовании, в государственном управлении.
Цель статьи — рассмотреть особенности Agile-методологии, описать возможности ее использования для организации проектной деятельности в новых
условиях, конкретизировать способы, с помощью которых руководство организации может каскадировать свои цели участникам Agile-команд на местах, изучить опыт Сбербанка в данной области в силу того, что данная организация одной из первых начала масштабно, применительно к отличной от ИТ сфере деятельности, использовать Agile-методологию. Прежде проанализируем, что вкладывается в это понятие, какими свойствами она обладает?
Понятие и сущность Agile-методологии, основные
роли, процедуры, участников Agile-проектов
Что такое Agile-методология? В переводе с английского это слово означает «шустрый, проворный, быстрый». В свою очередь под методологией понимаются принципы, идеи, понятия, методы, способы и средства, которые определяют процесс разработки продукта, начиная от написания документации до его вывода на рынок. Таким образом, Agile-методология — это принципы, методы, способы, средства, с помощью которых можно быстро и гибко вывести новый продукт на рынок.
В зарубежной профессиональной среде эксперты разводят между собой понятия Agile и гибкую методологию разработки (Agile Software Development). Под Agile понимается оперативная способность создавать и реагировать на изменения, чтобы преуспеть в неопределенной и бурной среде. Гибкая методология разработки в свою очередь — это серия подходов к
оо
о
со
J
<
СО
оо
о
CN
со
CN
J <
со
разработке программного обеспечения, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля [1]. В настоящей работе будем понимать данные понятия как синонимы, ориентируясь на характеристику гибкой методологии разработки в силу ее конкретности и четких характеристик определения.
В основе Agile лежат ключевые ценности, правила и принципы, которые были изложены в 2001 г. в документе под названием «Agile Manifesto» [1]. В нем представлены следующие ценности Agile:
1) люди и взаимодействие важнее процессов и инструментов;
2) работающий продукт важнее исчерпывающей документации;
3) сотрудничество с заказчиком важнее согласования условий контракта;
4) готовность к изменениям важнее следования первоначальному плану.
Помимо этих 4 ценностей в манифесте выделяются 12 правил Agile:
1) наивысший приоритет — удовлетворение потребностей заказчика;
2) изменение требований приветствуется;
3) продукт следует выпускать как можно чаще;
4) ежедневно работать вместе;
5) мотивированные профессионалы;
6) непосредственное общение;
7) работающий продукт;
8) поддерживать постоянный ритм;
9) постоянное внимание к техническому совершенству;
10) простота — искусство минимизации лишней работы;
11) самоорганизующиеся команды;
12) поиски улучшения эффективности.
И, наконец, выделяют 3 базовых принципа гибкой разработки:
1. Прозрачность. Процесс должен одинаково пониматься всеми его участниками. Все участники процесса должны пользоваться общей терминологией. Те, кто выполняет работу, и принимает итоговый результат, должны иметь общее представление о критериях готовности продукта.
2. Инспекция. Участники процесса должны часто инспектировать ключевые моменты работы, отслеживать прогресс достижения цели проекта для своевременного выявления нежелательных отклонений. Однако, инспектирование не должно быть настолько частым, чтобы мешать работе и должно проводиться квалифицированными специалистами в области гибкой разработки.
3. Адаптация. Если в ходе инспекции было сделано заключение, что один или более аспектов процесса отклонились от допустимых норм, а производимый продукт может стать неприемлем, то необходимо внести изменения либо в процесс, либо в рабочие
материалы. Изменения должны вноситься как можно раньше для уменьшения риска последующего отклонения от нормы.
В силу большой значимости гибких подходов к разработке программного обеспечения можно найти большое количество книг и статей на тему Agile, наиболее известными работами можно обозначить следующие [2-5]. Данный подход получает все большее распространение в практике. На ценностях и принципах Agile основана деятельность таких лидеров как Google, Microsoft, Amazon. Их можно назвать полноценными Agile-организациями. Agile-организация — это объединение максимально самодостаточных самоорганизующихся кросс-функциональных команд, которые обладают всеми инструментами, навыками и полномочиями для удовлетворения определенной потребности клиента и используют гибкие методы разработки продукта при максимальной автоматизации внедрения и максимальной гибкости поддерживающих процессов.
Компании, работающие в Agile отмечают улучшения по многим параметрам. В случае успешного внедрения данной методологии увеличивается продуктивность команд, снижаются сроки и стоимость разработки продуктов, уменьшается количество дефектов и другие положительные эффекты. Однако, данный подход не обеспечивает 100% успех при внедрении. С опорой на опыт Agile-организа-ций можно выделить следующие критерии применимости Agile, которые обеспечат эффективное внедрение данной практики в деятельность организации:
• вовлечение бизнес-заказчика — возможность выделения на стороне бизнес-подразделения сотрудника, который будет отвечать за продукт, выступать в роли его владельца, т. е. принимать итоговый результат;
• команда и ее окружение — возможность создания кросс-функциональных (включающих все необходимые компетенции (аналитики, дизайнеры, архитектор автоматизированной системы, разработчики, тестировщики, администратор тестового стенда, администратор автоматизированной системы)) команд размером 5-9 человек и вовлечения всех участников процесса от производства до сопровождения;
• система и ее окружение — архитектура системы должна обеспечивать возможность работы с атомарными задачами, гибкое управление требованиями и безопасные частые внедрения.
С учетом обозначенных моментов можно сделать вывод, что, несмотря на кажущуюся эффективность, интерес бизнеса к Agile, который во многом перегрет вниманием массовой общности практиков, внедрение данной методологии должно быть крайне продуманным, учитывающим все системные последствия коренного изменения подходов к организации деятельности проектных команд. Рассмотрим, что из себя представляет Agile-методология, какие роли участников в ней выделяются, какие процедуры используются для организации их деятельности.
Базовые элементы Agile-методологии: структуры, процедуры, роли
Какие базовые структуры выделяются в Agile-подходе? Во-первых, это команда — кросс-функциональная совместно работающая группа специалистов, обладающая всеми навыками, инструментами и полномочиями для самостоятельной разработки работающего продукта. Размер команды, как правило, не превышает 10-12 человек. Она должна быть кросс-функциональной (аналитики,дизайнеры, архитектор автоматизированной системы, разработчики, тестиров-щики, администратор тестового стенда, администратор автоматизированной системы). Участники команды разработки должны быть взаимозаменяемы, однако допускается распределение ролей и функций между ними.
Следующий элемент Agile-структуры — это трайб, под которым понимается группа взаимосвязанных команд, сформированная вокруг определенного продукта/бизнес-цели и отвечающая за бизнес-результат. Размер трайба — до 150 человек или до 1500 при наличии кластеров. В случаях превышения максимального размера трайба или когда требуется тесная координация команд, команды объединяются в «кластеры».
Кластер — это виртуальная группа взаимосвязанных команд в рамках одного трайба, сформированная вокруг определенного продукта/бизнес-цели. Как правило, она не имеет выделенных сотрудников, роль лидера трайба выполняется одним из владельцев продукта. Размер кластер может достигать 150 человек (опционально). Ограничение размера трайба/кластера построено на «Числе Данбара», которое говорит, что количество постоянных социальных связей, которые человек может поддерживать составляет 125-150 человек. Можно обозначить еще несколько важных элементов в Agile-структуре, это куратор и чаптер. Куратор — руководитель организации, вовлеченный в Agile, отвечает за бизнес-результат нескольких трай-бов. Чаптер — группа специалистов одной области компетенций, как правило, 10-12 человек.
Таким образом, в Agile производственный процесс происходит на уровне трайба посредством реализации суперспринта, и на уровне команд через реализацию спринтов. Спринт — это период создания закончен-
Демонстрация продукта трайба
Ретроспектива трайба
Обсуждение КОРТ
Подготовка
планирования
суперспринта
Планирование суперспринта
Продуктовая синхронизация (РО Sync)
I I
Синхронизация команд (Scrum of Scrums)
Трайб Суперспринт (12 недель)
Команда JlS щ ШЩ шя Ш.'Ш
Спринт (2 недели)
Вт Ср Чт Пт Пн Вт Ср Чт Пт Пн
т т т т т т т т т
Ежедневный стендап Актуализация бэклога команды Планирование спринта Демонстрация
Ретроспектива
Рис. 1. Базовые процедуры, используемые при реализации Agile
ного функционала продукта, длительностью от одной недели до одного месяца. Суперспринт — такт работы трайба, в ходе которого создаются новые версии продуктов трайба как совокупный результат усилий всех команд. Система всех процедур, предусмотренных Agile-методологией приведена на рис. 1.
Описанию процедур, а также их особенностей может быть посвящена отдельная работа, поэтому в данной статье этот момент не рассматривается.
Проанализируем систему всех ролей участников Agile, она приведена на рис. 2.
Следует отметить, что методология допускает совмещение некоторых ролей одним и тем же сотрудником, поэтому в реальности реализация Agile может осуществляться меньшим количеством работников, по сравнению с указанной схемой. Как было отмечено ранее, основная деятельность участников Agile осуществляется в рамках команд и трайбов. Система ролей их участников представлена на рис. 3.
Гибкая разработка выполняется командой продукта, в которую входят владелец продукта/менеджер продукта, скрам-мастер и одна или более команд разработки. Команда продукта отвечает за выпуск продукта, соответствующего требованиям пользователей и клиентов. За выявление этих требований отвечает владелец продукта/менеджер продукта. Остальные роли выполняют четко обозначенный функционал,
оо
о
CN
со
CN
J <
со О
Рис. 2. Перечень ролей в рамках Agile-методологии
оо
о
CN
со
CN
J <
со
Рис. 3. Базовые роли в Agile внутри трайба
имеют специализированные инструменты и артефакты, которые обеспечивают успех работы участников.
Каким образом в данном подходе может быть обеспечено каскадирование целей от руководства организации, которое представлено ролями кураторов к непосредственным исполнителям в командах? Рассмотрим ответ на данный вопрос подробнее, для этого воспользуемся кейсом Сбербанка, который внедрил Agile-подход в деятельности ИТ и розничного блока. Прежде дадим общую характеристику реализованного проекта внедрения Agile в практику банка.
Общая характеристика проекта внедрения Agile-методологии в Сбербанке
Во-первых, можно выделить следующие вызовы, которые обусловили необходимость внедрения Agile в Сбербанке:
1. Низкая скорость внедрения изменений, например, данные о времени, необходимом для внедрения некоторых продуктов Сбербанка на рынок с момента начального замысла представлены в табл. 1. Таким образом, из данных табл. 1 видно, что длительность проекта от экспресс-оценки до внедрения в промышленную эксплуатацию составляет более 2 лет. В современных условиях острой конкуренции на рынке такой длительный срок создания новых банковских продуктов просто неприемлем.
2. Высокий уровень забюрократизованности. Низкая скорость принятия решений. Низкая коллаборативность.
Сильная иерархичность — большинство решений принимаются на высоком уровне. Увеличивающаяся конкуренция со стороны более мелких и гибких игроков банковского сектора и финтех-стартапов.
Большинство крупных банков в мире сталкиваются со схожими вызовами, и пионеры в области изменений решают возникающие вызовы с помощью Agile-трансформации. Ориентируясь на успешный опыт руководство Сбербанка приняло решение внедрить Agile в практику компании. Топ-менеджментом были поставлены следующие цели Agile-трансформации в Сбербанке:
• суперкороткое время вывода продукта на рынок — способность выводить новую функциональность в продуктив каждые две недели;
• максимальная удовлетворенность клиентов за счет предоставления продуктов, которые соответствует их потребностям и желаниям;
• лучший на рынке клиентский опыт;
• №1 на рынке среди работодателей по удовлетворенности и вовлеченности сотрудников;
• непрерывные и быстрые улучшения продуктов и процессов за счет внешних и внутренних инноваций;
• повышение эффективности и продуктивности персонала.
В рамках адаптации методологии Agile к специфике Сбербанка в организации родился специальный термин «Sbergile», под которым понималась методология для разработки и поддержки продуктов в Сбербанке, основанная на ценностях гибких подходов к разработке продукта.
Планируется, что внедрение Agile позволит перейти от иерархичной структуры к Agile-структуре, в которой не будет традиционных подразделений, которые специализируются на процессе/продукте, а будут трайбы, кросфункциональные команд с включением в них бизнес-экспертов и ИТ-специалистов.
Следует отметить, что руководство банка понимало, что ключевым условием успешности Agile являются не методы, не технологии и даже не опыт, который банк в силу наличия значительных финансовых ресурсов всегда может купить, а организационная культура. Именно поэтому была поставлена цель не просто трансформировать подходы к организации работы проектных команд, но произвести изменения в головах работников, инициировать в их сознании уход от индивидуальных интересов. Для этого необходимо понимать, к чему стремиться банк и чем готово пожертвовать руководство и сотрудники банка, задействованные в трансформации.
Внедрение Agile в банке в первую очередь потребовало развития «soft-skills» сотрудников, ключевые из них представлены в табл. 2.
Таблица 1
Время от начального замысла до внедрения на рынок по некоторым продуктам Сбербанка
Банковский продукт Время внедрения (в месяцах)
Копилка - сервис Сбербанка для накопления денег на счете 27
Автоперевод P2P - перевод с карты на карту (временное решение) 29,3
СБНКД (Сбербанк на каждый день) - комплекс продуктов, которыми клиент может пользоваться каждый день (мобильный банк, «Спасибо от Сбербанка», автоплатеж и т. д.) (оформление базового пакета) 15,1
СБНКД (новые карточные продукты Momentum Classic) 21,9
Тарифный план «Золотой» 15,7
Таблица 2
«Soft-skills» сотрудников, необходимые для эффективной реализации Agile-подхода в банке
Базовый «soft-skill» Характеристика компетенции
Самоорганизация Берет на себя ответственность за результат и самостоятельно решает как выполнить задачу и какую роль на себя взять в ее выполнении, в условиях, когда известен лишь образ результата
Коллаборация Быстро и эффективно находит решения, вовлекая других и делясь своим опытом и идеями с другими, ставит командный результат выше личных интересов
Эмпатия Способен представить себя на месте другого человека и понять его чувства, желания, идеи и поступки для того, чтобы сделать взаимодействие с ним наиболее эффективным
Признание ошибок Стремится обсуждать свои ошибки с коллегами, анализировать причины их возникновения и извлекать уроки для минимизации их повторения в дальнейшем
Психологическая безопасность Поддерживает в команде особую атмосферу, позволяющую свободно высказывать свою точку зрения, давать предложения и действовать самым необычным, нестандартным методом без страха негативной реакции со стороны команды
Фокус на результат Предпочитает проверить идеи на деле, вместо длительного согласования
Постоянное совершенствование Ищет пути улучшить работу организации
В периметр первой волны внедрения Agile в Сбербанке попало около 1800 сотрудников, представителей розничного блока и блока «Технологии».
Можно выделить 3 ключевые сферы работы с использованием Agile в банке в настоящее время — это мобильные приложения, единая фронтальная система (ЕФС), платформа поддержки развития бизнеса (18+). В первой группе представлены такие продукты как: персональный финансовый менеджмент, документы, аватар/мессенджер, сбербанк-онлайн (мобильная версия) и др.
Сбербанк открыл новую стратегическую программу «Создание платформы поддержки развития бизнеса (18+)», в рамках которой инновационные технологии будут повышать производительность, снижать совокупную стоимость владения ИТ-инфраструктурой группы, сокращать срок запуска новых продуктов.
Самой крупной пилотной площадкой стала программа «Единая фронтальная система», многие проекты которой уже успешно использует гибкую методологию. Для знакомства с основными практиками Agile блок «Технологии» совместно с дирекцией программы был организован семинар «Погружение в Agile».
Далее рассмотрим процедуру трансформации. В табл. 3 представлен шаблон плана внедрения Agile-методологии, который был определен в качестве базового для первой волны внедрения в Сбербанке.
В рамках трансформации банк планирует перейти от функционально-ориентированных подразделений к трайбам, объединяющим кросс-функциональные команды для удовлетворения макропотребностей клиента. Согласно типам решаемых задач, трайбы и команды в Сбербанке могут быть двух типов:
1) клиентоориентированные:
• реализуют элементы бизнес-задач и клиентского опыта, например, продукты или клиентские путешествия;
• позволяют построить сквозной клиентский опыт;
• состоят из кросс-функциональных специалистов, способных самостоятельно создать и выпустить продукт/сервис;
• управляются руководителем розничного блока;
2) платформенные:
• создают базовые модули платформ, предоставляющих стандартные сервисы множеству других команд;
• используются в случаях, когда сложность модуля и/или взаимосвязей с другими модулями требует вовлечения нескольких технических специалистов с глубоким знаниями. Обеспечивают архитектурную целостность;
• состоят преимущественно из технических специалистов, создающих автономный модуль платформы и устойчивые алгоритмы;
Таблица 3
План внедрения Agile-методологии в первую волну внедрения
Направления изменения Действия в рамках плана внедрения
Структура организации Назначить лидеров трайбов первой волны внедрения
Назначить лидеров компетенций, лидеров чаптеров и владельцев продуктов первой волны внедрения
Определить пофамильные списки команд первой волны внедрения
Обучение Провести обучение критических ролей (в том числе лидеров трайбов) первой волны внедрения
Провести обучение участников команд первой волны внедрения
Процессы Определить подход к управлению программами и бюджетированию
Внедрить утвержденную структуру бюджетов
Agile-процесс Провести фокус-группы и доработать производственный процесс
Детализировать план по внедрению ЭеуОрн
Экспертиза Agile Нанять и подготовить Agile-коучей
Ко-локация Разработать план перемещения сотрудников
Завершить ремонт помещений и монтаж мебели
Начать переезд сотрудников и старт работы команд
оо
о
CN
со
CN
J <
СО
ПРАВО • МЕНЕДЖМЕНТ • МАРКЕТИНГ
Клиентоориентированные трайбы
Общие принципы
Платформенные трайбы
оо
О CN
со
CN
J <
СО
Клиенто-центричность
Продукт, канал, сегмент в одном трайбе
Омниканальность
Гарантия целостности
Распределенное внедрение
Удовлетворение определенной потребности клиента
По возможности соединять продукт, управление каналами, сегмент в одном трайбе
Каждый Трайб ответственен за клиентский опыт в каждом канале
Целостность каналов и систем обеспечивается Чаптером
Создаются команды для реализации программ, управляющиеся по специальным правилам
К
/
Трайб или команда должны производить законченный, готовый для использования, продукт
Число переходов и зависимостей
межцу трайбами/ командами должно быть минимальным
■и
-О CD
S
и о
u>
не должен превышать "10 человек («2 пиццы»), размер кластера/трайба-150 человек, трайба при наличии кластеров -1 500 человек
Архитектурная целостность
Централизация экспертизы
Повышение стабильности
Переиспользуемость
^змер KOMav,fX
Рис. 4. Базовые принципы формирования трайбов в Сбербанке
При создании новых платформенных и общеиспользуемых модулей
Платформенных специалистов
За счет снижения частоты изменения платформы
Идентичного стандартный функционал используется большим числом трайбов (напр. электронные подписи, главная книга и т.д.)
• управляются руководителем блока ИТ.
Ключевые базовые принципы формирования трайбов в Сбербанке приведены на рис. 4. Основной принцип формирования трайбов — самодостаточность для удовлетворения конкретной потребности.
Каждый трайб и каждая команда могут самостоятельно определять свое название и миссию. Название — любое наименование, помогающее идентифицировать команду. Миссия — основная цель команды\трайба, смысл ее существования. В банке приветствуются оригинальные названия, которые могут мотивировать участников.
В «первую волну» трансформации в Сбербанке были выделены 7 трайбов, сфокусированных на макропотребностях клиента, и один платформенный трайб:
1) чувствовать себя уникальным/mass personalization;
2) иметь банк всегда с собой/digital business platform;
3) занять и сберегать/соге banking products;
4) карточные продукты/card solutions;
5) заплатить и перевести/payments&transfers solutions;
6) Сбербанк всегда рядом/банк рядом;
Рис. 5. Связь стратегии компании с работой команды
7) чувствовать заботу и поддержку/customer care;
8) базовые платформенные сервисы.
Далее рассмотрим каким образом в новых условиях была налажено целеполагание и приоритезация работы участников Agile-проектов.
Целеполагание и приоритезация работы в Agile
В данной работе под целеполаганием будет пониматься каскадирование ключевых показателей эффективности организации (КПЭ) и ее стратегических тем.
Постановка всех задач в Agile ведется по принципу «что/как». Вышестоящий уровень ставит задачу в форме «что сделать» или «какой цели нужно достичь», а нижестоящий уровень сам определяет «как» делать. При этом очень важный момент — вышестоящий уровень не должен вмешиваться в то «как» нижестоящий уровень будет выполнять задачу.
Контроль за исполнением задач в данном случае осуществляется на демонстрациях продуктов и КОРТ (квартальный обзор результатов трайба). Целостность подходов к работе и архитектуры, соблюдение стандартов поддерживается механизмом чаптеров и архитекторами/технологами.
В базовом сценарии методологии постановка задач осуществляется руководителем организации, куратором трайба, лидером трайба, которые обозначают, что нужно сделать куратору трайба, лидеру трайба, владельцу продукта и команде. Куратор, лидер трайба и владелец продукта — решают «как» лучше декомпозировать задачу. Участники команды сами решают «как» выполнить задачу, в рамках стандартов чаптера, а также архитектурных стандартов.
В случае, когда трайб участвует в программе, для программных задач кто-либо в роли президента, куратора программы, руководителя программы ставит задачу куратору программы, руководителю программы, лидеру трайба. Они решают «как» лучше декомпозировать программную задачу.
Стратегия — план на уровне компании, определяющий ее миссию, главные ориентиры для роста и комплекс мер для достижения бизнес-результата. Для
связи стратегии компании с работой команды в Agile используется 5 артефактов:
• Стратегическая тема — способ достижения бизнес результата в определенном сегменте бизнеса или функциональной области с конкретным набором КПЭ.
• Стрим трайба — способ достижения бизнес результата в определенном подсегменте бизнеса или функциональной подобласти с конкретными КПЭ, привязанными к КПЭ стратегической темы.
• Эпик — описание клиентского опыта с продуктами или сервисами организации (описание инструмента или логически обособленного набора функций).
• Фича — описание одной из составляющих клиентского опыта с продуктами или сервисами организации (описание одной из составляющих инструмента или набора функций).
• История — пример цельного клиентского опыта с продуктами или сервисами команды (набор элементарных компонент функции или инструмента). Взаимосвязь этих артефактов, а также последовательность их реализации приведены на рис. 5.
Каждый уровень управления обладает максимальным уровнем самостоятельности при декомпозиции и определении подхода и способа реализации, поставленной перед ним задачи.
Пример связей стратегии организации с работой команд приведен на рис. 6. В данном случае представлен кейс Сбербанка, который внедрил Agile в работу розничного и ИТ-блоков.
Можно выделить следующие базовые положения Agile-целеполагания в Сбербанке:
1. Планирование деятельности осуществляется по стримам трайбов и программ на следующие 6 кварталов (суперспринтов).
2. Синхронизация целей и стратегических тем, корректировка стримов происходит каждый квартал на церемонии КОРТ.
3. Порядок и способ реализации стримов трайбов и программ определяется трайбом самостоятельно c учетом приоритетов программ.
4. Программа добавляет трайбу стримы программы и релевантные КПЭ. При отсутствии дополнительных ресурсов, реализация стримов трайба сдвигается на срок реализации стримов программы.
5. Трайб отвечает за достижение время вывода продукта на рынок и релевантных показателей (например, P/L (profit and loss), NPS (net promoter score), доля рынка, надежность, доступность, стоимость и т. д.).
6. Команда отвечает за время вывода продукта на рынок и релевантные зоне ответственности показатели (например, usage, удовлетворенность продуктом или сервисом, доступность операций и другие).
7. Если за реализацию стрима отвечает более одной команды, то ответственность за релевантные показатели распространяется на все команды в равной степени.
Схема каскадирования задач и КПЭ в Сбербанке в рамках Agile приведена на рис. 7.
Правление отвечает за реализацию стратегии банка, которая декомпозируется и каскадируется на нижестоящие уровни управления. Для этих целей оно задает стратегические темы и КПЭ (ключевые показатели эффективности), далее распределяет стратегические темы и КПЭ по членам правления (выступающим в роли кураторов трайбов), определяет приоритет стратегических тем/программ.
Далее куратор группы трайбов распределяет стратегические темы и КПЭ по трайбам. И после этого трайб самостоятельно определяет подход к реализации стратегических тем через определение стримов трайба, далее защищает стримы и планы их реализации на КОРТ, а также отвечает за достижение КПЭ стратегических тем (например, P/L, NPS, доля рынка и т. д.).
Рис. 6. Пример связей стратегии банка с работой А^Це-комаид в Сбербанке
оо
о
CN
со
CN
J <
со
Рис. 7. Принцип каскадирования задач и КПЭ в Agile-организации
И, наконец, команда самостоятельно определяет эпики, фичи и истории для реализации стримов трайба, отвечает за реализацию эпиков, фич и историй, отвечает за достижение релевантных исполняемой задаче бизнес-показателей и времени вывода продукта на рынок.
Кураторы программы в рамках своего функционала каскадируют стратегические темы и КПЭ на программы. После этого руководитель программы самостоятельно определяет стримы программы на основании стратегической темы, распределяет стри-мы и КПЭ программы между классическими проектами (при необходимости) и трайбами, участвует в утверждении стримов и планов их реализации на КОРТ и в классическом проектном управлении, отвечает за синхронизацию работ трайбов и проектов по стримам программы, контролирует исполнения целей трайба ведется на церемониях КОРТ, Business review, демонстрациях продуктов трайбов/команд, бэклогах команды.
КОРТ — это встреча куратора с лидерами всех его трайбов, для обсуждения результатов трайбов в прошлом квартале и планов трайбов на следующий
Visible
Invisible
Ценность для клиента (эпики, фичи, истории) Architectural Runway (эпики, фичи, истории)
Дефекты Технический долг
Рис. 8. Варианты типов задач в бэклоге
квартал. Длительность данной процедуры составляет 1-2 рабочих дня. Она осуществляется на ежеквартальной основе. Участниками КОРТа являются: куратор, лидеры всех трайбов куратора, руководители программ (при необходимости).
Целями данной процедуры выступают: обсуждение результатов суперспринта, планирование следующих 6 суперспринтов, планирование стримов следующего суперспринта и их приоритизация.
Следующая важная процедура — business review. Это регулярная встреча куратора с лидерами трайбов. Ее цель: синхронизация информации по статусам реализации у куратора и лидеров трайбов, решение открытых вопросов. Длительность: 1-2 часа. Регулярность: 1 раз в месяц. Участниками business review являются: куратор, лидер трайба/кластера, кураторы программ (при необходимости).
Одной из важнейших регулярных мероприятий трайба является демонстрация продукта трайба. Она проходит во время выполнения последнего спринта суперспринта, в ходе которого проводится демонстрация результатов всего трайба заинтересованным лицам. Длительность данной процедуры составляет, как правило, 2-4 часа. Ее периодичность — 1 раз в суперспринт. Ее участниками являются: лидер трайба, скрам мастер трайба, владельцы продукта, скрам мастеры, архитекторы программ, (при необходимости), представители команд и все другие заинтересованные лица.
Для реализации стримов трайба команды детализируют стримы в бэклоге команды. Бэклог команды — это перечень всех требований к стриму трайба/ программы, переданных в команду либо созданных внутри нее. Решение о включении элемента в бэклог и его приоритете принимает владелец продукта, который постоянно обновляет его, собирая сведения из множественных источников. В бэклоге должны быть только необходимые элементы. Бэклог команды фиксируется на доске команды и отражается в производственной системе (например, Jira).
Источниками элементов бэклога могут выступать: владелец продукта, команда, другие команды, сам трайб. Можно выделить следующие элементы бэклога: эпики, фичи, истории (могут быть пользовательскими либо техническими), техдолг, дефекты и др.
Бэклог состоит из разных типов задач, они представлены на рис. 8.
Ключевое значение в бэклоге играет пользовательская история. Что это такое? Это просто высказанное пожелание пользователя, имеющее ценность с точки зрения бизнеса, другими словами, это краткий и простой рассказ, написанный от лица пользователя.
«Рецепт» пользовательской истории достаточно прост, она может формулироваться по следующему скрипту: «Будучи <роль>, я хотел бы <элемент>, чтобы получить <преимущество>». По данной схеме можно сформулировать следующие примеры пользовательских историй:
• «Будучи туристом, я хотел бы забронировать номер в отеле, чтобы у меня было, где остановиться».
• «Будучи человеком, составляющим планы на отпуск, я хотел бы видеть фотографии отелей, чтобы решить, где я хочу остановиться».
• «Будучи клиентом, имеющим бронь в отеле, я хотел бы отменить ее, чтобы получить возврат денежных средств».
• «Будучи владельцем отеля, я хотел бы видеть отчет обо всех отменах брони, чтобы проанализировать их».
Важный момент, при формулировке пользовательской истории следует помнить, что, что «роль» — это фактический конечный пользователь, а не какая-либо система или лицо, например: отдыхающий, владелец отеля, сотрудник турагентства, человек, планирующий свой отпуск, или родитель ребенка.
Пользовательские истории можно считать достаточно качественными, если они отвечают критериям INVEST»:
отдельность (independent) — упрощение планирования;
возможность обсуждения (negotiable) — совместное определение подробностей; выгода (value) — «каким будет результат?»; измеримость (estimable) — «избыточный размер/ неопределенность?»;
уместность масштаба (sized appropriately) — «возможность реализации за неделю?»; проверяемость (testable) — критерии приемки пользователем.
В пользовательскую историю также включатся критерии приемки. Их структура выглядит следующим образом: «Учитывая <определенные условия>, когда <выполняется действие>, <происходит следующее>». Критерии приемки могут выглядеть следующим образом:
• «Учитывая, что я привилегированный клиент, когда я отменяю бронь меньше чем за 24 часа до приезда, с меня не взимается неустойка».
• «Учитывая, что я непривилегированный клиент, когда я отменяю бронь меньше чем за 24 часа до приезда, с меня взимается неустойка в размере 50%».
• «Учитывая, что я зарегистрирован на сайте, когда я отменяю бронь, мне направляется подтверждение по электронной почте».
Качественная история — это история, которую можно целиком записать на одной карточке, а критерии приемки — на ее обратной стороне.
Таковы основные моменты целеполагания в Agile. Как видно из обзора инструментов, используемых для этих задач в Сбербанке, данная методология предполагает разнообразные подходы на каждом из уровней. С одной стороны, в ней обеспечена четкая взаимосвязь задач, стоящих перед каждой конкретной командой, и стратегией организации, с другой стороны, на уровне конкретных исполнителей предусмотрена возможность внесения корректив в планы работы исходя из новых пользовательских историй и других конкретных факторов, влияющих на их деятельность. В данном подходе значение менеджеров полностью меняется, кураторы, владельцы продуктов, руководители программы, лидеры трайба и другие условно руководящие роли в Agile — выступают больше в качестве кочеров, контроллеров деятельности, мотиваторов к саморазвитию членов команд. Таким образом, внедрение Agile в организации потребует не только пересмотр организационной
структуры компании, но и полное переформатирование представление руководителей о сути управленческой деятельности. Данная методология только начинает осваиваться отечественными компаниями, поэтому можно спрогнозировать, что в ближайшее время интерес к обозначенным вопросам будет только повышаться. Также потребуется пересмотр подходов к мотивации и стимулированию участников Agile-проектов, а также их сопоставление с действующие инструментами, используемыми в проектном управлении.
Заключение
Как следует из обзора Agile-методологии данный подход применим не только к управлению ИТ-проектами, но и проектами вообще.
Опыт Сбербанка, который был проанализирован в работе, показал, что данное направление крайне актуально для отечественного бизнеса, в силу того, что успешные производство, реализация продуктов и осуществление услуг в современных условиях малоперспективны без опоры на ИТ, и значит нужно осваивать новые подходы к организации своей деятельности, выстраивать эффективное управление всеми участниками Agile.
Таким образом, Agile-методология является прогрессивным подходом к организации работы проектных групп, которая имеет перспективы использования в различных областях деятельности. Бесспорно, в данном случае потребуется значительная работа по доработке Agile-подхода, но его ключевое преимущество в гибкости и значит он легко может быть адаптирован к любым условиям.
Список использованных источников
1. K. Schwaber, J. Sutherland. The scrum guide. Published by Scrum. Org and Scrumlnc. 2016. http://www.scrumguides.org/docs/ scrumguide/v2016/2016-Scrum-Guide-US.pdf.
2. Х. Книберг. Scrum и XP: заметки с передовой = Scrum and XP from the trenches. C4Media, 2007
3. М. Кон. К64 Scrum: гибкая разработка ПО/Пер. с англ. М.: ООО «ИД Вильямс», 2011. 576 с.
4. М. Кон. Пользовательские истории. Гибкая разработка программного обеспечения = User Stories Applied: For Agile Software Developme. М.: Вильямс, 2012. 256 с.
5. Дж. Сазерленд. Scrum. Революционный метод управления проектами. М.: Манн, Иванов и Фербер, 2016. 288 с.
Capabilities of organization goal cascading among the participants of agile-projects R. A. Dolzhenko, doct. sc. (econ.), deputy vice-rector for research, chair of labor economics and personnel management department, Ural state university of economics.
The article considers the essence of the Agile-approach, which is actively used by IT, also by other business companies as a special form of project activities in the organization. Taking into account the new requirements for organizing the activities of participants in Agile-projects, the question becomes urgent: how in this approach, which is new for organizational practice, manage the goal setting of employees? The experience of Sberbank, which among the first domestic companies began to use Agile in its activities, was able to organize the work of the employees of the Retail and IT blocks in a new way was highlighted. The tools for systematically cascading the goals and tasks facing the Agile-organization from Managers to the direct executors of the project teams was studied.
Keywords: innovation, project management, Agile, flexible development methodology, project activity, goal setting, team management.
oo
о
CN
со
CN
J <
CQ О
