Как айтишники решали свои проблемы и изменили менеджмент во всех отраслях
История о развитии Agile-подходов, их внедрении вне IT и о том, почему гибкость нужна не всем
Компания «Северсталь» делала сталь с защитным покрытием, но цикл разработки новых видов стали занимал 2 года, из-за чего было сложно конкурировать с другими компаниями. Когда руководство собрало отдельную команду и применило гибкие методы из IT-разработки, то «Северсталь» смогла сократить цикл с 2 лет до 4 месяцев.
Это не единичный случай. Методы, которые программисты придумали для себя, теперь проникают в металлургию, производство, HR и даже медицину. Почему подходы из IT ломают привычные иерархические системы управления в командах, которые никогда не писали ни строчки кода?
Об этом рассказал Василий Савунов, партнер компании ScrumTrek, канбан-тренер AKT и Agile-коуч. Из статьи вы узнаете, как Agile стал популярным, почему вышел за пределы IT и какие нюансы стоит учитывать при переходе на гибкие подходы.
Василий также ведет Telegram-канал «Данные в действии», где рассказывает про канбан-метод и использование ИИ.
Какая боль айтишников привела к появлению Agile
Гибкие подходы родились как ответ на простую боль многих разработчиков — нежелание по несколько раз переделывать то, что уже готово. Эта проблема была острой в 50-80-е годы, когда доминировали тяжеловесные традиционные подходы, в частности каскадная модель, также известная как водопадная, или waterfall.
Каскадная модель обещала предсказуемость и последовательное выполнение проекта, но в реальности давала длинный цикл обратной связи и массу переделок. Заказчик видел результат в самом конце, хотя мир вокруг давно менялся, а вносить правки было либо слишком дорого, либо невозможно без полной переработки продукта.
Еще одно ограничение — многие неверно трактовали суть waterfall
Интересно, что сам создатель каскадной модели Уинстон Ройс настоятельно требовал не применять этот подход для сложных комплексных проектов. Модель подходит, лишь когда требования и архитектура полностью определены и не меняются. В этих стабильных условиях каскадный процесс действительно эффективен.
Более того, Ройс предлагал проходить каскад дважды: сначала довести продукт до внутреннего тестирования и лишь затем, скорректировав требования, выполнять второй цикл и показывать результат клиенту.
Даже в модели Ройса была предусмотрена итеративность. Но менеджеры проигнорировали эту часть и стали применять каскад так, будто требования неизменны с самого начала, пытаясь сделать все за один проход, что неизбежно приводило к провалам».
Василий Савунов, Agile-коуч.
В программной разработке это стало особенно заметно, когда появились продукты для массовых пользователей, у которых был компьютер. Например, текстовые редакторы. Тогда появлялось по несколько конкурентов в год, а побеждал тот, кто быстрее выпускал свою версию, раньше собирал отзывы и исправлял ошибки в продукте, а не в документации. Сейчас мы все знаем, что победу одержал Microsoft Word, но в те времена редакторы только появлялись и боролись за внимание пользователя.
Как ценности Agile бросили вызов традиционным подходам
К началу 90-х каскадный подход к разработке ПО оказался несколько дискредитирован. Это случилось не только на фоне обсуждения недостатков waterfall, но и за счет успешного опыта других компаний.
Значимую роль сыграла статья двух японских ученых The New New Product Development Game. В ней рассказали об опыте Fuji-Xerox, Canon, Honda и других крупных компаний. Их объединяло то, что за короткий срок они умудрялись придумывать и воплощать в жизнь новые версии продуктов, которые оказывались очень успешными на рынке.
Секрет был в командном подходе. Если при традиционном каскаде команды каждого этапа работали обособленно друг от друга, то при командном подходе сотрудники взаимодействовали друг с другом на протяжении всего проекта. Это позволяло вовремя внести корректировки при необходимости или начинать новый этап до окончания предыдущего.
С конца 80-х программисты начали придумывать свои подходы. Например, появились:
- Extreme Programming, или XP;
- Feature Driven Development;
- фреймворк Scrum;
- семейство подходов Crystal.
У них разный набор практик, но при этом есть много общего. Именно поэтому авторы этих подходов и другие эксперты в области гибких процессов собрались на встречу. Они хотели легитимизировать свой взгляд на управление разработкой и составили 4 ценности, которые легли в основу Agile:
1. Люди и взаимодействие важнее процессов и инструментов. Если процессы и инструменты мешают эффективной работе, то их нужно менять.
2. Работающий продукт важнее исчерпывающей документации. В waterfall много сил вкладывают в планирование и создание документации. Можно создать все артефакты, но не получить готовый продукт. Сторонники Agile же считают, что сначала нужно получить что-то работающее, а уже потом создавать документацию.
3. Сотрудничество с заказчиком важнее согласования условий контракта. Часто возникает ситуация: заказчик спрашивает, почему программисты не сделали очевидную функцию. Программист отвечает: «Этого не было в требованиях». Или функцию реализовали неверным способом, но программист говорит: «В требованиях не было указано деталей, я сделал, как понял». В итоге приходится тратить время на ТЗ или вновь проходить круг неприятных вопросов друг к другу.
Гораздо продуктивнее общаться с заказчиком напрямую и находить общие точки, чтобы лучше понимать друг друга. Именно это предлагают авторы Agile.
4. Готовность к изменениям важнее следования первоначальному плану. Это самая сложная ценность для реализации. В больших компаниях существуют регламенты, правила, приказы, но часто Agile предлагает отказаться от таких формальностей, чтобы сотрудникам было проще взаимодействовать друг с другом. На это готовы не все организации, из-за чего гибкость теряет смысл.
«У меня был опыт, когда команда разрабатывала решение для юридического отдела в той же компании. Программисты хотели задать прямые вопросы юристам, но не могли — запрещали внутренние нормативы. Приходилось общаться через менеджеров, из-за чего искажалась информация и растягивался цикл обратной связи».
Василий Савунов, Agile-коуч
В таких условиях гибкий подход начинает спорить не с людьми, а с самой архитектурой управления.
Что касается ценностей, то в будущем авторы подхода раскрыли их детальнее с помощью 12 принципов Agile. Итоговый документ назвали Agile-манифестом, который стал популярным среди разработчиков и сделал гибкость более массовой.
Постепенно Agile вышел за пределы IT
Проблемы с затянутыми процессами есть не только в IT. Похожие барьеры встречаются в маркетинге, продажах и других сферах. Например, когда формально отделы общаются, но делают это через цепочку согласований. Из-за этого любое предложение превращается в отдельный затянутый процесс.
Поэтому успех гибких методологий среди команд разработчиков стал причиной, по которой Agile начали использовать другие направления. В России уже в 2017 году 20% компаний работали по Agile, хотя их деятельность никак не связана с разработкой продуктов и IT-компаниями.
На текущий момент, если мы говорим про Agile, то, как правило, речь идет про Scrum — фреймворк, который сейчас используют чаще всего.
Сюда же можно и отнести производные Scrum. Например, SAFe (Scaled Agile Framework) и Less. Это фреймворки, которые рассчитаны на работу с большим количеством людей, но в основе каждого из них лежит Scrum.
«В целом применять Agile и конкретно Scrum можно и не для IT-задач. Конечно, из-за разных ограничений, его не всегда удается реализовать в чистом виде и по изначальной задумке. Однако сделать подход, который будет соответствовать ценностям и принципам Agile-манифеста, вполне можно».
Василий Савунов, Agile-коуч
Читайте также: Редакция Kaiten рассказала об опыте команд из направлений маркетинга, юриспруденции и HR, которые перешли на гибкие подходы.
Когда гибкие подходы дают рывок вне IT: несколько примеров
Если коротко, то Agile-подходы нужны там, где есть неопределенность и нужна быстрая обратная связь. Ниже рассказываю подробнее на примере нескольких сфер.
Металлургия
Здесь речь пойдет про «Северсталь». Кейс этой компании я упомянул в самом начале статьи, а здесь раскрою подробнее. Я работал с командой «Северстали», когда у нее была простая по формулировке и сложная по сути проблема — разработка новых видов стали с защитным покрытием занимала около 2 лет.
«2 года было совершенно неконкурентным сроком для рынка. За это время другие производители успевали создать свои марки и начать продажи, поэтому «Северсталь» не была первопроходцем со своим предложением».
Василий Савунов, Agile-коуч.
К тому же такое отставание приводило и к выгоранию сотрудников. Вот фрагмент из статьи, где говорится о трансформации процессов в «Северстали»:
Чтобы исправить это, сначала реализовали принцип командной работы. Для этого в компании собрали команду под задачу создания новых видов стали и их вывода на рынок. Ни одного программиста в ее составе не было. В команду вошли:
- логист;
- технолог;
- представитель производства;
- куратор плана;
- человек из маркетинга;
- человек из продаж.
Суть была в том, чтобы условно посадить всех участников вместе, ускорить процесс обсуждения и направить внимание сотрудников на одну задачу. В рамках этой практики команда:
- придумывала рецептуры;
- запускала небольшие эксперименты;
- искала клиентов, которым интересны конструкции из новой стали;
- вместе с ними тестировала эти конструкции;
- собирала обратную связь;
- дорабатывала марку под реальные условия эксплуатации.
Только за счет того, что людей посадили рядом и дали общую цель, цикл разработки сократился с 2 лет до года. Следующим шагом было сделать привести эту работу в к виду исследовательского процесса.
«Я помогал выстроить исследовательский процесс в духе Scrum, и этот фреймворк позволил сократить цикл до 4 месяцев. Причем результатом была не теоретическая рецептура или “голая” формула стали. В эти 4 месяца входила и проверка на реальном заказчике — партнере, который изготавливал конструкции и был готов опробовать новые марки».
Василий Савунов, Agile-коуч.
Это классический пример Agile вне IT: кросс-функциональная команда, ориентация на быстрые эксперименты, частая связь с рынком.
Маркетинг, продажи, платная медицина
Похожие истории я вижу в маркетинге и продажах. Команды не просто запускают кампании по плану на год. Они начинают:
- запускать небольшие эксперименты;
- смотреть реакцию рынка;
- менять продуктовое предложение и форматы;
- возвращать результаты в общий процесс.
Есть интересные примеры и в медицине. Я знаю про клинику, где пациента принимает не один врач, а сразу консилиум специалистов разных профилей. Они вместе:
- разговаривают с человеком;
- задают вопросы с разных точек зрения;
- смотрят результаты анализов;
- ищут коренную причину состояния в связке симптомов.
Это тоже кросс-функциональная команда. Там важна не формальная передача карты от одного кабинета к другому, а совместная работа с человеком и его проблемой.
Во всех этих случаях Agile проявляется через:
- общую цель;
- совместное планирование;
- короткие циклы;
- выход на результат в реальном мире, а не на бумаге.
Так создается более гибкий процесс, где важна не только стратегия, но и постоянная адаптация к изменениям в потребностях и обстоятельствах.
Почему Agile не взлетает, и где он вообще не нужен
Применение Agile часто упирается в 2 проблемы, которые актуальны как для разработчиков, так и для любых других команд.
Проблема 1 — игнорирование правил подходов. Так как чаще всего внедряют Scrum, объясню на его примере. У Scrum есть конкретные мероприятия, артефакты и роли, которые создатели фреймворка Кен Швабер и Джефф Сазерленд описали в Scrum Guide. Все эти элементы составляют фреймворк — каркас, если переводить с английского.
И при понимании сути Scrum возникают разные искажения, которые приводят к неправильному использованию фреймворку.
«Многие, кто внедряет Scrum, не понимают, зачем нужен весь его набор элементов и почему нельзя просто убрать, например, ретроспективу, демо или роль скрам-мастера. Однако в Scrum все взаимосвязано: исключите один компонент — и система перестает работать».
Василий Савунов, Agile-коуч.
При этом добавлять новые роли, артефакты и мероприятия Scrum не запрещает. Если понимаете, что не хватает какого-то элемента, то добавьте его. Главное — не исключать ключевые элементы фреймворка.
Проблема 2 — игнорирование области, где внедряют подходы. Подчеркну простую вещь — Agile применим не везде. Он вырос из потребности быстро получать обратную связь: делать шаг вперед, получать новую информацию и снова двигаться дальше. Кто двигается быстрее, тот обгоняет конкурентов. Но такая скорость нужна не всегда.
Если задача четко описана и можно просчитать все от начала до конца, гибкие методы только мешают. Понимать это особенно важно командам, которые смотрят на Agile как на «серебряную пулю».
«Часто люди не разбираются, где можно применять гибкие подходы, а где нельзя. Для них тот же Scrum — модное слово, и именно поэтому его нужно внедрить. Хотя на деле надежнее может оказаться каскадная модель. Да, работа по ней не такая быстрая. Но если ее внедрили уместно, то она обеспечит хороший результат без лишних расходов».
Василий Савунов, Agile-коуч.
Есть виды работ, где достаточно следовать инструкциям. Объясню на примерах.
Колл-центр
В колл-центре оператор отвечает на звонки по четкому скрипту. Перед ним лежит сценарий:
- если клиент говорит так, оператор задает один вопрос;
- если иначе, задает другой.
→ Это работа по инструкции. Здесь нет исследования и нет ежедневного поиска новой информации. Внутри такой операционной работы Agile не нужен.
Но у этой же компании может появиться другая задача. Например, пересмотр самих скриптов. Тогда смысл меняется:
- нужно собрать данные о звонках;
- придумать гипотезы новых формулировок;
- проверить их на части потока;
- доработать.
→ Вот под такую задачу уже имеет смысл собрать отдельную кросс-функциональную команду и дать ей Agile-подход.
То же самое в маркетинге: если отдел выполняет рутинные задачи по инструкции, Scrum не нужен, но если разрабатывает новую стратегию продвижения и тестирует гипотезы — Scrum может помочь.
Читайте также: Как аутсорсинг-бухгалтерия «Кнопка» перешла на Agile-маркетинг и организовала работу в Kaiten
Строительство моста
Строительство моста — сложная инженерная задача. Эксперты заранее просчитывают:
- нагрузки;
- материалы;
- последовательность работ;
- требования к испытаниям.
Ценность появляется только в конце, когда мост достроен и прошел проверку. На промежуточных этапах результата для пользователя нет. Разбить работу на спринты можно, но каждый промежуточный результат не несет ценности для горожан. Вбили сваи — моста нет, положили перекладины — моста еще нет.
→ Готовый результат появляется только в конце, когда мост проверили на устойчивость и нагрузку, а затем ввели в эксплуатацию. Здесь Agile тоже не поможет.
Читайте также: Как Good Wood ускорили строительство домов в 2 раза и в чем им помог Kaiten
Импортозамещение кредитного конвейера
Расскажу про ситуацию из моей практики. Ко мне обратился крупный банк, у которого была крупная и сложная система — кредитный конвейер. Это набор сервисов, которые последовательно обрабатывают данные о клиенте, заявке, рисках и всех сопутствующих этапах, пока банк не выдаст кредит. Процесс детально регламентирован:
- какие сервисы участвуют;
- как заявка переходит от шага к шагу;
- какие проверки проходят данные;
- какие документы и подписи нужны.
Система уже существовала, и задача заключалась в ее импортозамещении — переписать весь конвейер на отечественные технологии. И изначально работы по этому проекту вели по Scrum и не видели результатов. Причина — Scrum для такой задачи не нужен, он лишь затягивает сроки.
«В моей практике это был курьезный случай, ведь мне, Agile-коучу, пришлось убеждать коллег не работать по Scrum, а использовать каскадную модель. Когда весь проект разбили на понятные этапы, работа стала двигаться по плану. В итоге традиционный подход оказался намного эффективнее и позволил завершить проект до событий 2022 года».
Василий Савунов, Agile-коуч
И хоть это пример из разработки, он наглядно показывает, что не так важна отрасль, как конкретная область, где хотят внедрить Agile.
Почему Agile дорогой, но все равно интересен бизнесу
Обычно одна и та же команда разрывается между несколькими проектами и каждому руководителю достается «по части» человека: часть времени сотрудник работает с задачами одного проекта, еще часть — с задачами другого. На бумаге это выглядит как экономия ресурсов. В реальности же проседает скорость.
Agile предлагает иной подход — выделить команды под каждый продукт. Это значит, что специалисты больше не «размазаны» по нескольким проектам, а работают только над одним. Из-за этого Scrum и другие гибкие подходы стоят бизнесу денег.
«Для большинства организаций это непривычно и дорого: людей нужно забрать из функциональных подразделений, а их руководители уже не могут ставить им задачи — это делает только владелец продукта. Приходится тратиться на наём и расширять штат, что стоит бизнесу денег».
Василий Савунов, Agile-коуч.
Поэтому вопрос «внедрять Scrum или нет» всегда встает как расчет. Компания считает:
- сколько будет стоить выделенная команда;
- сколько она может принести за счет скорости и эффекта на рынке.
Если выгода перекрывает издержки, agile начинает окупаться.
Пример, когда Agile окупился
В своей практике я видел хороший пример такого расчета в Сбере в 2016 году. 4 октября в России впервые заработала система Apple Pay, а банки приступили к работе по добавлению бесконтактной оплаты для своих клиентов. И Сбер стал первым банком, который дал пользователям возможность рассчитываться через Apple Pay.
На достижение цели ушло несколько недель. Чтобы достичь ее, в компании:
- собрали людей из разных подразделений;
- сосредоточили их на одной задаче;
- дали им возможность быстро договариваться между собой.
«Благодаря этому к банку присоединилось 10 миллионов новых пользователей. По-моему, это отличный результат. Ради таких побед компания пошла на дорогое для себя удовольствие и собрала из разных подразделений специалистов высокого класса, чтобы они работали только над этим продуктом. В таких ситуациях Scrum имеет смысл».
Василий Савунов, Agile-коуч.
Опять же это пример из разработки, но именно такие истории убеждают не айтишные функции смотреть на Agile серьезно. Руководитель из маркетинга или продаж видит, какую цену может иметь ранний выход на рынок. И уже готов обсуждать не «модную методологию», а инвестицию в скорость обучения и изменения.
Примечание от редакции Kaiten: Ранее мы общались с командой Agile-коучей Сбера и расспросили, как они организовали собственные процессы в Kaiten. Прочитать можно здесь.
Что в итоге для не айтишных команд
Если коротко, ситуация выглядит так.
- Agile вырос из боли программистов, которые устали переделывать готовую работу после долгих каскадных проектов.
- Эти же принципы помогают сегодня там, где команды сталкиваются с неопределенностью и реальным рынком.
- В промышленности, маркетинге, продажах, медицине agile бросает вызов иерархии и регламентам, которые не дают людям напрямую общаться, быстро пробовать и быстро исправлять.
- Гибкие подходы не нужны в рутинной работе по инструкции и в проектах, где ценность появляется только в самом конце просчитанного плана.
- Scrum и похожие форматы стоят денег, потому что требуют выделенных команд. Поэтому решение о внедрении всегда должно идти через расчет выгод. Если финансовая выгода превысит затраты на фонд оплаты труда новой команды — стоит идти в эту историю, если нет — может, стоит подыскать другой подход.
Важно: Agile не заменяет собой все способы управления. Он дает инструмент для тех задач, где компании нужно быстро получать новую информацию, принимать решения на ее основе и проверять их в реальном мире. Именно такие задачи все чаще стоят не только перед айтишниками.
