Бюрократия в компаниях тормозит внедрение Agile-подходов. Что мешает повышению гибкости и скорости бизнес-процессов? Рассказывает управляющий партнер ScrumTrek Иван Дубровин (Москва) на e-xecutive.ru.

В России понятие Business agility (бизнес-гибкость) довольно прочно ассоциируется с командами. Считается, что достаточно собрать в одну или несколько Agile-команд людей из разных отделов – и они тут же начнут быстро выдавать продукт, который порадует клиентов. Почему же этого часто не происходит?

Нет инфраструктуры для быстрых экспериментов

Agile-команда – это группа, объединяющая от 5 до 10 человек разных специальностей, компетенций которых хватает для самодостаточного создания ценного продукта. Команда выдвигает гипотезу, проверяет ее на пользователях и по результатам улучшает продукт. Работает такая команда короткими спринтами. Соответственно, чтобы работа была эффективной, Agile-команде нужны полномочия, возможности и инфраструктура для быстрых, недорогих и безопасных экспериментов и проверки гипотез. Нет инфраструктуры – не будет и скорости.

К примеру, в одной компании, производящей пельмени, блины и полуфабрикаты, решили ввести Agile-подход: руководство не устраивало, что вывод нового продукта на рынок занимал 4-8 месяцев. Запустили Agile-команды, технологи и дизайнеры приступили к работе, но оказалось, что для выпуска нового продукта все равно приходится ждать несколько месяцев. Почему так? Потому что выпуск зависит от основного цеха и основной производственной линии. А там уже существуют собственные планы по выпуску продукции, и команду просто не пускают в цех на пару дней для пробного производства 100 кг новых пельменей.

Вывод прост: даже введя стендапы и спринты, отсутствие инфраструктуры не поможет увеличить скорость работы, и Agile-подход становится бессмысленным.

В компании приняты годовые бюджеты

Что такое годовой бюджет? Как правило, еще летом руководство начинает обсуждать бюджет на следующий год, а осенью проходят жаркие дебаты. И каждый проект, который команда планирует запустить в следующем году, нужно обосновать с финансовой точки зрения: сколько денег потратится, сколько будет командировок и так далее. Финансовому департаменту без разницы, как именно вы работаете, ему нужно сверстать и проконтролировать годовой бюджет.

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

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

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

Решения об инвестициях принимают пару раз в год

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

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

И команде приходится на это время брать паузу, хотя рынок и клиенты не ждут. Пока мы ходим по кругам и сидим без дела, конкуренты могут все сделать и внедрить. Момент будет упущен.

Долгие тендерные процедуры

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

Естественно, такая длительная процедура снижает скорость работы. Кроме того, подрядчиков часто выбирают по бумажкам, критерии оценки – цена, подтверждение былых заслуг, квалификация персонала (всех, а не только команды на проект). Также нужно учитывать – если в компании подрядчика работает огромная иерархическая бюрократическая машина, вероятно, он не сможет полноценно работать с вами в Agile-подходе. Не сможет выделить людей, которые будут ежедневно работать с вашей командой, станет затягивать сроки, подключать бюрократию и согласования. Работы в нужном темпе просто не получится.

Так что при переходе в Agile нужно менять процесс и критерии выбора подрядчиков, уходить от традиционной тендерной системы, создавать подходящие контракты и процедуры.

Устаревший подход к составлению контрактов

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

Вторая крайность – Time And Materials (Т&M). В этом случае вы даете часовую ставку и каждую неделю подписываете с подрядчиком time sheet, в котором отражаете, сколько часов мы отработали, сколько отработал дорогой специалист, сколько недорогой. Проблема здесь в том, что подрядчик не несет ответственности за результат, он просто предоставляет людей, которые что-то делают, а мы оплачиваем их время. Если подрядчик хороший, ответственный, то он работает на результат, но если подрядчик хитрый и непорядочный, то он может специально затягивать сроки и проект, чтобы побольше получить денег.

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

Работая по agile, нужно уходить от подробных техзаданий, которые снижают гибкость. Можно фиксировать цели на уровне бизнес-результатов. К примеру, если вы делаете мобильное приложение, опишите, какие у него цели, но не добавляйте нюансов вроде того, какие кнопки и где будут, и сколько именно требуется функций.

HR-процессы тормозят бизнес

К примеру, Agile-команда понимает, что ей не хватает нужного специалиста, допустим, дизайнера. Обращается в HR-отдел и сталкивается с типичными ограничениями крупной компании. Система найма включает в себя 15 раундов собеседований, каждого претендента нужно показать ряду топ-менеджеров (у которых плотный график). Потом нужно проверить всех в службе безопасности чуть ли не на полиграфе.

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

Еще один нюанс, который может развалить даже успешную команду – принятая в компании система мотивации. Часто принято разделять ответственность: если что-то пошло не так, ищут виноватого, и депремируют его одного, а остальные участники команды по-прежнему получают премию. Такой подход разобщает. При работе в стиле Agile – да и вообще при любой работе – стоит стремиться к групповой ответственности за результат. Либо все молодцы и получают премии, либо вся команда совершила ошибку, и не выигрывает никто. От персональных премий лучше отказаться.

В общем, если ваша цель – реальное повышение скорости и гибкости компании за счет перехода к Agile-принципам, настраивайтесь на большую и серьезную работу по изменению текущего уклада. Без Agile-команд не обойтись, но много вопросов лежит вне их компетенций.