Less

Mindbox два миллиона строк кода b2b бизнес-логики под нагрузкой. Наши продукты: CDP, программа лояльности, персонализация сайта, транзакционные и массовые рассылки критичные по надежности и скорости работы элементы инфраструктуры бизнеса.

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

Это третий ежегодный пост про разработку по итогам черной пятницы недели максимальной нагрузки. Почему наконец думаем, что мы молодцы; что для этого сделали; почему столкнулись с трудностями и что планируем делать дальше.

Резюме: два года работали не зря

Пятый год подряд нагрузка на Mindbox примерно удваивается ежегодно. В ноябре 2020 мы обработали 8,75 млрд запросов к API, против 4,48 млрд годом ранее. Пик 400 тысяч запросов в минуту. Отправили 1,64 млрд писем и 440 млн мобильных пушей. Год назад писем было 1,1 млрд, а пушей почти не было.

Динамика количества рассылок в неделю черной пятницы:



По нашим данным, это сравнимый с hh.ru уровень нагрузки по запросам к API, по нагрузке на базы данных с Avito. Около трети от Яндекс-такси по запросам в минуту.

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

Сегодня можно делать вывод: справляться с ростом мы научились. Черная пятница в 2020 прошла без инцидентов, затронувших более одного клиента. Было два краткосрочных частичных отказа по вине внешней инфраструктуры, не нарушивших SLA. К сожалению, жалобы от нескольких самых крупных клиентов были, но это понятные нам единичные истории, над которыми мы работаем.

Более того, данные и субъективные отзывы пользователей показывают долгосрочный тренд увеличения качества разработки. Уменьшается количество дефектов критических ошибок, отказов и случаев неудовлетворительной производительности.

На графике нарушения внутреннего SLA (более строгого, чем внешнего), которое в этом году мы дополнительно сделали еще более строгим:


Количество нарушений внутреннего SLA у среднего клиента

Нам удалось за два года полностью переизобрести разработку, продолжая расти средним темпом 40% выручки в год (в 2019 431 млн, в 2020 618 млн) и выпуская новые фичи. Ощущения примерно, как менять двигатель у машины на полном ходу.

Что сделали за два года:
Попробовали централизованное управление разработкой (LESS) и отказались от него, выработав децентрализованные процессы, в том числе управления надежностью.
Выделили до 50% ресурса разработки на улучшение качества, сформировали две (из восьми) выделенные инфраструктурные команды.
Удвоили штат SRE. Теперь у нас семь SRE и круглосуточные дежурства.
Сделали успешную школу разработчиков, закрывающую половину потребности в найме, научились нанимать сеньоров и лидов.
Автоматизировали SLA и сбор других метрик разработки.
Мигрировали критичные элементы инфраструктуры в Яндекс-облако, полностью поменяв технологии разработки.

Это далеко не всё из запланированного. Продолжаем увеличивать объем выделенных на качество ресурсов. Ожидаем дальнейшего увеличения качества и ускорения выпуска новых функций в 2021 году и далее.

Кстати, мы регулярно пишем об обновлениях в продукте и ведем статус-страницу с историей инцидентов.

Истоки трудностей: 20082018

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

В 2014 рынок заставил нас повернуть в сторону более массового сегмента, в том числе е-commerce и retail. Это потребовало вложений в клиентский сервис, продажи и маркетинг.

Компания никогда не привлекала внешних инвестиций, всегда развивалась на свою прибыль. Вдобавок в 2017 году, через полгода после того как я стал CEO, мы столкнулись с нехваткой денег, я испугался и избыточно нарастил рентабельность. Всё это привело к сокращению расходов на разработку до 24% от выручки в 20182019 годах.

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

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

Какие меры мы приняли

Процессы и ресурсы

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

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

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

Пришли к ответственности архитекторов и команд за метрики надежности и прогноз стоимости серверов. Дополнительно выделили 30% в каждой команде на техдолг и баги, при ожидании непрерывности поставки бизнеса.

В 2020 процессы устоялись: сформировали вторую инфраструктурную команду, наладилась поставка. Доля ресурсов на бизнес-задачи стала медленно расти с нижней точки около 50%, а доля багов стала уменьшаться:


Распределение ресурсов разработки по задачам. График не очень информативен, так как надежную метрику наладили относительно недавно, но подкрепляется впечатлениями с мест

За это время научились нанимать и онбордить SRE, отделили их от DevOps и офисного IT, сформировали процессы дежурства и описали роль.

