Донесение идей Agile до классических проектных команд. Адаптация под текущую корпоративную методологию

Зачем нужна гибкость

Гибкие методы заняли свое место, и множество команд уже работают с ними. Для IT-мира это стандартная история. Но что происходит, когда мы приходим с этим подходом к другим командам – к тем, которые привыкли работать в операционном или вообще не проектном подходе?

Либо к тем, кто работает в классическом предикативном подходе, где используется водопад, и только в нем они умеют работать. Именно этой теме посвящена данная статья.

Зачем нам нужна гибкость? Что к этому подталкивает, и почему такая потребность возникает у крупных корпораций?

1. Быстрая смена окружения. Постоянные новые правила, новые вводные. В таких условиях непонятно, как планировать. Мы не можем нормально планировать и не можем построить модель, которая будет достаточно хорошо предсказывать результат и будет нам понятна.

2. Импортозамещение. Многие сейчас работают с такими задачами. Огромный пласт задач связан с тем, что софт уходит, его нужно чем-то заменять, и делать это нужно быстро. Лицензии заканчиваются, и возникает вопрос, что делать дальше.

3. Стремление к большему вовлечению проектных команд. Речь о том, чтобы люди не действовали по шаблону или по указке, а могли проявлять инициативу, реализовываться в максимальной степени и давать наилучший результат.

Сложности использования Agile

Если посмотреть на реальность, то гибкие подходы действительно позволяют разрабатывать и выходить на рынок быстрее. Метрика Time To Market сейчас крайне важна, потому что нужно как можно быстрее дать продукт, который закроет потребность.

Но когда мы приходим к реальным людям, реакция часто одна и та же: «Все это здорово, но у нас это не сработает». Я напрямую занимаюсь обучением проектных команд и постоянно слышу, что в их картине мира это не получается, и даже пробовать трудно.

Первый барьер – неполная включенность. Гибкие подходы предполагают небольшую команду профессионалов, которую условно можно накормить двумя пиццами, и которая будет выдавать продукт. В реальном мире это не работает. В крупных компаниях проектная деятельность не является основной для этих людей. У них есть большое количество операционных задач.

Это хорошо видно и на моем собственном опыте. Когда я веду обучение, я полностью включен в него: один день, второй, третий, четвертый. В итоге четыре дня из пяти я пропускаю все летучки и стендап-митинги. Через неделю возвращаюсь и с трудом понимаю, что вообще происходило в проекте.

Второй барьер – жесткое регулирование. Многие процессы регламентированы на уровне законодательства. Например, закупочная деятельность, 223-ФЗ и аналогичные процедуры.

При проведении закупки:

• на подготовку к процедуре тратится около 20 дней,

• процедура занимает около 30 дней, 

• требуется дополнительное время на выбор победителя и заключение контракта.

В результате процедура занимает 2–4 месяца. Никакие короткие спринты здесь невозможны. Если к этому добавляется вмешательство ФАС и начинается претензионная работа, сроки становятся еще больше. Возникает вопрос, как создавать продукт, если одна закупка занимает несколько месяцев.

Третий барьер – предикативная модель, к которой все привыкли. Государство выделяет деньги на проекты, по которым ожидается прогнозируемый результат. Но как прогнозировать результат, если нет плана? План не гарантирует результата, но он дает ясность. Поэтому такие проекты сложно продать на уровне получения финансирования.

Принципы Agile

Итеративность и инкрементность технически довольно просто объяснить. Люди, работающие в технической сфере, понимают, что есть исследования и опытно-конструкторская работа. Каждый раз создается что-то новое: опытный образец, предсерийное производство, опытная эксплуатация. Эта идея воспринимается хорошо.

С ценностью ситуация сложнее, потому что за одну итерацию не всегда удается получить ценность. В этом случае нужно смотреть, какую промежуточную ценность можно донести. В организационных процессах работает тот же принцип. Если автоматизируются бизнес-процессы, сначала берется один процесс, он реализуется, и важно, чтобы люди получили ценность.

Возникает вопрос, как сделать так, чтобы люди эту ценность почувствовали. Есть бизнес-процессы, в которые вовлекаются люди. Как сделать так, чтобы они увидели пользу этих процессов для себя и были заинтересованы в участии?

