tekBlueprint

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

Введение

Да, всем известные крупные компании используют методы для отслеживания трендов и технологий внутри себя, даже открывают в публичный доступ свои техрадары. Но глядя на них, возникает вопрос: действительно ли то, что опубликовано, несёт хоть какую-то пользу, а не просто интересная картинка с кружочками?

Поясню: на просторах интернета можно найти в публичном доступе техрадары, которые по большому счёту выглядят просто как список баззвордов. Непонятно, для чего эти технологии у них используются. Непонятно, когда вообще обновлялось, так как действительно старые вещи встречаются. Бывает, что сам список выглядит странно. Например, указан JSON. Вот что означает JSON: умеете парсить? Неожиданно – редкий навык. :)

Зачем и как

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

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

1. Должен содержать актуальную информацию. Если информация не обновляется:
   1. Ведёт к ошибочным предположениям о компетенциях команд или проектов, расхождение в ожиданиях между внутренними командами или внешними заказчиками/подрядчиками/вендорами решений.
   2. Нельзя использовать как источник информации для планирования внутреннего обучения сотрудников.
2. Информация на техрадаре не должна состоять только исключительно из названия. Хочется понимать следующее:
   1. Почему именно технология используется сейчас в компании. Почему она важна и является фундаментальной для бизнеса. Рекомендации по использованию.
   2. Если это новая технология, то почему решили попробовать, что может улучшить в будущем. То есть, понять, это чей-то каприз без причины или всё-таки осознанная необходимость, к которой пришли через путь проб и ошибок.
   3. Если это старая технология, от которой отказываются, то почему её всё ещё используют (если используют) и на что будет замена. Какие проблемы несёт дальнейшее использование.
3. Поддержка историчности изменений. Здесь имею в виду возможность отслеживания изменений по какой-то технологии. Например, в 2000 году мы начали использовать С++, а в 2008 отказались, переведя в Hold и переориентировавшись на Java. С комментарием и причиной изменения.
4. Требование к инструменту отображения радара для конечного пользователя. Представление техрадара должно быть наглядным и информативным. С поиском, фильтрацией и возможностью экспорта в различные форматы.

Обычно на радаре есть деление на 4 категории:

1. Adopt – технологии, которые уже используются и считаются основными для компании.
2. Trial – технологии, которые уже протестированы и готовы к использованию.
3. Assess – технологии, которые исследуются или планируются для использования в ближайшем будущем.
4. Hold – технологии, от которых отказываются или не используют.

Дополнительно может использоваться индикация для переходных состояний:

1. New – технологии, которые только что были добавлены на радар.
2. Moved in – технологии, которые двигаются от Hold к Adopt.
3. Moved out – технологии, которые двигаются от Adopt к Hold

Кому и чем может помочь

Основное назначение - это поддержание актуальности технологий и их использования внутри компании. Косвенно это может помочь в:

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

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

Что использовал

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

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

Ниже пример радара с сайта Thoughtworks:

Что у них понравилось:

1. Возможность создавать несколько радаров по различным направлениям (отдел архитектуры, отдел тестирования, проектный офис, отдел аналитики, отдел разработки, отдел DevOps и так далее)
2. Элементы радара могут содержать подробное описание для каждой технологии.
3. Есть историчность переходов между стадиями использования технологии.

Чего не хватало:

1. Техрадары импортируются из CSV или Google Docs, а хочется нормального пользовательского интерфейса для добавления и редактирования элементов. Что и приходилось делать рядом в виде отдельного веб-приложения.
2. Нет возможности комментировать технологии и обсуждать их внутри радара. Больше как идея, но может быть полезно внутри компании, не для публичного использования.
3. Опциональная, но полезная интеграция с LMS или системами ведения компетенций сотрудников. Чтобы можно было выстроить сквозную связь. Опять же приходилось делать рядом в виде отдельного сервиса.

Заключение

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

Thoughtworks как готовый инструмент удобен для использования, а вот дорабатывать его не очень удобно – не рассчитан, похоже, на это. Хочется всё-таки в будущем сделать какой-нибудь tekBlueprint.radar со всем, чего не хватало, без костылей в виде сервисов рядом.