Что такое техрадар и почему он сбережёт ваши нервы

Техрадар обычно бывает двух видов: или труп, или сделан неправильно. Я Олег Федоткин, Head of PaaS СберМаркета. Хочу рассказать, почему это так и как заставить техрадар работать.

Это текстовая версия моего выступления на Podlodka TechLead Crew. Если вам больше нравится смотреть видео, то оно здесь.

Зачем нужен техрадар

Представим условного Васю. Он CTO, технический директор, и у него проблемы.

Одна из команд внедрила MongoDB. Выяснилось, что поддерживать эту базу данных никто не умеет. Теперь база есть, но непонятно, что делать, если она упадёт.

Другая команда сделала сервис на MySQL. В последние полгода MySQL в продукте выпиливался, но парни были не в курсе. И запилили MySQL снова. И при обновлении MySQL уронили прод.

Третья команда притащила Solr. А в продукте уже был Elasticsearch. Команда об этом не знала, поэтому теперь у них есть и то, и другое.

И как вишенка на торте — эйчары жаловались: перечисление технологического стека компании занимает лист А4. Кандидаты читают стек и убегают в ужасе. Столько живой человек знать не может.

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

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

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

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

Несмотря на это, проблему с техрадаром помог решить один из принципов системы Toyota Production System.

Toyota Production System (TPS) — это система идей. Её разработал Тайити Оно для производства автомобилей Toyota. Она показала свою эффективность не только в Японии: когда систему применили в компании Porsche, процент брака снизился вполовину, а скорость производства выросла на 76%.

TPS дала классный результат, и её начали адаптировать под другие сферы. Так появился Scrum Guide, который победил в ИТ.

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

Если принять технологии за инструменты, то техрадар — это набор полок, где эти инструменты лежат. На полках надо навести порядок и закрепить, что где лежит. Иными словами, правильно организовать инструменты. В методологии TPS есть пять этапов организации инструментов, они называются 5S.

Техрадар оказался прекрасным наложением идеи 5S на айтишку. Давайте пройдем все этапы 5S и посмотрим, в чём его польза.

Для кого строят техрадар

Техрадар строят для разработчиков. Не для владельца компании, архитекторов, менеджмента или СТО. Для разработчиков. Иначе получится техрадар, которым никто не пользуется. И время на построение будет потрачено впустую.

Разработчики используют техрадар, чтобы:

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

• прокачать скиллы. Джунам и мидлам надо качаться. Для этого нужно понимать, что осваивать. Если вы говорите: «Вот тебе Google, вот клавиатура, давай, чок-чок, организуйся», это плохо. Лучше дать техрадар и сказать: «Вот то, что мы используем, тебе надо осваивать это. Именно в такой последовательности: это более важно, это менее». Разработчик будет качаться в нужном направлении и лучше работать. А ещё его лояльность будет выше, ведь вы заботитесь о его развитии. Важно показать сотрудникам, что они не ресурс или материал. Они люди, которых мы развиваем и с которыми вместе растём;

• планировать проекты. Плохо, когда рекламу новой фичи уже приготовили, блогеров зарядили, а технология для фичи ещё в компании не появилась. Техрадар помогает избежать рассинхрона и ориентироваться в сроках появления технологий;

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

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

Как сделать техрадар

Шаг первый — собрать технологии

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

Шаг второй — разбить технологии по категориям

В техрадаре СберМаркета есть два вида категоризации: по области применения и по степени внедрения.

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

Степень внедрения — это насколько технология близка продукту, насколько её можно применять. Всего их выделяют четыре:

• Adopt — когда мы уверены в технологии, умеем с ней обращаться и смело используем в проде. Это то, что точно взлетит;

• Trial — эффективные технологии. По таким есть MVP, часть из которых уже в проде. На них нет большой нагрузки, и это не проекты business critical. Но они есть, работают, и, в принципе, эту технологию уже можно назвать нашей;

• Assess — эта технология нам интересна. Мы её тыкаем, возможно, пробуем в пет-проектах. Но в прод не выводим ни в коем случае;

• Hold — то, что использовали раньше, но уже перестали. Это legacy. Возможно, это старый язык, мы его поддерживаем, но на нём не пишем. Не надо использовать это в продукте ни под каким соусом.

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

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

