Снежный ком: почему в России резко растет спрос на Agile

Спрос на Agile – это не вопрос моды. Бизнесы, успех которых зависит от скорости реакции на вызовы внешней среды, просто «обречены» на гибкие методологии, считает собеседник Executive.ru, тренер компании ScrumTrek Алексей Пименов.

Executive.ru: Как вы оцениваете интерес к Agile в России сегодня, в середине 2017 года?

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

Executive.ru: Можно ли выразить этот рост в цифрах?

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

Executive.ru: Чем объясняется рост интереса к Agile?

А.П.: Бизнес начинает осознавать необходимость более короткого time to market и time to decision: без этого невозможно выжить в быстро меняющемся мире. Вызовы, с которыми сталкиваются современные компании, требуют от бизнеса очень быстрого реагирования как в плане принятия продуктовых решений, так и в плане реализации этих решений. Чтобы обеспечить скорость, нужны очень быстрые подходы. Поэтому растет спрос на Agile. Традиционный проектный подход уже давно впитывает в себя Agile-подходы – они теперь включены в стандарты PMI и PRINCE2. Важно и то, что применение Agile вызывает культурную трансформацию внутри организации: меняет в лучшую сторону отношение людей к работе, которой они занимаются.

Executive.ru: Как ведет себя в этих условиях предметная область Agile? Проект какого профиля реализуется c применением гибких методологий?

А.П.: Самые крупные заказчики, которые бросились «в эту воду», – это коммерческие банки. Почему? Потому что в их секторе – самые большие вызовы рынка. Появляются так называемые виртуальные банки, о которых глава Сбербанка Герман Греф говорил некоторое время назад, и конкуренция разворачивается между традиционными банками и компаниями сектора FinTech. Эти новые компании могут выдавить с рынка классических игроков.

Executive.ru: Как отвечает экспертное сообщество на рост спроса?

А.П.: Провайдеров Agile-трансформации становится больше – если раньше на рынке было две-три крупных компании, занимавшихся Agile, несколько экспертов-одиночек, то сейчас число провайдеров выросло примерно до десяти. Я понимаю, что 10 – это мало, но с точки зрения рынка – происходит рост в разы. Количество одиночных экспертов тоже значительно выросло.

Executive.ru: Что в связи с этим происходит с инфраструктурой Agile? Как организована передача знаний, какова динамика экспертных сообществ?

А.П.: Происходит размытие сообществ. Рынок провайдеров Agile-трансформации сильно изменился, появились новые игроки, каждый из них хочет создать вокруг себя собственное сообщество. Это влияет на уже сложившиеся сообщества, такие как Agile Russia, которое существует уже около десяти лет.

Также меняется положение дел в сертификации. Если раньше на рынке были, в основном, разовые тренинги на конкретные темы – например, что такое Scrum и как с ним работать, то теперь провайдеры, которые движутся быстрее остальных, проводят тренинги на тему – что такое Business agility, как масштабируется это явление, какие подходы существуют в этой сфере. Проводят специальные тренинги для product owners с глубоким изучением продуктового менеджмента. Таким образом, этот сегмент расширяется сразу в нескольких направлениях. Мы и наши коллеги из других компаний стараемся показывать собственные наработки и приносить в Россию зарубежный опыт.

Executive.ru: Происходит ли институционализация Agile-тематики в образовательном поле? Проникла ли она в вузы, бизнес-школы или корпоративные университеты?

А.П.: Да. Многие корпоративные университеты (не только в Сбербанке) открыли программы по Agile – эти курсы начинаются с изучения базовых вещей и заканчиваются эффективными крупными тренингами, которые проводят внутренние тренеры. Темой заинтересовались и государственные вузы, пока здесь контакт ограничивается разовыми лекциями, семинарами и вебинарами, но есть вузы, которые работают над запуском крупных учебных программ по Agile.

Executive.ru: Можно сравнить ту картину, которую вы нарисовали, с аналогичной картиной в странах Восточной и Западной Европы?