Практика показывает, что важно выбирать процессы, которые затрагивают людей напрямую. Один из подходов – первым автоматизировать процесс, важный для собственника, а вторым – отпуск. Когда появляется автоматизированный процесс отпуска, люди с большим интересом вовлекаются, начинают планировать, и у них не возникает вопроса, зачем в этом участвовать.

Следующий принцип – гибкость. Здесь возникает интересный момент. Часто можно услышать: «У нас есть план, и никакая гибкость невозможна». При этом любой проект становится гибким в тот момент, когда план перестает работать.

Пример: проект по созданию системы для единого государственного экзамена. Система была разработана, но в архитектуре обнаружилась принципиальная ошибка, из-за которой временные параметры процесса невозможно было обеспечить. В этом проекте я отвечал за качество. В результате команда перешла к гибкому подходу и начала работать в режиме парного программирования. Технический лидер садился за код и проговаривал: «Я буду делать это, это и это. Транзакция будет работать так и так. Какие есть замечания и предложения, почему это может не сработать?» В таком диалоге система очень быстро дорабатывалась и запускалась.

Отдельно стоит принцип сотрудничества. Здесь проявляется важный момент: разные люди получают деньги за разные вещи. Если нет единой команды, работающей над проектом, а есть только функциональные специалисты, приходится сильно балансировать, чтобы команда почувствовала общую ответственность за результат. Иногда это удается за счет общих командных премий, иногда – за счет включения показателей в KPI. В этих случаях сотрудничество начинает работать.

Практики гибких методологий в реальности

Рассмотрим, что происходит на практике. Это изображение из последнего отчета, где перечислены практики, которые считаются широко распространенными. По моему опыту, ситуация выглядит иначе.

Большинство практик применяет от трети до половины команд. Daily-стендапы практикует примерно половина. Ретроспективы заметно меньше. Планирование спринтов и итераций, короткие итерации – еще меньше. Канбан-доски для визуализации тоже используются не всеми.

Сравнение Scrum и Kanban как подходов к внедрению

Когда мы приходим в организацию и говорим, как нужно работать, нам отвечают: «Так не получается». Возникает вопрос, что мы можем сделать, чтобы получалось?

Говоря о гибких методологиях, мы обычно имеем в виду два подхода: Scrum и Kanban.

Scrum предлагает разбить деятельность на короткие фазы – спринты, запустить планирование, группой специалистов оценить, сколько времени это займет, затем регулярно синхронизироваться через ежедневные встречи, провести демонстрацию и в конце провести ретроспективу, чтобы следующий спринт стал лучше.

Здесь постоянно возникает вопрос. Уже существует свод регламентов, который определяет, кто, как и когда должен взаимодействовать. В эту структуру пытаются встроить Scrum. В коммерческой разработке это часто работает хорошо. Например, при разработке системы сервис-деска работа идет итерациями: раз в одну или две недели дорабатывается функциональность, заказчик видит, что его требования реализованы, продукт отгружается, внедряется, и дальше систему можно дорабатывать под следующего заказчика.

Внутри большой корпорации ситуация другая. Есть собственные правила и регламенты. При попытке внедрить Scrum чаще всего берут отдельные элементы и говорят: «Давайте хотя бы здесь что-то будем делать». При этом, если внедрены не все элементы и действия, то это уже не Scrum, а Scrum-but – некая производная. Здесь начинается интересный момент.

Предположим, что команда, несмотря на регламенты и препятствия, говорит: «Мы все равно будем работать так». Что это означает? Прежде всего, что команда этого хочет. Это значит, что команда сильная. Второе – у нее есть серьезное влияние: либо хороший контакт с заказчиком, либо сильная административная поддержка, которая допускает отклонение от регламентов.

Возникает вопрос, является ли она успешной потому, что работает по методологии, или потому, что сама по себе сильная и хорошо обеспечена ресурсами. 

Теперь рассмотрим второй подход, который начинается с визуализации – Kanban. Здесь ситуация другая. Преимущество Kanban в том, что он бережно относится к существующим процессам и структуре. Это может быть проект, IT-проект, учебный продукт – все что угодно. Работа разбивается на фазы, затем анализируется, какие задачи поступают и в каком объеме, над чем сейчас работает команда, и как задачи передаются заказчику.

Эта идея хорошо ложится на любую существующую систему. 

После этого команда становится более предсказуемой для заказчика, заказчик перестает испытывать напряжение. Команда видит объем задач и начинает работать спокойнее. Появляется кредит доверия. Заказчик говорит, что подход непривычный и не всегда понятный, но он работает, и команда может продолжать. У команды накапливается ресурс.

Примеры успешного внедрения Kanban

Однажды, когда я рассказывал про Kanban, ко мне подошел один из учеников и сказал, что раньше работал в Следственном комитете. И что если бы он тогда знал про этот подход, он бы по нему выстраивал работу с делами. У каждого дела есть процессуальные сроки, этапы, суды и действия. Все это можно сделать наглядным, понятным и предсказуемым.

Еще один пример – внедрение Kanban в моей семье. В какой-то момент стало понятно, что пятеро детей – это слишком много для ручного управления задачами. Задач много. Мы нарисовали доску, обозначили дела, которые дети могут брать на себя. Дети брали карточки, показывали, сколько и что они сделали, и в конце недели получали вознаграждение в виде карманных денег. У каждого ребенка появились свои предпочтительные задачи. Это сработало.

Подстройка под локальную терминологию 

Что делать, если хочется применять гибкие подходы в корпоративной среде? Необходимо адаптироваться и подстраиваться. Новое должно стать похожим на привычное, чтобы люди понимали, что это про них, а не абстрактная методология.

Подходы и практики нужно подстраивать под существующий ландшафт и мышление. Если есть привычная роль администратора, значит используется администратор, а не Scrum-мастер. Если есть понятие производственного цикла, значит это не итерация, а такт производственного цикла. В этом случае люди начинают выполнять практики, потому что они им понятны, и подход начинает работать.

Чтобы это проиллюстрировать, приведу пример, который хорошо вовлекает людей. Представим человека, которому не нравится ходить к врачам. Он решает лечиться экстрасенсорно. Он приходит к экстрасенсу, а у экстрасенса при этом есть физиологическое образование. В поликлинике врачу платят мало, а экстрасенсу – много.

Экстрасенс видит перед собой человека, ведущего малоподвижный образ жизни, и понимает, что с этим нужно что-то сделать. Он говорит: «У тебя нарушена связь чакр и энергии. Чтобы это исправить, тебе нужно выйти туда, где над тобой небо (а это прогулка), установить связь с небом и поднять руки вверх, после чего установить связь с землей и дотронуться до нее ладонями». Представили себе, как выглядят эти движения?  

В итоге человек выполняет физическую нагрузку и делает зарядку. Ну и для усиления эффекта можно подняться на гору, подальше от жилья: «потому что рядом с жильем энергия ощущается хуже». Фактически мы даем человеку задачу увеличить количество движения, но он для себя объясняет это тем, что устанавливает связь с космосом.

Используйте гибридные подходы

Следующий момент – микс подходов. Если нельзя сделать все гибким сразу, можно делать по частям. Была собрана группа экспертов из разных направлений, чтобы посмотреть, что можно сделать для внедрения гибких подходов. В результате был сформулирован следующий вывод.

В организации бывают проекты, где гибкие подходы внедряются лучше всего. Это могут быть обособленные подразделения, которые пока работают в отрыве от типовых процедур. Например, наша компания постоянно растет, в том числе за счет присоединения новых команд, и часть этих команд еще не в полной мере работает по регламентам. В таких местах возможно больше гибкости.

В любом проекте есть предпроектная часть, документальная составляющая и интеллектуальная составляющая. Частое возражение звучит так: атомную станцию нельзя построить по гибким методам двухнедельными итерациями. Оказывается, что станцию построить нельзя, а вот спроектировать и согласовать документацию таким образом можно. Есть примеры, когда согласование с зарубежными контрагентами проходило именно в гибком подходе.

Существуют и внутренние проекты, где можно попробовать гибкие методы на собственных задачах – на том, что давно хотелось сделать и что пока не регламентировано. Команда получает опыт работы в гибком подходе, после чего отдельные элементы можно переносить дальше.

Когда появляется опыт взаимодействия, следующий шаг – перенос этих методов в форму корпоративных регламентов.

Проводились исследования, анализировалось, как работают разные компании. В крупном бизнесе часто существует разделение: регламенты для классического подхода и регламенты для гибких методов.

Начиная с 2024 года в нашей компании часть гибридных подходов включена в корпоративную методологию, и часть проектов может исполняться в гибридном формате. Это позволяет быть гибкими там, где это возможно.