Agile-коуч
Agile-трансформация
AgileSurvey
Beyond Budgeting
DevOps
HR
Kanban
KPI
LeSS
OKR
OKR-инструменты
PMI
Project management
SAFe
Scrum
Scrum in Hardware
Scrum-мастер
Spotify
XM
Архитектура
Бюджетирование
Владелец продукта
Игра
Инженерия
Конфликты
Менеджмент
Обучение
Продуктовый менеджмент
Самоорганизация
Тренинг
Фасилитация
Финансы
Холакратия
Применить

Темная сторона Agile

Спустя некоторое время после перехода, например, на Scrum, компании начинают сталкиваться с новыми вызовами, порожденными гибкими методологиями. И мало кто рассказывает, что Agile потянет за собой дорогие и долгие задачи по архитектуре, инфраструктуре, процессам и, что особенно сложно, культуре.

Доклад на конференции AgileDays 22 марта 2018 года. Слайды доклада

Дмитрий Круглов

Дмитрий Круглов, ИТ директор, Яндекс.Деньги

Очень интересно, что у нас подряд два доклада на похожую тему: «Почему, может быть, вам не стоит внедрять Agile?» [имеется в виду доклад Антона Зотина]. Но я сделаю акцент на том, в чём больше я считаю себя специалистом. Я не психолог, про людей у меня будет, но не много. Я сделаю акцент на процессах, на технических аспектах, и иногда даже и про деньги поговорим.

Скажите, пожалуйста, «тёмная сторона Agile» у кого ассоциируется с Дартом Вейдером? На деле — речь не про это. Речь пойдет о темной стороне Луны, которая, как известно, была для человечества неизвестна, до тех пор, пока туда не прилетел первый космический аппарат, который сфотографировал. Так вот, суть моего доклада и его идея в том, что, когда вы начинаете внедрять Agile, вы составляете проект освоения Луны, не зная, что на другой стороне. И лучше бы эти вещи представлять заранее.

Мой рассказ — в достаточной степени капитанский для тех, кто прошёл хотя бы половину пути. Если вы в завершающей части того, что сейчас прогрессивное человечество знает и умеет про Agile, то для вас вообще всё это будет просто повторением того, что вы уже пережили. Лично для меня это опыт в трёх разных компаниях, плюс достаточно много референсных историй от моих друзей, которые в общем вылились в то, что я рассказывал эту историю за последние полгода раз десять. И понял, что она стоит того, чтобы её рассказать на более широкую аудиторию.

Всё начинается с разработки

Всё начинается с попытки внедрить новый процесс разработки, будь то Scrum или Kanban, или гибрид Scrumban, или какой-нибудь велосипед, который изобретёте у себя. Но классические отделы разработки — это отделы с ресурсными менеджерами во главе, и у них есть общая потребность. Ну вы представляете себе, один человек говорит: «Не надо ходить, пожалуйста, к моим разработчикам, приходите ко мне». Дальше он распределяет эти задачи. Бывают хорошие ресурсные менеджеры, бывают плохие. Но даже хорошие, когда они прекрасно справляются с распределением задач, рано или поздно, начинают делить свою работу на выделенные потоки для выделенных клиентов. Потому что нормально, когда в бизнесе есть много различных внутренних заказчиков или даже внешних заказчиков, неизбежно начинаются конфликты, начинается борьба за ресурсы. И так или иначе, ресурсный менеджер пытается это решить, выделяя, например, потоки.

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

Бизнес очень доволен. Бизнес — это продакт оунеры — люди, которые помимо того что отвечают за функциональность, также несут бремя ответственности за P&L, за трафик, за прочие KPI, которые сверху им даны, такие как цена ресурса, который они получили. Так вот, бизнес доволен, потому что вот теперь мы видим живых разработчиков, мы с ними общаемся, есть прямой контакт, можно транслировать идею, можно их вовлекать. И это все работает, и все вроде хорошо.

Начинается изменение кодовой базы

Так вот, не все хорошо. Дело в том, что в большинстве отделов классической формации, экономически целесообразно иметь монолит. И это не голословно. Я знаю, у меня есть знакомый, который в крупном ритейле построил автоматизацию на монолите от вендора и вполне мотивированно объяснял мне, почему для него это лучшее из возможных решений. То есть, когда в каком-то отделе по инициативе самого отдела начинают внедряться, например, микросервисы – это скорее всего та же мотивация, как “попробовать новые технологии”. То есть, хочется что-то новенького. В большинстве же случаев, работа в монолите внутри отдела экономически оправдана, со всеми понятными последствиями — такими, как релизный цикл 2-3-4 недели, долгие сборки, долгое тестирование. Команды так жить не могут, Product Owner не будет ждать 2-3-4 недели, когда очередной крупный релиз проходит, поэтому команды начинают писать свой код.