Дефицит инженеров удалось снизить двумя способами:
Создали школу разработки, выпускающую 8-12 junior-разработчиков в год. Это разработчики, имеющие опыт с нашим стэком, в способностях которых мы уверены. На сегодня в школе постоянно учатся 2 команды по 4 стажера.
Планомерно повышали ФОТ разработки, благо бизнес-результаты позволили. Средняя зарплата в разработке выросла со 120 тысяч рублей в 2015, до 170+ на конец 2020 и продолжает расти. Это позволило нанять несколько новых сильных сеньоров и техлидов. Доля расходов на разработку поднялась до 28%, а количество людей выросло с 27 до 64.

Метрики, метрики и автоматические метрики

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

Мы начали с автоматизации четырех метрик из книги Accelerate и ускорения конвейера поставки. Это не дало немедленных очевидных эффектов. Зато обмен опытом с hh.ru и Яндекс-облаком привел нас к автоматизации метрики нарушения SLA и автоматическому заведению дефектов. Тут мы ясно ощутили пользу и связь с прикладываемыми усилиями. График этой метрики с трендом в начале поста.

Нескромно, но, думаю, мы одна из немногих в мире компаний, у которой есть API для клиентов, позволяющий получать метрику доступности компонентов платформы в реальном времени.

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

Наконец, анонимные квартальные опросы (тексты с тех пор улучшились, но суть опроса не поменялась) и высокая оценка на Хабр-карьере показывают уменьшение несчастья разработки. Это касается оценки своего дохода относительно рынка, переработок и eNPS (данные пока только за два квартала).

Опрос о доходах разработчиков:



Опрос о переработках разработчиков:



eNPS разработчиков:

По шкале от 1 до 10 насколько вероятно, что порекомендуешь Mindbox как место работы?

Наконец, но не в последнюю очередь техника

Всё это позволило организовать переписывание монолитного продукта более 2 млн строк кода на IIS + ASP.NET + NLB / Windows Service / MS SQL одновременно по всем направлениям:

Микросервисный API и бэкенд, когда один запрос клиента к API Gateway прозрачно обрабатывается несколькими микросервисами, в том числе синхронные запросы (saga pattern).
Микрофронтенд, где разделы интерфейса отделенные от бэкенда SPA-приложения, способные размещаться в собственных репозиториях, со своим конвейером выкладки.
Перевод мультитенантных микросервисов с MS SQL на распределенные масштабируемые хранилища: Cassandra, Сlickhouse. Kafka вместо RabbitMQ.
Перевод приложения на .NET Core, linux и частичный переезд в Managed Kubernetes Яндекс-облака. Тут же внедрение современных SRE и DevOps технологий: OctopusDeploy + Helm, Prometheus, Grafana, Graylog + Sentry, Amixr.IO.

Возможно, мы один из самых нагруженных клиентов Яндекс-облака, поэтому о нашем внедрении и совместном с Яндексом преодолении трудностей CTO Никита Прудников рассказал на Yandex Scale 2020.

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

Дальнейшие планы развития

Несмотря на достигнутые результаты, должен сказать, что сделано меньше половины из запланированного. Впереди:
Продолжение повышения доходов разработчиков и найма лучших сеньоров и техлидов.
Третья команда школы разработчиков, позволяющая выпускать до 12 разработчиков в год.
Продолжение перевода приложения на .NET, k8s и Яндекс-облако, автомасштабирование, blue-green выкладка с моментальными rollback.
Движение к автоматическому заведению инцидентов на статус-странице, избавление от ложных срабатываний SLA.
Переход на .NET 5, EF.Core и PostgreSQL (а разработчиков на новые макбуки)&
Выделение еще нескольких крупномасштабных кусков из монолита.

Призываю мотивированных расти .NET-разработчиков, техлидов и SRE-специалистов откликаться на наши на наши вакансии на hh.ru. Будет интересно, можно приобрести уникальный на рынке опыт и делать штуки.

Роадмэп платформы в 2021 году

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

В этом году добавим в платформе:
Конструктор сценариев.
Хранение анонимных заказов и отчетность по ним.
Больше быстрых отчетов в интерфейсе (как в нашем курсе).
Интеграцию с BI.
Новый модуль мобильных пушей, в том числе. новый SDK.
Возможность быстро удалять любые сущности с учетом зависимостей друг от друга.
Больше ML-алгоритмов и множество улучшений качества существующих.
Больше страниц в новом дизайне с улучшенной отзывчивостью интерфейса.
Упрощенную настройку стандартных интеграций и механик.

Планы на 2022 более грандиозные, но о них надеюсь написать через год, если оптимизм окажется оправдан.

Спасибо

Как и клиентские истории успеха, эта заслуга конкретных людей, которым выражаю благодарность:

