Из разработчиков — в Solution Architects: история одной трансформации

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

«Когда я сказал, что покидаю компанию, коллеги смотрели на меня с недоумением»

Сегодня я в футболке, которая осталась еще с предыдущего места работы. Это стартап, где были собраны самые «упоротые» разработчики со всея Минска и не только. Мы делали волшебные технологические решения, не имея почти никаких ограничений по срокам и бюджету. Это и мобильные клиенты на Swift и Kotlin, и бэкенд на Go. На свой страх и риск мы использовали еще не проверенные временем, но многообещающие подходы в реактивном и функциональном программировании. К счастью, все получилось: к моменту релиза эти технологии дозрели до уровня production-ready — кстати, не без нашего участия.

Без интересных решений не обошелся и бэкенд: современное оркестрирование, big-data-ready-система журналирования с отчетностью на основе Grafana/Kibana. Язык Go также располагал к интересным решениям — например, микросервисной архитектуре и оркестрированию большого количества взаимозаменяемых узлов. Больше всего запомнился их fail-tolerance-подход: если сталкиваешься с ошибкой, проще убить узел и перезапустить систему. Это займет полсекунды и сэкономит много времени. Приходилось решать задачи, сложные с точки зрения алгоритмики. С одной стороны, такая работа давала мне стимул расти как инженеру, а с другой — хотелось делиться интересными практиками за пределами нашей команды, влиять на то, чтобы люди делали что-то лучше.

Когда я сказал, что покидаю компанию, коллеги смотрели на меня с недоумением, ведь для того чтобы уйти из передового стартапа, нужна четкая цель. У меня она была — развитие в качестве технического лидера. Если честно, не хотелось оставаться в рамках разработки: в какой-то момент просто стало страшно, что платформа может оказаться неактуальной. В EPAM мне предложили работу в качестве Solution Architect. Не был уверен, получится ли, но решил: раз уж дают такую возможность — нужно соглашаться.

EPAM — место, где можно получить понимание процессов разработки продукта «от и до», научиться видеть их через призму бизнеса. К этой компании я присмотрелся еще пару лет назад после участия в их внутренней конференции EPAM Insider. Ее уровень показал, что раньше я недооценивал эту компанию. Через какое-то время, после общения с проектным менеджером Ириной Сусаниной и директором Internet of Things в EPAM Дмитрием Огиевичем, я оказался в EPAM.

Образно говоря, сначала представлял себе работу Solution Architect как рисование квадратиков и стрелочек. Однако мое отношение стало меняться уже на этапе собеседования, которое архитектор Олег Орел из EPAM начал с фразы «Архитектор — это такой менеджер…».

А ведь он был прав. Оказалось, что одна из моих основных задач на текущем проекте — сделать так, чтобы множество участников процесса разработки говорили об одном и том же и не писали сотни гневных писем друг другу. Чтобы после нескольких месяцев работы «куски», выполненные большими командами, распределенными по всему миру, «волшебным образом» склеились в работающую систему. И при этом чтобы разработчики даже не догадывались, что процесс «склеивания» вообще имеет место. Это все равно что вовремя подставлять ступеньки под ноги человеку, идущему с закрытыми глазами. EPAM начала работу над проектом в качестве разработчика мобильного приложения, но постепенно компания превращается в интегратора, который заставляет работать все части проекта вместе.

«Мы создаем мобильное приложение, которое в перспективе станет незаметным, но необходимым, как воздух»

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

Как проект выглядит с точки зрения разработчиков из EPAM? Мы создаем мобильное приложение, которое в перспективе станет незаметным, но необходимым, как воздух. Представьте, что вы приехали в Европу без сим-карты и вам понадобилось срочно с кем-то связаться через интернет. Ваш смартфон определил 200 точек Wi-Fi вокруг, для доступа к которым требуется пароль. Большинство этих точек принадлежат одной сотовой компании — почему бы не сделать опыт пользователей Wi-Fi таким же, как и пользователей сотовой связи? Ты идешь по городу, и твой телефон автоматически подключается к разным точкам без пароля. Переключение происходит незаметно для глаз: твое видео с котиками не прерывается.

