В 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 в РФ ждет появления новых специальностей, где гибкость становится стилем работы не для отдельных команд, но для целых организаций.
Андрей, Scrum рассматривает Scrum-команду как целостную самостоятельную единицу, эдакий корпоративный мини-стартап. Ну а коль скоро это "стартап", то вполне понятно, что ему жизненно необходимо понимать, что же _на_самом_деле_ нужно рынку и заказчику, поэтому в Scrum в обязательном порядке заложено прямое общение с заказчиками, а в идеале - и с пользователями продукта. Без этого он просто не работает. Если для вас эта часть - маркетинговая - ок, пусть так и будет. Суть от этого не меняется.
Так же в Scrum Guide записано требование о том, что по итогам каждой итерации, команда должна подготовить "potentially releasable product Increment", который в обязательном порядке должен показываться заказчику, и если он пожелает - этот increment должен быть поставлен клиенту незамедлительно. Но делать это или нет опеределяет Product Owner - человек от бизнеса наделенный правом самостоятельно принимать решение о наполнении продукта функциональностью, и о составе релиза
Вполне нормально, когда по-началу, на первых итерациях команда сделает minimal viable product - минимально жизнеспособную реализацию, которая уже сможет выполнять свои функции, и доставлять заказчику ценность. Но на этом дело никогда не заканчивается, тк в следующих итерациях, данный MVP будет наращиваться согласно пожеланиям заказчика.
Если я верно понял ваше описание "полного цикла XP" - то это ровно то же самое.
На счет "бек-офиса" Agile, как вы выражаетесь, он действительно может быть реализован как угодно, лишь бы позволял быстро и гибко поставлять заказчику результат. Опять же, если говорить ТОЛЬКО про Scrum - в нем вообще не оговаривается, как именно будет организован этот "бек-офис", лишь описаны необходимые встречи, роли, артефакты. Поэтому Scrum и называется framework - то есть "каркас", определяющий необходимый минимум, но позволяющий наполнять его любыми практиками, которые помогают делать продукт быстрее и гибче.
Широко используются приемы из XP, Crystal, инструменты Customer Development (User Story Mapping, Impact Mapping, Service Blueprint) и тд. Все это инструменты, и каждый выбирает то, что подходит конкретно под его ситуацию.
Предлагаю все-же сосредоточиться на проблематике, поднятой в статье, тк XP или Scrum - это командный уровень.
В то же время, есть более верхнеуровневые проблемы, связанные с устойчивостью бизнеса в долгосрочной перспективе. Так называемой, fragility - хрупкости бизнес-модели.
И сейчас речь больше идет не об Agile, а о Business Agility. Достаточно известна история Nokia, которая использовала Agile-подходы очень широко, но это не спасло ее от fragility.
В то же время, можно привести пример компании IBM, которая существует с 1911 года, и за свою столетнюю историю, много раз "переизобретала" себя, свои бизнес-модели, и в результате жива до сих пор. В 1911 году, IBM выпускала широкий ассортмиент электрического оборудования: весы, сырорезки и тп. Позже она стала известна благодаря производств компьютеров (мейнфреймы, потом PC и тд), и вот с 2014 года IBM - fabless-компания, которая фокусируется в первую очередь на консалтинге, проектировании (но не производстве) процессоров, информационной безопасности и облачных технологиях.
IBM демонстрирует пример Business Agility, и статья именно об этом, и о том, как ее достигать, говорится в статье.
Давайте сосредоточимся на обсуждении материала статьи
Так об этом вам написал уже на две страницы ))) , и вы только теперь соглашаетесь ...
Команда маркетологов выполняет по сути те же задачи, но уже в первых методологиях Agile, и в первую очередь в XP, появились технологии вовлечения в работу с клиентом всего коллектива.
+ Ещё обходится тот факт, что в маркетологов редко допускают до разработки нового или доработки уже существующего продукта или услуги, хотя технологии работы с клиентом уже давно разработаны именно маркетологами. Им чаще отводят чисто технические функции по продвижению - Спецы - разработчики уверены, что сами знают потребности потенциальных клиентов ... )))
))) Успешная разработка на основе методологии XP (Экстремального программирования) известна уже около более 20 лет. Предполагаю, что более интересна другая закрытая для большинства ))) тематика, которая может сильно заинтересовать ограниченную аудиторию из Топов )))
Scrum - капитализм изобретает новые формы эксплуатации.
Основные тезисы: У процессного подхода больше нет идеала - он перестал работать как идеологическая подложка. Ему на смену приходят другие подходы, для ещё большей эксплуатации - Scrum стал одним из таких подходов:
Намного превышаются границы, установленные трудовым законодательством — люди работают чрезвычайно много и напряженно. Постоянные жалобы на переработку - Это стандартно, но работники всё равно терпят:
- "Ты эджайл, и ты должен оставаться после рабочего дня".
- "Пусть у тебя не будет личного времени и личной жизни, но ты должен доделать свой scrum-спринт".
Бурные аплодисменты - являются ли они верным признаком правильности подхода??? - В своё время, Майкла Хаммера встречали бурными аплодисментами большие залы с Топами и собственниками с его тезисом: "Реинжиниринг: не автоматизируйте - уничтожайте". Правда потом, Хаммер и его соавтор Чампи говорили, что их не так поняли и извинялись ))) Пришлось извиняться и научному руководителю проекта, в котором они были простыми исполнителями, Томасу Дэвенпорту.
>тематика, которая может сильно заинтересовать ограниченную аудиторию из Топов ))) >Scrum - капитализм изобретает новые формы эксплуатации.
Отличная тема! Подойдет на для Agile Business Conference так и для Agile Days. Пожалуйста, дайте мне возможность написать вам в личку, и мы обсудим детали выступления с докладом.
Лично я с удовольствием бы послушал.
И еще раз прошу : вернитесь к теме статьи.
XP, Scrum, FDD, DAD и тд - это все низовой уровень. Он не делает бизнес гибким сам по себе Особенно крупный бизнес. Вопрос сейчас больше про то, "как научить слонов танцевать" - это вызов ближайшего будущего
Только о ней и говорим. Ваш Enterprise Agile Coach пытается заменить процессный подход (process approach) на Agile process approach.
В процессном подходе учитывают разницу в заинтересованных сторонах - потребители; владельцы; поставщики; инвесторы; партнеры; кредиторы и другие.
Перечисленные в статье шаги Discovery, Prioritization и даже Delivery + Support - это как раз когда маркетинг выдвигается на первый план. Команда маркетологов с привлечением специалистов справится с этими шагами не хуже, если не лучше, чем коуч со стороны. Беда в том, что маркетологам этого часто не дают делать - об этом тоже говорилось.
Первым методологом и первым коучем в нашей стране можно назвать Георгия Петровича Щедровицого. Он прекрасно справлялся с подобными задачами.
Например, он в своё время делал Росатом более гибким в вопросах управления строительством АЭС. Многим помогут его принципы методологической школы управления - глубокая теоретическая и онтологическая проработка оргуправленческого мышления.
Упоминаете в статье крупнейшие по капитализации компании - Есть такой нюанс - Наши крупнейшие компании со своими офшорами стали крупными инвесторами в зарубежных странах. Для них гибкость - это типа "а теперь хочу Венесуэлу" )))
В СССР была лучшая атомная энергетика и космос (с учетом того, в каих рамках сволочное государство держало специалистов), и у технологоий АЭС большой запас прочности.
Однако в целом - АЭС и Аджайл не совместимы идеологически :)
На первой странице дискуссии автор даёт полезную ссылку:
Росатом: https://m.youtube.com/watch?v=PBBgp1D2lRU
Как пример из этого доклада: финов нужно уговорить построить у них АЭС - для этого нужно что-то доработать в проекте - вы подключаете маркетологов, которые изучают вопросы, которые могут заинтересовать финов. Автор доклада рассказывает, что для этого они используют Scrum - это тот же маркетинг, только засоренный ))) терминами на английском + технологии организации работ ))). Потом делается предложение - это ещё не готовый проект - выступающий по ссылке называет это Концепт. И фины могут купить эту идею - заключить договор
Или - основные программы, для управления сложными технологиями на АЭС пишутся на надёжном языке Oberon, который выбрали разработчики Росатом. Что-то другое выбрать трудно - С и С++ ненадёжны, Java тоже, ADA под контролем американцев, Scala и Go тоже вряд ли пройдут сертификацию, JavaScript - даже смешно упоминать ...
Могу подтвердить надёжность современных Oberon технологий - мы сами их используем. При написании этих программ можно использовать такую методологию разработки как XP, в которой каждый шаг тестируется, и на выходе будет программный продукт с документацией, готовый к промышленной эксплуатации - это тоже Agile.