Никите Прудникову, CTO, за видение, системность и планомерное дожимание.

Роману Ивонину, ведущему архитектору, за терпение, построение команд, широкую ответственность, неформальное лидерство и бессонные ночи.

Игорю Кудрину, CIO, за фундамент SRE-экспертизы, видение и спасение всего, когда никто не знает как.

Ростиславу, Леониду, Дмитрию, Мите, Илье, двум Артёмам, Алексею, Сергею, Николаю, Ивану, Славе, Жене и другим неравнодушным разработчикам, продуктам, техлидам и SRE, сделавшим всё это реальностью. Простите, если кого-то не упомянул.

Отдельное спасибо клиентам, которые терпели, не смотря на то что мы подводили, и дали возможность исправиться. Приложим все усилия, чтобы дальше становилось только лучше.

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

Mindbox 15лет развивает B2B-продукт ивырос с3до70человек вразработке. Мытестировали разные подходы кмасштабированию иготовы поделиться опытом, чтобы вам непришлось наступать натеже грабли. Ниже расскажу, как попробовали полную автономию команд ицентрализацию, роняли надежность, демотивировали команды, как врезультате сэтим справились ивыработали свою систему масштабирования.

По материалам выступления на Agile Days 2021:

Надежность как ядро разработки

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

ВMindbox одна изсамых нагруженных разработок вРоссии, нопри этом она сохраняет высокую надежность. Когда покупатель пробивает чек накассе вБургер Кинге или аптеке Ригла, транзакция идет кнам. За200 миллисекунд мырассчитываем суммы иотвечаем кассе. Если сервис упал, томного людей повсей стране 24/7 становятся несчастны.

Запоследние 34 года бизнес растет по4050% вгод инагрузка удваивается ежегодно. Внешне всё отлично, ноуMindbox был длинный период становления, который влиял намасштабирование разработки.

Масштаб бизнеса и разработки

Эволюция разработки

Как работает автономия ицентрализация разработки

Проблема масштабирования разработки сводится кпоиску баланса между автономией ицентрализацией. Есть две организационные крайности:

1. Автономия. Вомногих компаниях победили автономные инженеры инет никаких сроков. Разработка постоянно закрывает секретный техдолг, абизнес непонимает, как решать крупные задачи. Это заканчивается революцией: бизнес теряет терпение ивносит радикальные изменения впроцессы.
2. Централизация. Другая крайность когда побеждает бизнес. Дедлайны спускаются наразработку сверху, задачи бизнеса решаются, нокопится техдолг. Потом процессы опять замедляются иистория заканчивается революцией: предлагают переписать код снуля или продать компанию.

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

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

Как внедрили автономию

С2007 по2013 год было мало клиентов ибизнес рос медленно, потому что писали большой исложный продукт. При этом управление разработкой было простым: один главный бизнес-эксперт иглавный архитектор это я и34команды. Делал статусы раз внеделю, потом раз вдве недели ходил покомандам эффективно илегко.

Дали автономию командам. Постепенно бизнес стал прибавлять по4050% вгод, поэтому нужно было запускать больше продуктов ипродвигаться быстрее. Втоже время мыначали строить бирюзовую культуру, прочитали книгу Лалу ирешили, что нужны автономные продуктовые команды сменеджерами продуктов. Иэто заработало запустили новые продукты.

Бирюзовая компания вРоссии: открытые зарплаты, самоуправление, прозрачность иошибки
Фредерик Лалу: Открывая организации будущего

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

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

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

Как внедрили централизацию

Централизовали управление. Прочитали книгу оLeSS (Large Scale Scrum), сходили натренинг ирешили централизовать разработку: внедрить общий roadmap, единое управление иразгрумить эпик надежности.

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

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

Так мысоздали роль CTO (chief technical officer), хотя доэтого небыло менеджмента, отвели30% ресурса натехдолг ивнедрили LeSS. Это значит, что70% разработчиков занимались roadmap бизнеса, а30% техническим roadmap, который определяет CTO. Врезультате техдолг начал сокращаться, имыувидели положительные изменения.

LeSS Scrum набольших масштабах

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

Демотивировали инженеров именеджеров попродукту. Следом случилась ещё одна черная пятница, исервис снова лег. Это было грустно, хотя мыуже видели, что есть положительные изменения. Ноэто было неглавным.

Главное, что год мыпрожили врежиме LeSS изаметили негативные эффекты для компании. Инженеры именеджеры попродукту были демотивированы. Уинженеров небыло домена ичувства собственности, как увавтономных команд: три месяца они работали над одним продуктом, потом три месяца над другим. Менеджеры попродукту загрустили, потому что roadmap планируется централизованно иtime tomarket стал огромным. Нельзя было взять ивнедрить небольшую доработку для клиента, потому что roadmap управляют централизованно.

