Сегодня мы находимся на третьей волне Agile, которая характеризуется стремлением бизнеса адаптироваться быстро и оптимально к динамичным внешним условиям с использованием гибких подходов и практик. Базовый механизм, гарантирующий создание свойства адаптации, заключается в переосмыслении жесткой иерархической структуры управления в сторону подвижной, ориентированной по направлению доставляемой ценности конечному потребителю [1].
Стоит отметить, третья волна является характеристикой предложения со стороны сообщества экспертов и управленцев, практикующих Agile подходы в контексте организаций. Однако, сами организации могут находится на первой, второй волне или вовсе быть за рамками потока.
В данной статье будет сделана попытка ретроспективно описать эмпирический опыт поиска волн для компании, находящейся в данный момент вне гребня. Запрос на поиск своей волны обусловлен тремя простыми причинами:
Сформирован положительный организационный прецедент, при котором появилась самодостаточная и самостоятельная бизнес единица, ориентированная по отношению цепочки доставки ценности потребителям. Данный прецедент характеризует первую волну и восхождение на вторую в части масштабирования.
Компания, находящаяся в поиске своей волны, открывает карьерные и корпоративные политические возможности для управленцев и лидеров. Соответственно, инициация поиска со стороны руководства запустила процесс диверсификации организационных рисков.
Сформулированная потребность на изменения, позволила активировать творческий процесс поиска ответов на свои вопросы и отсеять страх при выдвижении и апробации организационных гипотез.
Данная статья может быть интересна управленцам-эмпирикам, которые считают организацию самообучающейся системой и их роль заключается в том, чтобы создавать и поддерживать механизмы самообучения.
Организационная структура
Организация за 20 лет выросла в крупного IT интегратора на Российском B2G рынке, как с точки зрения продуктовых решений, оборота, так и сотрудников, которые занимаются развитием и поддержкой данных решений. На протяжении всего времени, модель организационной структуры блока, где собственно появилась потребность в трансформации, развивалась в функциональной парадигме и выросла до 7 уровней иерархии административных руководителей.
Уровень 1 – уровень управления высшего звена, который отвечает непосредственно за показатели и развитие организации перед акционерами.
Уровень 2 – уровень управления высшего звена, который отвечает за доставку решения на обозначенные сегменты рынка B2G под ключ.
Уровень 3 – уровень управления высшего звена, который отвечает только за имплементацию и развитие своих функций в контексте портфолио дирекции и стратегии.
Уровень 4 – уровень управления среднего звена, который отвечает только за имплементацию и развитие функций департамента в контексте обозначенного решения.
Уровень 5 – уровень управления среднего звена, отвечающий за развитие и имплементацию набора связанных по смыслу функций в контексте департамента.
Уровень 6 – уровень управления младшего звена, отвечающий за развитие и имплементацию выделенной функции в контексте управления департамента.
Уровень 7 – уровень управления младшего звена, отвечающий за приоритезацию работ в контексте своей функции для разрабатываемого решения.
Уровень 8 - исполнители с обозначенной функцией, использование которой, обеспечивает доставку работ в контексте разрабатываемого решения.
Существующая модель организации имеет ряд интересных особенностей, которые характеризуют специфику и ритм разрабатываемых решений:
Продуктовая модель управления начинается и заканчивается на уровне 2, где организационные блоки характеризуют рынки, заказчиков и поставляемые решения.
Уровень 3 выстроен по своим выделяемым функциями дирекции, и задан правилами руководителя с уровня 2. Дирекция производства отвечает за функции (анализ, проектирование, разработка, тестирование, поставка), обеспечивающие доставку портфолио решения для бизнес-дирекции. Бизнес дирекция отвечает за функции (ресурсное планирование, финансовое планирование, контрактование, управление составом работ, взаимодействие с заказчиками, управление ожиданиями, сопровождение), обеспечивающие финансирование деятельности организации.
Взаимодействие производственной дирекции и бизнес-дирекции имеет конкурентный характер, а не коллаборативный. Данная позиция смещает фокус с поиска решения для развития на создание дополнительных границ в виде регламентов, которые в свою очередь увеличивают время доставки решения.
Модель организации Уровень 4 – Уровень 7, как следствие, наследуют функциональную модель организации с уровня 3.
Проработка инициатив по развитию подходов к разработке и доставки решения происходят только на Уровень 4 – Уровень 5. Данная позиция организации противоречит принципу «Гемба-Кайдзен» при которой изменения в компании должны идти от непосредственно исполнителей.
Все мероприятия по развитию подходов рассматриваются вне разрабатываемых решений и имеет свою модель финансирования.
На Уровень 4 – Уровень 6 закрепились в основном ветераны компании (стаж работы от 10 лет), которые снижают риски своей лояльностью и предоставляют гарантию стабильности для компании.
Среднее время выпуска инкремента решения составляет от 2 до 4 месяцев и имеет неритмичный характер.
В одном производственном департаменте Уровень 4 – Уровень 6, может присутствовать до 15 отделов со своими функциями (отдел прикладного тестирования, отдел системного анализа, отдел прикладной разработки и т.д.), что свидетельствует о сильной бюрократизации модели управления.
Приведенная организационная модель и ее особенности являются отправной точкой для планирования изменений и сравнения эффекта от их имплементации. Выдвинем следующие организационные гипотезы для проверки:
Существует такая альтернативная модель организации, при которой количество уровней иерархии снижено до 4х и менее, и обладает такой же стабильностью и повышенной гибкостью.
Существует такая альтернативная модель организации, при которой разработка и доставка решений имеет инкрементно-итеративный характер.
Целевая продуктовая организационная структура
В целях проектирования целевой продуктовой модели организации, был выбран фреймворк SAFe 5.0. Данный выбор обусловлен следующими особенностями:
В организации эмпирически сложилось так, что над одним портфолио работают до 400 человек, над программой работают от 30 – 60;
В организации существует большое количество иерархий, которые могут идеально вписаться в предлагаемые фреймворком уровни с точки зрения контекста и управления.
Наличие крупного сообщества и базы знаний у фреймворка SAFe.
Наличие непрерывного развития фреймворка SAFe.
Наличие успешных историй внедрения SAFe в крупных компаниях [2].
В целевой схеме предлагается воплотить два базовых принципа: сократить количество уровней иерархии с 8 до 4; выстроить управление на каждом уровне в разрезе контента по направлению цепочки доставки ценности стейкхолдерам, а не функциональным компетенциями.
Уровень 1 – данный уровень остается без изменений и по-прежнему характеризуется трансляцией интересов акционеров и бизнеса на организацию. На данном уровне присутствуют минимальные риски принятия, так как в существующей модели верхний уровень выстроен по отношению доставляемой ценности на определенный сегмент B2G рынка.
Уровень 2 – данный уровень потребует больших волевых усилий для организации и переосмысления. Во-первых, придется упразднить уровни «Блок» и «Дирекция», так как они нагружают систему избыточными административными уровнями, находятся дальше всего от источника информации, а также определяют функциональную парадигму управления. Во-вторых, данный уровень необходимо будет выстроить по отношению доставляемой ценности, и эта активность предъявляет другие навыки, компетенции, отличные от функциональной модели управления. В-третьих, данную нишу займут сотрудники с 4 уровня существующей модели управления, так как они ближе всего находятся к источнику информации, определяют облик решения и подходов по реализации.
Результатом работы данного уровня будет являться доставка ценности решений для стекйхолдеров, входящих в портфолио. Перед данным уровнем стояли бы качественно новые проблемы для решения:
Определить операционный стрим заказчика
Определить стратегические темы и видение портфолио
Создать механизм бережливого финансирования
Создать механизм бережливого управления проектами (LPM)
Управлять и поддерживать бэклог портфолио
Создать систему метрик, оценивающих ценность доставляемых решений
Запустить непрерывной пайплайн доставки и поддержки портфолио
Организация и дальнейшее развитие данного уровня характеризовало бы переход организации на третью волну гибкости – бизнес гибкость (business agility).
Уровень 3 - данный уровень бросает вызов наследованной модели функционального управления через линейных руководителей для адаптации сотрудников с уровня «групп» для новой роли. Результатом работ уровня программы является доставка и поддержка инкремента решения по направлению потока работ.
Перед данным уровнем стояли бы качественно новые проблемы для решения:
Определить и запустить непрерывный пайплайн доставки решений
Создать и поддерживать бэклог программы
Создать и поддерживать видение программы
Применять продуктовые практики клиентоориентированности и дизайн мышления
Обеспечить кросс доменную синхронизацию и интеграцию
Обеспечить выполнение бизнес целей
Организация и дальнейшее развитие данного уровня характеризовало бы переход организации на вторую волну – масштабируемая гибкость (Agile at scale).
Уровень 4 - данный уровень, с точки зрения имплементации, внедряется без особых трудностей, так как сотрудники всегда делают все возможное со своей стороны для доставки результата, и если есть какие-то проблемы, то они должны рассматриваться в плоскости системы. Система как раз и определяется выше стоящими уровнями. Результатом работы данного уровня является выпущенные новые функциональности по направлению цепочки доставки ценности.
Перед данным уровнем стояли бы качественно новые проблемы для решения:
- Научиться применять гибкие мета-фреймворки (Scrum, Kanban, XP);
- Научиться управлять и развивать бэклог команды;
- Определять и задавать цели
- Уметь самоорганизовываться и самообучаться
- Уметь доставлять работоспособный инкремент итеративно
- Формировать свое видение и брать за это ответственность
Организация и дальнейшее развитие данного уровня характеризовало бы начало пути и поиск первой волны гибкости – гибкая команда (Agile Teams). Стоит отметить, что принятие гибкой команды в качестве меты обеспечивает непрерывный процесс поиска остальных волн. В противном случае, о продуктовой модели организации можно забыть, если отсутствует понятие кроссфункциональной команды.
В выше перечисленных разделах статьи были приведены две модели организационной структуры:
Модель 1 – существующая функциональная модель управления со своими высокоуровневыми особенностями.
Модель 2 – проектируемая модель продуктового управления с использованием фреймворка SAFe.
В данной статье рассматривается лишь маленький участок трансформации из Модели 1 в Модель 2 в части организации Уровня 4 – формирование гибких команд. Рассмотрение этого участка происходит через призму взаимодействия со стекйхолдерами, используемых подходов и практик, а также имплементацию с фиксацией измеримых метрик.
Синхронизация в производственном департаменте
Запрос на изменения исходил от директора дирекции (уровень 3) производства, где было предложено рассмотреть один из производственных департаментов с более лояльным директором к изменениям. В данном департаменте, как и в остальных, существовала своя методология (фреймворк), развиваемая на протяжении 20 лет. Данный фреймворк является интересным явлением для анализа, так как характеризует эволюционный процесс адаптации организации к внешним условиям и ограничен внутренним корпоративным опытом. Однако, накопилась критическая масса, при которой единственной адаптацией для выживания организации является переосмысление устоявшихся подходов и создание новых с использованием внешнего опыта.
Цели синхронизации с производственным департаментом:
Сформировать рабочую группу лидеров изменений на уровне начальников управлений;
Определить и зафиксировать понятие кроссфункциональной команды
(Agile Team);Определить и зафиксировать понятие команды кроссфункциональных команд (Team of Agile Teams)
Выбрать объект апробации Модели 2;
После достижения выше обозначенных целей, появилась общая позиция в части возможности применения гибкого фреймворка на проектах бизнес департамента.
Этап 1. Формирование рабочей группы
Рабочая группа включила в себя сотрудников, обладающих наибольшими административными полномочиями для принятия решений в департаменте: директор департамента, начальники управлений. Департамент организационно делился по функциональному признаку на три управления: управление обеспечения качества (УОК), управление анализа и проектирования (УАП), управление разработки и архитектуры (УРА). У каждого управления были свои отделы, наследующие функциональный признак деления.
Формирование рабочей группы с участием руководителей отделов не имело смысла, так как данный уровень больше направлен в сторону тактических задач, когда как управление направлено на стратегию департамента.
При формировании рабочей группы были достигнуты следующие договоренности:
Формат работы рабочей группы: еженедельные сессии по синхронизации.
Выразили необходимость изменений как вектор развития департамента
Выразили приверженность целям синхронизации
Этап 2. Определение кроссфункциональной команды (Agile Team)
По своему определению кроссфункциональная команда – группа сотрудников со всеми необходимыми знаниями и навыками, способные определить, реализовать, валидировать и доставить инкремент решения. Данное определение являлось сложным для восприятия, так как противоречило существующей модели функционального управления и заводило в когнитивный тупик.
Выйти из тупика позволила принятая всеми идеализированная картина мира: Существует такая команда, которая в состоянии самостоятельно разрабатывать и поставлять часть решения без участия административного персонала. Данная картина мира имеет право на существование, пока не доказано обратное.
После того как была принята идеализированная картина, каждый начальник управления предложил свое видение, кто должен войти в кроссфункциональную команду с сопоставлением существующих ролей с ролями продуктовой модели. После нескольких итераций, сложилось общее понимание какие роли из функциональной модели необходимы для формирования команды.
Из интересного стоит отметить, что в ходе дискуссии были исключены все роли с административными полномочиями (руководители групп, начальник), и часть ролей были упразднены с перераспределением их функций на другие роли. Достигнув общей позиции в вопросе кроссфункциональной команды, был осуществлен переход к следующему этапу, где команды имеют разную топологию и разный способ взаимодействия.
Этап 3. Определение команды кроссфункциональных команд (Team of Agile Teams)
Предыдущий этап позволил осмыслить и допустить существование команды численностью от 5 до 10 человек. Однако, чтобы разрабатывать и доставлять решения, над которыми работают на текущий моменты времени от 50 сотрудников, мы снова идеализировали картину мира:
Существует топология команд и такие способы их взаимодействия, которые обеспечивают разработку и доставку решений без участия сотрудников с административными функциями. Была предложена следующая модель топологии команд [3]:
Модель топологии команд и их способ взаимодействия была наложена на существующие отделы управлений, чтобы понять какие компетенции необходимо включить в какие команды для доставки ценности в контексте программы. По результатам нескольких сессий была выработана синхронизированная позиция в части вектора изменений отделов управлений в сторону продуктовых механизмов.
Результатом работ на данном этапе является спроектированная конфигурация команд, которая обеспечивает самостоятельную разработку и поставку решения без участия сотрудников с административной ролью.
После достижения общей позиции по вопросу масштабирования кроссфункциональной команды, был осуществлен переход к следующему этапу, где определяли место пилотирования продуктовой модели.
Этап 4. Выбор объекта для апробации модели 2 (продуктовой модели)
Для определения места пилотирования, было принято допущение, что конечным уровнем иерархии с точки зрения содержания результата работ для пользователя является информационная система. Информационная система представляет собой совокупность организационных, ресурсных, технологических, экономических и политических связей в компании. В свою очередь, механизмы взаимодействия данных связей (то каким образом они влияют на содержание) обуславливают форму результата работ.
Использование информационной системы в качестве объекта для апробации новой модели является сложной задачей третьего порядка (400 человек). Для решения данной задачи, было принято допущение:
Существует такой набор элементов с идентичными атрибутами информационной системы, который обладает самодостаточными связями для доставки результата работ конечному пользователю.
Используя данное допущение, мы приняли, что данным и следующим элементом иерархии содержания результата работ является информационная подсистема.
Другими словами, для решения задачи третьего порядка нам понадобиться решить следующие проблемы:
Решить задачу второго порядка, применив продуктовую модель на одной информационной подсистеме в качестве объекта апробации;
Масштабировать продуктовую модель на все информационные подсистемы;
Определить форму доставки результата работ информационных подсистем в контексте информационной системы
В свою очередь, чтобы решить задачу второго порядка, мы в очередной раз сделали допущение:
Существует такой набор элементов с идентичными атрибутами информационной подсистемы, который обладает самодостаточными связями для доставки результата работ конечному пользователю.
Используя данное допущение, мы приняли, что данным и следующим элементом иерархии содержания результата работ является функциональное направление.
Другими словами, для решения задачи второго порядка нам понадобиться решить следующие проблемы:
Решить задачу первого порядка, применив продуктовую модель на функциональном направлении в качестве объекта апробации;
Масштабировать продуктовую модель на все функциональные направления;
Определить форму доставки результата работ функциональных направлений в контексте информационной подсистемы.
Далее, в целях решения задачи первого порядка, мы приняли допущение, что функциональное направление является конечным элементом иерархии и характеризуется самодостаточными связями для доставки результата работ конечному пользователю.
Для решения задачи первого порядка нам понадобиться решить единственную проблему: Определить форму доставки результата работ функционального направления в контексте самого функционального направления.
По результату выбора объекта апробации было принято:
Объектом апробации модели 2 (продуктовой модели) является функциональное направление, как нижний элемент иерархии;
Решение задачи второго порядка начинается после валидации и интерпретации результатов решения задачи первого порядка;
Решение задачи третьего порядка начинается после валидации и интерпретации результатов решения задачи второго порядка;
Синхронизация в бизнес департаменте
Синхронизация в производственном департаменте позволила заинтересованным сторонам переосмыслить существующую модель организации производства в части необходимых действий для перехода к новой модели гибкой разработки. Более того, появилось общее видение и позиция перед синхронизацией с бизнес департаментом, который в свою очередь, в рамках имеющейся специфики компании, должен согласовать апробацию новой модели на своих проектах.
Для синхронизации с бизнес департаментом была подготовлена презентация с использованием материалов, разработанных на этапе синхронизации с производственным департаментом. После нескольких сессий, мы получили приверженность со стороны бизнеса, который выделил часть функциональных направлений информационной подсистемы для апробации модели продуктовой разработки.
Таким образом, мы приступили к решению задачи первого порядка через имплементацию продуктовой модели в функциональном направлении.
Проведение пилотирования
Синхронизация в производственном и бизнес департаменте позволила получить приверженность от заинтересованных сторон и сделать видение трансформации транспорентным, а также получить легальный доступ к команде для апробации модели.
Само пилотирование удобно описать в контексте становления и развития кроссфункциональной команды. Аргументом данного подхода является ранее сформулированная проблема, что определение формы доставки результата функционального направления в контексте самого направления позволит охарактеризовать применимость новой модели и ее влияние на результат.
Этап 1. Подготовка к пилотированию
Данный этап является самым коротким и важным, так как определяет психологический вектор пилотирования и закладывает фундамент для отношений между скрам мастером, владельцем продукта и командой.
Акцент 1. Подготовка и тренинг владельца продукта.
Готовность владельца продукта к изменениям и его расположенность определяют успех данных изменений на 50%, остальные 50% определяются кроссфункциональной командой. При подготовке владельца продукта необходимо сделать акцент на особенностях фреймворка, рассказать про этапы, про ожидания со стороны заинтересованных сторон.
Цель акцента: сформировать команду между скрам мастером и владельцем продукта
Доступные средства: отдельные сессии, презентация с видением пилотирования для владельца продуктаАкцент 2. Знакомство и первый контакт с командой.
Зачастую изменения происходят медленно, что приводит к высокому риску их отторжения, а также повышает когнитивную нагрузку исполнителей для осмысления. Для исключения тупиковых вопросов осмысления со стороны команды, скрам мастеру необходимо задать с самого начала свои правила игры и встроиться в операционные процессы. Данные правила задаются через отдельную kick-off (начальную встречу), где происходит формирование нового культурного фундамента через осмысление общих целей, ценностей и миссии команды.
Цель акцента: заложить новый культурный фундамент и вектор изменений
Доступные средства: общая kick-off сессия, использование любого визуализированного шаблона
Этап 2. Формирование команды (1 - 2 спринт)
После знакомства с командой начинается этап ее формирования в кроссфункциональную, где действуют новые правила, определяемые самой командой под направлением скрам мастера. Данный этап характеризуется внедрением трех атрибутов фреймворка: события, артефакты и визуализация рабочего процесса (Kanban).
Акцент 1. Внедрение событий.
Скрам мастер договаривается с командой об удобном времени каждого события: ежедневный стендап, планирование спринта, обзор спринта и ретроспектива. Более того, задачей скрам мастера становится хранить традиции событий и отвечать на все открытые вопросы, если ставится под сомнение их значимость.
Цель акцента: сделать работу команды ритмичной и дисциплинированной
Доступные средства: опыт и харизма скрам-мастераАкцент 2. Внедрение общих артефактов.
Для команды, в которой сотрудники ранее работали в функциональной парадигме в рамках своей компетенции через тимлидов свойственно иметь собственный набор функциональных артефактов (например, тестовые кейсы, постановка задачи, пояснительная записка, доработки, компонентные доработки, автотесты и т.д.). Соответственно, задачей скрам мастера стоит предложить и внедрить интеграционные артефакты (бэклог продукта, бэклог спринта и инкремент). Далее команда принимает, что функциональные артефакты становятся элементами бэклога, выполнение которых обеспечивает выпуск инкремента с добавленной ценностью для клиента.
Цель акцента: сплотить и сфокусировать работу команды
Доступные средства: опыт и харизма скрам-мастераАкцент 3. Визуализация рабочего процесса (Kanban)
Возвращаясь к проблеме функционального управления, для данной парадигмы свойственно фокусировать внимание только на задачах, находящиеся в данный момент на определенном сотруднике с понятной функцией. Соответственно, задачей скрам мастера является визуализация всего рабочего процесса для обеспечения транспорентности и понимания общей картины для команды.
Цель акцента: транспорентность производственного процесса, воспитание ответственности за общий процесс, понимание влияния на доставку результата
Доступные средства: kanban доски
Этап 3. Стабилизация команды (3 - 8 спринт)
После того как команда научилась работать в ритме событий инспекции и адаптации, настает время для акцентов, влияющих на качество. К таким акцентам относятся критерии завершенности, цепочка доставки ценности инкремента команды и первые вопросы метрик и производительности команды.
Акцент 1. Критерии завершенности
После прохождения этапа формирования, команда научилась выпускать какой-то инкремент. Для наделения инкремента качественными атрибутами, необходимо предложить команде придумать систему критериев, подтверждающих выпуск инкремента. Соответственно, при развитии команды, также будут изменяться критерии завершенности в контексте совершенствования производственного процесса.
Цель акцента: сформировать критерии качества инкремента
Доступные средства: ретроспектива, отдельная сессияАкцент 2. Цепочка доставки ценности инкремента команды
Согласно Деминг У.Э. изменения в системе и ее оптимизация возможны только в том случае, если имеется видение общей картины организационной системы и ее частей. Проектирование цепочки доставки ценности инкремента команды позволяет понять сотруднику общий поток, свое влияние на общий результат и влияние своих коллег. Более того, цепочка доставки ценности является отправной точкой для осмысления метрик.
Цель акцента: сформировать общую картину системы
Доступные средства: ретроспектива, отдельная сессияАкцент 3. Метрики и производительность
Система критериев завершенности и цепочка доставки ценности являются удобными механизмами для выдвижения организационных гипотез с дальнейшей их апробацией. С целью понимания влияния организационных гипотез необходимо с командой разработать систему метрик, которые в свою очередь могли бы оценить эффект от изменений. Система метрик может в свою очередь также эволюционировать от простых (количество решенных проблем, количество выпущенных функциональностей и т.д.) до сложных (velocity, TTM, добавочная ценность и т.д.).
Цель акцента: сформировать систему метрик
Доступные средства: ретроспектива, отдельная сессия
Этап 4. Плато команды (9 спринт)
На данном этапе команда достигает пика своего творческого потенциала и самоорганизации. Произошло изменение формы доставки результата в контексте функционального направления за счет внедрения новых механизмов фреймворка. После решения локальных проблем, влияющих на эффективность доставки результата, команда поднимает вопросы и проблемы, выходящие за ее периметр. Новые проблемы и вопросы лежат в плоскости решения задачи второго порядка: применение продуктовой модели на информационной подсистеме. Соответственно, команда выходит на своеобразное плато, где все внутренние проблемы решены и идет непрерывная доставка ценности своего функционального направления, но существуют проблемы интеграционные между кроссфункциональными командами.
Акцент 1. Поддержка механизмов непрерывной доставки
В том случае, если команда вышла на плато, важно интерпретировать данное время, как возможность улучшения для всей системы в контексте программы. Скрам мастеру необходимо поддерживать мотивацию своей команды и инициировать вопросы о трансформации смежных команд, закрепляя свои аргументы фактами и показателями.
Цель акцента: поддержка и сопровождение внедренного фреймворка
Доступные средства: ретроспектива, ежедневные стендапыАкцент 2. Цепочка доставки ценности инкремента программы
Самое время для команды начать задавать вопросы, выходящие за персональные границы, которые характеризуют способы взаимодействия со смежными командами. Инкремент функционального направления одной команды не является отображением инкремента другой, если не наследуется общая форма. Соответственно, необходимо задуматься об общем инкременте программы в контексте непрерывной цепочки доставки ценности в качестве отправной точки для перехода к решению задачи второго порядка.
Цель акцента: активировать творческий процесс поиска ответов
Доступные средства: встречи со стекйхолдерами производственного и бизнес департамента
В данном разделе эмпирически описаны этапы внедрения фреймворка scrum для одной из команд функционального направления. В следующем разделе будут сформулированы результаты на основании принятых метрик и сделаны выводы с учетом их интерпретации.
Результаты и выводы пилотирования
Формализация результатов и интерпретация метрик в существующей сложной иерархической организационной системе обладает свойством дуализма. Производственный департамент, будучи оркестратором производственной культуры, обладает своим набором системы метрик. С другой стороны, бизнес департамент, отвечающий за доставку результата заказчику, имеет собственную систему метрик для оценки эффективности. Данное обстоятельство принимается как исторически случившийся факт и с точки зрения интерпретации результата пилотирования, было принято собрать метрики с двух позиций и далее найти сходимость мнений для принятия решений.
Данным подходом мы допустили полярность мнений и заложили фундамент к формированию общей системы метрик, которая характеризовала бы показатели организации в целом, а не обособленных организационных единиц. В дополнении стоит отметить, что проблему создания общей системы метрик, было принято рассмотреть в контексте проблемы 2го порядка.
Система метрик производственного департамента
Производственный департамент предложил рассмотреть интегральную систему метрик, которая в свою очередь базируется на непрерывном производственном потоке доставки ценности заинтересованным сторонам. Данный выбор обусловлен дальнейшей возможностью оптимизации отдельно взятых элементов потока. В каждой организации поток доставки ценности имеет свой отличительный вид, однако, все сводится к 4м простым этапам:
Анализ. Что делаем? Определяем, что мы хотим сделать.
Разработка. Как делаем? Определяем и делаем конкретные шаги.
Тестирование. Как качественно? Определяем критерии качества.
Приемка. Как соответствует? Определяем соответствие видению.
Каждый этап характеризуется 3 параметрами:
ВО (время обработки) – полезное время, затраченное на артефакт бэклога на определенном этапе в ч/ч (человеко-час).
ВВО (время ожидания в очереди) – фактическое время нахождения элемента бэклога на определенном этапе в ч/ч (человеко-час).
% - отношение (ВВО/ВО) времени ожидания в очереди на время обработки, характеризующее производительность системы (КПД).
Гипотеза 1. При пилотировании продуктовой модели для кроссфункциональной команды, сократится время доставки инкремента направления за счет снижения времени ожидания в очереди (ВВО). Для исследования гипотезы предложено рассмотреть:
Параметры стрима до пилотирования при модели 1 (функциональная модель)
a. Временной промежуток длительностью 2 месяца до пилотирования;
b. 10 доработок, которые инициированы и доведены до завершения по всему стриму за обозначенный период;Параметры стрима после пилотирования при модели 2 (продуктовая модель)
a. Временной промежуток длительностью 2 месяца во время пилотирования;
b. 10 доработок, которые инициированы и доведены до завершения по всему стриму за указанный период;
Сравнительные результаты приведены в инфографике ниже:
Результаты исследования гипотезы:
Для доставки полезной работы 15 ч/ч требовалось 360 ч/ч при модели 1; и 255 ч/ч при пилотировании модели 2;
Улучшение производительности цепочки доставки ценности составило 2% за счет сокращения ВВО (времени ожидания в очереди) на 30%;
Суммарным достигнутым эффектом является уменьшение времени выпуска инкремента на 105 ч/ч за счет снижения времени ожидания;
Существенное сокращение ВВО обеспечили активности, связанные с анализом, тестированием и приемкой;
Система метрик бизнес департамента
Бизнес департамент предложил рассмотреть количественную систему метрик для интерпретации результатов пилотирования продуктовой модели. Количественная система метрик включает в себя 3 основных параметра и 2 производных параметра:
(Д) Количество выпущенных доработок (новых функций)
(О1) Количество дефектов, выявленных при тестировании командой
(О2) Количество дефектов, выявленных пилотной фокус группой пользователей
(О1/Д) Соотношение дефектов команды к выпущенным доработкам
(О2/Д) Соотношение дефектов фокус группы к выпущенным доработкам
Гипотеза 2. Система количественных метрик при пилотировании продуктовой модели для одной кроссфункциональной команды направления, будет отличаться от системны метрик смежной команды направления, которая в свою очередь использует функциональную модель. Обязательным условием для сравнения команд является владение общим контекстом программы, а также схожая степень сложности реализации доработок. Для исследования гипотезы предложено рассмотреть:
Параметры системы количественных метрик для команды, в которой проводится пилотирование модели 2 (продуктовая модель).
a. Временной промежуток определяется выпуском протестированной работоспособной версией (3 месяца);
b. Для анализа учитываются все доработки и связанные с ними ошибки, реализованные в контексте выпущенной версии;Параметры системы количественных метрик для команды, в которой продолжает использоваться модель 1 (функциональная модель).
a. Временной промежуток определяется выпуском протестированной работоспособной версией (3 месяца);
b. Для анализа учитываются все доработки и связанные с ними ошибки, реализованные в контексте выпущенной версии;
Сравнительные результаты приведены в инфонографике ниже:
Результаты исследования гипотезы:
Команда, работающая по продуктовой модели, выпустила в 2 раза больше новых доработок;
Команды в равной пропорции устранили дефекты, определенные командой;
Команда, работающая по продуктовой модели, в 1,5 раза меньше допустила появление дефектов, определенные фокус пользователями.
Сходимость мнений и следующие шаги
При появлении результатов исследования двух гипотез, настала очередь определения общего мнения двух департаментов. Общее мнение было заключено в том, что гипотеза 1 и гипотеза 2 определили ценность продуктовой модели для организации команды.
Общее мнение позволило сформировать следующие этапы:
Поддержка и развитие продуктовой модели для команды, участвовавшей в пилотировании;
Провести пилотирование продуктовой модели для смежной команды, которая использует функциональную модель.
По результату пилотирования у смежной команды, перейти к решению проблемы второго порядка: внедрение продуктовой модели для программы.
[1] - https://www.solutionsiq.com/resource/white-paper/the-third-wave-of-agile-2/
[3] - Team Topologies: Organizing Business and Technology Teams for Fast Flow