Тендеры и лиды
Информация
Иван Головко, CEO и основатель GINC Radar, — о том, как превратить управление техдолгом из ручного ада в прозрачный и автоматизированный процесс.
Про техдолг написаны горы постов и сломаны тонны копий. За свою карьеру в IT, пройдя путь от инженера до руководителя, я снова и снова наблюдал один из двух сценариев.
Первый — «да ну его, потом разберёмся». Всё внимание уходит в фичи, техдолг игнорируется. «Потом» наступает внезапно: что-то падает, миграция из-за критичной уязвимости превращается в месяцы ручного ада, люди выгорают и бегут. Конец известен.
Второй сценарий — «будем всё контролировать по науке». Создаётся технаправление, вводятся ADR, требования к лицензиям, собираются комитеты. Работает, но какой ценой: титанические усилия, сотни человеко-часов на рутину, тонны вики-страниц. Разработчики меньше пишут код и больше координируют процессы.
Оба сценария плохи. В первом — хаос и судный день, во втором — бесконечный админотдел внутри R&D. По моим оценкам, до 30% времени R&D-команды буквально сгорает на ручные сверки, бесконечные миграции и попытки просто понять, на каком стеке мы работаем. Это прямые убытки для бизнеса, которые никто не считает.
Нужно проверить, на каких версиях живёт любимый фреймворк. Что делает разработчик?Клонирует проект, ждёт, лезет в lock-файл или руками смотрит зависимости через команду. А таких проектов десятки или сотни.
Дальше — координация. Вики, таблички, Jira. На миграцию, например, favorite-framework 1.1.x → 2.x.x заводятся десятки задач, кто-то вручную проставляет версии в табличку. Кто-то случайно затирает чужую строку, кто-то забывает обновить статус. В лучшем случае всё работает на честном слове.
ADR? Красиво, модно, молодежно, но кто из ревьюеров реально их читает и поддерживает?Лицензии? Пропустил GPL в коммерческий продукт — получишь юристов на голову. Для нормальной автоматизации нужны отдельные инструменты и штат.
Итого — везде бардак и ручной труд. Общей картины нет. У каждого своя правда: у одной команды в вики, у другой в чатике, у третьей в голове лида. Если CTO спросит «на чем мы реально стоим», ответа нет.
Я понял, что рынку нужен совершенно другой инструмент. Не очередная система контроля, а живая карта технологического здоровья компании. Система, которая сама обходит репозитории, собирает стек и зависимости, показывает живую карту технологий и сигнализирует, где беда.Не в виде красивой слайд-картинки для презентации, а в виде настоящего живого радара, к которому можно привязать проверки и правила.
Хочется нажать кнопку и получить список: вот проекты, где фреймворк отстал на 3 мажорных версии; вот лицензии, которые конфликтуют с политикой; вот прогресс миграции.Хочется, чтобы новые репозитории находились сами, а Jira-таски на миграции создавались автоматом. Хочется не тонуть в табличках, а видеть живую динамику: что растёт, что устаревает, что нужно тушить.
Мечта выглядела утопично. Но однажды я решил: стоит попробовать ее реализовать.
Идея была первым шагом. В какой-то момент стало ясно, что для решения такой задачи нужен системный подход, а не просто набор скриптов. Так что, я основал компанию GINC и собрал крутую команду. Так началась работа над GINC Radar — платформой, которая должна была навсегда изменить подход к управлению техдолгом. Путь оказался длинным и местами болезненным, но интересным.
Конечно, мы не стали сразу писать код, а изучили, что уже существует:
Итак, инструмента, который сам лезет в репозитории и строит живую стратегическую карту, не нашлось.
Мы взяли за основу простое open-source решение для техрадара — AOE Tecnology Radar, но быстро поняли, что оно не тянет. Пришлось переписать ядро Angular с выделенным API-слоем и модульной архитектурой и углубиться в тригонометрию визуализации: как делить сектора, как показывать квадранты и нестандартные структуры. Хотелось гибкости, а не жёсткой картинки.
Мы допилили поддержку сложных структур, сделали визуальный конструктор: можно загрузить структурированный JSON или сконфигурировать радар мышкой, двигая ползунки.
В реальном мире, в компании может быть несколько продуктов и команд, а значит — нужны несколько радаров. Окей, сделали поддержку множества, без ограничений с рендерингом на базе D3.js.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13202 тендера
проведено за восемь лет работы нашего сайта.
Карточка технологий в GINC Radar
Картинка без данных — витрина. Настоящая магия — под капотом.Мы научили GINC Radar сканировать репозитории: либо указываешь URL, либо он через API Bitbucket/GitLab сам находит все проекты (используем эндпоинты для списков репозиториев, веток и файлов, обрабатываем rate limits; для ускорения применяем многопоточность). Настраиваешь фоновые задачи и ждёшь. Некоторые сканирования могут быть сильно ресурсоемкими. Если не хочется ждать, всегда можно запустить сканирование вручную.
Парсить зависимости — отдельная история. В одном проекте есть lock-файл, в другом нет. Пришлось сделать два режима:
Сейчас GINC Radar поддерживает больше десяти пакетных менеджеров: Bundler, Composer, Conan, Gradle, npm, NuGet, pip, SwiftPM и др. И этот список постоянно растет.
Сырые данные: «spring-core v2.5.4». А на радаре это что? Spring? Spring Boot? Просто «Java-фреймворки»?
Сначала мы делали гибкие регулярки, настраивали их руками в админке. Больно, но иначе никак.Сейчас мы интегрируем в GINC Radar AI-ассистента на базе последних моделей GPT. Он помогает автоматически классифицировать сотни библиотек, экономя десятки часов работы архитекторов.
Мы поняли, что техрадар — не место для табличных данных (для этого сделали отдельные страницы и аналитику).
Но он идеален как сигнализатор.
А значит, нужны правила. Ключевые правила уже встроены в GINC Radar, и они дают мгновенный эффект: контроль устаревания версий и распространения нежелательных технологий. И мы постоянно расширяем библиотеку правил, от валидации лицензий до контроля прогресса миграций.
Масштабных пилотов ещё не было, совсем недавно стартанули. Но уже есть архитектура, продуманная платформа и подход находит отклик у тимлидов и архитекторов, которые сталкиваются с теми же проблемами.
Первые внедрения GINC Radar показали: одна из команд смогла за две недели спланировать и запустить миграцию критичного фреймворка, на которую раньше у них ушли бы месяцы. Прозрачность стека позволяет принимать решения, основанные на данных, а не на интуиции.
Главные инсайты:
Хватит мириться с хаосом в технологическом стеке и терять время и деньги на ручной труд. Управление техдолгом может и должно быть автоматизированным и прозрачным.
Узнайте, как GINC Radar может помочь именно вашей компании. Запишитесь на персональное демо, и мы покажем, как вернуть контроль над вашим технологическим ландшафтом.
Хочется автоматизировать рутину, чтобы оставалось время писать код. Вернуть разработчиков и архитекторов обратно в продукт. На этом и стоим.
Иван Головко, CEO GINC Radar
