Меня зовут Вера Кокотова, я руководитель группы технических архитекторов 1С в компании КРОК. Устроилась в компанию 11 лет назад начинающим разработчиком и рошла большой увлекательный путь до эксперта по технологическим вопросам. Кроме того, последние пять лет я активно участвую в найме технических специалистов. 

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

Кто такой технический архитектор в КРОК

Вопрос немного сложнее, чем может показаться изначально. Разные компании, так или иначе связанные с 1С (интеграторы, ИТ-компании, мелкий, средний и крупный бизнес) предъявляют разные требования к ТА и ставят разные задачи.

В компаниях с небольшими ИТ-системами, число пользователей которых невелико, один специалист может совмещать роли аналитика, разработчика и архитектора. Масштаб же проектов в КРОК требует четкого разделения труда. В нашей методологии выделены четкие роли: технический менеджер (ТМ), функциональный архитектор (ФА), технический архитектор (ТА), консультант, разработчик и инженер. Именно поэтому нам было очень важно определить для себя, кто такой ТА, что входит в зону его ответственности и какие требования предъявляются к специалистам.

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

Кроме того, в нашем понимании технический архитектор — это профессионал не только с глубокими техническими знаниями и обширным практическим опытом, но и с развитыми софт-скилами. Соответственно, при подборе ТА мы внимательно смотрим и на личные качества. Если у вас в команде есть коллега со слабыми хардами, это поправимо, но если у вас сотрудник со слабыми софтами, это проблема, а возможно, и не одна.

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

А ещё никуда без самостоятельности. Под самостоятельностью имею в виду способность работать автономно. На общий прогресс сильно влияет умение быстро изучать новое, своевременно задавая правильные вопросы и «не закапываясь».

Какие задачи решает ТА 

Мы подразделяем задачи технического архитектора на три ключевых направления:

— построение архитектуры решения; 

— организация процесса и управление разработкой;

— эксплуатация системы.

Построение архитектуры

Это направление во многом обусловлено спецификой наших проектов — крупных внедрений с масштабной кастомизацией типовых решений. Архитектурные функции ТА связаны не только с доработками в самой системе, но и с проектированием архитектуры кластера приложений и СУБД, принятием решения по количеству площадок и использованию РИБ, в том числе с анализом рисков по производительности.

Список задач этого блока:

1. Разработка технических разделов проектной документации, в частности технического задания:

• технические требования к оборудованию для прод системы, сайзинг; 
• проработка требований отказоустойчивости/высокой доступности; 
• выбор ПО, в том числе СУБД, понимание особенностей импортозамещения;
• формирование требований к тестовым стендам и стенду разработки;
• проработка интеграционной архитектуры;
• проработка архитектуры лицензирования;
• проработка требований к быстродействию.

2. Валидация требований на непротиворечивость и техническую реализуемость на этапе моделирования.
3. Выбор технологий и инструментов для реализации требований.
4. Помощь в выборе варианта реализации требований, согласование проектных решений.
5. Унификация создаваемых решений на уровне всей системы, задание единых правил проектирования.
6. Контроль технологического качества проектных решений на этапе проектирования.
7. Оценка доработок.

Организация процесса и управление разработкой

Наиболее простая в освоении часть, она включает в себя: 

1. подготовку и контроль исполнения регламента разработки;
2. подготовку стенда разработки (совместно с инженером);
3. оперативное распределение задач между исполнителями в соответствии со сроками, приоритетностью и зависимостями; 
4. контроль сроков и трудозатрат;
5. контроль качества кода: code-review, автотесты;
6. управление изменениями, подготовку релизов;
7. управление загрузкой команды разработки: выравнивание загрузки; своевременно коммуникация с техническим менеджером о необходимости изменения размера команды или о замене разработчика.

Эксплуатация системы

Третий блок работ связан с эксплуатацией стендов и внедренной системы:

1. обеспечение производительности и стабильности работы системы, в том числе решение возникших в ходе эксплуатации проблем;
2. настройка кластера 1С, СУБД для получения максимальной производительности;
3. организация мониторинга прод и тестовых стендов (с участием инженера);
4. проведение нагрузочного тестирования. 

Зачем растить своих ТА

Требования к ТА в КРОК обширны и включают много знаний, специфичных только для крупных внедрений. Учитывая, что у нас нет отдельной группы эксплуатации, ТА в значительной степени владеет и навыками эксперта по техническим вопросам (ЭВТ). 

Если объем работ очень большой или у ТА не хватает компетенций в этой области, можем подключить эксперта по техническим вопросам. Мы не требуем обязательной сертификации на ЭТВ для ТА, но обеспечиваем прохождение соответствующих курсов и включаем в персональные цели сотрудника освоение конкретных инструментов, технологий и навыков. Готовых специалистов под такой профиль задач в принципе мало.

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

