Всем привет, меня зовут Сергей и я 15 лет работаю в ИТ (на самом деле больше, но так красивее смотрится).

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

Зачем всё это?

Я предполагаю, что это будет полезно кому-то, кого-то убережет от ошибок молодости (не полностью), а кого-то, наоборот, привлечет в эту область.

К сожалению, я не профессиональный писатель, поэтому постараюсь не утомить вас своим юным слогом.

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

Впрочем, к этому тоже можно придраться — многие мои однокурсники стали тестировщиками.

Я никогда не строил себе явного карьерного плана — хочу стать архитектором или техлидом в 25 лет, поэтому именно архитектором я стал относительно случайно.

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

Начало карьеры и какого ментора мне не хватало

Когда я устраивался на несколько своих первых работ, мне естественно системного понимания ситуации не хватало, а слова «онбординг» тогда еще не изобрели. Поэтому я постоянно ощущал себя потерянным, и мои работы имели весьма фрагментарный характер. Например, эту функцию я написал — а что дальше? Бывают ли на нее тесты, куда их писать? Например, я не знал, как использовать JUnit для написания unit‑тестов или как создавать мок‑объекты с Mockito, чтобы протестировать взаимодействие компонентов.

Это уж не говоря о ситуации, когда мне надо было, например, запускать сборку проекта или, не дай боже, деплой на какое‑то окружение. Помню, как я пытался вручную настраивать сборку через Maven или Gradle, разбираясь в профилях для разных сред. А деплой иногда превращался в ад, когда я сталкивался с конфигурационными проблемами и долгими ночами, пытаясь вручную исправить баги.

Так вот, в этот момент мне очень не хватало ментора, который бы оперативно отвечал на вопросики — как по ЯП, так и по проекту вообще:

«А зачем на Java вот это?»

«А какой тип данных тут использовать?» (обычно это был BigDecimal, а не Double)

«Не зря ли я тут навертел concurrency?» (чаще всего зря)

И второй момент — у ментора должен быть искренний интерес помогать мне. Я уж слишком много видел аллоцированных на онбординг специалистов, которые:

«Господи, что за тупой вопрос!»

«Ну давай посмотрю, что ты там наделал — наверняка фигню какую‑то»

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

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

Как же правильно?

Например, понятные документы для онбординга — самый нижний уровень архитектурной схемы С4 — насколько я знаю, большинство компаний в РФ в принципе ленятся его прорабатывать, поддерживать и хранить. Например, диаграммы, описывающие, как взаимодействуют микросервисы через Kafka или RabbitMQ, могли бы значительно ускорить вливание в проект новых разработчиков.

Или даже банально перечислить эндпоинты - многие и этим не занимаются.

Сессии передачи знаний — KT — или просто сессии о продукте, где техлид или сеньор поясняют за технические решения проекта, которые можно пересматривать неоднократно — такие я в жизни видел, сам записывал — но опять же, далеко не во всех компаниях. Например, обсуждение архитектуры, в которой используется подход Event Sourcing, или объяснение, почему мы выбрали Consul для сервис‑дискавери, могли бы сэкономить мне кучу времени.

В конце концов, даже такая простая вещь, как «отрезать у техлида или сеньора N процентов времени на менторинг джуна» — ее мало кто делает даже в нынешнем 2024-м. Поддержка в виде разбора, как правильно настроить Kubernetes для деплоя микросервисов, или объяснение принципов распределенных транзакций могла бы существенно помочь в начале.

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

И на этой ноте можно плавно перепрыгнуть в менеджмент — управление проектом и прочие аджайлы.

Чем был плох менеджмент в моих первых компаниях?

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

Например, проводить ретроспективы и что‑то делать после них(!) — это критически важная часть, иначе команда постепенно остывает к выдаче фидбеков и вся церемония становится бессмысленной — а ля «мы собрались, поговорили в пятницу вечером, все лучше, чем работу работать перед выходными».

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

Конечно же, планирование — оно должно включать реальную оценку задач, а не ту, которую требует заказчик, иначе у вас фуфлоджайл. Я такого тоже насмотрелся.
Например, стандартное планирование в одной из компаний выглядело так: заказчик диктует сверху срок (скажем, одну неделю), команда оценивает задачи, нарезает бэклог, стараясь впихнуть максимум, а потом приходит бодрый ПМ или надПМ с формулой: «у нас 50 задач, времени неделя, значит каждая задача занимает максимум 15 минут.» Никакой связи с реальностью. Помню случай, когда мы получили задачу «оптимизировать работу базы данных». Время оценки было 3 часа, но даже грубое исследование показало, что нужно менять индексы, проводить миграции и переписывать часть запросов — на это уходило минимум три дня. В итоге команда потратила больше времени на обсуждения, чем на саму работу, а дедлайн всё равно сорвали.

Что было хорошо с проектом

Но что я всё о проблемах да о проблемах — наверняка было что-то хорошее в моем начале пути?

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

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

Вообще, главное качество технаря, которое мне сильно бросилось в глаза на том этапе, — это безропотная исполнительность. Нужно до завтра мост построить? Ок, пошёл делать. Прод упал ночью? Да, это проблема техлида, сейчас поправим. Возможно, причины этого в воспитании, биографии или каких‑то социальных нормах, в которых мои коллеги воспитывались, но это было прям показательно практически всегда. Например, однажды мы весь выходной разгребали проблемы после обновления, хотя они произошли из‑за ошибок заказчика, который изменил API без уведомления. Все молча засели, исправили, даже не подняв вопрос о переработке.

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

Комментарии, соображения, замечания — велком.