Как нашли баланс между автономией ицентрализацией

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

Вернули команду инфраструктурной платформы. Фактически инфраструктура это тоже внутренний продукт, аCTO выполняет роль менеджера попродукту, поэтому выделили отдельную команду под инфраструктуру.

Сточки зрения бирюзы инфраструктурная команда казалась неправильным шагом, новделе это показало себя хорошо, итакая команда мотивировала всех остальных. Сначала мыбоялись, что интересные технические задачи уйдут винфраструктурную команду. Насамом деле выделили для этого отдельных экспертов иотдали задачи, которыми нехотели заниматься разработчики издругих команд.

Оставили30% ресурса команды налокальный техдолг. Мыдоговорились одвухуровневом разделении. Наверхнем уровне30% всего ресурса разработки отдали CTO наинфраструктурную команду итехнический roadmap. Ещё30% отдали натехдолг, который приоритезирует команда. Фактически смомента, когда начались проблемы снадежностью имасштабированием, почти50% всего ресурса это технические задачи.

Техдолг ~30% платформы и 30% команды

около 50% в целом



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

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


Из LeSS оставили кросс-командный рефайнмент, чтобы снять риск монолита и управлять roadmap

Ввели автоматический контроль надежности. Чтобы усилить надежность, мыпосоветовались сразными компаниями исделали автоматическую метрику. Раньше клиенты жаловались накритические баги, менеджеры сообщали обэтом разработке имыиханализировали. Атеперь мысоздали автоматические уведомления, который приходят, если нарушаются определенные метрики. Иэто помогло улучшить надежность, потому что навсех статусах мыстали обсуждать формальные вопросы: нарушается SLA или нет.

Несмотря наточто впрошлый раз мыупали вчерную пятницу, было ощущение, что платформа стала надежнее имыдвижемся вверном направлении. Новая метрика доказала наши наблюдения надежность компании действительно росла.

Нарушения SLA среднего клиента вмесяц надежность повышается

Починили надежность. Следующую черную пятницу мыпережили нормально. Это стало доказательством того, что процесс работает иесть положительный эффект для бизнеса.

Создали роль Scrum-мастера. После того как разобрались срисками вдецентрализованном roadmap, справились стехдолгом инадежностью, решили повышать эффективность разработки. Для этого создали роль Scrum-мастера, который собирает весь опыт разработки (developer experience) изаносит вспециальную форму все препятствия ипричины, мешающие разработке. Потом поаналогии состатусами понадежности Scrum-мастера централизованно обсуждают сCTO задачи замесяц, приоритезируют ихичасть добавляют втехдолг.

Создали круги управления. Чтобы комплексно управлять общими аспектами разработки, мыорганизовали виртуальную команду, или круг управления, представители которого сидят вразных командах. Уэтого круга есть набор ритуалов, которые собраны надоске вTrello: встречи побюджету, демонстрации продукта или найму. Такое кросс-командное общение помогает сфокусироваться накаждом процессе инатом, как его улучшить вовсех командах сразу.

Виртуальная команда (круг) управления

Ритуалы управления

Круг управления помогает аккумулировать кросс-командные аспекты: надежность, стоимость железа, найм, developer experience. Для этого проводятся встречи ритуалы управления


Определили метрики разработки. Пока мымасштабировали разработку, нас волновал один вопрос: какие метрики позволяют оценить разработку ичто нужно оптимизировать. Это было неочевидно.

Мызнали, что скорость иroadmap нельзя измерять, потому что есть проблемы стехдолгом иэто только демотивирует разработчиков. Науровне стратегии разработки мысформулировали, что цель разработки оптимизировать непрерывный запуск продуктов (time tomarket) врамках ограничений надежности, стоимости железа ибез увеличения технического долга. Ировно такиеже ожидания сформировали для команды. Команда должна непрерывно поставлять фичи, увеличивать time tomarket, нопри этом поддерживать определенные обязательства понадежности, SLA истоимости.

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

Показатель эффективности

врамках SLA, стоимости железа ибез увеличения техдолга

Какую выработали систему масштабирования разработки

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

Разумное регулирование общего. Как ядро оставили общие задачи, над которыми должны работать централизованно: roadmap монолита, надежность иинфраструктура, стоимость железа иdeveloper experience. Если нет общих знаний отом, как создаются базовые вещи, топеремещение разработчиков между командами будет затруднено, код будет дублироваться иесть риск потерять эффект масштабной разработки, когда каждая команда существует изолированно отвсех.