А.П.: Украинский рынок Agile-трансформации, насколько я знаю, развивается примерно так же, как российский. Рынки других стран оценить сложнее, поскольку нужно иметь достоверные источники. Страны Западной Европы идут на шаг впереди по такому параметру как зрелость внутренних процессов – мы в трансформации проходим сейчас те шаги, которые они сделали пять лет назад.

Executive.ru: Какой смысл вы сейчас вложили в слово «зрелость»?

А.П.: Качество Agile-трансформации. Самый крупный кейс такого рода в России – трансформация Сбербанка. Если мы попробуем найти другие подобные кейсы, у нас едва ли это получится: примеров глубинной трансформации нет. При этом и в отношении Сбербанка тоже нельзя сказать, что он стал быстрым и научился моментально реагировать на изменения рынка. А на Западе есть много крупных компаний, которые могут показать успешные кейсы колоссального масштабирования изменений. Эти кейсы доступны, с ними можно ознакомиться. Назову пример Zara и Zappos. Западные компании прошли этап взросления гораздо раньше, чем мы, и гораздо раньше приступили к массовым проектам. Мы сейчас только подходим к массовому этапу. Мы находимся на этапе взросления, набираемся опыта, который отражает нашу ментальность. Далеко не всегда та экспертиза, которой обладают западные эксперты в Agile, подходит для нашего рынка.

Executive.ru: Какие успешные книги по гибким методологиям вы рекомендуете читателям Executive.ru, помимо книги Джеффа Сазерленда «Scrum: Революционный метод управления проектами», о которой мы уже рассказывали?

А.П.: Мы начали сотрудничество с издательством «Манн, Иванов, Фербер», затем с помощью Executive.ru познакомились с «Альпиной». Я назову те книги, которые уже есть в продаже. Во-первых, это книга Романа Пихлера «Управление продуктом в Scrum». Также вышел в свет труд Дэвида Андерсона «Канбан. Альтернативный путь в Agile». Эндрю Стеллман и Дженнифер Грин написали книгу, которая так и называется «Постигая Agile» – очень хорошая книга, рекомендую ее тем, кто хочет составить комплексное представление о предмете: в ней есть краткий просмотр всего, что есть на Agile-рынке. Также вышла книга Джеффа Сазерленда и Кена Швабера, которая называется «Программное обеспечение за 30 дней» (в российской версии она называется «Софт за 30 дней»).

Executive.ru: Какие отрасли или компании, какого профиля и размера завтра будут втянуты в пространство гибких методологий?

А.П.: Направление №1 – госсектор. Здесь идет глубокая работа. По определенным причинам не могу делиться подробностями, скажу только, что для того, чтобы государственный сектор мог работать с Agile, необходимы изменения в федеральном законодательстве. Эти изменения касаются государственных особенностей финансирования проектов.

Направление №2 – рынок движется в сторону работы с «железом». Если раньше гибкие методологии ассоциировались прежде всего с программным обеспечением, то теперь они соприкасаются с физическим созданием наукоемких объектов, hardware. А также со строительством.

Executive.ru: Как бы вы ответили на вопрос – когда компании действительно нужен Agile, и когда ей лучше не искушать судьбу?

А.П.: Я бы ответил так – у компании должен быть запрос на трансформацию. Agile решает ряд определенных проблем, прежде всего – ускорение time to market и time to decision. Если этих проблем у компании нет, то «просто так» Agile внедрять не стоит.

Executive.ru: Вы сказали, что Agile движется в материальное производство. Значит ли это, что сопротивление гибким методологиям будет возрастать?

А.П.: Часто на конференциях по управлению проектами кто-нибудь встает и начинает говорить нечто вроде: «А как вы будете строить ядерную подводную лодку или атомную электростанцию с помощью Scrum?». Если взглянуть на эту проблему внимательнее, то выяснится, что нет такого проекта, как разработка ядерной электростанции или атомной подводной лодки. Есть целый портфель проектов, в котором есть множество разных активностей. И среди этих активностей есть такие как, допустим, подготовка разрешительной документации. Этот процесс требует очень много разных согласований. Нужно, чтобы к нему были причастны множество разных специалистов. И в этих вот как раз вопросах очень хорошо работает Scrum: когда мы собираемся со всеми специалистами и одним большим рывком «вскрываем» огромный пласт бумажной работы. Конечно же, инженерные работы, связанные с постройкой чего-то, Scrum часто решить не может, но он может позволить эффективно выполнять задачи, связанные с документацией.