Проект далеко не прост для воплощения: за нашим мобильным приложением стоит огромная компания со сложной инфраструктурой. У меня до сих пор не получилось до конца понять, как работает Wi-Fi-роутер, а описание его возможностей занимает огромные документы, которых не один и даже не два. Поэтому я, как Solution Architect, вполне осознанно могу сказать, что Wi-Fi — это «гребаная магия». И в то же время, извернувшись, преодолев технические ограничения, можно сделать продукт, над которым мы сейчас работаем для одного из операторов Wi-Fi — глобального панъевропейского заказчика.

«Здесь у тебя появляется злое знание: если ты сейчас допустишь ошибку, то через месяц 30 разработчиков будут сидеть без дела, а это дорого»

Подобные проекты не так давно на рынке: проект для британской компании и некоторых операторов в США, наметки Белтелекома (не в сторону мобильного приложения, а объединения всех роутеров в одну систему). Но информации о них исчезающе мало, поэтому мы ни в коем случае не копируем, а создаем продукт с нуля. Технологии здесь не имеют значения. Конечно, замечательно, что наше мобильное приложение строится на современных архитектурах, использует реактивное программирование и даже имеет тесты. Но главное — это огромная организационная сложность проекта: разные части бэкэнда (например, сервисы данных о пользовании телефоном, наработанные командами из разных стран) необходимо «подружить» между собой. Знаете, чем отличается эта работа от работы над стартапом? Команда стартапа целенаправленно создает один продукт. Здесь же есть много команд, которые занимаются разными продуктами и другими активностями, времени и внимания которых необходимо еще добиться. В стартапе ты живешь по простой идеологии: «Решаем проблемы по мере их поступления». А на проекте в EPAM у тебя появляется злое знание: если ты сейчас допустишь ошибку, то через месяц 30 разработчиков будут сидеть без дела, а это дорого. Речь идет не о принятии решений, а о принятии ответственности, готовности слепить конфетку из того, что есть под рукой.

«Моя самооценка колеблется между “Если я уйду с этого проекта, через неделю ему конец” и “Если я уйду с этого проекта, через месяц никто и не заметит”»

Не ошибаться просто нельзя, и тем не менее форс-мажоров никогда не возникало — если только локальные ошибки. Я завел себе файлик под названием «Мои факапы», куда записываю свои наблюдения. Например, за это время пришел к выводу, что нельзя создать такого процесса, по которому все будет безукоризненно работать. Обычно в команде есть два-три инициативных сотрудника, которые закрывают дыры, а потом учат этому других. Без них не поможет никакой Scrum. Для того чтобы эффективнее строить коммуникацию с людьми, следую простому правилу — заведи файлики про них и записывай туда минимальные факты: за что ответствен, где участвует, в чем помог, в чем не помог, отвечает ли без напоминаний. Самая сложная задача, которую мне когда-либо приходилось решать, — как-то упорядочить информацию, которая приходит в виде писем, встреч, знакомств, документов. Мечтаю о таких палатах разума, как у Шерлока.

Работа настолько динамичная, что за 8 месяцев я кардинально изменился как профессионал — начиная с первых митингов с заказчиками, когда я просил говорить за меня коллегу, и заканчивая текущим, автономным, состоянием. Я научился лучше планировать свое время и быстрее переключаться между задачами. Это привело к жизни «по календарю», когда даже время на «подумать об отпуске» заносится в расписание. Планирование помогло мне привести в порядок не только работу, но и всю остальную жизнь.

Помимо этого, работа в качестве Solution Architect в EPAM помогла мне справляться с личными психологическими проблемами: не думать о том, как тебя оценивают другие, принимать некоторые удары за себя и за других, чтобы проект двигался вперед. Тем не менее сложно работать, когда результаты твоих действий могут быть очень растянуты во времени. Моя самооценка колеблется между «Если я уйду с этого проекта, через неделю ему конец» и «Если я уйду с этого проекта, через месяц никто и не заметит».

Помимо проектных активностей, EPAM дала много возможностей расти в совершенно любом направлении — от eye-contact-тренингов до обзора новостей из мира архитектуры. Есть возможность делиться своими знаниями с сообществом в рамках Центра мобильной компетенции, пройти обучение в так называемом Solution Architecture University — программе, направленной на рост специалистов уровня Senior и Lead. Подобные инициативы всегда поддерживаются руководством. За время работы в этой компании я понял: ты можешь заниматься здесь всем, чем можешь и хочешь. Главное, чтобы позволяло время.