Снежный ком: почему в России резко растет спрос на 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, Москва
Александр Соловьев пишет:
а пытаюсь уточнить область использования.

"Я Вам не скажу за всю Одессу...", но у нас это (Agile) работает.

Правда, нужно учесть, что Agile, появился как обобщения "лучших практик" разработки Программного Обеспечения на ЗАКАЗ. А мы именно этим занимаемся на проф. уровне.

Должен сказать, что не все так просто... как кажется. Нужна готовность с двух сторон, как со стороны исполнителя, так и со стороны ЗАКАЗЧИКА. При этом заказчик - это непосредственный потребитель ПО, специалист в СВОЕЙ прикладной области и НЕ специалист в IT. А ПО не "коробочный" (массовый продукт) а в некотором смысле уникальный.

Так что , по-моему, условие эффективности идеологии Agile есть сочетание особенности работы:

1. Уникальность (единичное производство, не массовое)
2. Высокая заинтересованность ЗАКАЗЧИКА в результате.
3. Не четко сформулированы потребительские свойства продукта.
4. В работе над продуктом требуются взаимозависимые процессы/специалисты.

И чтоб посмеяться.
Я прошел предложенный автором тест на знания Agile. 4 ответа из 12 у меня оказались правильные.
Оказывается, мы около 5 лет не тому Agile (у) следуем. ;-))




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

В разработке ПО понятно, хотя можно бесконечно спорить о деталях :).

Более интересно "осмыслить", когда говорят об Agile-трансформации компании - Если трансформация это преобразование структур, форм и способов, изменение целевой направленности деятельности ... - то это можно смело отнести к Реинжинирингу. В чём он заключается? -

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

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

Другие преимущества типа маркетинговых технологий, для создания и проектирования нового продукта, источники которых можно найти в ТРИЗ и других методах решения изобретательских задач тоже известны и уместны. Или можно просто ТРИЗ использовать, т.к. слово Маркетинг многим не нравится :) У Agile нет прав собственности на всё это.

и ещё совсем чуть-чуть непонятно - это они "переосмыслили опыт Toyota", и при этом видна скорее "кастрация" . Ну, это Да, глубоко ... надо подумать :)
Нач. отдела, зам. руководителя, Москва
Валерий Овсий пишет: Я прошел предложенный автором тест на знания Agile ...

Не нашёл такого Теста в этой статье, но сомневаюсь в создании теста по всем технологиям Agile :)

А я бы не прошёл такой тест на знание опыта компании Toyota по цитируемой в статье книге Дэвида Андерсона "Канбан. Альтернативный путь в Agile" :) На мой взгляд описание далеко от действительности, скорее маркетинговая фишка.

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

Автор книги не прошёл бы мой тест - цитирую по книге:

Выигрыша в производительности Toyota достигает благодаря снижению объемов партии и уменьшению вариативности, благодаря чему сокращается количество необходимых производственных запасов. Именно сокращение таких запасов привело к достижению экономических преимуществ, и это стало возможным благодаря таким системам сокращения незавершенного производства, как канбан

- когда Toyota начала экспортировать свои автомобили в США и Канаду, при дорогой логистике основной вклад в преимущество компании по цене вносила низкая заработная плата рабочих ~ 2 раза ниже американских.


Консультант, Москва
Валерий Овсий пишет:

Вы ничего не попутали?

Валерий, нет не попутал. В условиях постоянно меняющейся рыночной ситуации мы не можем точно предугадать что из создаваемого нами "выстрелит". Именно поэтому нам надо уметь быстро проверять гипотезы на реальном потребителе, а это и есть time to decision и time to market (быстро выдвинуть гипотезу, реализовать ее и выбросить на рынок) дальше идет анализ реакции потребителя, мы опять принимаем решение о гипотезе и опять быстро изменяем продукт пытаясь нащупать то, что нужно потребителю. Из принципов Agile это третий принцип и третья ценность. Остальные вещи помогают организовать работу так, чтобы сократить ttm. Ну и верховенством тут является конечно customer satisfaction

Но стоит отдать должное, вы подметили правильную вещь, сам манифест не показывает конечной цели, он скорее о ценностях позволяющих ее достичь. Та цель ради которой все это делается (customer satisfaction) лежит в основе термина Business Agility, а он со словом Agile не связан (для примера я не уверен, что у Zara есть какие нибудь Agile-команды или не дай бог где то Scrum, но это безусловно очень гибкая компания)

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

Дайте я тут немного поясню, под термином Kanban я все таки использую не канбан из TPS (Lean Manufacturing) а вот это: http://leankanban.com/project/wkanban/ (пощелкайте там по ссылкам слева)

Тут у создателей этого подхода постоянная путаница идет из-за того, что они переиспользовали слово (проклятый маркетинг)

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

Консультант, Москва
Андрей Роговский пишет:
Потому что там где экономят на ТЗ - применяют Аджайл


Аджайл и Scrum не отрицают ТЗ и не требуют его заменить на что-то другое. Если вам кто-то говорил, что отрицают и требуют заменить - этот человек заблуждался