Комментарии
Researcher, Москва

Цитата 1: "...Бизнес начинает осознавать необходимость более короткого time to market и time to decision: без этого невозможно выжить в быстро меняющемся мире. Вызовы, с которыми сталкиваются современные компании, требуют от бизнеса очень быстрого реагирования как в плане принятия продуктовых решений, так и в плане реализации этих решений."

Цитата 2: "...Чтобы обеспечить скорость, нужны очень быстрые подходы. Поэтому растет спрос на Agile...".

Если цитата 1 - бесспорные приоритеты, то при чем здесь Agile (цитата 2) ?

Вы ничего не попутали?
Причем здесь "скорость" и "быстрые подходы" ?? Где они в "Agile Manifesto" или в "12 Principles"

Напоминаю:

Agile Manifesto:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan
  1. Люди и взаимодействие важнее процессов и инструментов;
  2. Работающий продукт важнее исчерпывающей документации;
  3. Сотрудничество с заказчиком важнее согласования условий контракта;
  4. Готовность к изменениям важнее следования первоначальному плану.

12 Principles

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity--the art of maximizing the amount of work not done--is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

12 принципов:

  1. Нашим главным приоритетом является удовлетворение заказчика посредством ранней и непрерывной поставки работоспособного программного обеспечения.
  2. Приветствуйте меняющиеся требования даже на поздних стадиях разработки. Гибкие процессы используют изменения как средство получить конкурентные преимущества для заказчика.
  3. Поставляйте работоспособное программное обеспечение часто: от раза в несколько недель, до раза в несколько месяцев, отдавая предпочтение коротким интервалам.
  4. Представители бизнеса и разработчики должны работать вместе в течение всего проекта.
  5. Стройте проекты вокруг мотивированных личностей. Предоставьте им среду и поддержку, в которой они нуждаются, и доверьте им самим сделать работу.
  6. Наиболее эффективный способ передать информацию в команду проекта (а также передавать её внутри команды) - это непосредственное живое общение.
  7. Основной мерой прогресса проекта является работоспособное программное обеспечение.
  8. Гибкие процессы поощряют разработку с постоянной скоростью. Спонсоры проекта, разработчики и пользователи должны быть способны поддерживать постоянную скорость на неограниченной дистанции.
  9. Непрерывное внимание техническому совершенству и хорошему дизайну увеличивает степень гибкости.
  10. Простота - искусство максимизации работы, которую не надо делать, - является существенным фактором.
  11. Наилучшие архитектуры, требования и дизайн создаются самоорганизующимися командами.
  12. Через регулярные промежутки времени команда должна проводить анализ того, как стать более эффективной и улучшать свой процесс работы.
Нач. отдела, зам. руководителя, Москва

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

Ранее Термин Agile использовался или для обозначения гибкого производства, или технологии разработки ПО. Сейчас термин размыт :) различными авторами и постепенно теряет смысл

Вот сравните: Новая система TPS 2 является настоящим изобретением самого высокого 5 уровня, если следовать классификации АРИЗ, когда изобретательская ситуация представляет собой клубок сложных проблем:

Цитата из книги Dao Toyota: Система Toyota не является системой"изготовления на заказ". Это система "изменения по заказу". Основное отличие состоит в том, что мы можем изменить технические характеристики машины, которая движется по сборочной линии. Мы занимались этим всегда. Просто теперь мы выходим на новый, гораздо более высокий уровень. Мы берем любую машину на сборочной линии и изменяем ее. Разумеется,существуют определенные нормы на количество таких изменений в день, поэтому у нас всегда есть необходимый запас деталей".

Место Agile в приведённом примере - это разработка новых моделей -> все "остальные места уже заняты" существующими технологиями.

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

Нач. отдела, зам. руководителя, Москва

Почему этим занимаются коммерческие банки ... ответ очень простой, и его озвучил Герман Греф - > если банковское ПО строится на основе сервис-ориентированной архитектуры, то становится легко добавлять новый сервис. Нужна только технология для изобретения новых сервисов, которые будут востребованы клиентами. Но из этого не стоит делать выводы, что это всегда означает полную трансформацию.



