Строим карьеру архитектора

Александр рассказывает о себе: пять лет в Tinkoff, сейчас руководит управлением, которое отвечает за мобильный банк для физлиц и за онлайн-привлечение клиентов, — порядка 400 человек; себя он называет скорее техническим директором этой части компании, чем архитектором. Ведущие ставят проблему главы: человек, ушедший на руководящую должность, отдаляется от работы в полях, квалификация тает, а знать нужно всё больше — фронтенд, мобильную разработку, дата-слой. Ответ Александра: чем шире зона ответственности, тем на более высоком уровне абстракции ты думаешь — понимаешь направление, функциональные и нефункциональные требования и то, какие команды участвуют в решении, а конкретные решения принимают на местах более компетентные люди; тот, кто пытается быть самым умным и всем диктовать, получит и бунт, и посредственный результат. Книга же предлагает правило 20 минут: двадцать минут в день читать про технологии, чтобы уменьшать область того, чего ты не знаешь, что не знаешь.

Женя Пешков говорит, что правило работает отлично, хотя усидчивости на каждый день не хватает: он практикует его периодами и сейчас копает в сторону менеджмента, где неизвестного у него больше, чем в IT. Ведущие добавляют, что темп важнее рывка: десять страниц в день дают за год около 3500 страниц, пяток средних книг, а клуб раз в неделю делает регулярность внешней. Сам Александр правило не практикует, но после книги подписался на рекомендованное: рассылки DZone с Refcardz и ежемесячный Architecture Newsletter от InfoQ — оттуда он вытащил статью авторов Team Topologies. На самообразование уходит часа два в день, в рабочее время успевает редко, но работой это не считает — скорее стилем жизни. За самым свежим он советует идти в white paper крупных компаний: там есть и дизайн-документ, и цена облачного сервиса — видно, почему геораспределённая база с транзакциями столько стоит. Так он открывал документ про Google Spanner, услышав термин NewSQL, но, кажется, прочёл пару страниц.

Следующий шаг главы — персональный техрадар, и начинают с обычного: документ ThoughtWorks, мишень из секторов и колец. Секторов четыре — тулинг, языки, фреймворки, техники и подходы. Колец тоже четыре: hold, assess, trial и adopt, от дальнего к центру. Ведущий признаётся, что кольца понял не до конца: книга объясняет hold как «пока не используйте», слишком новое и непроверенное, но туда же попадает и deprecated. Александр подтверждает: сейчас в hold лежит практика блокирующего peer review, и он не уверен, что она вообще бывала во внутренних кольцах: её могли подсветить, чтобы индустрия перестала так делать. Дальше движение: assess — тема интересная, но вглубь не копали; trial — надо попробовать внутри, потому что маркетинговым и восторженным отзывам верить нельзя; adopt — то, во что стоит вкладывать силы. Из adopt технология уходит в hold, когда появился способ получше, но пробивать все кольца необязательно: новинка часто мигает на радаре и исчезает — очередной JS-фреймворк, обещавший решить всё.

Личное портфолио книга предлагает вести так же: знания, практики и привычки — набор инструментов, которым вы диверсифицируете риски, и в hold отправляются не только технологии, но и привычки без пользы, например любимый портал, сползший с технических материалов на развлекательные. Оттуда же образ, который Александр пересказывает из чужого прошлогоднего выступления на вручении архитектурной награды Software Engineering Institute: раньше архитектор проектировал систему с нуля, теперь у него набор кубиков Lego, и надо понимать, какие они бывают, что гарантируют и как соединяются. В крупной компании сложнее — непонятно, радар чего рисовать: приложения для физлиц, юрлиц и инвестиций живут на разных подходах, где-то корутины, где-то Rx, общий радар превращается в объединение всего, а пяток отдельных перестаёт задавать направление. Зато радар нужного стека можно приложить к вакансии, и Александр ценит компании, которые публикуют его открыто: кандидат сам поймёт, его это подход или соседней команды.

Последний параграф — снова мишень, теперь про связи: в центре сильные (коллеги и семья, о ком знаешь хотя бы, как он обедал на этой неделе), дальше слабые и потенциальные, а новое приходит от слабых. Ведущий считает диаграмму притянутой: смысл тот же, что с рассылками, — подпишись на интересных людей в твиттере или телеграме. Александр добавляет по существу: сообщество небольшое, за несколько лет конференций почти всех знаешь через одно-два рукопожатия, и, упершись в сложную проблему, находишь эксперта; та же сеть работает на найм и приглашения. Расширяет её публичность: спикеру знакомиться проще, а признанного эксперта зовут в программный комитет — один из ведущих замечает, что этой осенью его самого позвали экспертом благодаря подкасту. Опасность, к которой глава сводится, — информационный пузырь и узкая специализация на технологии, ненужной через считаные годы. Главу заканчивают цитата о том, что шансов построить великую архитектуру в карьере выпадает всего пяток, и совет тренироваться на архитектурных катах, где проектируешь, не закапывая деньги в прод.

Сам Александр в катах не участвовал, зато за год провёл несколько десятков — по его оценке, меньше сотни — дизайн-интервью по распределённым системам и написал часть задач для дизайн-секции. Хорошая задача устроена как детектив: требования работают подсказками и оставляют один-два разумных варианта. Из внутреннего архитектурного Slack-канала, где тоже больше 400 человек, он набирает пул интервьюеров: те ходят вторым пилотом, а потом ведут сами. Роли он делит на три: software architecture, которую в идеале делают инженеры уровня staff и principal, не ушедшие из кода; solution architecture — про сложность решения, тянущегося через несколько систем и команд; и полумифическая enterprise architecture с TOGAF и матрицей Захмана, тогда как унификацию в масштабе даёт не всезнающий человек, а общие платформы и инженерные практики. Идеального архитектора из книги он считает целевым состоянием: директивное управление не работает, решения приходится продавать — приносить RFC с проблемой и вариантами, а фиксировать уже ADR.