Подход к развитию технических архитекторов

Когда я пришла в КРОК более 10 лет назад, четкого трека от младшего разработчика до ТА не существовало. Разрабатывая его с нуля, мы опирались, в первую очередь, на реальный опыт — мой и моих коллег. 

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

Дополнительный плюс: можно менять план обучения в соответствие с реалиями рынка. 

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

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

Кто может стать ТА

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

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

Эту роль мы называем ТА-1 или младший ТА. На большом проекте их может быть несколько. Таким образом, нагрузка на архитектора в части оперативных задач уменьшается, а а помощники планомерно развиваются, получая оперативную обратную связь.

Если же мы имеем дело с более опытным специалистом (ведущий разработчик), у которого часть компетенций уже развита на хорошем уровне, то предпочитаем более автономный вариант. Подключаем нового ТА на проект в целевой роли, но обязательно при участии бадди — опытного наставника, который проконтролирует реализацию ключевых точек и поможет там, где это необходимо. 
 

Сложности и их преодоление

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

Функции каждой роли на проекте (младший/мидл/ведущий разработчик, архитектор, эксперт) и наше видение качеств, необходимых специалистам, упакованы в карту грейдов и в расширенную матрицу компетенций. 

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

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

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

Карта грейдов КРОК и расширенная матрица компетенций как ориентир роста

Как мы развиваем ТА: дополнительные материалы 

Но прокачиванием хардов сложности не ограничиваются. Во-первых, даже если теория освоена, не всегда удается сразу применить новые знания на практике. В этом плане развитие внутри крупной компании предпочтительнее, чем самостоятельное освоение курсов. В КРОК мы не просто учим ТА, а погружаем их в реальные проекты. Вопрос «как мне использовать полученные знания» не стоит вовсе — учеба привязана к практике очень прочно. 

Во-вторых, и это не менее важно, ТА должны прокачивать софты. Нужно перестроить мышление, научиться смотреть на задачи по-новому. 

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

 Что нужно, чтобы стать ТА

Я собрала топ наиболее полезных рекомендаций из моего опыта управления и развития от разработчика до технического архитектора. 

1. Прежде всего, отпустить карьеру разработчика: количество задач, связанных с программированием уменьшается, а количество коммуникаций растет. Наверняка в какой-то момент ты загрустишь по спокойным дням сфокусированной работы на одной задаче. Новые проекты и условия поначалу будут вгонять в стресс. Этот этап нужно пережить. Не все его проходят, и это тоже нормально — возможно, вам и не нужно становиться ТА :). 
2. Смотреть на проект в целом и брать ответственность за результаты команды разработки в контексте всего проекта. Научиться контролировать сроки и качество, не скатываясь в микроменеджмент. Действует принцип «доверяй, но проверяй». А еще нужно видеть слабые и сильные стороны участников команды.
3. Быть проактивным, а это тоже навык. ТА — тот человек, который принимает решения. Не надо ждать, пока менеджер проекта подумает, как тебе и твоей команде было бы удобнее работать.
4. Оценивать трудоемкость и сроки по задачам исходя не из своего уровня, а из уровня команды. Закладывать риски и человеческий фактор. При оценке своих задач учитывать время на согласование (несколько итераций) и коммуникации.
5. Искать баланс между сроками и качеством, идеальным результатом, красивым решением и реальными потребностями бизнеса. Если необходимо, принять риски недостаточно глубокого проектирования и подсветить их команде управления проекта. Запланировать и вернуться к устранению техдолга в будущем, если необходимо.
6. Выстраивать эффективную коммуникацию с коллегами и заказчиком проекта и в целом управлять временем и энергией: выполнять множество разноплановых задач и не выгорать, успевать важное и откидывать неприоритетное.
7. Оценивать и закладывать риски, принимать решения в условиях неопределенности. Важно уметь обозначать ограничения предложенного решения и ключевые моменты, а также задавать вопросы, помогающие конкретизировать задачу и выявить реальные боли. Сюда же относится умение давать индикативную оценку.
8. Ретроспективно оценивать качество принятых решений. Особенно это касается навыка проектирования: без реализации прочеленджить предложенное решение.
9. Не замыкаться только в мире 1С, помнить, за его пределами есть множество интересных технологий. Это расширяет кругозор и улучшает качество решений.
10. Не судить себя слишком строго, избегать синдрома самозванца и нездорового перфекционизма.

ТА нужны всем!

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

Руководителям и тимлидам стоит задуматься о поддержке и развитии талантливых специалистов, ведь именно от их знаний и опыта зависит создание надежных и эффективных систем. Инвестируя в обучение и рост технических архитекторов, можно значительно повысить конкурентоспособность компании и усилить её позиции на рынке, а также вкладываться в развитие отрасли, в целом.

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