4.3 БЫСТРЫЕ УСПЕХИ НА КАЖДОМ ЭТАПЕ
Авторы раздела:
Бутвина Н. Л.
Алферов П. А.
Крюнькин Е. Н.
Потапова Е. Г.
Романов Ф. А.
Agile пропагандирует получение первого результата в короткие сроки. Поэтому правило «хочешь реализовать изменения — делай их быстро» действует применительно к гибким проектам. В этом разделе показано, как можно быстро достигать успехов на каждом этапе. Даны несколько рекомендаций относительно каждого из пяти этапов.
Agile пропагандирует получение первого результата в короткие сроки. Поэтому правило «хочешь реализовать изменения — делай их быстро» действует применительно к гибким проектам. В этом разделе показано, как можно быстро достигать успехов на каждом этапе. Даны несколько рекомендаций относительно каждого из пяти этапов.
4.3.1 ПРЕДВАРИТЕЛЬНЫЙ ЭТАП
4.3.1 ПРЕДВАРИТЕЛЬНЫЙ ЭТАП
Время чтения: 10 мин.
На предварительном этапе обратите внимание на следующие ключевые точки:
- определение инициатора перемен;
- поиск и приобретение необходимых знаний;
- по возможности получение статусной поддержки от руководства;
- поиск единомышленников и систематическое общение с ними (как доведение новостей, так и сбор обратной связи типа «понимают — не понимают», «относятся позитивно — беспокоятся», «поддержат — воспрепятствуют»).
- подбор и обучение сотрудников Agile-команд (см. раздел 3.1.6).
Время чтения: 10 мин.
На предварительном этапе обратите внимание на следующие ключевые точки:
- определение инициатора перемен;
- поиск и приобретение необходимых знаний;
- по возможности получение статусной поддержки от руководства;
- поиск единомышленников и систематическое общение с ними (как доведение новостей, так и сбор обратной связи типа «понимают — не понимают», «относятся позитивно — беспокоятся», «поддержат — воспрепятствуют»).
- подбор и обучение сотрудников Agile-команд (см. раздел 3.1.6).
4.3.2 ЭТАП «ПОДГОТОВКА»
4.3.2 ЭТАП «ПОДГОТОВКА»
На этапе «Подготовка» придерживайтесь следующих рекомендаций:
Поначалу вашей задачей является не увеличение производительности или скорости работы команды в разы, а новый формат взаимодействия между сотрудниками.
- Для начала выберите самый простой фреймворк, например Kanban (также можно Scrum, но он сложнее и требует более тщательной организации). Не стоит сразу пробовать сложные фреймворки, например SAFe, они требуют наличия высокого уровня экспертизы у команды.
- Выберите сотрудников, которые хотят принять участие в эксперименте (пилоте). Сотрудники, настроенные негативно, будут искать минусы Agile и однозначно найдут их, вам нужны сотрудники, которые смогут оценить достоинства Agile и использовать их максимально эффективно.
- Как руководитель обеспечьте максимальное «прикрытие» пилотного проекта Agile от любых внешних и внутренних возмущающих факторов (это могут быть внутренние смежные подразделения, действующие нормы и правила, внешние проверки и т. д.). В идеальной ситуации стоит сделать максимально защищенную «песочницу».
Поначалу вашей задачей является не увеличение производительности или скорости работы команды в разы, а новый формат взаимодействия между сотрудниками.
Подобная практика уже не нова в Российской Федерации, например, существуют «регуляторные песочницы» Центробанка, используемые для пилотирования инновационных подходов и продуктов на практике.
4.3.3 ЭТАП «РАЗРАБОТКА АЛЬФА-ВЕРСИИ»
4.3.3 ЭТАП «РАЗРАБОТКА АЛЬФА-ВЕРСИИ»
На этом этапе вместе с командой выполните следующее:
Ключевой аспект данного этапа — создание команды перемен. Не обязательно делать это резко и революционно, желательно двигаться небольшими шагами, путем внедрения незначительных изменений. Часть сотрудников можно привлекать в проектную команду на временной основе, не отвлекая их от операционной работы. На этом и следующем этапах важно доказать принципиальную возможность внедрения Agile-подходов и их результативность.
- Обсудите выбранный фреймворк, который будете использовать. Все участники должны понимать основные принципы Scrum или Kanban. Проведите сравнение, как у вас работают процессы сейчас и как они изменятся на время эксперимента.
- Обратите внимание, что для ряда проектов ни один из стандартных фреймворков может не подходить по ряду причин (законодательные ограничения, ограничение бюджета, неприятие командой каких-то инструментов). Вы можете проявить гибкость и использовать только те инструменты, которые работают именно на вашем проекте. Однако при первой попытке такого рода существует немало рисков (например, скатиться в карго-культ (см. раздел 4.5) или просто не уложиться в сроки), поэтому рекомендуем допускать отступления от фреймворка только под руководством опытного внешнего коуча или опытных коллег из других команд.
- Распределите роли. В каждом фреймворке Agile есть командные роли, зафиксируйте роль каждого участника. Роли должны быть распределены с согласия команды, например, если большинство считает, что конкретный человек не подходит на роль владельца продукта, то стоит рассмотреть другого кандидата.
- Выберите метрики эффективности (см. раздел 3.1.7). Необходимо оценить, что будет критерием успеха вашего проекта. Показатели должны быть понятны всем, их должен легко оценить любой участник команды. Вы должны быть готовы показать эти метрики руководству.
- Обратите внимание на то, что отбор участников гибких команд идет в процессе стажировки в полевых условиях, на реальных проектах. Поэтому недостаточно собрать команду на начальных этапах, нужно контролировать ее состав постоянно. Как правило, не более 10% сотрудников могут постоянно работать в кросс-функциональных профессиональных командах. 85% могут работать периодически или в качестве экспертов по своему узкому вопросу, еще 5% не приемлют проектную деятельность или саботируют изменения.
- Заложите в проект управление изменениями. Очень важно начать применять меры по управлению изменениями как можно раньше.
Ключевой аспект данного этапа — создание команды перемен. Не обязательно делать это резко и революционно, желательно двигаться небольшими шагами, путем внедрения незначительных изменений. Часть сотрудников можно привлекать в проектную команду на временной основе, не отвлекая их от операционной работы. На этом и следующем этапах важно доказать принципиальную возможность внедрения Agile-подходов и их результативность.
Государство как платформа: люди и технологии (раздел 3.1. Управление изменениями — ключевой фактор успеха).
4.3.4 ЭТАП «РАЗРАБОТКА БЕТА-ВЕРСИИ»
4.3.4 ЭТАП «РАЗРАБОТКА БЕТА-ВЕРСИИ»
На этапе «Разработка бета-версии» допустимо создать постоянную проектную команду, работающую в режиме 100%-го участия, когда члены команды не участвуют в операционной деятельности организации. Операционные сотрудники привлекаются как эксперты в ходе спринтов.
Кейс 13. Егор К. высказывается так: «Кажется, что на этом этапе легко забрать сотрудников, с тем чтобы работать в режиме 100/0 в команде трансформации. Но когда в 2016 году мы решили трансформироваться, никто не хотел отдавать сотрудников на непонятный фронт работ в режиме не то что 100/0, а даже 10/90». Соответственно, на этом этапе важны административный ресурс, лично заинтересованный лидер и лояльное ближайшее окружение.
Кейс 13. Егор К. высказывается так: «Кажется, что на этом этапе легко забрать сотрудников, с тем чтобы работать в режиме 100/0 в команде трансформации. Но когда в 2016 году мы решили трансформироваться, никто не хотел отдавать сотрудников на непонятный фронт работ в режиме не то что 100/0, а даже 10/90». Соответственно, на этом этапе важны административный ресурс, лично заинтересованный лидер и лояльное ближайшее окружение.
Модернизацию процессов в организации может поддержать создание ряда внутренних нормативных документов, фиксирующих практику применения гибких подходов. Допустимо разработать или обновить в соответствии с подходами Agile такие документы, как должностные инструкции членов проектных команд, приказы о создании рабочей группы «Проектный офис», о запуске проекта, дополнение к правилам по оплате труда и премированию (с учетом специфики Agile-команд), положение о проектной деятельности, регламент управления проектами, регламент управления проектной деятельностью, методички и руководства.
Самым важным моментом, который все хотят пропустить, является ретроспектива. Благодаря ей происходит значительный рост опыта и компетенций внутри команды, а процессы начинают меняться в лучшую сторону. Каждую неделю уделите один час анализу эффективности вашей команды. Вам потребуется конструктивная критика и обсуждение, как можно улучшить взаимодействие внутри команды. Избегайте обвинений, главная цель состоит в выявлении проблем и совместном поиске способов решения.
После завершения проекта нужно провести ретроспективу всего проекта, причем обратить внимание на следующее:
Самым важным моментом, который все хотят пропустить, является ретроспектива. Благодаря ей происходит значительный рост опыта и компетенций внутри команды, а процессы начинают меняться в лучшую сторону. Каждую неделю уделите один час анализу эффективности вашей команды. Вам потребуется конструктивная критика и обсуждение, как можно улучшить взаимодействие внутри команды. Избегайте обвинений, главная цель состоит в выявлении проблем и совместном поиске способов решения.
После завершения проекта нужно провести ретроспективу всего проекта, причем обратить внимание на следующее:
- Метрики эффективности. Посмотрите метрики, которые вы задали вначале, и оцените их. Пусть каждый участник команды выскажет мнение, почему был получен такой результат, как его можно улучшить и считает ли он эксперимент с Agile успешным.
- Взаимодействие внутри команды. Оцените, как люди взаимодействовали раньше и как это происходило по Agile. Одним из критериев хорошего взаимодействия является снижение количества задач, которые все забыли и выполняли в спешке в последний момент.
- Мнение заказчиков. Пригласите заказчиков проекта. Традиционно ретроспектива проводится только внутри команды, но для первого применения Agile это может быть важно. После того как каждый участник команды высказался, будет полезно выслушать мнение человека со стороны, который наблюдал за ходом работ и может сравнить, как было раньше и как стало с Agile. Важно дать ему слово последним, так как его мнение не должно повлиять на мнения участников команды.
Хотя такие документы в чем-то будут противоречить одному из основополагающих принципов Agile (работающий продукт важнее исчерпывающей документации), они актуальны для госорганизации.
4.3.5 ЭТАП «РАЗВИТИЕ ПРОДУКТА (ПРОЕКТА)»
4.3.5 ЭТАП «РАЗВИТИЕ ПРОДУКТА (ПРОЕКТА)»
Допустимо наладить постоянную работу нескольких проектных команд, постепенно вовлекать новых операционных сотрудников в качестве экспертов, переносить полученный опыт в соседние команды. Поскольку продукт уже находится в режиме продуктивной эксплуатации, важно обеспечить построение процессов поддержки пользователей, устранение инцидентов и управление релизами. На этом же этапе ведется постоянное улучшение продукта. Также важной задачей является перенос достигнутых изменений в культуре команды в культуру всей организации и распространение прочих лучших практик, опробованных в команде, во всей организации.
4.3.6 ОБЩИЕ РЕКОМЕНДАЦИИ ДЛЯ ВСЕХ ЭТАПОВ
4.3.6 ОБЩИЕ РЕКОМЕНДАЦИИ ДЛЯ ВСЕХ ЭТАПОВ
Для внедрения Agile-культуры и практик на всех стадиях также рекомендуется применять следующие подходы:
- Использовать подход «от простого к сложному», демонстрировать и систематически публично поддерживать регулярные видимые изменения и результаты.
- Активно использовать обмен опытом и сбор лучших практик, развивать профессиональные сообщества, самим участвовать в существующих сообществах (посещать конференции, митапы и т. д.).
- Для преодоления сопротивления применять подход «снизу вверх», проводить пилотные проекты с участием команд, более открытых для изменений, давать рекламу позитивных изменений и результатов, распространять успешные практики в других командах.
- Начать с внедрения / применения фреймворка Kanban, улучшения физического и цифрового рабочего пространства — инфраструктуры и средств совместной работы. Для практик Kanban можно показать видимый и значимый результат за 1−3 месяца.
- При успешной работе с фреймворком Kanban следующим этапом запустить пилотный проект, выбрать фреймворк Scrum с участием одной или нескольких команд, создающих или развивающих инновационные продукты. Внедрение Scrum сложнее, требует бóльших усилий, он не всем подходит, может потребовать замены отдельных членов команд. Благодаря внедрению Scrum можно показать видимый и значимый результат за 3−6 месяцев. В ряде случаев Scrum может оказаться более революционным и не подходящим для конкретной организации, тогда можно постепенно добавлять подходящие вашей команде элементы этого фреймворка, однако желательно делать это под руководством коуча или более опытных коллег.
- При внедрении Agile-культуры также нужно применять подход «снизу вверх», работать над изменением культуры отдельных проектных команд и подразделений, стараться формировать заказ руководителей на более активные изменения культуры в организации.
- Применять гибридный подход для реализации крупных проектов.
Чтобы расширить знания о самых популярных Agile-подходах (Scrum, XP (экстремальном программировании), Lean (бережливом производстве) и о Kanban, узнать, как различные команды используют Agile для создания превосходных продуктов и как с помощью Agile добиться подобных результатов, рекомендуем прочитать: Грин Д., Стеллман Э. Постигая Agile. СПб.: O’Reilly, 2015.