Код расползается, это совершенно естественная эволюция работы в Agile. Микросервисы вернулись к нам исторически именно потому, что мы стали переходить на небольшие команды и работать в командах. Когда расползается код, ускоряется выпуск продукта, начинаются чаще собираться релизы. И, естественным образом, возникает следующая проблема: мы упираемся в тестирование.

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

Начинается реформирование тестирования

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

Из личного опыта. Мы, когда начинали, у нас на каждый монолит было по одному тестовому стенду, и, в принципе, всё было хорошо. Потом, когда появились команды, и мы сделали очень сложный проект по разделению тестовых стендов, у нас их стало 20. Аппетит приходит во время еды, мы живём сейчас более чем 70-тью стендами и реально пониманием, что достаточно будет порядка двухсот. 200 тестовых стендов, плюс продакшен, умножить на более чем 50 компонентов в вашей системе… это же сколько приходится усилий тратить на деплоймент?! Когда мы только начинали этот путь, я спросил у одного из моих системных администраторов естественный вопрос: «Скажи, а где же автоматизация деплоя?». Он сказал: «У меня выкладка раз в две недели занимает час, что мне здесь автоматизировать?». Это эпоха монолита, а теперь мы имеем эти самые 50 плюс компонент, и, если бы их не катил робот, это было бы просто невозможно потянуть с точки зрения ФОТа.

Зарождается DevOps

И у вас неизбежно появляются автоматизированные процессы сборки, доставки на прод, у вас, более или менее, отлаживается работа в командах по процессу. И вы достигаете каких-то серьёзных показателей, например, 60-80 релизов в неделю: каждый компонент по паре, тройке раз релизится в день. Когда это всё заработает, вот тогда начинается состояние хаоса: никто не понимает, что вообще в системе в данный момент происходит. Она становится слишком большой, чтобы один человек её мог охватить взглядом. Вот чем хороши монолиты, — обязательно в отделе найдется пару старожилов, которые или создавали, или были с самого начала, и они вам просто на пальцах любую проблему объяснят и сразу у них чуйка на проблему, они знают, где и почему она возникла. Они помнят все эти баги, которые они закопали на 100 лет, они помнят все странные логические решения, которые бизнес продавил. Из разряда, надо нормально 3 раза попробовать в клиента постучаться, но вот этот клиент особый, мы будем 100 раз стучаться, там специально коэффициент поправочный стоит, и не надо его, пожалуйста, трогать, он там не просто так.

Требуется качественно другой мониторинг

В этот момент, катастрофически возникает потребность в мониторинге. И вы знаете, приходишь к админам, а они говорят: «Да, у нас есть мониторинг, у нас всё покрыто мониторингом, у нас, смотри, каждый процессор, его температура меряется». Кому это помогло в случае с инцидентом с клиентами? Железячные метрики не работают. Софтверные метрики разработчиков “Сколько Java сейчас памяти отожрала” — в большинстве случае вам тоже не помогут. И что самое обидное, вам не особо помогут бизнес-метрики, если вы их не сделали кастомными.

Почему? Дело в том, что мир сложен, он не чёрный и белый, и редко бывает, когда у вас идеальный API или идеальный продукт, и клиенты очень точно и правильно их используют. Чаще всего там есть эти самые пресловутые костыли. И клиенты, если они адекватные, это тоже принимают, они под костыли подстраиваются. И вот как вам поможет классический мониторинг, если вдруг там сломались платежи у клиента, потому что вы баг починили? А это обычная история, она случилась у нас 2 недели назад. Мы баг починили на продакшене, и сломалось несколько рабочих процессов у клиентов, у которых под нас была специальная подстройка — именно под этот конкретный баг. То есть, они его учитывали в своих процессах. А мы, естественно, баги, знаете ли, не мониторим.

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

Начинаются конфликты планирования

И зонтичные проекты, я считаю, — это история, которую никто пока рынке хорошо не решил. И как бы нам не продавали консультанты новые надстройки над ставшими уже классическими Скрамом и Канбаном, например, SAFe, — они не работают. Точнее, работают, но они дорогие. Они дорогие административно, они дорогие ресурсно. Они требуют еще более дорогих и сложных компетенций, которых на рынке пока нет. Поэтому история с зонтичными проектами ни у кого хорошо не решена. А зонтичные проекты – это, если кто-то в теме, например, ФЗ-52, когда государство так говорит: «Ребята, перестройте-ка, пожалуйста, все кассовые системы в стране». Или история, когда маркетинг уже проплатил вам рекламную компанию, а продукт-то еще не готов, и его еще пилить и пилить. А дедлайн, он настоящий, за него расстреляют. Или вот эта история: просто приходит кто-то из ТОПов, и не важно по какой причине, но у него есть дедлайн.

