Технический архитектор (ТА) — востребованная специальность в большинстве ИТ-компаний. Однако на сегодняшний день не существует точного определения этой роли. Как следствие, специалисты, которые хотят вырасти до ТА, зачастую не понимают, с чего начинать и какие навыки прокачивать. Причём это касается не только джунов, но и сеньоров. В КРОК мы выстроили последовательный карьерный трек для разработчиков, которые хотят стать техническими архитекторами, развиваться в сильной команде и решать интересные задачи. Делюсь нашим опытом.
Меня зовут Вера Кокотова, я руководитель группы технических архитекторов 1С в компании КРОК. Устроилась в компанию 11 лет назад начинающим разработчиком и прошла большой увлекательный путь до эксперта по технологическим вопросам. Кроме того, последние пять лет я активно участвую в найме технических специалистов.
В этой статье расскажу, чем у нас занимаются технические архитекторы и как от новичка подняться до специалиста, который играет ведущую роль в крупных проектах по автоматизации. Также я поделюсь советами по построению успешного карьерного трека для ТА. У себя в КРОК мы создали и развиваем систему подготовки технических архитекторов внутри компании в соответствии с нашим видением этой роли.
Кто такой технический архитектор в КРОК
Вопрос немного сложнее, чем может показаться изначально. Разные компании, так или иначе связанные с 1С (интеграторы, ИТ-компании, мелкий, средний и крупный бизнес) предъявляют разные требования к ТА и ставят разные задачи.
В компаниях с небольшими ИТ-системами, число пользователей которых невелико, один специалист может совмещать роли аналитика, разработчика и архитектора. Масштаб же проектов в КРОК требует четкого разделения труда. В нашей методологии выделены четкие роли: технический менеджер (ТМ), функциональный архитектор (ФА), технический архитектор (ТА), консультант, разработчик и инженер. Именно поэтому нам было очень важно определить для себя, кто такой ТА, что входит в зону его ответственности и какие требования предъявлять к специалистам.
Важная особенность роли ТА в КРОК — специализация только на технических вопросах. Технический архитектор анализирует требования на непротиворечивость, обеспечивает единую реализацию похожих механизмов, задает общие правила проектирования и разработки. Для выполнения этих задач требуется практический опыт работы с конфигурациями, но глубокое погружение в методологию не обязательно. Все же ТА смотрит на доработки прежде всего со стороны архитектуры метаданных, программной реализации, дальнейшей поддержки, расширяемости и обновляемости решения.
Кроме того, в нашем понимании технический архитектор — это профессионал не только с глубокими техническими знаниями и обширным практическим опытом, но и с развитыми софт-скилами. Соответственно, при подборе ТА мы внимательно смотрим и на личные качества. Если у вас в команде есть коллега со слабыми хардами, это поправимо, но если у вас сотрудник со слабыми софтами, это проблема, а возможно, и не одна.
Технический архитектор обязательно должен уметь и хотеть брать ответственность за общий результат команды, а не только за свой личный. Также важны хорошие коммуникативные навыки, умение договариваться, делегировать задачи, работать в условиях неопределенности и сжатых сроков.
А ещё никуда без самостоятельности. Под самостоятельностью имею в виду способность работать автономно. На общий прогресс сильно влияет умение быстро изучать новое, своевременно задавая правильные вопросы «не закапываясь».
Какие задачи решает ТА
Мы подразделяем задачи технического архитектора на три ключевых направления:
построение архитектуры решения;
организация процесса и управление разработкой;
эксплуатация системы.
Построение архитектуры
Это направление во многом обусловлено спецификой наших проектов — крупных внедрений с масштабной кастомизацией типовых решений. Архитектурные функции ТА связаны не только с доработками в самой системе, но и с проектированием архитектуры кластера приложений и СУБД, принятием решения по количеству площадок и использованию РИБ, в том числе с анализом рисков по производительности.
Список задач этого блока:
-
Разработка технических разделов проектной документации, в частности технического задания:
технические требования к оборудованию для продуктивной системы, сайзинг;
проработка требований отказоустойчивости/высокой доступности;
выбор ПО, в том числе СУБД, понимание особенностей импортозамещения;
формирование требований к тестовым стендам и стенду разработки;
проработка интеграционной архитектуры;
проработка архитектуры лицензирования;
проработка требований к быстродействию.
Валидация требований на непротиворечивость и техническую реализуемость на этапе моделирования.
Выбор технологий и инструментов для реализации требований.
Помощь в выборе варианта реализации требований, согласование проектных решений.
Унификация создаваемых решений на уровне всей системы, задание единых правил проектирования.
Контроль технологического качества проектных решений на этапе проектирования.
Оценка доработок.
Организация процесса и управление разработкой
Наиболее простая в освоении часть. Она включает в себя:
Подготовку и контроль исполнения регламента разработки.
Подготовку стенда разработки (совместно с инженером).
Оперативное распределение задач между исполнителями в соответствии со сроками, приоритетностью и зависимостями.
Контроль сроков и трудозатрат.
Контроль качества кода: code-review, автотесты.
Управление изменениями, подготовку релизов.
Управление загрузкой команды разработки: выравнивание загрузки; своевременная коммуникация с техническим менеджером о необходимости изменения размера команды или о замене разработчика.
Эксплуатация системы
Третий блок работ связан с эксплуатацией стендов и внедренной системы:
Обеспечение производительности и стабильности работы системы, в том числе решений, возникших в ходе эксплуатации проблем.
Настройка кластера 1С, СУБД для получения максимальной производительности.
Организация мониторинга продуктивных и тестовых стендов (с участием инженера).
Проведение нагрузочного тестирования.
Зачем растить своих ТА
Требования к ТА в КРОК обширны и включают много знаний, специфичных только для крупных внедрений. Учитывая, что у нас нет отдельной группы эксплуатации, ТА в значительной степени владеет и навыками эксперта по техническим вопросам (ЭВТ).
Если объем работ очень большой или у ТА не хватает компетенций в этой области, можем подключить эксперта по техническим вопросам. Мы не требуем обязательной сертификации на ЭТВ для ТА, но обеспечиваем прохождение соответствующих курсов и включаем в персональные цели сотрудника освоение конкретных инструментов, технологий и навыков. Готовых специалистов под такой профиль задач в принципе мало на рынке.
В 2022 мы столкнулись с серьезным вызовом — число проектов стремительно увеличивалось, а профессионалов нужной нам квалификации на рынке всегда было недостаточно, и ситуация только ухудшалась. Это привело нас к очевидному решению — надо растить технических архитекторов самостоятельно.
Подход к развитию технических архитекторов
Когда я пришла в КРОК (более 10 лет назад), четкого трека от младшего разработчика до ТА не существовало. Разрабатывая его с нуля, мы опирались в первую очередь на реальный опыт — мой и моих коллег.
Пришли к выводу, что самый действенный подход к обучению — гибкий, с опорой на реальные проекты компании, при поддержке более опытных коллег. Это куда более эффективно, чем решать выдуманные теоретические задачи, и позволяет получить максимум пользы и для компании, и для сотрудника.
Дополнительный плюс: можно менять план обучения в соответствии с реалиями рынка.
Например, в прошлом году проводилось много предпроектных обследований, во время которых разрабатывалось техническое задание. В позапрошлом году ситуация отличалась: преобладали проекты на стадии разработки и опытной эксплуатации. Нужны были архитекторы с навыками управления разработкой, чтобы выстроить процесс приема новых требований и отработку ошибок.
В целом за последние два года значительно увеличилось количество небольших проектов миграции на импортозамещенный стек технологий. Соответственно, в планы обучения были встроены задачи по развитию необходимых навыков.
Кто может стать ТА
В основном к росту в ТА приходят либо старшие, либо ведущие разработчики. Карьерные треки будут немного отличаться.
Если говорить о развитии от уровня старшего разработчика, я предпочитаю вариант с подключением сотрудника в проект с уже состоявшимся ТА. Таким образом, старший разработчик выступает помощником более опытного коллеги: выполняет code-review, согласование проектных решений по доработкам. Со временем ему поручается контроль за небольшой группой разработчиков в проекте, задачи по администрированию сервера, выпуск релизов, проработка новых требований, встреча с заказчиком.
Эту роль мы называем ТА-1 или младший ТА. На большом проекте их может быть несколько. Таким образом нагрузка на архитектора в части оперативных задач уменьшается, а помощники планомерно развиваются, получая оперативную обратную связь.
Если же мы имеем дело с более опытным специалистом (ведущий разработчик), у которого часть компетенций уже развита на хорошем уровне, то предпочитаем более автономный вариант. Подключаем нового ТА на проект в целевой роли, но обязательно при участии бадди — опытного наставника, который проконтролирует реализацию ключевых точек и поможет там, где это необходимо.
Сложности и их преодоление
На пути разработчика, развивающегося по пути ТА, встречается множество сложностей. На рынке нет единого определения этой роли, а значит, отсутствует и единая, всеми признанная система обучения. Противоречащим требованиям разных компаний соответствовать невозможно. Материалы и курсы разрозненные, из них сложно составить понимание необходимых хардов.
Функции каждой роли на проекте (младший/мидл/ведущий разработчик, архитектор, эксперт) и наше видение качеств, необходимых специалистам, упакованы в карту грейдов и в расширенную матрицу компетенций.
Для каждого уровня мы формулируем ключевые требования по трем направлениям: профессиональные навыки, личностные качества и проектный опыт.
Карта грейдов дает ориентир для развития на верхнем уровне и не преследует цель жестко ограничивать переход на следующий грейд. Расширенная матрица компетенций помогает детализировать требования к развитию.
Каждые шесть месяцев по всей компании проводятся индивидуальные встречи с сотрудниками для обсуждения их профессионального роста. На встречах анализируем выполненные проекты, достижения и сложности, изучаем отзывы коллег и определяем цели на следующий период.
Карта грейдов КРОК и расширенная матрица компетенций как ориентир роста
Скрытый текст
В тоже время, учитывая, что сфера знаний ТА широка и объемна, и далеко не все вопросы можно сходу изучить к важной встрече или к началу этапа проекта, в индивидуальный план включаются как внешние курсы, так и изучение внутренних материалов.
Как мы развиваем ТА: дополнительные материалы
Скрытый текст
Внешние курсы и материалы
Разделы ИТС: Технологические вопросы крупных внедрений, Методическая поддержка администраторов, документация по платформе «Клиент-серверный вариант. Руководство администратора» (особенно «Глава 2. Клиент-серверный вариант работы», «Глава 10. Защита от несанкционированного использования: особенности и настройка»), Стандарты и методики разработки.
Курсы, материалы и разделы ИТС по технологиям экосистемы 1С: «1С:Шина», «1С:Аналитика», «1С:Элемент», etc.
«Зазеркалье 1С» (https://wonderland.v8.1c.ru/).
Партнерский форум (с отбором по разделам, например, «Платформа», ТКВ, тег #Новое для новых релизов ERP).
Курсы и материалы по функциональным возможностям типовых конфигураций.
Курсы для подготовки к Эксперту, Эксплуататору: «Основы ремесла 1С: Эксперта», «Подготовка к 1С: Эксперту» (основной курс, применение методик), «Эксплуатация крупных информационных систем».
Материалы с сайтов http://www.gilev.ru/ и курсы-1с-рф.
Курсы и материалы по СУБД.
Курсы и материалы по linux, bash, работе с регулярными выражениями.
Курсы и материалы, связанные с обзором инструментов devops и применением их в экосистеме 1С.
Курсы и материалы по проектированию корпоративных систем. Крайне не распространены в экосистеме 1С, но существуют в природе.
Для чего: разобраться, какие существуют стандарты моделирования, типы архитектур, паттерны проектирования.Профильные конференции: партнерская конференция, инфостарт и прочие, не связанные с 1С (TeamLead Conf, Agiledays, etc).
Курсы и тренинги по развитию soft-скилов: навыки проведения презентаций, встреч и проч.
Внутренние материалы размещены в базе знаний технической группы и на корпоративной образовательной платформе, доступной всем сотрудникам компании. Они структурированы по модулям и собраны в единый каталог. Такая организация позволяет эффективно отслеживать прогресс каждого сотрудника и оценивать уровень освоения необходимых для работы компетенций.
Внутренние курсы
Технические требования к системе: сайзинг.
Технические требования к системе: архитектура.
Старт нового проекта и проектные роли.
Лучшие практики создания ТЗ.
Проекты миграции и импортозамещения.
Методология управления разработкой и практика использования jira.
Построение DR-архитектур и нюансы лицензирования 1С.
Какие параметры учитываем при расчете сайзинга и на что они влияют:
конфигурация;
количество активных пользователей;
RTO/RPO;
стек технологий;
высокая доступность/DR;
размещение в облаке/поставка железа/текущие ресурсы;
влияние географического фактора: удаленность отдельных групп пользователей, наличие/отсутствие стабильных быстрых каналов связи;
подходы к расчету размера БД;
прочие нюансы (СХД или NVMe, частота процессоров и прочее).
В блоке про управление разработкой систематизированы базовые подходы к организации процесса, собрана вся документация и инструменты, которые приняты к использованию в компании: от системы управления задачами Jira до специализированных разработок на платформе 1С. Подробно описали интеграцию Jira в корпоративную экосистему и ее связь с принятой в компании проектной методологией.
Кроме того, периодически обмениваемся проектным опытом между ТА и фиксируем интересные кейсы во внутренней базе знаний.
Но прокачиванием хардов сложности не ограничиваются. Во-первых, даже если теория освоена, не всегда удается сразу применить новые знания на практике. В этом плане развитие внутри крупной компании предпочтительнее, чем самостоятельное освоение курсов. В КРОК мы не просто учим ТА, а погружаем их в реальные проекты. Вопрос «как мне использовать полученные знания» не стоит вовсе — учеба привязана к практике очень прочно.
Во-вторых, и это не менее важно, ТА должны прокачивать софты. Нужно перестроить мышление, научиться смотреть на задачи по-новому.
Часто харды пересекаются с софтами, например, оценка задач — это хард, но если речь идет о взаимодействии с командой, согласовании оценок или управлении ожиданиями, то тут уже требуются софт-скилы.
Что нужно, чтобы стать ТА
Я собрала топ наиболее полезных рекомендаций из моего опыта управления и развития от разработчика до технического архитектора.
Прежде всего, отпустить карьеру разработчика: количество задач, связанных с программированием, уменьшается, а количество коммуникаций растет. Наверняка в какой-то момент ты загрустишь по спокойным дням сфокусированной работы на одной задаче. Новые проекты и условия поначалу будут вгонять в стресс. Этот этап нужно пережить. Не все его проходят, и это тоже нормально — возможно, вам и не нужно становиться ТА :).
Смотреть на проект в целом и брать ответственность за результаты команды разработки в контексте всего проекта. Научиться контролировать сроки и качество, не скатываясь в микроменеджмент. Действует принцип «доверяй, но проверяй». А еще нужно видеть слабые и сильные стороны участников команды.
Быть проактивным, а это тоже навык. ТА — тот человек, который принимает решения. Не надо ждать, пока менеджер проекта подумает, как тебе и твоей команде было бы удобнее работать.
Оценивать трудоемкость и сроки по задачам исходя не из своего уровня, а из уровня команды. Закладывать риски и человеческий фактор. При оценке своих задач учитывать время на согласование (несколько итераций) и коммуникации.
Искать баланс между сроками и качеством, идеальным результатом, красивым решением и реальными потребностями бизнеса. Если необходимо, принять риски недостаточно глубокого проектирования и подсветить их команде управления проекта. Запланировать и вернуться к устранению техдолга в будущем, если необходимо.
Выстраивать эффективную коммуникацию с коллегами и заказчиком проекта и в целом управлять временем и энергией: выполнять множество разноплановых задач и не выгорать, успевать важное и откидывать неприоритетное.
Оценивать и закладывать риски, принимать решения в условиях неопределенности. Важно уметь обозначать ограничения предложенного решения и ключевые моменты, а также задавать вопросы, помогающие конкретизировать задачу и выявлять реальные боли. Сюда же относится умение давать индикативную оценку.
Ретроспективно оценивать качество принятых решений. Особенно это касается навыка проектирования: без реализации прочеленджить предложенное решение.
Не замыкаться только в мире 1С, помнить, что за его пределами есть множество интересных технологий. Это расширяет кругозор и улучшает качество решений.
Не судить себя слишком строго, избегать синдрома самозванца и нездорового перфекционизма.
ТА нужны всем!
В условиях быстро меняющегося мира ИТ актуальность специальности технический архитектор неуклонно растет: качественные архитектурные решения становятся ключевыми для успешной реализации проектов и достижения бизнес-целей.
Руководителям и тимлидам стоит задуматься о поддержке и развитии талантливых специалистов, ведь именно от их знаний и опыта зависит создание надежных и эффективных систем. Инвестируя в обучение и рост технических архитекторов, можно значительно повысить конкурентоспособность компании и усилить её позиции на рынке, тем самым также вкладываясь в развитие отрасли в целом.
А разработчикам, которые выбирают этот сложный, но захватывающий карьерный трек, стоит помнить о множестве открывающихся возможностей и перспективах. ТА может в значительной степени влиять на реализацию ИТ-проектов и в конечном счете на бизнес. Быть архитектором — значит одновременно и решать архитектурные задачи, и формировать будущее технологической экосистемы, и вдохновлять команды. Стать ТА непросто, но это очень интересный путь развития, который стоит того, чтобы его пройти.