Почему Agile-команды не обеспечат бизнес-гибкость

В России понятие 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-команд не обойтись, но много вопросов лежит вне их компетенций.

Комментарии
Консультант, Москва

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

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

Системный администратор, Сыктывкар
Илья Мытин пишет:
Agile

Я думаю все подобные методики (Agile и другие) можно определить в одно семейство методик - Гы-гылити

Системный администратор, Сыктывкар

Поколение G
G - gamers (геймеры, игроки комп игр)
Мы живем в обществе, в котором присутствует множество игроков компьютерных игр. Ими зачастую оценка окружающего мира осуществляется по знакомым играм. Зачастую ими используются методы и навыки, приобретенные при участии в компьютерной игре. Их же можно и нужно выделить в семейство G.
Таким образом, необходимым является классификация представителей семейства G.
В компьютерных играх возможно поведение двух основных видов: дрочеры и жорики. При этом обычно целью приобретения игровых достижений является получения хайпа (иначе говоря "гы-гы", затмевающее "гы-гы" других игроков - типа: сделал "пиу-пиу" и получил в награду "гы-гы").
Дрочеры выполняют все задания и таким способом приобретают игровые достижения.
Жорики покупают за реальные деньги ценности, способствующие им приобретать игровые достижения.
Задроченные жорики применяют оба пути для приобретения игровых достижений.

 

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

Глава филиала, регион. директор, Магнитогорск

Как говорил Франсуа де Ларошфуко, «Все жалуются на свою память, но никто не жалуется на свой ум».

При этом, на место памяти в статье можно вписать (и вписано!) всё, что угодно — отсутствие инфраструктуры, мышление годовыми бюджетами… вплоть до «не тех» HR-процессов. Но не упомянуто главное — архаичные технологии принятия решений и генерации идей, в частности — примитивный «мозговой штурм» (детище Алекса Осборна без малого столетней давности — образца 1930-х годов).

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

Какая разница, какими методами внедрять СЛАБЫЕ решения? Бедным производителям полуфабрикатов новый сорт пельменей внедрить быстро не дают? А что реально нового в этих пельменях? Больше перца, меньше лука? На какой процент этот новый сорт увеличит прибыль? На пару процентов? Где реальная инновационность и внеконкурентность?

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

Или не пробуйте и оставайтесь бесконечно пережёвывать тему «Работает или не работает Agile». Что ещё вам остаётся?

IT-консультант, Украина
Александр Пелевин пишет:
Андрей Роговский пишет:

Посмотрите в сторону https://www.scaledagileframework.com/

 

это просто "WOW" :-) ну так в США и миллиардеров больше. Могут себе позволить пару десятков WOW-манагеров нанять :-)

Зачем там "Customer satisfaction", если успех деньгами измеряется?

Например, если у меня денег нет, то я не стану WOW покупать :-)

 

Зачем мне танки, их кавалерия шашками порубает (c) Один эффективный менеджер

 

Системный администратор, Сыктывкар
Константин Куликов пишет:
«Все жалуются на свою память, но никто не жалуется на свой ум»

Ум это одно, а память это другое. Вы смешиваете не смешиваемое :-)

Типа: центральный процессор и жесткий диск представляете единым целым.

Глава филиала, регион. директор, Магнитогорск
Александр Пелевин пишет:
Константин Куликов пишет:
«Все жалуются на свою память, но никто не жалуется на свой ум»

Ум это одно, а память это другое. Вы смешиваете не смешиваемое :-)

Типа: центральный процессор и жесткий диск представляете единым целым.

Александр, Вы читать умеете? Претензии — не ко мне, а к Франсуа де Ларошфуко, пожалуйста. Это цитата, между прочим. Закавыченная. С отмеченным авторством.

А во времена Ларошфуко компьютеров не было (сверьтесь по датам хотя бы с Википедией). Я же как системный администратор с 15-летним стажем в прошлом процессоры с памятью (ни с постоянной, ни с оперативной) на уровне архитектуры не смешиваю. Предполагать такое по меньшей мере странно.

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

Ларошфуко лишь отметил, что все жалуются на сбои памяти, но не на недостаток ума. Впрочем, это естественно. Поскольку в силу следствий теоремы о неполноте Гёделя заметить недостатки «главного процессора» можно лишь из надсистемы, с уровня супервизора. Поэтому, определить недостаток интеллекта может лишь более развитый сторонний (!) интеллект.

Так что саможалобы на дурость, практически, исключены. Саморефлексия — вообще крайне затратна и слишком редка, особенно нынче. ;)

А во-вторых, ни процессор, ни память в отдельности функционального смысла не имеют. Рассматривать их функционирование имеет смысл лишь в рамках единой системы (компьютера). Она-то  действительно с точки зрения главной полезной функции (вычисления) является единым целым. Как является единым целым и человек. («Медицинское» дробление на органы — лишь для упрощения анализа в частных случаях. Здоровье же, в том числе, интеллектуальное, комплексно.)

Учите матчасть, юноша.

Системный администратор, Сыктывкар
Константин Куликов пишет:
А во-вторых, ни процессор, ни память в отдельности функционального смысла не имеют. Рассматривать их функционирование имеет смысл лишь в рамках единой системы (компьютера).

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

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

Партнер, Москва
Александр Пелевин пишет: А относительно обеспечения безопасности (безопасного обращения с объектом), то принято составлять модель угроз и оценивать угрозы и риски, а также защиту от них, в связи с пораженной частью (модулем). Естесственно при обследовании пораженного модуля это модуль исследуется до атома, если такое возможно.

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

Вот Роберт Мартин - один из тех, кто написал Манифест - приводит такой пример:  "Сколько из вас видели как СEO североамериканской Volkswagen давал показания перед конгрессом, обвиняя пару разработчиков программного обеспечения в том, что они подделали результаты тестов? "Ооо, это была пара программистов, которые с чего-то накосячили".

А знаете в чем дело? Это действительно была пара программистов. Может быть даже больше. Это они написали тот код, обманывающий тесты. Некоторые программисты так делают :

Если РежимТестирования Тогда

Сообщить("Все хорошо")
Возврат;

КонецЕсли;

Я даже думаю, что они осознавали, что делают. И в этом проблема. И будет день, когда кто-то из нас напишет программу, которая приведет к интересным газетным заголовкам. Что это может быть за программа? Да что угодно, от софта управляющего самолетом, до софта управляющего футбольным стадионом. Это просто вопрос времени".

1 3
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии