В 2016 году крупнейший банк страны, «Сбербанк», затеял масштабную перестройку своих рабочих процессов по Agile. Целый год Герман Греф давал интервью, а «Сбербанк» «высасывал» с рынка всех, кто умел «коучить», «создавать команды» и «внедрять Agile».
Была разработана своя версия реализации Agile, названная Sbergile, описание которой занимало не одну страницу. Некоторым сотрудникам не понравился новый подход, и они ушли, но многие его приняли, и вот уже два года «Сбербанк» движется по выбранному пути, не думая сворачивать эту деятельность.
Вслед за «Сбербанком» и другие крупные игроки финансового рынка стали пробовать новомодный подход, а за ними потянулись представители телеком-компаний, и даже несколько промышленных гигантов (например, «Северсталь»).
В этом движении мы идем вслед за всем миром и, несмотря на то, что начали позже, в ряде отраслей — в частности, в финансовом секторе — мы даже опережаем остальной мир.
А с чего все началось? Почему потребовались более гибкие подходы к работе, ведь все отлично работало и до этого. Ответ кроется в двух трендах.
Первый показывает, что новые технологии и, как следствие, новые продукты, появляются все чаще и быстрее. Если между появлением парового двигателя и первого автомобиля прошло порядка 100 лет, то начиная с середины XX века, все начало двигаться и появляться гораздо быстрее. С появлением первого микропроцессора технологии стали появляться как грибы после дождя, экспоненциально. Появилось даже понятие «технологической сингулярности», которая описывает вероятное будущее, в котором технический прогресс станет настолько быстрым и сложным, что окажется недоступным пониманию человека.
И этот вал технологий стал порождать новые виды услуг, продуктов или новые способы оказания услуг, новые каналы продаж и т. д. и т. п.
Все это привело к возрастанию конкуренции, и появлению на рынке множества новых игроков, которые использовали преимущества современных технологий и обгоняли мастодонтов, десятилетия почивавших на лаврах успеха. Достаточно вспомнить компании Kodak, 3M, Nokia, которые потеряли свое лидерство довольно быстро.
Второй тренд описывается исследованием профессора Йельской школы менеджмента Ричардом Фостером истории рейтинга «S& P 500», в котором представлены 500 крупнейших по капитализации компаний. Согласно этому исследованию, среднее время жизни этих компаний, драматически сократилось за последние 60 лет. Если в 1960 году среднее время жизни таких компаний составляло порядка 60 лет, то в настоящее время среднее время жизни — порядка 10-15 лет. Эта тенденция была также подтверждена в исследовании компании Deloitte: 50 лет назад средняя продолжительность жизни компании из списка Fortune 500 составляла 75 лет, а сегодня она сократилась до 15 лет.
То есть, с середины XX века — как раз когда появились микропроцессоры, и пошел рост количества новых технологий — компании стали «умирать» все быстрее.
В то же время, на рынке появились стартапы, которые быстро растут, и занимают освободившееся место. Они клиентоориентированы, и создают новые продукты, которые могут даже разрушить устоявшиеся бизнес-модели на рынке. Достаточно вспомнить Uber, для примера.
Эти стартапы используют философию Lean Startup, основанную на быстрой проверке продуктовых гипотез, чтобы выявить инновационную бизнес-модель, которая позволяет наилучшим образом удовлетворить клиента, и быстро захватить значительную долю рынка. Они используют Agile-подходы для быстрой и гибкой разработки продуктов и, таким образом, опережают неповоротливых Enterprise-гигантов.
Естественно, что руководство крупных компаний все эти тренды видит, и начинает осваивать Agile-подходы, не желая отставать в конкурентной борьбе. Если поставить себя на место руководства этих компаний, то возникает два вопроса.
Первый — кто может внятно объяснить, что это за Agile такой, и как он реализуется, кто нужен, чтобы этому обучать, и как можно обучить сотни сотрудников компании?
И второй — кто может помочь составить план действий, объяснит — что и где надо менять и в какой последовательности? Объяснит про изменения оргструктуры и системы поощрений, разработает гибкий алгоритм принятия решений и расстановки приоритетов и, конечно же, сможет сопровождать эти изменения и возглавлять их.
Если на первый вопрос ответить можно довольно просто — находится соответствующий сертифицированный провайдер, которому ставится задача провести обучение, и вот у вас уже куча теоретически подкованных сотрудников, которым не надо объяснять азы.
Но вот со вторым вопросом все гораздо сложнее. Каким навыками должен обладать человек, который будет возглавлять эти изменения? Каким опытом? Должен ли это быть человек изнутри или снаружи?
Давайте попробуем разобраться.
Обычно такого человека называют Enterprise Agile Coach (EAC), и он работает на уровне всей организации. Его задача состоит в том, чтобы выстраивать системный процесс, пронизывающий все подразделения компании.
Очевидно, что у него должен быть опыт управленческой деятельности, и опыт работы на большом масштабе людей. С другой стороны, это должен быть человек с Agile-мышлением, хорошо разбирающийся в теории и практике применения Agile-подходов для больших проектов.
Зона ответственности такого специалиста — вся организация, и было бы правильно говорить о том, что целью EAC является развитие Business Agility для всей компании, чтобы она стала адаптивной и гибкой по отношению к быстро меняющемуся рынку.
В любой организации есть два вида рабочих процессов, радикально отличающихся по целям и средствам.
Первые — это так называемые Run-процессы, направленные на поддержание текущей оперативной деятельности компании, выстроенной вокруг ее основного продукта. Задача этого процесса — обеспечить гарантированный, надежный результат нужного качества в предсказуемые сроки. Речь идет о зрелом и устоявшемся процессе, который повторяется каждый день и дает предсказуемый результат. Данные процессы работают в условиях определенности и предсказуемости, оперируя известной информацией, и не пытаясь изобрести что-то новое. Здесь креативность от сотрудников не требуется, более того, она может даже навредить
Вторые — это Change-процессы, это трансформационная деятельность, призванная вывести бизнес на новый уровень, найти новые продукты, новые сегменты покупателей и новые бизнес-модели. Это работа в условиях большой неопределенности и недостатка информации. Заниматься ей должны изобретательные, готовые рисковать, амбициозные сотрудники, задачей которых является проверить как можно быстрее и дешевле максимальное количество продуктовых гипотез, чтобы создать не существовавший ранее спрос на новом рынке («голубой океан»), где практически отсутствуют конкуренты, вместо того, чтобы конкурировать со множеством конкурентов на малоприбыльных рынках («красный океан»).
Обязанностью Enterprise Agile Coach будет поиск «узких мест» в компании, которые сдерживают Change-процессы. Иногда, в компании вообще нет подразделения, которое бы специально занималось Change-деятельностью, и это большая проблема, так как не имея запаса проверенных гипотез, не понимая своих альтернатив, компания становится «хрупкой» по отношению к внешним изменениям.
Если посмотреть на список компаний Fortune 500 1988 года и 2017 года, можно увидеть, что лишь 25% компаний, которые входили в Топ-30 этого списка, остались в нем и в 2017 году.
Из списка выбыли очень известные компании, такие как:
- Intel
- Texaco
- DuPont
- Chrysler
- Procter & Gamble
- Kodak
- McDonnel Douglas
- PepsiCo
И другие. Полный список представлен в исследовании Fletcher/CSI «Fortune 500».
Кто же остался? Всего семь компаний: Exxon Mobil, General Motors, AT& T, Ford Motor, General Electric, Chevron, Boeing.
Не составит труда найти информацию, что практически каждая из этих компаний использует Agile-подходы, чтобы отвечать на быстроменяющиеся вызовы рынка.
Конечно, были и другие факторы, которые позволили удержаться этим компаниям среди Топ-30 Fortune 500, но нельзя отрицать, что все они осознают необходимость выстраивания Change-процессов и прикладывают к этому усилия.
Работа с Change значительно отличается от работы с Run. Требуется выстроить исследовательский процесс в условиях недостатка информации о способах достижения и даже о конечной точке назначения.
Чтобы это реализовать, надо посмотреть на организацию с точки зрения потока поставки ценности. Для каждой организации этот поток организован по-разному, но так или иначе, для развития Business Agility нужно, чтобы в нем были следующие шаги:
- Discovery — исследование новых продуктов и проверка продуктовых гипотез. Здесь наши идеи должны пройти первую «обкатку» в полях, через интервью с потенциальными покупателями, заинтересованными лицами и экспертами. Мы должны выяснить, как они сейчас решают ту или иную задачу, или справляются с проблемой, какие готовые решения применяют, что занимает больше всего времени и сил. И дальше — выдвигаем гипотезы о том, что и как мы могли бы облегчить, улучшить или ускорить для них в этом процессе?
Можно использовать такие инструменты, как Customer Jorney Map или Value Proposition Canvas, с помощью которых мы «упаковываем» собранную информацию, и можем лучше понять, какие именно эксперименты стоит проводить для проверки гипотез.
Но лучшей проверкой жизнеспособности нашей идеи является то, что покупатель готов ее купить. Поэтому на этапе Discovery критически важно иметь возможность быстро и дешево реализовать первую, самую простейшую рабочую версию нашей идеи, и попробовать продать ее. Если клиент купил — значит мы на правильном пути. Начинают обычно с Minimal Viable Product — Минимальной Жизнеспособной Версии Продукта, которую мы можем начать продавать клиентам, чтобы получить первый фидбек, и понять, какие функции наращивать следующими, чтобы повышать ценность для клиента. - Prioritization — определяется результатами Discovery и является частью следующего этапа Delivery (разработка и поставка). Мы можем создать много гипотез, но не все они равнозначны с точки зрения ценности получаемой информации, да и ресурсы наши не безграничны, поэтому нам следует приоритезировать гипотезы друг относительно друга, чтобы понять, на чем делать упор. Здесь нам пригодятся модели AAARRR, понимание воронки продаж, и расчет экономики — например с использованием юнит-экономики или иных инструментов расчета. Приоритеты должны исходить из потребностей, и долгосрочного видения компании, в этом случае мы не будем распылять наши усилия, а планомерно исследовать нужное нам направление, концентрируя усилия.
- Delivery — этап быстрого производства новых версий продукта и поставки клиенту. Здесь в дело вступают Scrum-команды, которые итеративно, в тесном контакте с заказчиком, создают улучшения продукта, так, чтобы в каждую итерацию можно было продать клиенту новые возможности.
- Support — этап поддержки после поставки продукта клиенту. Критически важен для сбора обратной связи и увеличения лояльности клиентов.
Enterprise Agile Coach должен уметь выстраивать эти процессы, исследовать существующий поток поставки ценности, находить в нем «заторы», и уметь устранять препятствия, ускоряя Change-процессы во всей компании.
Чтобы понять, за что браться в первую очередь, и каков будет план действий, Enterprise Agile Coaching и представители компании должны ответить на многие вопросы касательно собственной организации, например: как поток поставки ценности соотносится с оргструктурой? Помогает или способствует текущая оргструктура Change-процессам? Есть ли административные барьеры на этом пути? Есть ли подразделения, занимающихся Discovery? Способен ли Delivery поставлять с нужной скоростью? Как соотносятся этапы работы с воронкой продаж? Что нам говорит экономический расчет продуктов? Какую бизнес-метрику надо выбрать за точку отсчета? К какому этапу эта бизнес-метрика относится? И еще много других вопросов, которые позволяют прояснить модель, и сделать достоверную гипотезу о том, какие изменения требуются для достижения целевого состояния.
Конечно, это требует образования и опыта, и вам повезет, если вы найдете такого специалиста, но к сожалению, на российском рынке таких специалистов почти нет.
Есть программа обучения ICAgile Enterprise Agile Coaching, и ее стоило бы освоить всем руководителям. Правда, провайдеров такого обучения в России можно по пальцам одной руки пересчитать.
В общем, рынок Agile в РФ ждет появления новых специальностей, где гибкость становится стилем работы не для отдельных команд, но для целых организаций.
Андрей, вы совершенно верно заметили, что у Agile - подходов есть ограничения области применения. Если брать конкретно Scrum, то он построен на постоянном цикле гипотеза-эксперимент-проверка-новая гипотеза. И естественно что и гипотеза может оказаться неверной или эксперимент неудачным. Поэтому вполне понятно, что в тех областях, где стоимость неудачного эксперимента слишком высока - в атомной отрасли, или в ракетостроении, например - там применение Scrum не рекомендуется. В Росатом работают очень опытные инженеры, поэтому они все эти ограничения понимают и используют Scrum там, где он применим.
NASA тоже до сих пор делает ракеты по классическим подходам, без всяких Scrum-ов.
Хотя мы с вами знаем одного человека, по имени Элон Маск, который интерактивно-инкрементально делает свою ракету :)
Это не сам Scrum так построен - так построен маркетинг!!! Во всех методологиях Agile эта маркетинговая - фронт-офис - часть расширена насколько можно так, что вовлекает в работу с клиентом всех участников проекта.
И вы дали хорошую ссылку, по которой это сразу видно - Северсталь - первый вопрос к докладчику, который это раскрывает:
Специфика отрасли - ты не можешь зарабатывать, наращивая новые мощности,
и поэтому это работа с клиентом, и это набор новых требований к новым видам продуктов.
Особенность всех статей, которые читал о Scrum на этом ресурсе в том, что авторы постепенно подгребают от Agile к Scrum, и переход такой плавный, что читателям не уследить за разницей с первого раза, по крайней мере, или со второго, ... ))) Есть такая тенденция у скрумовцев заполнить собою всю область применения Agile )))
Бэк-офис Agile в различных методологиях может сильно отличаться. Например, Экстремальное программирование (англ. Extreme Programming, XP) максимально снижает риски, и на выходе получается качественный готовый программный продукт, готовый к поставке клиенту, который будет работать и в атомной отрасли, в космической и в любой другой.
Качественный Agile - это не только для клиента. Но если почитать отзывы о работодателях, то явное перегибание палки - работники жалуются на низкие заработки - отдачи нет - компания процветает - зарплаты стараются поддерживать на среднестатистическом уровне, часто не платят за переработку - вместо 8 часов постоянно работают по 10. Ожидалось ведь лучшего для работников?
Андрей, спасибо, что продолжаете беседу и помогаете раскрыть тему
Действительно, мне часто задают вопрос "А Agile это Scrum? А Scrum это Agile?" и приходится говорить много слов и объяснять, что Scrum - это одна из реализаций Agile, а Agile - это 4 ценности Agile Manifesto.
Есть XP, FDD, DAD, и другие подходы, которые тоже реализуют эти 4 ценности, и все они объединяются под "зонтичным брендом" Agile. Иногда еще поминают Канбан, но его создатель Дэвид Андерсон, сейчас активно "отстраивает" этот подход от Agile, утверждая, что это не Agile, это совсем другое.
Если говорить, конкретно про Scrum, и только про него, то он реализует на практике цикл Деминга-Щухарта, PDCA (Plan-Do-Check-Act), который помогает найти решение в Complex домене (Cynefin Model), когда конечное решение нельзя просчитать на старте, и приходится делать ряд итераций, с циклами обратной связи, чтобы "нащупать" правильное движение. Тк Scrum - по определению его создателей - это "фреймворк для создания комплексных продуктов" ( https://scrumguides.org/scrum-guide.html ), то вполне понятно, что для совершенно новых продуктов, при том сложных, по иному действовать и не получится.
Разрабатывая новый продукт мы многого не понимаем на старте, поэтому Agile-подходы, за терпимость к ошибкам, тк и ошибки - это источник дополнительной информации. Я думаю, вы слышали фразу Fail Fast - лучше обнаружить ошибку в самом начале и исправить ее, чем обнаружить ее в самом конце цикла разработки, и не имея резерва времени - стараться ее исправить.
На этом же принципе основан подход Lean Startup, описанный Эриком Рисом, который я упоминал в статье, и который сейчас, де факто, стал почти "стандартом" для развития стартапов. В нем мы делаем дешевый "прототип" продукта - даже не сам продукт - и пытаемся его продать. По сути , мы пытаемся продать саму идею - и смотрим, готов ли за нее кто-нибудь заплатить? Если да - только тогда начинаем вкладывать средства и развивать продукт, если нет - мы задешево проверили продуктовую гипотезу, на старте обнаружили ошибку в своем предположении о том, что такой продукт нужен рынку, и можем не тратить на это ни время ни деньги, а искать новую идею.
Достаточно вспомнить, что 9 из 10 стартапов умирают именно потому, что когда пытаются продать готовый товар, то оказывается, что изначальная идея - никому не нужна, или люди не готовы платить за нее даже по себестоимости, а вот бесплатно - пожалуйста. Это как раз пример нерационального и очень самонадеянного подхода к средствам и времени.
------------
Что до Росатома - то я все же с вами не соглашусь, да и вы сами несколько коммментариев назад написали :
И XP хотя и снижает риски качества разработки, но не решает проблему продуктовых рисков, неверной постановки задачи, неверного понимания потребностей и желания заказчика и тд. Поэтому, страшно представить, что будет если мы сделаем ПО для управления нагрузкой на АЭС, и понадеявшись на XP сразу пустим его в работу на реальной атомной станции.
В случае с Росатомом, как вы верно заметили, лучше быстро разработать работающий концепт, обкатать его в тестовых условиях, а потом - по классическим проектным подходам - проверять, внедрять, тестировать и тд. В данном случае - пусть уж мы сделаем долго, но будем уверены в результате, чем сделаем быстро, и "на авось" попробуем использовать. Терпимость к ошибкам в данном случае должна быть минимальная. Потому что цена - человеческая жизнь
Риски у XP (Экстремального программирования) меньше, и связаны только со скоростью вывода на рынок - кто-то может успеть раньше - но эта скорость вывода Готового программного продукта выше, чем у Scrum. Я уже рассказывал, что уже на первой встрече с потенциальным клиентом можно набросать макет, а на следующей это может уже быть минимально жизнеспособный продукт, который можно потестировать прямо при нём.
И я с вами не согласен в каких-то сильных отличиях фронт-офиса во многих Agile методологиях - фронт-офис у всех "маркетинговый" - т.е известные в маркетинге методы и технологии, и разница только в личностях. Просто за словесной шелухой иностранных терминов сразу трудно разглядеть, что различий в маркетинговом подходе нет. Бэк-офис Agile в различных методологиях может сильно отличаться.
Назовите из своего фронт-офиса что-то, что не используют команды маркетологов? )))
Вы плохо представляете как работает Бэк-офис в XP. Это разработка, основанная на тестировании, когда каждый следующий шаг делается только после тестирования. Обратный пример - это ваша ссылка на Илона Маска - человек постоянно что-то обещает, ему верят, он собирает деньги и многие годы кормит всех обещаниями ... )))
"Чистый код, который работает, – это цель, к которой стоит стремиться потому, что:
• это предсказуемый способ разработки программ. Вы знаете, когда
работу можно считать законченной и не беспокоиться о длинной череде
ошибок;
• дает шанс усвоить уроки, которые преподносит код. Если вы
воспользуетесь первой же идеей, которая пришла в голову, у вас не
будет шанса реализовать вторую, лучшую идею;
• улучшает жизнь пользователей ваших программ;
• позволяет вашим коллегам рассчитывать на вас, а вам –
рассчитывать на них;
• писать такой код приятнее.
Но как получить чистый код, который работает? Многие силы
мешают нам получить чистый код, а иногда не удается даже получить
код, который просто работает. Чтобы избавиться от множества проблем,
мы будем разрабатывать код, опираясь на автоматизированное
тестирование. Такой стиль программирования называется разработкой
через тестирование. Согласно этой методике
• новый код пишется только после того, как будет написан
автоматический тест, завершающийся неудачей;
• любое дублирование устраняется.
Два простых правила, не правда ли? Однако они генерируют
сложное индивидуальное и групповое поведение со множеством
технических последствий:
• в процессе проектирования мы постоянно запускаем код и
получаем представление о его работе, это помогает принимать
правильные решения;
• мы сами пишем тесты, так как не можем ждать, что кто-то другой
напишет тесты для нас;
• наша среда разработки должна быстро реагировать на небольшие
модификации кода.
Андрей, очень приятно, что вы так подробно изучаете доклады с нашей конференции Agile Days. Сейчас идет набор докладов для Agile Days 2020, предлагаю вам выступить: https://agiledays.ru/#speaker
Василий, вы так и не ответили на мой вопрос.
Назовите лучше Scrum-Days - Если на ваших Agile Days выступают только Scrum-коучи, то вряд ли подходит название Agile )))
Scrum - это просто маркетинговая технология, со своеобразной терминологией, схемой организации работ в Бэк-офис , и в которую добавлены ритуалы.
В плане Бэк-офис - в Scrum отсутствуют технологии разработки конечного продукта - только макета. Это тоже понятно по ссылке в обсуждении. Как удалось относительно небольшим компаниям Тинькофф и Альфа по сравнению со Сбером - 11000 сотрудников в Сберджайле ))) - разработать лучшие и более удобные банковские продукты тоже понятно ... - лебедь, рак и щука - всё ещё актуально - Из кожи лезут вон, а возу все нет ходу!
Добавлю, что в отличие от Scrum, XP - это полный цикл разработки - от маркетинга до конечного продукта.
Андрей, приглашение остается в силе :) Выходите из тени, пообщаемся на конференции.
Я, как один из продюсеров конференции, буду только рад предоставить вам площадку для рассказа о вашем опыте применения XP для полного цикла разработки. К сожалению, докладов про XP у нас мало, и я буду рад, если вы "взорвете" зал, поделившись вашим опытом.
Давайте спишемся, и договоримся о подаче доклада.