IT-консультант, Украина

Потому что там где экономят на ТЗ - применяют Аджайл


Генеральный директор, Санкт-Петербург

Очень смахивает на то, как в средние века многие верили в существование "философского камня"....

Директор по работе с клиентами, Москва

Возьмите статьи, когда входили в моду crm, управлние проектами, бережливое производство, матрица компетенций. Дань моде и вера в волшебную палочку-панацею от всех проблем в бизнесе. Один, даже самый хороший инструмент ничего не решит. Я не против вышерепечисленного и не против agile. Я за системность решений. А заявления типа "не будет agile - бизнес умрет, кау минимум -популизм. Раскройте важность этого инструмента в общей системе управления :)

Нач. отдела, зам. руководителя, Москва
Юрий Шакун пишет: Один, даже самый хороший инструмент ничего не решит. Я не против вышерепечисленного и не против agile. Я за системность решений.

Важно ещё знать область применения. Есть пример последствий Реинжиниринга по Хаммеру и Чампи, когда сотни тысяч компаний пострадали, в том числе многие ушли с рынка. Они потом оправдывались, что их не так поняли, и ещё писали во втором издании своей книги "Реинженириниг Корпорации Манифест революции в бизнесе, что когда писали книгу не понимали Главное - процессы, а не Реинжиниринг .

Ещё пришлось извиняться даже научному руководителю проекта, в котором они учавствовали, Томасу Дэвенпорту. Хотя в своей статье, которая была опубликована раньше, он сразу предупреждал, что методы новые и требуют проверки. Похожая ситуация с Agile - надо знать область применения, а об этом никто из авторов статей не говорит - Годится для всех :) Это и настораживает, прежде всего ...

Нач. отдела, зам. руководителя, Волгоград

Гендиректор после поездок в Москву на лекции по МВА уверовал в свою непогрешимость: раньше он по-простому говорил, что он поменял мнение свое или "переобулся", а теперь он реализует нам передовую концепцию Agile-менеджмента. Плохо только сотрудникам, то, что вчера так долго обсуждали и планировали, сегодня нужно выбросить, как в старом анекдоте - "концепция поменялась".

P.S. Речь идет про химическое производство и поставку продукции на всю Россию с кучей дилеров и соответственными планами/стратегиями.

Слушатель MBA, EMBA, Москва
Александр Соловьев пишет:
что когда писали книгу не понимали Главное - процессы, а не Реинжиниринг .

А теперь понимают, что Главное - НЕ процессы, и НЕ Реинжиниринг. А Главное это РЕЗУЛЬТАТ. Поэтому мы и слышим с разных сторон и по разным поводам: "... ориентированные(-ое) на результат..."

Если Вы лично правильного РЕЗУЛЬТАТА (по всяким, разным KPI) добьетесь без agile, то на свалку этот agile. Кстати, Вы (как и многие другие менеджеры), в своей практике можете применять свои собственные приемчики управления, не осознавая, что они описаны в букварях по agile только другими словами. Чаще всего эти слова заумные, что бы поднять значимость сочинения про agile.

Слушатель MBA, EMBA, Москва
Александр Соловьев пишет:
Есть пример последствий Реинжиниринга по Хаммеру и Чампи, когда сотни тысяч компаний пострадали

Послушайте, мне очень интересно... Хоть один случай пострадавшей компании можете привести для анализа? Я просто не могу себе представить как нужно делать Реинжиниринг, что бы стало хуже, чем было до него. Может компании ушли с рынка по другой причине (бездарный менеджмент), а все свалили на Реинжиниринг?

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

В Ижевске состоялась конференция «Региональная модель управления человеческими ресурсами».

Кто хочет знать зарплату коллег

Служба Исследований hh.ru выяснила, кто из соискателей знает размер зарплаты своих коллег.

Травмы на работе - угроза ВВП

Почти 3 миллиона человек в мире ежегодно умирают на своих рабочих местах.

Arena: анонимный поиск работы

Запущен сервис для анонимного поиска работы в сфере разработки.