Всем привет!

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



Интересующимся и желающим пообщаться на эту тему добро пожаловать под кат.

Начнем с крупных компаний. Под крупными компаниями я имею ввиду компании с тысячами разработчиков, тестировщиков, аналитиков, инженеров девопса, владельцев продукта и прочих пипл менеджеров. Это десятки подразделений, сотни команд, сложные иерархии, бесконечные зависимости и зоны ответственности.

Попадая в такую компанию, поначалу сложно сориентироваться. Но проходит время, и вот ты уже вполне можешь представить себе свой островок. Как правило, это:

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

Знакомая картина?

Так выглядит типичная, и не самая худшая система разработки ПО. Обычно, к такому виду приходят департаменты разработки компаний с успешными продуктами лет через 10-15. Успешные продукты приносят деньги, деньги вкладываются в разработку. Разработка растет как на дрожжах, ее линейно масштабируют и приходят к ситуации, когда проектные менеджеры уже не могут держать в голове все зависимости, множество команд начинают тянуть одеяло на себя, и, порой вредят продукту, нежели развивают его. В такой ситуации вполне нормально, когда одна команда стремится к собственному успеху, уже не переживая, что их коллеги испытывают какие-то проблемы и их общая фича не будет из-за этого доставлена. В порядке вещей разрабатывать тот функционал, который громче всех просят бесконечные стейкхолдеры, а не тот, который нужен пользователям. Не редкость и разработка в стол. Процесс ведь идет требования приходят, реализуются, тестируются, поставляются. За ширмой из суеты и шума легко спрятать главное разработка продукта уже далеко не такая эффективная, как раньше.

Для того, чтобы осознать эту потерю в эффективности, давайте обратимся к классике продуктового менеджмента. Сейчас достаточно онлайн школ или университетов, которые могут за те или иные деньги обучить вас этой науке.


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

Не похоже на историю выше, верно?

Дело в том, что когда вы небольшой стартап, то все процессы разработки продукта довольно прозрачны и понятны. Очень просто засечь проблему и исправить ее. Просто понять идею продукта. Просто понять и разработать требуемый функционал. Пользователи вот они, под рукой. Прод вот он, со всеми метриками.

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

• Пользователей кастдевил продакт? Теперь ваши владельцы продукта о них не вспоминают, они носятся от одного стейкхолдера к другому, пытаясь понять за какие требования хвататься в первую очередь;
• Была ясная и прозрачная юнит-экономика? Теперь владельцы продукта не считают даже PnL, загружая всю команду на пол спринта сторями с сомнительной пользой;
• Были job story, customer journey map и прочие персоны? Теперь в сторе пишут Как продакт оунер я хочу чтобы это было сделано, потому что это нужно департаменту Operation and Maintanence;
• Было понимание ответственности за результат и сроки? Теперь каждая команда сама за себя, ваши фичи доставят на релиз-другой позже.

Сложность управления разработкой для масштабных продуктов растет по экспоненте. Что же делать?

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


Являются ли они серебряной пулей?

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

И могу сказать следующее:

• это дорого;
• это не быстро;
• это очень рискованно;
• конечный успех сильно зависит от культуры компании. Если люди понимают и верят успех вероятен.

Единственно ли верен подобный подход? Давайте посмотрим, что еще можно сделать.



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

Продукт. Продукт должен приносить ценность. Рассмотрите зоопарк ваших систем и компонент с точки зрения ценности. Выделите все потоки ценности (value streams) для конечных клиентов, контрагентов или третьих лиц и разделите карту систем по таким потокам. Каждый владелец продукта должен иметь в управлении полную цепочку систем, имеющих ценность. Дайте ему пару аналитиков, если объем ответственности слишком велик.

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

Пользователи. В сторону стейкхолдеров. Только пользователи могут дать верное представление о ценности продукта. Владелец продукта должен ориентироваться на результаты интервью и анализ тикетов поддержки в своих гипотезах.

Гипотезы. Никаких больше имплементаций функционала в слепую. У каждого эпика или фичи должны быть ожидания по влиянию на метрики. Реализуя фичи и проверяя их А/B тестами, владельцы продукта должны понимать успешна была гипотеза или нет.

Координация. Разумеется, работа многочисленных продактов должна быть скоординирована в соответствии с выбранным вами фреймворком. Однако не стоит превращать такую координацию в коллегию продакт-менеджеров с коллективной ответственностью.

Я считаю, что только сохраняя вышеописанные условия можно успешно смасштабировать продуктовый менеджмент, и по большому счёту не важно, какой фреймворк вы выберите для этого масштабирования.