Я был впечатлен, когда, общаясь со Spotify, узнал, что они очень сильно фрустрировали из-за семейной подписки. Они придумали ее за год до того, как ее выпустили Apple и Google, но не смогли реализовать по одной простой причине. Spotify — на западном рынке сейчас одна из образцовых компаний, работающих по Agile. Команды по-настоящему независимы. Но проблема независимости, когда тебе нужно сделать проект на 10 команд, оборачивается очень долгими сроками, потому что всех нужно уговорить. Потому что, если команды скрамовские, самостоятельные и хорошо работают, у них свои roadmaps, и ваша семейная подписка – это вообще не их цель сейчас.

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

От руководителей требуется другое

Отделы распределенные – это отделы, в которых руководителю очень некомфортно, потому что классический руководитель не понимает, в чем же его роль там в этом отделе. Это болезненный переход — от того, что я всем раздал задачи, до состояния, когда у меня вообще нет людей, и зачем тогда я в компании. Это процесс, когда нужно руководителей или учить и растить, или, упаси Боже, если так случается, менять. У меня был однажды руководитель в отделе — control freak на 100%: практиковал zero inbox сам и двойной публичный код ревью во всем отделе, и не дай Бог, если хоть одна задача без его внимания попадет на прод. И когда людей раздали в команды, у него не осталось людей, возникло страшное чувство дискомфорта: «Я вообще зачем здесь?». А затем, чтобы разработчики во всех командах обменивались информацией, росли более-менее синхронно в одном направлении, и чтобы система не расползалась и не превращалась в лоскутное одеяло, — вот зачем. А этому надо учить сначала самих руководителей, и это не просто, а на рынке их не достать.

Повышается требование осознанности

И последний момент: осознанность людей. Тут я даже не буду пытаться утверждать и говорить вам, что мы его перебороли или как-то освоили, или пережили. Увы, нет. Но изменения в культуре в IT становятся очевидными, если пройти все предыдущие этапы, и они касаются того, что мы ждём от отдельно взятого человека. Раньше чем разработчик был исполнительней, тем нам было комфортнее. То есть, поставил задачу, и он её очень чётко в срок быстро сделал. А теперь разработчики в командах, и состояние, когда они в команде внутри между собой самостоятельно договорились, — это тоже не очень хорошее состояние. Потому что они начинают отстаивать интересы команды, хотя это не единственные интересы в компании.

А правильное поведение — это когда люди дорастают до такого уровня зрелости, когда понимают, что есть служба безопасности, есть требования безопасности. Когда они понимают, что есть архитектура, она не просто так придумана и архитекторы не злодеи и не враги, и не сознательно им жизнь портят, а просто думают вперед на несколько лет. Когда они начинают учитывать интересы соседних команд. И вот такое поведение выявлять, взращивать, поощрять, — это становится очень серьёзной задачей.

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

Agile — верхушка айсберга

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

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

Второе: это процесс очень дорогой. Откровенно говоря, я считаю, что внедрять Agile и двигаться по всему этому пути нужно тогда, когда: а) у вас хороший, крепкий и достаточно устойчивый бизнес и крепкая компания и б) когда вы понимаете, что впереди будет больше, круче и вам нужно расти. Потому что, если у вас вопрос выживания, то извините меня, но вас это убьёт. И кажется, я где-то слышал статистику, что компании из top Fortune 500, которые начинали Scrum, оттуда и вылетали, потому, что это последняя вещь, которая добивает компанию. Там и так плохи дела, а ещё сверху Scrum, и вся это бодяга с инфраструктурой, админами и прочим.

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

Три вывода в заключение

В конце у меня есть для вас 3 вывода. Они очень простые.

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

Второй вывод. Если это локальная история, если у вас нет задачи всю компанию перестраивать, если у вас есть желание внутри или потребность, навязанная кем-либо, сделать новый продукт по новым подходам быстрее обычного, то иногда это проще отделить. И мы видели эти примеры на рынке. И Альфа Лаборатория тому хороший пример, и у Открытия есть свой «гараж», и можно даже банально нанять аутсорсера, который по Agile работает, дать продакт оунеру внешний ресурс. То есть, зачем завязываться на перестройку всего, если это локальная история…

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

Ну, и если вы отважились и уже идёте по этому пути, то удачи вам!

6 июл 2020, Дмитрий Круглов
Другие статьи
3 авг 2020, Дмитрий Кустов
Impact Mapping — инструкция по применению

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

30 июл 2020, Константин Хохрин
Цели в OKR: почему они должны мотивировать

Небольшой кусочек тренинга Константина Хохрина и Сергея Рогачева про OKR.

26 июл 2020, Константин Хохрин
Нежелательные явления как фокусировка для OKR

«Нет денег», «Не растет выручка», «Все плохо» – знакомые всем проблемы, которые часто партнеры и акционеры просят нас решить до того, как дадут нам инвестиции. Проблема таких проблем в том, что они не решаемы в том виде, в котором сформулированы. Для этого мы попробуем использовать ТОС (теорию ограничений) и дерево нежелательных явлений, как ключевой драйвер поиска исходных предпосылок — корневых проблем, на которые и следует сфокусироваться в наших OKR.