Консультант, Москва
Павел Кузовников пишет:
Очень смахивает на то, как в средние века многие верили в существование "философского камня"....

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

Нач. отдела, зам. руководителя, Москва
Алексей Пименов пишет: Если посмотреть глобально, то LeanKanban (имени Девида Андерсона) - это метод улучшения качества сервиса для гетерогенных систем (а Lean Manufacturins это больше для гомогенных систем) - по заявлению автора. И оно так и есть, ибо в LeanKanban мы рассматриваем организацию как экосистему взаимозависимых сервисов.

Я уже приводил пример на первой странице дискуссии, но необязательно что эти сервисы взаимосвязаны:

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


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

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

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

Владимир Зонзов +10253 Владимир Зонзов Директор по производству, Украина

Время от времени, попадаются на глаза публикации о Scrum&Agile. И я всё вчитываюсь в них и не понимаю -- что можно ими делать. Нет, по опыту, я привык к быстрому определению ожидаемой пользы от инструмента и к его быстрому освоению-применению. А со Scrum&Agile -- ну, никак. Приведу пример того, что практика не подтверждает декларируемые возможности Scrum&Agile для создания материальных объектов. Для точной привязки, ответ Алексея Пименова буду комментировать по частям.

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

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

Комментарий В.З.: Нет. Проект создания материального объекта есть. Он -- един и управляется одним человеком. Роль этого человека называется по-разному:

  • - Для объекта техники (например, АПЛ) -- ГК -- главный конструктор.
  • - Для строительства промышленного сооружения (завода) -- ГИП -- главный инженер проекта.
  • - Для строительства гражданского сооружения (здания) -- ГАП -- главный архитектор проекта.

И кого бы он ни набрал в команду проекта, кому бы он ни делегировал права управления разработкой каждой частью проекта, отвечать за всё будет он. И нагромождение новых терминов (типа: портфель"; "активность"; ...) эту его ответственность не отменяет.

Ответ Алексея Пименова: "... среди этих активностей есть такие как, допустим, подготовка разрешительной документации. Этот процесс требует очень много разных согласований. Нужно, чтобы к нему были причастны множество разных специалистов. И в этих вот как раз вопросах очень хорошо работает Scrum: когда мы собираемся со всеми специалистами ...".

Комментарий В.З.: Нет. Невозможно собрать вместе представителей разрешительно-согласовательной системы (РСС). Напротив. В каждой команде проекта есть специалист по прохождению разрешительно-согласовательной системы. Он сам ездит к каждому из представителей РСС. Ездит на разных этапах разработки проекта. Ездит по несколько раз на каждом этапе проекта. В газете "Бизнес" (Украина, где-то лето 2000-2001 гг) есть число: полный цикл от получения разрешения на проектирование до оформления акта приёмки-сдачи построенного объекта потребовал получения более 150 подписей. По опыту скажу, трудозатраты спеца по получению подписей представителей РСС в размере одного года большими не считаются.

Ответ Алексея Пименова: "... и одним большим рывком «вскрываем» огромный пласт бумажной работы ..."

Комментарий В.З.: Нет. "одного большого рывка" тоже не бывает. Потому что, согласования персонифицированы. Каждый представитель РСС ставит свою подпись только после личного изучения своего и только своего аспекта проекта. И сие изучение проекта бумаг не добавляет. Так что непонятно, о каком "огромном пласте бумажной работы" идёт речь.

Ответ Алексея Пименова: "... Конечно же, инженерные работы, связанные с постройкой чего-то, Scrum часто решить не может,

Комментарий В.З.: Не часто, а всегда не может. Потому что, "инженерные работы, связанные с постройкой чего-то" -- это алгоритмы-технологии действий и средства обеспечения осуществления этих действий. Причем, алгоритмы-технологии, утверждённые нормативным образом. А Scrum&Agile далеки от этих "подробностей".

Ответ Алексея Пименова: "... но он может позволить эффективно выполнять задачи, связанные с документацией".

Комментарий В.З.: Выше я кратко описал, почему Scrum&Agile не могут "эффективно выполнять задачи, связанные с документацией". А позволять. -- "Ну кто же им запретит это делать?".

.==================================================.

"Всякий инструмент имеет свою область применимости".

Применимость-эффективность Scrum&Fgile для разработки-создания материальных объектов не обнаруживается.

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

Специалисты меньше, чем руководители и директора, склонны к доверию.

Зарплатные ожидания IT-специалистов превышают возможности работодателей в 1,5-2 раза

Общий рост зарплат в IT-сфере за первые 9 месяцев 2023 года составил 15-20%.

Россияне стали меньше тревожиться из-за работы

Год назад уровень тревожности россиян по поводу различных возможных проблем на работе был выше.

Уровень счастья напрямую влияет на продуктивность большинства россиян

При этом почти каждый четвертый респондент считает, что их руководитель ничего не делает для счастья сотрудников.