Методология Agile говорит о том, что не нужно пытаться с первого раза создать сложный и безупречный продукт - пока мы будем его совершенствовать, нас могут обогнать маленькие и шустрые конкуренты. К моменту, когда мы завершим весь цикл работ, наш проект может стать никому не нужен либо его концепция устареет. А денег, времени и сил будет потрачено много.
За популярность в России Agile может быть признателен Герману Грефу. Именно он во всеуслышание высказался в поддержку этого гибкого метода и продолжает обосновывать, почему это важно для банковской сферы (и не только). Хотя, надо признать, что Agile в России применялся еще до того, как Герман Оскарович съездил в Кремниевую долину, где познакомился с системой. Сегодня Agile внедряется в государственных учреждениях, банках, коммерческих организациях и используется для достижения совместных бытовых планов в некоторых семьях.
Вот несколько важных тезисов, которые, надеюсь, помогут вам понять этот, не такой уж сложный, подход.
Для тех, кто торопится и не хочет читать долго - объясню подход в четырех строках. Это цитата из манифеста Agile-разработчиков: «Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану».
А для тех, кто все-таки хочет копнуть глубже - 7 фактов об Agile.
Тезис №1. Agile нужен, чтобы в сжатые сроки показать клиенту результат
Для этого большой проект разбивается на отрезки (итерации) длиной от 1 до 4 недель, в конце каждого из которых клиент должен получить работающий продукт. После получения обратной связи от клиента продукт с каждой новой итерацией становится лучше и ценнее для клиента. Например, заместитель директора информационной службы штата Вашингтон Майкл де Анджело рассказал, что еженедельно они рассылают во все государственные учреждения своего региона практические планы. Задача - регулярно в 7 дней, пусть маленькими шагами, но что-то менять в лучшую сторону. Служба выдает потенциально готовый продукт, который учреждения могут начинать применять сразу же. Не всегда это что-то материальное, важно, чтобы это было что-то, создающее ценность (например, полезные рекомендации к работе).
Тезис №2. Agile позволяет быстро запустить продукт, обогнав конкурентов
Забудьте о многолетней подготовке продукта - как говорится, лучше времени, чем сейчас, никогда не будет. Гораздо выгоднее дополнительно инвестировать в команду и оперативно занять никем не освоенный сегмент рынка, опередив всех своих конкурентов. Вспомним октябрь 2016 года и Сбербанк - тогда он первым на российском рынке предоставил возможность оплаты через Apple Pay. Как результат - 10 млн пользователей, которых банк сразу же собрал и записал себе в актив. Вот это было по-Agile.
Тезис №3. Agile нужен для гибкого управления бизнесом в постоянно меняющемся мире
Слово «agile» переводится с английского как «проворный, расторопный». И хотя agile-методы действительно позволяют быстро выводить на рынок качественные продукты, суть этого подхода не в скорости, а в гибкости. Хороший пример - компания «Кнопка», которая работает на бухгалтерском рынке. Типичная компания этой сферы - это 200 клиентов на 20 сотрудников. Привлечь большее количество клиентов можно, но зачастую это приводит к раздуванию штата. В «Кнопке» смогли применить гибкость и творческий подход agile-системы, тем самым увеличив портфель клиентов практически до 1000, не расширяя свой штат. В компании отказались от жестких KPI, регламентов и микроконтроля. Кроме того, было решено «облегчить жизнь» бухгалтерии: в компании поняли, что довести бухгалтерский баланс до совершенства невозможно, и стали применять принцип Парето - риск доначисления нескольких сотен рублей не должен стать поводом бессонных ночей бухгалтера и бесконечных звонков клиенту с требованиям предоставить все возможные данные. Так сократились часы сотрудников, уменьшился градус напряженности в коллективе и нашлось место для «творческого подхода» в области дебета и кредита.
Тезис №4. Agile мотивирует команду, не прибегая к материальным стимулам
По итогам каждого отрезка заказчик оценивает результат и даёт обратную связь. Забеги на короткие дистанции дают ощущение быстрой победы, а благодаря регулярному общению и тесной связи с бизнесом команда ощущает значимость своей работы для общего дела. Неудивительно, что 98 % компаний, внедривших Agile, отмечают рост мотивации своих сотрудников. Например, разработчик облачных решений Salesforce применил Agile-подход, когда компания выросла до 200+. В этот момент руководство поняло, что, «как раньше» работать не получается. Поэтому все команды переформировали в кросс-функциональные (сотрудники разных отделов могли больше взаимодействовать, были ориентированы на один общий результат и узнавали о параллельных процессах много интересного). В итоге, компания за три месяца достигла того, чего не могла добиться весь предыдущий год. Как результат - счастливые заказчики и команды без дополнительных мотивационных вложений.
Тезис №5. Agile и микроконтроль несовместимы
Согласно методике Agile, руководитель не контролирует команду, а задаёт рамки, указывает цели и даёт достаточно свободы в принятии решений. После чего поддерживает, фокусирует, направляет и устраняет препятствия на пути команды. Для эффективной работы команда должна быть самоорганизованной единицей. Контроль как инструмент управления в Agilе-подходах заменяется на полную прозрачность процесса, которая в трех простых вещах: каждый в команде знает, что делают все остальные. Каждая команда знает, зачем она делает то, что делает (иными словами, ориентирована на бизнес-цель). И, наконец, проблемы, промахи и ошибки не замалчиваются, а обсуждаются и решаются. Например, поставщик онлайн-платежей PayU практиковали гибкость в течение нескольких лет на большинстве предприятий, но пока они не избавились от избыточной корпоративной отчетности, больших сдвигов не происходило.
Тезис №6. Agile подходит не только для IT-бизнеса
Agile-подходы применяются не только в разработке программного обеспечения, но и в производстве физических вещей и даже в госуправлении. Например, испанец Амансио Ортега - богатейший человек мира на август 2017 г. - применяет agile-подходы почти во всех компаниях, входящих в принадлежащий ему розничный гигант Inditex: Zara, Massimo Dutti, Bershka, Pull and Bear и другие. Быстрая обратная связь от потребителей и регулярные эксперименты, позволяющие оперативно проверять гипотезы, позволяют Zara выпускать до 40 коллекций в год (у среднего аналогичного бренда - от 4 до 8 коллекций). Другой пример - госучреждения Великобритании, где Agile - негласный стандарт. Например, метод применяется в области государственных услуг. Данные о потребностях граждан постоянно анализируются и работа сервисов госуслуг корректируется, исходя из собранной информации (например, становятся более удобными часы работы).
Тезис №7. Внедрение Agile может привести к краткосрочному снижению издержек, но это не главное
Хорошие профессионалы стоят дорого, поэтому пока формируется команда, расходы оказываются высокими. Однако суммарные затраты на проект будут низкими за счет быстрого запуска продукта. Например, поставщик медицинских информационных решений корпорация Cerner внедрил Agile, когда встала необходимость ускорить выпуск своих продуктов на рынок. Благодаря гибкому подходу компания сократила выход на рынок и издержки до 75%.
По следам конференции "Команды-2017. Опыт лидеров", которая прошла 29 ноября и на которой побывала Юлия Чемеринская
Самое практическое и конкретное выступление было у Наталии Даниленко, начальника управления по работе с персоналом Сбербанк Технологии. О нем и напишу. Ибо масштаб сберджайлизации абсолютно уникален для России: сейчас в agile--периметре уже более 11000 сотрудников группы компаний Сбербанк, из них более 6000 - это сотрудники ИТ-компании, в которой Наталия является руководителем HR-службы.
Agile-технологии в Сбере за год слегка трансформировались и приобрели свой формат, поэтому его называют Sbergile:)
КАК ЭДЖАЙЛ ЖИВЕТ В СБЕРБАНКЕ
Манифест - манифестом, его уже все выучили:)А вот конкретные цели. Чего в компании хотели достичь:
Организационная единица - это команда. Объединена она по способности создать продукт. Команда в Sbergile - постоянная команда. В отличие от Scrum. Ее не распускают. Она отвечает за созданный продукт, совершенствует его в течение всей его жизни.
Важно, что в команде все со всеми общаются лично каждый день.
Представляете, 1300 команд? 10 тысяч человек? Масштаб вызывает уважение. А представляете, какую гигантскую работу пришлось провести, чтобы это стало возможным? Вот лишь четыре задачи трансформации. Каждая огромна, трудозатратна и с точки зрения перестройки крайне непроста. И самое сложное здесь - это культурная трансформация людей и компании.
Разумеется, возникает вопрос: при размывании роли руководителей как оно все управляется? И что сказали боссы, которых лишили должностей и званий? Сняли, так сказать, погоны? Отвечу сначала на второй вопрос. Разговоров пришлось провести много. Но теперь в подразделениях Сбербанка, перешедших в agile, больше нет отделов, управлений и департаментов в штатном расписании. Бывшие начальники отделов, управлений, департаментов теперь на экспертных должностях без подчиненных. Трайб - это организационный "мешок" в котором нет больше иерархической структуры и начальников.
Кстати, никто из них не уволился! В отличие от, к примеру, переходящего на холакратию Zappos, который потерял 50% своих менеджеров, не согласных с таким поворотом:)
УПРАВЛЕНИЕ В СБЕРДЖАЙЛ
Как выглядит управлениие в Сберджайл.Agile - структура виртуальная. А так все сотрудники числятся на единой должности ИТ-инженер с широкими обязанностями.
А роль руководителя размыта между разными людьми и держится на четырех ключевых фигурах. Ну потому что, согласитесь, не может быть одного руководителя над девятью разными профессиями, собранными в одной команде.
1. Владелец продукта.
С ним все более-менее просто. Сложно только, что это роль, а не должность:) Часто воспринимается как руководитель - сложно перестроиться с иерархической культуры. Хотя Владелец продукта может получать меньше участника команды.
Опыт пребывания Владельцем продукта полезен всем, но не всем комфортен.
2 и 3. Лидер чаптера и Лидер компетенции
Лидер чаптера - это такой играющий тренер. У него 7 человек. На 50% он является лидером чаптера, а на 50% занимается развитием других. Например, у него 15-летний опыт работы с кредитными картами. Он и создает с командой продукт, и развивает сотрудников в других командах, кто тоже занимается кредитеыми картами.
Лидер области компетенций, к примеру, мастер 80-го уровня в IOS, занимается только развитием этой техкомпетенции у 24 сотрудников, за которых он отвечает. Грубо говоря, учит писать и проверяет их IOS-коды.
От скрам-мастеров Сбер отказался и передал их роль agile-коучам. Они ребята очень загруженные, коучат по 3-4 команды. Развивают ценностно (в сторону agile) и помогают понять и реализовать потенциал каждого сотрудника.
Кто же принимает решения и несет ответственность?
Решения принимает вся команда, результаты оцениваются общие.
Есть правила работы частично на основании методологии, частично создаются свои законы.
ОЦЕНКА И РАЗВИТИЕ ЛЮДЕЙ В СБЕРДЖАЙЛ
Что является обязательным условием развития? Стимул развиваться, объективная оценка и постоянная обратная связь.Про развитие по всем фронтам уже написала выше. И бизнес-компетенции тебе развивают, и технические, и человеческие.
Так же происходит и оценка: с разных сторон, разными людьми.
То есть одним человеком на постоянной основе занимаются аж сразу три человека:
- владелец продукта смотрит на него с позиции создания самого продукта - качества и сроков,
- лидер компетенции - на его технические компетенции,
- аgile-коуч отвечает за его развитие в эджайл, его роли в команде, его потенциала.
ПРЕМИРОВАНИЕ
До недавнего времени, а именно до октября этого года, в Сбербанке была квартальная система премирования, основанная на целой многоступенчатой системе KPI. С октября от нее отказались, потому что в понимании Наталии (я, кстати, тоже очень поддерживаю) материальное стимулирование не работает на сотрудниках, от которых мы ждем интеллектуального продукта, креативности и инновационности. Оценка по KPI превращается в профанацию, все пытаются "обмануть систему" или "прогнуться" под нее, убивая инновации, риск и творчество.В результате перевели премирование в оклад и осталась только небольшая годовая премия. Это очень верно. Айтишники не премиями мотивируются.
Кстати, если вы хотите научиться разрабатывать эффективные схемы оплаты, в том числе для айтишников, добро пожаловать к нам на курс Менеджер по компенсациям и льготам .
Ну и в заключении плюсы и минусы.
ПЛЮСЫ AGILE-ТРАНСФОРМАЦИИ
МИНУСЫ AGILE-ТРАНСФОРМАЦИИ
В конце Наталия пригласила всех желающих на экскурсию по Сберджайлу, которая состоится в декабре в офисе на Кутузовском. Следите за нашими анонсами!
Если вам было интересно, ставьте лайки и делитесь постом, буду писать еще.
Удачи,
Ваша Чемеринская
jc@сайт
Казалось бы, вот она идеальная модель управления и организации, если бы ни одно "но". Вся мотивация, заряд позитива от ТОП-менеджмента Банка разбивается об амбиции линейного руководителя, неадекватность которого без соответствующего аудио ряда описать сложно.
Есть в Банке подразделение мониторинга (для простоты понимания - занимается мониторингом финансового состояния клиентов, его залогами, выполнением условий кредитной документации). Подразделение молодое и только стало развиваться, обрело проектное наполнение, закрепилось. И тут появляется новая фигура - г-н М.Ю.Ш.
За первые два месяца 2018 г. не сделано ни одного шага вперед по сутевым вещам. Резко возросло количество совещаний, где один спикер, мотивирующий через унижение самооценки сотрудников, постоянно повторяющий: "... я взял на себя обязательства, я подписался, это не мне надо... меня попросили, но я сюда не вызывался...", два часа соло одного актера.
Совещания подпитываются "10+" итерациями по согласованию с ним одной бумажки, не готовность г-на Ш. принимать решения по ним вообще поражает. Все решения голосованием. Народ в кулуарах смеется и рыдает. Для совместного сотрудничества предлагается подписать "коммитмент" (контракт). Всем явно говорят - скажите спасибо за то, что с вами вообще будут работать. Царь! Свой секретариат из особо приближенных - штаб!!!, новые люди, которые вообще к предметной области никакого отношения не имеют.
За 2 месяца из подающего надежды подразделения сотрудники превратились в серую измотанную бюрократией массу, без мотивации и прозрачности своего будущего. Сарафанное радио уже работает, очные встречи проведены г-ном Ш. с руководителями территориальных Банков, там тоже народ недоумевает. И это только часть той ситуации, которую никак иначе как "показухой" и имитацией рабочей деятельности не назовешь. Наблюдая за всем этим, возникает чувство глубокого разочарования и бессилия перед глупостью одного "лидера" в огромной системе.
Колонка руководителя проектного офиса компании Phobos
В закладки
Руководитель проектного офиса компании Phobos Алексей Прокопенко написал для сайт колонку о том, почему он перестал руководить ИТ-проектами в «Сбербанк-технологиях» и ушел работать по Agile на аутсорсе. Автор также рассказал, почему система Agile не приживется в крупных банках.
Герман Греф съездил на экскурсию в Калифорнию и привез картошку Agile в Россию. Стоит заметить, что Россия идет с большим отставанием в вопросе разработки, внедрения и эксплуатации технологий. Причины очевидны - климат для бизнеса и инноваций в стране отсутствует. Но одна из главных причин - это непонимание скорости развития технологий.
Мы знаем много случаев создания революционных продуктов небольшой группой людей. Например, команда , создавшая первую версию OS Android, состояла из пяти человек. Dropbox и вовсе придуман одним Дрью Хьюстоном в автобусе. Для появления инноваций на западе есть развитая инфраструктура - хакатоны, акселераторы, инкубаторы, бизнес-ангелы, венчурные инвесторы, фонды, крупные компании и прочее, которые удовлетворяют спрос на технологии мира.
Сейчас технологии развиваются с фантастической скоростью. Количество научных статей за месяц только по data science превосходит человеческие возможности по их изучению. Это приводит к тому, что действительно прорывные технологические компании находятся в состоянии самой жесткой в мире конкуренции. Чтобы поддерживать свое лидерство, они должны быть быстрыми и мобильными. В современном мире невозможно стимулировать рост технологий, увеличивая количество людей и затрачиваемого капитала.
Мы строили, строили…
Я руководил ИТ-проектами в составе «Сбербанк-технологии». При его создании руководство «Сбербанка» имело четкую цель - централизовать ИТ-команду в отдельном подразделении. Банку нужно было делать разработку продуктов быстрой, а систему гибкой. Но работая в «Сбертехе», мы подчинялись самому «Сбербанку» и вынуждены были согласовывать каждый свой шаг.
Бесконечные заполнения документов, отправка их на согласование и ожидание ответа - все это замедляло процесс создания проекта и не давало стимула работать. Даже самого сильного специалиста с крутой идеей погубит осознание того, что эту идею не донести. Бюрократический ад не позволяет создавать продукт быстро. Государственный банк - большая неповоротливая монополия, которой трудно «перевернуться».
Простой пример. Мы разрабатывали важный для банка стратегический проект. Ребята работали до истощения, зная, что задача поручена непосредственно руководством банка. Подготавливается пакет проектной документации с календарным планом, бюджетом, бизнес-требованиями, описанием архитектуры - все эти нужные документы должны пройти через комитет технологий, состоящий из членов правления и руководства блоков банка.
В итоге мы все подготавливаем, а показать не можем. Документы ждут одобрения неделю, две - так проходят три месяца. Сроки, бюджеты, планы теряют актуальность. Их требуется переделывать, пересогласовывать. А создание проекта так и не сдвинулось с мертвой точки.
Но и в крупных коммерческих банках не идеальная картина, хотя и намного . До «Сбертеха» я работал в ИТ-департаменте «Альфа-банка», где создавал большой проект . В ходе процесса разработки появлялись идеи, новые решения. Команда разработчиков устраивала брейн-штормы и, как тогда казалось, двигала процесс. Но коммерческий банк с собственным ИТ-подразделением страдал все теми же проблемами, что и государственный.
Срок создания проекта был рассчитан на месяцы, но внутренние процессы в самом «Альфа-банке» растянули его на годы. В течение такого большого промежутка времени с разработкой может произойти все что угодно. Мы делали одну систему, описывая стостраничные документы, а через месяц руководство понимает, что нужна совершенно другая. Проект теряет актуальность уже во время разработки, потому что бизнес-процесс меняется быстрее, чем его могут реализовать. Руководство начинало понимать, что если их банк хочет стать передовым, то нужно создавать проекты быстро. Вот только пошли они не тем путем.
На примере «Сбербанк-технологий» «Альфа-банк» создал свое подразделение - «Альфа-лабораторию», где отделили разработчиков приложений, мобильного банка, онлайн-сервисов и остальных. Но, как говорил и сам менеджер проектов «Альфа-лаба» Вячеслав Акулов: «Альфа-лаборатория» - это часть «Альфа-банка», сильно интегрированная с ним. Основной наш фокус - это фронт и обслуживание клиентов, однако есть огромная часть бэк-офиса банка. Безопасность, юристы, ИТ-системы и прочее - без них банк существовать не может". Поэтому, несмотря на появление отдельного подразделения, создание того или иного ИТ-проекта вынуждено проходить через всю систему банка, описанную выше.
Большие проекты и маленькие команды
Для меня очевидно, что каждое отделение компании должно быть обособлено. Если банк решил создать свое ИТ-подразделение, то его нужно сделать гибким. Оно не должно быть единой кирпичной стеной. Необходимо сделать так, чтобы после извлечения одного кирпича стена не разрушилась, а стала еще лучше.
Тот Agile, который хочет ввести Греф в «Сбербанк-технологии» (Sbergile) по щелчку пальца, не может быть гибким из-за самой структуры банка. Руководство государственного банка никак не может понять того, что для быстрого создания продукта нужна не только методология, но и разработка небольшими компаниями. Agile - это методология, которую нельзя надеть на всю структуру банка, как шапку на голову.
Хороший пример: для создания проекта «Сбербанк-онлайн» на Android компания наняла отдельную команду дизайнеров. Специалисты работали обособленно от остальных и смогли сделать действительно хороший продукт. Им просто никто не мешал. Команде не мешали внутренние согласования, подписание бумаг, ожидание комиссии. Дизайнерам не нужно было лезть во всю структуру банка. Благодаря этому они смогли создать проект быстро и качественно.
Мир уже давно начал поворот от количества в сторону качества - это естественный процесс развитых стран, которым требуется технологический фактор для роста их экономик. Лучшие решение для крупных компаний - это выделить spin-off или купить отдельную группу разработчиков, изолировать их от своей внутренней системы и дать быстро и направленно сделать продукт. Это станет возможным, только если компания сможет сделать всю систему гибкой.
Поработав в крупных компаниях, я увидел большую разницу в том, какой подход применялся для реализации той или иной поставленной цели. Я понял, что создание реальных проектов быстро возможно лишь при помощи гибкой Agile-системы, и ушел в Phobos. Это agile-outsource компания, которая специализируется на подборе проектной команды для реализации конкретной задачи. Команды, у которой есть опыт в реализации продуктов, а не написания документаций и согласования процессов.
Гибкая методология разработки позволяет таким командам в высоком темпе делать продукт и вносить в него изменения. Команда мотивирована тем, что может повлиять на процесс создания внутри - никакой лишней документации, никаких лишних переговоров. В итоге результат работы заказчик получает в срок, и продукт не устаревает еще на стадии разработки.
Каким будет аутсорс завтра
В «Альфа-банке» мы создавали проект по каскадной модели разработки: сначала пишется документация, затем она проходит согласование, далее идет процесс создания. Изначально при оценке проекта была допущена ошибка в сроках. В итоге за три месяца до дедлайна оказывается, что половина бумаг не согласована, а разработка вообще не начата. Половина сотрудников, удобно просидев на мягком кресле, начала бежать в появившиеся тогда «Сбербанк-технологии».
В итоге нет ничего: ни плана, ни команды, ни проекта. Срок создания был большой, и руководство не было в курсе, на какой он стадии. Так как команда разработчиков тоже была большая, то таким сотрудникам было легко спрятаться за спинами своих коллег. Ведь никто не узнает, кто в итоге был виноват.
В маленьких аутсорс-компаниях все иначе. Не за кого прятаться. Если ты что-то не сделал, то будет понятно, кто подвел команду. Кроме того, если это Agile-аутсорс, то на согласование не затрачиваются месяцы, а разработчики могут показать результат работы очень быстро. Если в проекте будут неточности, например, со сроками - их легко изменить.
Мне очень нравится Agile таким, каким он был создан. Это очень простая методология, подробное описание которой умещается в шесть строк. К сожалению, тот Agile, о котором мы сейчас часто читаем - это очень сложное и непонятное порождение маркетологов и консультантов, которое не имеет ничего общего с методологией, созданной когда-то группой практикующих разработчиков ПО.
«Туту.ру»: естественная эволюция
Гибкая разработка пришла из IT, и опрошенные РБК эксперты сходятся во мнении, что именно для компаний этой отрасли внедрение Agile более чем логично. «IT не та сфера, где допустимы тонны бумажек и бесконечные согласования, — считает Алексей Спасский, гендиректор IT-компаний Phobos и Deimos. — Рынок технологий — самый конкурентный и динамичный, он не растет простым масштабированием. У небольших и быстрых команд здесь все преимущества. Android, например, разработали восемь человек».
Софтверные компании часто сами приходят к Agile. Так получилось у российского туристического онлайн-сервиса «Туту.ру». С управленческими проблемами компания столкнулась, когда переживала бурный рост, в 2013 году штат отделов разработки и тестирования достиг 40 человек, рабочие процессы стали запутанными, менеджеры, ответственные за разработку разных продуктов, вели постоянную битву за опытных специалистов, нагружая их одновременно десятками задач. А разработчики софта жаловались, что ничего не успевают довести до ума. Решение созрело само. «Мы разделили людей на небольшие команды по семь—девять человек и сосредоточились на том, чтобы делать полезные для клиента функции сайта, а не просто выполнять задачи в рамках своей роли, — вспоминает технический директор «Туту.ру» Вадим Мельников. — Уже через месяц полноценно заработали пять команд».
Менеджеры, которые сами не программировали, а контролировали решение задач, смогли сосредоточиться на изучении потребностей аудитории и отслеживать большее количество проектов. И хотя число команд разработчиков удвоилось, это не потребовало увеличения штата менеджеров.
Использование практик Agile на всех уровнях позволило «Туту.ру» всего за три месяца разработать новый продукт «Автобусы», позволяющий покупать в онлайне билеты на междугородные автобусные рейсы, быстрее конкурентов среагировать на появление новой линейки тарифов у авиакомпаний (билеты по сниженным ценам для пассажиров без багажа) и добавить опцию поиска таких билетов.
Мельников убежден, что полноценно внедрить Agile в компании удалось именно потому, что общий стиль управления в компании всегда был неформальным и гибким: «Наш Agile — это в первую очередь мировоззрение руководителей и владельцев компании, признающих лучшим способом решения конфликтов на стыке компетенций коммуникацию, а не иерархию». Впрочем, он подчеркивает, что никакого революционного ускорения процессов внедрение Agile не дало: «Не было такого, чтобы было плохо — и вдруг стало хорошо, хотя в среднем все улучшилось».
Для небольшой компании, разрабатывающей онлайн-приложения, Agile — естественное решение. Куда труднее отказываются от иерархии в пользу скорости в крупных корпорациях.
Владимир Хренков (Фото: Владислав Шатило / РБК)
МТС: без фанатизма
В МТС об Agile задумались, когда компания стала выходить на новый для себя рынок — стала предлагать решения на стыке IT и телекоммуникаций. «Здесь очень важны сроки разработки продуктов: если будешь долго делать, то либо конкуренты опередят, либо спрос может пропасть, — рассказывает директор центра инноваций МТС Владимир Хренков. — Поменялся подход к производству: оказалось выгоднее не сосредоточиваться на долгой разработке больших и сложных продуктов, а в сжатые сроки выпускать так называемый минимально жизнеспособный продукт (MVP) и тут же начинать улучшать его, получая обратную связь от клиентов».
Agile-методики внедрялись в компании постепенно. В конце 2015 года директор департамента развития МТС Галина Ильчук пригласила консультанта по Agile Дмитрия Лобасева помочь улучшить работу одного из IT-направлений. Компанию не устраивала скорость, с которой разрабатывались новые программные продукты (в среднем 1,5-2 года), а также постоянные срывы календарных сроков. Проведенный Лобасевым аудит выявил несколько проблем, типичных для крупных компаний. Менеджеры не заботились об удовлетворенности клиентов, считая, что главное — подписать акты, и совсем не стремились иметь обратную связь по уже сделанным приложениям. Начальство приняло — и хорошо. Все решения по разработке новых программ требовали согласования 15-20 менеджеров, которые вместо того, чтобы встретиться и договориться по спорным моментам, вступали в затяжную переписку.
Организовав работу многофункциональными командами, в которых бок о бок работали сотрудники разных направлений, руководство компании добилось сокращения числа согласований в несколько раз. Также оказалось, что некоторые приложения и функции, которые давно и упорно разрабатывали программисты, уже не нужны пользователям.
В результате стало меняться отношение к подготовке проектов. «Например, компания отводила на разработку корпоративного портала более года, — рассказывает Дмитрий Лобасев. — В итоге мы провели тендер и сделали его всего за три недели. Запустили, протестировали. Обратная связь позволила улучшать портал уже в процессе работы».
Успешно опробованный на IT-направлении подход стал постепенно внедряться во всей компании. Созданный в октябре прошлого года инновационный центр МТС, подчиняющийся напрямую президенту компании, имеет простую структуру: это три команды по десять человек, в аппарате — всего три человека, которые занимаются координацией команд с другими направлениями.
У каждого сотрудника центра только один ключевой показатель успешности — выполнение задачи, над которой сейчас работает его команда. Члены команды сидят в одной комнате, чтобы общаться на короткой ноге и избегать ненужных совещаний. «Теперь мы выпускаем MVP за три месяца и сразу начинаем общаться с клиентом, — говорит Хренков. — Например, в прошлом году решили запустить услугу облачных вычислений и хранения данных для крупных корпоративных клиентов. Быстро запустили ее в самом простом варианте, и первый же клиент сказал: у вас только один центр обработки данных — ЦОД, что будет, если с ним что-то произойдет? Мы создали еще два в Петербурге и Новосибирске, и услуга сразу стала более востребованной». По такой же модели было создано приложение «Телемедицина», позволяющее консультироваться онлайн с врачами разного профиля. Сейчас инновационный центр МТС выпускает приложения по четырем направлениям: облачные технологии, цифровое здоровье, образование, киберспорт.
Существенно упростилась в компании и процедура финансирования проектов: раньше процесс мог тянуться месяцами, теперь вопрос о выделении относительно небольших для компании денег — до 100 млн руб. — может решаться в течение одного дня.
Хренков считает, что причина, по которой у МТC получается извлекать пользу из Agile, заключается в отсутствии фанатизма: «Мы не стали переводить на Agile все 75 тыс. сотрудников: тиражируем успешные подходы очень постепенно, адаптируя под каждое направление. Работа над некоторыми проектами, требующими крупных вложений средств и времени, связанных с большими рисками, останется каскадной».
NPM: «железо» со скоростью Facebook
Новосибирская компания NPM, один из крупнейших в России производителей оборудования для индустрии напитков, несколько лет назад начала поставлять свои аппараты за рубеж и столкнулась с жесткой конкуренцией. «И наши, и зарубежные производители оборудования для розлива пива в среднем готовят новый аппарат около двух лет, но по качеству и дизайну изделий они ушли на десятилетия вперед. Догнать их при равной скорости разработки невозможно», — говорит Agile-директор NPM Сергей Чирва.
В компании Сергей работает почти 20 лет — занимался маркетингом, поднимал продажи. Новую должность придумал себе два года назад, когда увлекся гибкой методологией разработки и, вдохновившись примерами Facebook и Amazon, задумался, можно ли производить новые аппараты путем итераций, то есть выпуская сначала базовую версию, а затем ее обновления. «Продукты в реальном производственном секторе создаются и меняются годами, — говорит Чирва. — Может ли заимствованный из IT подход увеличить скорость и качество в производстве «железа»? Наш опыт доказал, что может».
В качестве пробного камня была выбрана задуманная конструкторами компании интеллектуальная система Craftap Smart, которая могла бы в автоматическом режиме разливать пиво в тару любого объема, подавляя при этом образование пены.
Традиционная схема разработки — маркетологи создают концепт устройства, конструкторское бюро делает прототип, потом другие отделы готовят документацию, тестируют и, наконец, передают в производство. Руководство NPM решило рискнуть и делать новый аппарат так, как делаются программные продукты: поскорее выпустить первый вариант, а потом его дорабатывать.
Руководство компании выделило для работы над устройством специалистов из разных служб. Конструкторы работали в связке с маркетологами и специалистами по производству. «По самым смелым планам мы хотели разработать продукт в два раза быстрее обычного — за 12 месяцев, — говорит Чирва. — В результате сделали за шесть и продали целую партию, в основном за рубеж. Если бы мы разрабатывали Craftap Smart по обычной схеме, то до сих пор были бы далеки от первых поставок, а возможно, не создали бы его никогда».
Разработка и производство первой партии обошлись в 7 млн руб., уже на седьмой месяц с начала разработки было продано устройств на общую сумму 3 млн руб. (один аппарат стоит $3 тыс., или около 180 тыс. руб.), а к концу 2017 года компания планирует продавать Craftap Smart на 10 млн руб. в месяц.
Этот пример не уникален. Сейчас консультант по Agile Лобасев сотрудничает с одной из крупнейших сетей АЗС: помогает оптимизировать строительство новых заправок. «Здесь мы столкнулись с классической проблемой «колодцев». Речь о том, что в компании несколько подразделений, которые сосредоточены на исполнении процессов и выполнении своих KPI: это разведка подходящих площадок, юристы, безопасность, строители, розница, — говорит Лобасев. — С другими направлениями каждый «колодец» общается, переправляя тонны документов по почте. Мы объединили представителей этих «колодцев» в единую Agile-команду и предложили им встречаться несколько раз в неделю по утрам, чтобы совместно обсуждать вопросы по всем объектам».
Когда люди стали общаться на регулярной основе, выяснилось, что отдельные направления могут не ждать друг друга — например, юристы с удивлением узнавали, что могут начать оформлять документы еще до окончания основных работ по проекту, а не через месяц, как планировалось изначально. А главное — быстрее стали выявляться проблемы (со сроками, новыми требованиями от дорожных служб и т.п.), а значит, и быстрее стали обсуждаться пути их решения.
Беспощадный Agile
Если послушать пропагандистов Agile, то можно подумать, что эта методика — панацея, но это далеко не так, уверяет Алексей Спасский. Как правило, адепты этой методики умалчивают о провалах, ссылаясь на неэтичность упоминания компаний, где дело не пошло на лад. Но таких примеров немало.
Когда Сбербанк в 2012 году пригласил Дмитрия Лобасева внедрять Agile, из пяти созданных им команд фактически заработала лишь одна. Методики гибкого проектирования вступили в конфликт с 14-уровневой иерархией банка. «Это то, что принято называть наследием — корпоративная культура, которая сопротивляется изменениям», — говорит Дмитрий. Насколько продвинулось внедрение гибкой методологии разработки, можно судить лишь косвенно. Например, больше недели Сбербанк готовил комментарий к этому материалу РБК, но так и не смог его согласовать.
Если компания следует моде, не слишком хорошо понимая, чего она хочет в итоге достигнуть, внедрение Agile обернется пустой тратой денег, говорят все опрошенные РБК эксперты. И это недешевая ошибка. «Специалисты по Agile в банках и крупных компаниях получают от 100 тыс. до 600 тыс. руб. в день, — говорит Лобасев. — В среднем на начальный этап трансформации компании тратят около 10 млн руб.».
Многие признаются, что на протяжении первых месяцев Agile-трансформации в компаниях царит неразбериха. «Сотрудникам, которые так не работали раньше, это непривычно и дискомфортно, — рассказывает руководитель российской компании — разработчика игр RPF Анти Данилевский. — Кто-то считает, что это трата ценного рабочего времени, и воспринимает негативно». По наблюдениям Хренкова, рядовые сотрудники принимают перемены легче, а вот менеджеры, как правило, недовольны — ведь они теряют возможность использовать сотрудников для решения своих задач. В практике Лобасева были примеры, когда сопротивление менеджеров было столь сильным, что компаниям приходилось выбирать: либо сворачивать реформы, либо увольнять сопротивляющихся.
Гендиректор IT-компании Accera Анатолий Шеин отмечает следующий парадокс: Agile в большинстве компаний внедряется по каскадной методологии. То есть руководитель приказал, отделы потратили деньги и отчитались об успешно проведенной Agile-трансформации. И это показывает, насколько практика все еще далека от теории.