Познать эджайл: как не надо внедрять хайповую тему
Среди поисковых запросов в Google Agile значится как «сверхпопулярный» и в 2018 году из месяца в месяц достигает высшей отметки в 100 баллов. Ему приписывают «лечебные свойства» от всех управленческих болезней, крупнейшие банки, телекоммуникационные и интернет-компании и разработчики ПО наперебой рассказывают о его эффективности. Быть гибким — тренд. Но многие внедряют Agile, не разобравшись в его сути, — и в результате хваленый метод не работает. Управляющий партнер компании ScrumTrek Алексей Пименов рассказывает, как использовать Agile и не сломать компанию.
Не внедрять, а разделить
Agile — это система ценностей и принципов, благодаря которым продукт трансформируется под запросы заказчика в реальном времени. Казалось бы, все просто: ценности надо разделить, а принципами руководствоваться, и тогда успех гарантирован. Однако в отечественных компаниях Agile реализуют не всегда грамотно. Создаются отделы, управления и дирекции по внедрению Agile, в них трудится целая иерархия руководителей, которым внедрение Agile поставлено в KPI. Но Agile — это не самоцель, а вспомогательный инструмент, который призван решать определенные проблемы.
Кроме того, невозможно моментально изменить культуру организации, образ мышления людей и их подход к работе. Механическое использование практик одного из Agile-подходов не приведет к обещанному ускорению процесса. Новую систему ценностей не надо внедрять — ее надо «культивировать» в своей компании. В противном случае Agile становится лишь модным словом и теряет способность делать работу организации эффективной без «надзора» коучей и консультантов.
Не менять, а меняться
Agile можно сравнить с конституцией — в роли законов тогда будет Scrum, один из популярных подходов к организации процесса разработки. Его суть довольно проста: команда из разнонаправленных специалистов при поддержке скрам-мастера (тренера и помощника команды) делит весь процесс реализации продукта на короткие спринты (этапы работ продолжительностью 1-4 недели). Результатом каждого забега должен стать минимально работающий продукт. Команда получает обратную связь от клиента, понимает, в том ли направлении она бежит, — и работает дальше. Среди основных принципов Scrum: командный подход, представитель заказчика — только один человек, вместо переписки — регулярные встречи.
Чтобы Scrum работал, он принимается как есть, без изменений (убери какой-то из принципов — и все перестанет работать как надо). Меняться должна сама организация на всех управленческих уровнях. Но многие руководители или владельцы не готовы ради Scrum менять бизнес-процессы, которые они выстраивали на протяжении всей жизни. Когда страх перемен и рисков перевешивает любые доводы, Scrum может не принести пользы.
Заложить двойной бюджет
Если вы решились на инновации, будьте готовы к перераспределению бюджета. Большинство компаний заранее составляют бюджет на проекты, которые будут реализовываться в следующем году, подробно прописывая все статьи расходов. Но если у вас стартует проект с использованием Scrum, в котором команда проверяет свои гипотезы, делая множество итераций, будьте готовы к дополнительным вложениям.
Другой пример: допустим, в бюджет Scrum-команды была заложена закупка оборудования, но в ходе работы вся концепция продукта уже два раза поменялась и теперь вместо покупки оборудования надо нанять несколько квалифицированных специалистов. Как согласовать замену статьи расхода — нужно ли выносить обсуждение на заседание комитета топ-менеджеров? Делать специальную презентацию? Ждать решения в течение месяца (и с большой вероятностью получить отказ)?
Подобные нюансы лучше обсудить заранее. Если у вашей компании на данном этапе нет свободных средств для глобальных инноваций или руководство не согласно упростить схему перераспределения денег, то браться за Agile — рискованное предприятие: можно остаться и без денег, и без нового продукта.
Найти людей
Типичная ситуация: консультант «продает» компании идею Agile-трансформации и повсеместного Scrum, топ-менеджмент одобряет первый пилотный проект, начинает подбирать команду — и тут оказывается, что компания не готова выделить людей под новый проект. Причин бывает масса, и все они весомые. Организация может быть маленькой, и каждый сотрудник в ней незаменим и выполняет несколько функций. В большой организации специалистов редкой, но нужной компетенции может быть всего 2-3 человека — и все задействованы в текущей производственной системе. В таких случаях необходимо нанимать дополнительных людей, иначе Agile не будет работать, — но мало кто из владельцев бизнеса готов пойти на это.