Шаг третий — поддерживать радар актуальным

Показатель качества — не результат в виде картинки. Тайити Оно утверждал: если вы собираетесь вводить TPS, вы должны внедрять её каждый день. Не потому, что она сложная, а потому, что требует регулярности. 5S как часть TPS тоже требует регулярности.

Если же остановиться и не следить за обновлением техрадара, получим проблемы:

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

• legacy для сопровождения. Решили уходить от MySQL, но на техрадаре это не отметили. И разработчики пилят на MySQL, в эксплуатацию попадает то, от чего хотели избавиться;

• неактуальные знания у сотрудников. Сотрудники используют и даже учатся тому, что уже неинтересно компании. Опять же, потому что в техрадаре так написано;

• разбитое окно. Если техлид и принципал не следят за поддержкой техрадара, то почему разработчики должны? Это не их обязанность;

• и самое главное — потеря доверия. Если ввели процесс и забили на него, это маркер: процессы в компании разваливаются. Если надумали сделать радар и забить на него, лучше вообще не делать. Иначе это больше вреда принесёт.

Поэтому радар — это процесс. Это не картинка, по которой надо щёлкать и смотреть, как символы вылетают. Техрадар определяет инструменты. И как процесс он потребует действий.

Радар надо встроить в рабочие процессы. Не надо собираться по средам на ревью радара. 90% вероятности, что уже через месяц на эти встречи забьют. На рабочие процессы забить нельзя, поэтому встраивать радар надо именно в них.

Надо назначить ответственных за техрадар. Если распределяете роли по RACI-матрице, то вы должны быть accountable, но не responsible. Вы как руководитель должны нести ответственность, а не быть фактическим исполнителем.

И техрадар, как любой продукт, придётся развивать. Без развития он станет мёртвым. Зачем компании труп радара?

Шаг четвёртый — отдать исполнителям управление стандартами

Есть принуждающая и поощряющая системы стандартов.

В принуждающей системе стандарты — ось системы, на них всё держится. Система выключает сотрудников из цепочки управления, потому что стандарты идут сверху.

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

Представим, что есть проблема.

У сотрудников есть три решения: одно нормальное, второе отличное, а третье — ни шатко ни валко. Причём мнение о решениях у каждого сотрудника своё.

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

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

В СберМаркете построена поощряющая система стандартов. Мы сделали вишлист — систему с опросами людей в Google-формах. Когда у человека проблема, он приходит в вишлист и записывает её туда. У вишлиста есть несколько правил:

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

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

• проблемы обсуждаются открыто.

Вишлист — гарантия, что продукт и процессы открыты к улучшениям. Применение вишлиста в СберМаркете показывает нам: поощряющая система стандартов работает. В результате получаем не разовое, а непрерывное улучшение продукта.

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

Шаг пятый — совершенствовать процессы

Пожалуй, самый главный принцип 5S.

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

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

• информированность. Любое улучшение попадет в команды моментально. Знаю случаи, когда люди обновили четырнадцатый Postgres и об этом никто не узнал. А как им рассказать? Рассылку сделать? Вряд ли поможет;

• управление. Инструменты должны управляться теми, кто их применяет. Вы передаёте управление в руки людей, которым это надо. Не объясняете людям, как делать их работу, а говорите: «Управлять стандартами будете вы»;

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

• эксперименты. Я всегда говорил: чтобы сделать восемь шагов вперёд, два шага надо сделать назад. Техрадар — хорошая механика для экспериментов. Прозрачно для всей компании: не понравилось — откатили технологию подальше от центра радара.

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

Совершенствование процессов — последняя стадия построения техрадара. У неё не будет завершения. Потому что техрадар — это не достигнутая цель, а непрерывно работающий процесс.

Итог

Когда идёт речь о вводе техрадара, часто думают: «Не получится». Это нормально. Невозможно построить идеальный процесс с первого раза. Идеальный процесс — это тот, в котором недостатки видны сразу и понятно, как их исправлять. Тогда процесс получится улучшить и техрадар взлетит.

---

Мы завели соцсети с новостями и анонсами Tech-команды. Если хотите узнать, что под капотом высоконагруженного e-commerce, следите за нами там, где вам удобнее всего: Telegram, VK, FB, Twitter.