В цикле развития любой быстрорастущей компании наступает момент, когда CIO, CTO, главный технический архитектор (нужное подчеркнуть) задумывается о том, что компания доросла до уровня осознанного управлении технологиями, и нужно начинать двигаться в эту сторону. Первое, что приходит в голову, — визуализировать технологии, с которыми каждый день работают сотрудники. Кажется, этого достаточно. Но решает ли это проблему управления технологиями? Давайте разбираться — и добро пожаловать под кат.
Выше я говорил о крупных и быстрорастущих компаниях, в этом месте необходимо объяснить, почему речь идет именно о них. Для таких структур характерно:
Теперь чуть детальнее, какие тут могут быть проблемы. Начнем с самого очевидного: это зоопарк технологий, которые нужно поддерживать. Это дорого для компании. Большому числу команд сложно синхронизироваться по применяемым технологиям и паттернам их использования, например, какую стриминговую платформу использовать и есть ли опыт ее использования в компании? Непонятно, как управлять legacy-технологиями и выводить их из эксплуатации. И при этом при всем надо оставаться прозрачным для кандидатов на рынке.
Давайте разбираться, что с этим делать. Хорошим тоном при постановке задачи, а у нас она звучит как «управлять технологиями в компании», является задать вопрос — чтобы что? Зададим его и в этот раз и постараемся на него ответить.
Чего мы хотим достичь, теперь понятно. Подберем подходящий инструмент.
В Leroy Merlin к формированию стека подходили 2 раза. Первый раз зимой 2018-2019 годов. Это был стандартный тех. радар, коих вы видели уже превеликое множество. Такой подход показался не сильно удобным: непонятно, в каком случае какие именно технологии применять. Тогда мы просто зафиксировали технологии, которые используем, и их уровень зрелости внутри компании, но не описали, как мы работаем с ними, какой жизненный цикл технологии внутри компании и что делать, если я хочу попробовать решить бизнес-задачу с помощью технологии вне стека. По этим причинам мы отказались использовать радар как инструмент визуализации и управления технологиями внутри компании.
Второй подход к созданию тех. стека отличался от первого. Мы попробовали решить проблемы, с которыми столкнулись в первый раз. Чтобы последовательно управлять тех. стеком, мы создали технологический комитет, который состоит из CTO, архитекторов, технических лидов команд, а также представителей инфраструктуры. В новой парадигме стали использовать таблицу технологий вместо радара.
Такой подход нам больше понравился тем, что технологии поделены по сфере применения и способу использования. Например, нам необходимо сделать несложный сервис, который просто обращается к базе данных, — мы идем в раздел Business Application Backend, понимаем, что больше всего подходит CRUD, и смотрим, какая технология рекомендована для такого паттерна. Другой пример: когда нужен BFF, смотрим рекомендованные технологии и сразу берем low-code-платформу. Для каждого кейса использования подобрана технология: язык, фреймворк, инструмент или платформа и наше отношение к ней.
Все категории, кроме Research, могут работать в продакшене.
Категория Research наша самая любимая, и вот почему. Мы выработали правило: новые и интересные для нас технологии мы заносим в отдельную таблицу трендов с коротким обоснованием, чем данная технология может быть полезна. Каждая команда может взять в исследование одну из технологий. По результатам заполняем canvas эксперимента, который сделал Александр Регнер наш Engineering Manager. Далее команда приходит на ближайшее собрание технологического комитета и рассказывает о том, чем закончилось исследование, и уже по результатам принимаем решение о перемещении технологии в Trial или Hold.
Искушенный читатель, наверное, возразит, что мы усложняем работу с инновациями. Отвечу, что попробовать новое все так же легко, просто эту попытку необходимо описать, чтобы было меньше хаоса. А внутренним сообществам такое описание помогает понять, чем закончился эксперимент.
Пару слов про внутренние сообщества, раз уже помянули. В Leroy Merlin мы развиваем внутренние профильные сообщества, такие как Java, QA, Node и другие. Мы считаем важным, что у сотрудников есть площадка для обсуждения особенностей применения технологий в их командах и что они могут выдвигать предложения по дальнейшему развитию технологий в компании. Представители таких комьюнити включены в технологический комитет. Подробнее о правилах технологического комитета можно почитать на нашем тех. портале.
Буквально неделю назад у меня состоялся разговор с коллегой из Франции, перед которым стоит задача собрать технологический стек для всех компаний, входящих в группу ADEO (Leroy Merlin одна из компаний группы). Он спрашивал, как нам удалось договориться, ведь составить стек технологий, да еще и такой детальный, задача не из простых. Ну что тут ответить: мы неделю договаривались. Каждый день по часу ломали копья, громко хлопали кнопкой выхода из zoom-конференции, но тем не менее договориться получилось. Главное, для себя ответили на вопрос, почему именно эта технология находится в этой жизненной стадии.
Пару дней назад сделали осеннее ревью стека без лишних эмоций, четко и по делу, за полтора часа.
Что мы в итоге получили от внедрения такого подхода управления технологиями:
А как в вашей компании устроено управление технологическим стеком?
Что не так с большими компаниями?
Выше я говорил о крупных и быстрорастущих компаниях, в этом месте необходимо объяснить, почему речь идет именно о них. Для таких структур характерно:
- наличие большого числа технологий на различных стадиях использования;
- большое число команд;
- много legacy, от которого хочется избавиться.
Теперь чуть детальнее, какие тут могут быть проблемы. Начнем с самого очевидного: это зоопарк технологий, которые нужно поддерживать. Это дорого для компании. Большому числу команд сложно синхронизироваться по применяемым технологиям и паттернам их использования, например, какую стриминговую платформу использовать и есть ли опыт ее использования в компании? Непонятно, как управлять legacy-технологиями и выводить их из эксплуатации. И при этом при всем надо оставаться прозрачным для кандидатов на рынке.
Давайте разбираться, что с этим делать. Хорошим тоном при постановке задачи, а у нас она звучит как «управлять технологиями в компании», является задать вопрос — чтобы что? Зададим его и в этот раз и постараемся на него ответить.
- Обеспечить прозрачность стека для соискателей.
Разместим стек на портале, попросим рекрутеров отправлять кандидатам ссылки. Соискатели видят, с чем мы работаем каждый день, какой стек используем.
Прозрачность технологического стека для кандидатов помогает правильно решить, действительно ли я буду применять свои навыки на новом месте и смогу ли научиться новому. Визуализация помогает понять, насколько используемые технологии актуальны. Немногие разработчики согласятся писать фронт на JSP или интегрировать микросервисы через ESB.
А еще сделаем крутой баннер с технологиями, будем таскать его по конференциям. Поставим на стенде — пусть все видят, с чем мы работаем.
- Сделать прозрачным стек внутри всей компании.
Компания как сложный часовой механизм. Все должно работать слаженно. Знакомьтесь, это Константин, новый технический архитектор в компании. Руководство ставит задачу выбрать подходящие технологии для реализации нового продукта. После нескольких встреч с руководством и enterprise-архитекторами Костя понимает, что на такой продукт ресурса внутренних разработчиков, возможно, не хватит и часть задач придется переложить на подрядчика. А какие технологии выбрать? С чем в компании принято работать и что наши инженеры смогут потом поддерживать и развивать? Костя обращается к тех. стеку компании, принимает решение о выборе технологий и на основании этого, при необходимости, помогает владельцу продукта найти нужного партнера на рынке.
Такой подход:
- уменьшает время принятия решения сотруднику компании, ответственному за выбор технологий под конкретную задачу;
- снижает издержки на поддержку зоопарка технологий;
- дает возможность поиска внутренних ресурсов;
- делает возможным переиспользование кода внутри компании. Подробнее про Innersource можно почитать в одной из наших статей.
- Управлять технологическим развитием компании.
И, наконец, последний по порядку, но не по значению пункт. При грамотном управлении стеком сложные стратегические решения, такие как построение стратегии развития технологий, внедрение ПО, выработка стратегии подбора персонала или выбора инхаус\аутстаф\аутсорс, принимаются на основании данных. Решить, как развивать компанию в технологическом направлении, можно только зная, что происходит внутри компании в части технологий. Добавляем к этому знания о трендовых технологиях, описываем их жизненный цикл, критерии попадания в тех. стек, и вот мы приблизились к управлению технологиями в компании. И, конечно, не стоит забывать, что это один из инструментов управления тех. долгом. Legacy-система на технологиях не из стека или новая система, сделанная в обход стека, автоматически записывают себе тех. долг на переделку. Обычно в крупных компаниях этот процесс управления технологическим развитием централизован и управляется CTO.
Чего мы хотим достичь, теперь понятно. Подберем подходящий инструмент.
Какой подход выбрала Leroy Merlin
В Leroy Merlin к формированию стека подходили 2 раза. Первый раз зимой 2018-2019 годов. Это был стандартный тех. радар, коих вы видели уже превеликое множество. Такой подход показался не сильно удобным: непонятно, в каком случае какие именно технологии применять. Тогда мы просто зафиксировали технологии, которые используем, и их уровень зрелости внутри компании, но не описали, как мы работаем с ними, какой жизненный цикл технологии внутри компании и что делать, если я хочу попробовать решить бизнес-задачу с помощью технологии вне стека. По этим причинам мы отказались использовать радар как инструмент визуализации и управления технологиями внутри компании.
Второй подход к созданию тех. стека отличался от первого. Мы попробовали решить проблемы, с которыми столкнулись в первый раз. Чтобы последовательно управлять тех. стеком, мы создали технологический комитет, который состоит из CTO, архитекторов, технических лидов команд, а также представителей инфраструктуры. В новой парадигме стали использовать таблицу технологий вместо радара.
Такой подход нам больше понравился тем, что технологии поделены по сфере применения и способу использования. Например, нам необходимо сделать несложный сервис, который просто обращается к базе данных, — мы идем в раздел Business Application Backend, понимаем, что больше всего подходит CRUD, и смотрим, какая технология рекомендована для такого паттерна. Другой пример: когда нужен BFF, смотрим рекомендованные технологии и сразу берем low-code-платформу. Для каждого кейса использования подобрана технология: язык, фреймворк, инструмент или платформа и наше отношение к ней.
- Research — пробуем играть, пока непонятно.
- Trial — обкатывается в лимитированной версии на проде.
- Best Choice — круто, надо брать. Рекомендовано к использованию в новом проекте или продукте.
- Hold — пробовали, наигрались, хватит. Также в Hold попадаем, если происходит устаревание технологии, технология не поддерживается вендором или получен негативный опыт эксплуатации в стадиях Тrial и Research. Обычно тут находится наше Legacy, которое мы планомерно переписываем. В новых продуктах такие технологии рекомендуем не использовать.
Все категории, кроме Research, могут работать в продакшене.
Немного про управление экспериментом
Категория Research наша самая любимая, и вот почему. Мы выработали правило: новые и интересные для нас технологии мы заносим в отдельную таблицу трендов с коротким обоснованием, чем данная технология может быть полезна. Каждая команда может взять в исследование одну из технологий. По результатам заполняем canvas эксперимента, который сделал Александр Регнер наш Engineering Manager. Далее команда приходит на ближайшее собрание технологического комитета и рассказывает о том, чем закончилось исследование, и уже по результатам принимаем решение о перемещении технологии в Trial или Hold.
Искушенный читатель, наверное, возразит, что мы усложняем работу с инновациями. Отвечу, что попробовать новое все так же легко, просто эту попытку необходимо описать, чтобы было меньше хаоса. А внутренним сообществам такое описание помогает понять, чем закончился эксперимент.
Пару слов про внутренние сообщества, раз уже помянули. В Leroy Merlin мы развиваем внутренние профильные сообщества, такие как Java, QA, Node и другие. Мы считаем важным, что у сотрудников есть площадка для обсуждения особенностей применения технологий в их командах и что они могут выдвигать предложения по дальнейшему развитию технологий в компании. Представители таких комьюнити включены в технологический комитет. Подробнее о правилах технологического комитета можно почитать на нашем тех. портале.
Подводим итог
Буквально неделю назад у меня состоялся разговор с коллегой из Франции, перед которым стоит задача собрать технологический стек для всех компаний, входящих в группу ADEO (Leroy Merlin одна из компаний группы). Он спрашивал, как нам удалось договориться, ведь составить стек технологий, да еще и такой детальный, задача не из простых. Ну что тут ответить: мы неделю договаривались. Каждый день по часу ломали копья, громко хлопали кнопкой выхода из zoom-конференции, но тем не менее договориться получилось. Главное, для себя ответили на вопрос, почему именно эта технология находится в этой жизненной стадии.
Пару дней назад сделали осеннее ревью стека без лишних эмоций, четко и по делу, за полтора часа.
Что мы в итоге получили от внедрения такого подхода управления технологиями:
- инструмент визуализации;
- помощник в принятии решения;
- описанные правила работы с технологиями и их жизненный цикл в компании;
- инструмент HR-брендинга: кандидаты всегда могут посмотреть, с чем им предстоит работать. Баннер пока не сделали, с нетерпением ждем офлайновых конференций и вас на нашем стенде.
А как в вашей компании устроено управление технологическим стеком?
