В России понятие 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-команд не обойтись, но много вопросов лежит вне их компетенций.
Вот и почти готов ответ, но по опыту уже реализованных НЕ своих проектов.
В настоящее время что-то новое создавать сложно, так как уже скорее всего создано. Что-то изобрести сложно, потому что можно доказать, что это не изобретение, а формализация (документирование) уже существующих технологий - типа копипаст.
Кроме того, фермы типа Apple, Microsoft и др. смогли запантентовать элементы геометрических фигур, используемые при формировании графического интерфеса пользователя их продуктов. Насколько мне известно, Microsoft взымает плату за пользование "своих" разработок. Вот только каких "своих"? Они первые украли и поэтому они правы?
О давлении властей и компаний США на Huawei слышали? Вот причина: у Huawei больше 5G-патентов, чем у всех компаний США, вместе взятых (компании принадлежит более 16 000 патентов в области 5G).
Ребятушки. Живете и работаете в России, то сосредоточтесь на ЕСИА, платежной системе "Мир", соотвествии своего продукта российскому законодательству.
Помните: на западе никому вы не нужны, как самостоятельные и независимые личности. Особенно в США.
Если финансовое планирование противоречит Agile, тогда как в Agile компаниях управляют ликвидностью компании?
Или упор только на Agile и все остальное по боку?
Лариса, Agile с самого начала разработки, на всех циклах разработки учитывает интересы клиента. Просто компании, которые стремятся работать по Agile, немного раньше чем достигли уровня Agile, стали называть себя так. Очень похоже на то как ругательным стал LEAN-менеджмент.
Как говорят "с водой можно выплеснуть и ребенка". Agile, как и ребенок тут ни причем, а общее у них то, что "не ошибается только тот, кто ничего не делает".
Предполагаю, что Agile предусмотрены не только "мягкие" методы решения конфликтных ситуаций, а просто их нет в Agile и т.п. методов организации труда группы разработчиков. Типа: "вертеть пальцами"- импровизировать на ходу. Иначе говоря: заряжать электричеством девушек, а потом от них ловить шаровые молнии :-)
Типа: давайте не будем иметь четких целей и прозрачных отношений. Предполагаю, что это последствия применения
Западным технологиям Трудовой Кодекс РФ (далее ТК РФ) неведом, поэтому они разрабатывают какие-то "марсианские" технологии организации труда.
Попробовал представить минусы ТК РФ и не получается. Кроме одного, если от работника требуетс немедленное приступление к исполнению обязанностей без испытательного срока.
И также присутствует зависимость разработчика от производителя ПО, на котором будет работать продукт. И зависимость, приобретаемая вместе заимствованными технологиями (ПО в частности).
Вообще в первую очередь надо опредилить жизненный цикл разработки ПО (Application Lifecycle Management, ALM) и типы поддержки. Использовать модульность и вести учет полученных разработок. И со временем разработка ПО станет, как конструктор. Так образуется гибкость - естесственным путем и без Agile и т.п. методов.
Можете даже свой метод разработать :-)
Нормально Вы размышляете. Правильно. Иначе зрение перестанет быть роскошным :-)
Посмотрите в сторону https://www.scaledagileframework.com/
это просто "WOW" :-) ну так в США и миллиардеров больше. Могут себе позволить пару десятков WOW-манагеров нанять :-)
Зачем там "Customer satisfaction", если успех деньгами измеряется?
Например, если у меня денег нет, то я не стану WOW покупать :-)
Финансовое планирование само по себе не противоречит. Классические процессы детальных годовых бюджетов вставляют палки в колеса. Хорошая новость в том, что человечество уже придумало как решать эту проблему. Основная идея: разделить три смысла годовых бюджетов (целеполагание, прогноз и распределение ресурсов). Для это есть разные инструменты, например, capacity-based funding, rolling forecast, stage-gate funding, horizons of growth итд также советую погугли тему Beyond Budgeting. Многие корпорации (например, Volvo, Equinor) уже годами без годовых бюджетов работают. У нас Северсталь и ОМК, и еще масса примеров.
У них выбора нет при обстоятельствах, имеющих значение "по независимым от них причинам".
Но это лучше. чем просто на аутсорсинг все подряд переводить.
А если по-русски, точнее по-российски: у них имеются основные средства, без которых организация перестанет существовать.
Вы можете сколько угодно привлекать заимствования, но эти же заимствования, как и российские методы, действительны в рамках машинной логики нуля и единыцы. Таким образом, заимствования могуг быть избыточными и отвлекающими от целей, для которых существуют технологии.
Сорян за мой рашшиан. Не научную работу делаю :-)