Когда пора менять процессы в IT и как это сделать?21.05.2021 14:03

Мы, как разработчики, давно работаем по scrum, но к нам часто обращаются с проектами, которые нужно выполнить по техническому заданию. Тут мы немного грустим, потому что знаем, что для 8 из 10 проектов это утопическая модель работы.

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

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

Признаки того, что бизнесу пора менять подход и образ мышления в организации процессов в IT

1. Высокий показатель Time to Market. Это время от появления идеи до выхода продукта на рынок.

2. Длительная проработка бизнес и технических требований до старта реализации.

3. Много согласований в процессе реализации до вывода конечного продукта в прод. (аналитика, архитектура, релизы, трудозатраты, бюджет, ресурсы, скоуп).

4. Не собирается, не учитывается обратная связь от пользователей, или конечный продукт не попадает в ожидания пользователей и не пользуется спросом.

5. Плохая коммуникация. Недоступность высшего менеджмента и смежных команд (подразделений, отделов, департаментов, стримов), отдельных ключевых лиц для принятия решений (архитектор, специалист информационной безопасности, IT-Lead) для быстрого принятия решений, например из-за занятости. Не все вовлечены в этапы реализации проекта.

6. Нет безопасной среды для озвучивания проблем и проявления инициативы.

7. Нет регулярной частоты поставки инкремента продукта.

8. Зависимость процесса разработки от решений определенных людей. Неспособность людей самоорганизовываться.

Выход есть

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

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

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

Не для всех

Не всем компаниям нужен Agile. Это не универсальная таблетка от любой проблемы. Если в бизнесе процессы отлажены, и они не требуют адаптации к меняющемуся рынку, agile не обязателен. Например, космической отрасли не потребуется аджайл трансформация, потому что стоимость ошибки крайне высока, есть регламентные процессы и процедуры и нет возможности опробовать прототип MVP, потому что это очень дорого. Тут как раз тот случай, когда надо семь раз отмерить и один раз отрезать. Еще пример — колл-центр. Он работает по установленным правилам, все процессы заранее понятны и agile тут не нужен.

С чего начинается agile-трансформация?

Перед тем как начинать процесс трансформации хорошо бы знать, как строиться работа и с чего все начинается:

1. Определение команды лидеров, которые будут продвигать философию аджайла. Для этого привлекают коучей со стороны, которые имеют опыт в подобных проектах и смогут непредвзято взяться за «перерождение» взглядов и процессов.

2. Определение видения конечного состояния. Зачем вы это делаете, что есть до и будет после. Для этого коучи иногда применяют модель культур Шнейдера.

3. Составление Roadmap трансформации. Процесс зависит от поддержки руководства, готовности к изменениям и уровня бюрократии. Может начинаться с менеджмента или с команд разработки. В Roadmap отражаются этапы изменений процессов, график проведения тренингов, внедрение инструментов, правил взаимодействия, например, работа с таск-менеджером Jira. Дополнительные точки синхронизации, внедрение церемоний (встреч, митингов, совещаний).

Риски

1. Саботаж сотрудников. В любом коллективе найдутся сотрудники не готовые к переменам. Для сглаживания негативных настроений проводятся тренинги. Коучи выступают в роли психологов, объясняют преимущества и выгоды нового подхода. Но все же не будет такого, что всем будут нравиться изменения. Agile — это новый способ мышления, некоторые пугаются, бояться перемен. Будьте готовы к тому, что придется переобучить, перенаправить, и, что какой-то процент людей все же будет не готов к новой жизни.

2. Agile — трансформация затратный процесс. И может просто не сработать. Причиной могут стать непонимание зон ответственности участников трансформации, неготовность высшего менеджмента к глобальным изменениям, попытка внедрить аджайл там, где это не нужно.

Как понять, что аджайл заработал?

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

Лилия Алексеева, проводившая аджайл-трансформацию в Сбере, в интервью для ScrumTrek говорит, что они поняли, что аджайл заработал, только когда их многочисленные переговорки были постоянно заняты и пришлось создать систему бронирования.

Однако бизнес все равно использует измеримые показатели, например, среднее время, затраченное на релиз (от момента готовности к релизу до момента внедрения), общее время затраченное на все релизы, Time-to-market, кадровые метрики (индекс счастья команды, соотношения запланированных историй к выполненным и т.д), показатели качества.

А что со сроком?

Главный страх бизнеса перед переходом в аджайл, это неясность бюджетов и сроков реализации проектов. На самом деле этот процесс вполне поддается планированию. Методом User Story Mapping производится декомпозиция этапов проекта на нескольких уровнях с определением MVP и разбивкой на спринты. На верхних уровнях — до конца проекта, на нижнем (пользовательские истории) очерчивается ближайший горизонт планирования от нескольких спринтов (спринт — от одной недели до 1 го месяца) до квартала.

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

Привлеченные компании-разработчики, зная эту боль бизнеса, предлагают разработку MVP по техническому заданию, а в дальнейшем переходят на scrum. Такой подход помогает бизнесу безопасно перейти к гибкой разработке и довериться команде.

Два вопроса бизнесу

Какое будущее аджайл в российских компаниях?

Что будет, когда все перейдут на аджайл, станет ли мир лучше?

Agile привнесет в бизнес прозрачные, доступные для понимания правила игры, ускорит поставку ценности конечным пользователям. Двигаясь от идеи, многими этапами микроменеджмента можно пренебречь и получить взамен вдохновение, вовлеченность команд. Выигрывают те, кто быстро подхватывает идею, реализует ее в MVP (минимально жизнеспособном продукте) и как следствие одним из первых собирает аудиторию.

Благодарим за помощь в написании статьи Владислава Лазарева.

Полный текст статьи читайте на CMS Magazine