Год назад мобильный разработчик Иван Трифонов променял нашумевший стартап на позицию Solution Architect в одном из инновационных проектов в EPAM. Вот его рассказ о том, как он учился плавать в море проектных активностей, как изменилось его отношение к процессу работы, и почему позиция архитектора учит отвязываться от самооценки.
«Когда я сказал, что ухожу, коллеги смотрели на меня с недоумением»
Сегодня я в футболке, которая осталась еще с предыдущего места работы. Это стартап, где были собраны самые «упоротые» разработчики со всея Минска и не только. Мы делали волшебные технологические решения, не имея почти никаких ограничений по срокам и бюджету. Это и мобильные клиенты на Swift, и Kotlin, и бэкенд на Go.
На свой страх и риск мы использовали ещё не проверенные временем, но многообещающие подходы в реактивном и функциональном программировании. К счастью, всё получилось: к моменту релиза эти технологии дозрели до уровня production-ready — кстати, не без нашего участия.
Без интересных решений не обошелся и бэкенд: современное оркестрирование, big-data-ready-система журналирования с отчётностью на основе Grafana/Kibana. Язык Go также располагал к интересным решениям — например, микросервисной архитектуре и оркестрированию большого количества взаимозаменяемых узлов. Больше всего запомнился их fail-tolerance-подход: если сталкиваешься с ошибкой, проще убить узел и перезапустить систему. Это займет полсекунды и сэкономит много времени. Приходилось решать задачи, сложные с точки зрения алгоритмики.
С одной стороны, такая работа давала мне стимул расти как инженеру, а с другой — хотелось делиться интересными практиками за пределами нашей команды, влиять на то, чтобы люди делали что-то лучше.
Когда я сказал, что покидаю компанию, коллеги смотрели на меня с недоумением, ведь чтобы уйти из передового стартапа, нужна чёткая цель. У меня она была — развитие в качестве технического лидера. Если честно, не хотелось оставаться в рамках разработки: в какой-то момент просто стало страшно, что платформа может оказаться неактуальной. В EPAM мне предложили работу в качестве Solution Architect. Не был уверен, получится ли, но решил: раз уж дают такую возможность, нужно соглашаться.
«Архитектор — это такой менеджер…»
EPAM — место, где можно получить понимание процессов разработки продукта «от и до», научиться видеть их через призму бизнеса. К компании я присмотрелся ещё пару лет назад после участия в конференции EPAM Insider. Через какое-то время стал их сотрудником.
Образно говоря, сначала представлял себе работу Solution Architect как рисование квадратиков и стрелочек. Однако моё отношение стало меняться уже на этапе собеседования, которое архитектор Олег Орел из EPAM начал с фразы «Архитектор — это такой менеджер…».
А ведь он был прав. Оказалось, что одна из моих основных задач на текущем проекте — сделать так, чтобы множество участников процесса разработки говорили об одном и том же и не писали сотни гневных писем друг другу.
Чтобы после нескольких месяцев работы «куски», выполненные большими командами, распределёнными по всему миру, «волшебным образом» склеились в работающую систему. И при этом чтобы разработчики даже не догадывались, что процесс «склеивания» вообще имеет место. Это всё равно что вовремя подставлять ступеньки под ноги человеку, идущему с закрытыми глазами. EPAM начала работу над проектом в качестве разработчика мобильного приложения, но постепенно компания превращается в интегратора, который заставляет работать все части проекта вместе.
Проект Х: «Незаметное, но необходимое как воздух приложение»
Меня восхитило то, что EPAM налаживает процесс работы вокруг себя, постепенно расширяя его до команд из других компаний. Все договариваются и начинают работать по одному процессу, и эта магия происходит с твоим участием. Ты тесно общаешься с заказчиками и разработчиками — и в голове складывается картинка, которая обрастает новыми деталями в процессе коммуникации, выявляются и устраняются нестыковки.
Как проект выглядит с точки зрения разработчиков?
Мы создаем мобильное приложение, которое в перспективе станет незаметным, но необходимым, как воздух. Представьте, что вы приехали в Европу без сим-карты и вам понадобилось срочно с кем-то связаться через интернет. Ваш смартфон определил 200 точек Wi-Fi вокруг, для доступа к которым требуется пароль. Большинство этих точек принадлежат одной сотовой компании — почему бы не сделать опыт пользователей Wi-Fi таким же, как и пользователей сотовой связи? Ты идёшь по городу, и твой телефон автоматически подключается к разным точкам без пароля. Переключение происходит незаметно для глаз: твое видео с котиками не прерывается.
Проект далеко не прост для воплощения: за нашим мобильным приложением стоит один из операторов Wi-Fi — глобальный панъевропейский заказчик со сложной инфраструктурой. У меня до сих пор не получилось до конца понять, как работает Wi-Fi-роутер, а для описания его возможностей требуется не один документ. Поэтому я как Solution Architect вполне осознанно могу сказать, что Wi-Fi — это «грёбаная магия».
И в то же время, извернувшись, преодолев технические ограничения, можно сделать продукт, над которым мы сейчас работаем.
Подобные проекты не так давно на рынке: проект для британской компании и некоторых операторов в США, намётки «Белтелекома» (в сторону объединения всех роутеров в одну систему). Но информации о них исчезающе мало, поэтому мы ни в коем случае не копируем, а создаем продукт с нуля. Технологии здесь не имеют значения.
Конечно, замечательно, что наше приложение строится на современных архитектурах, использует реактивное программирование и даже имеет тесты. Но главное — это огромная организационная сложность проекта: разные части бэкенда (например, сервисы данных о пользовании телефоном, наработанные командами из разных стран) необходимо «подружить» между собой.
Между стартапом и EPAM: ответственность прежде всего
Знаете, чем отличается эта работа от работы над стартапом, команда стартапа целенаправленно создает один продукт? Здесь есть много команд, которые занимаются разными продуктами и другими активностями, времени и внимания которых необходимо ещё добиться.
В стартапе ты живешь по простой идеологии: «Решаем проблемы по мере их поступления». А в проекте EPAM у тебя появляется злое знание: если ты сейчас допустишь ошибку, то через месяц 30 разработчиков будут сидеть без дела, а это дорого. Речь идет не о принятии решений, а о принятии ответственности, готовности слепить конфетку из того, что есть под рукой.
Не ошибаться просто нельзя, и тем не менее форс-мажоров никогда не возникало — если только локальные ошибки. Я завёл себе файлик под названием «Мои факапы», куда записываю наблюдения. Например, за это время пришёл к выводу, что нельзя создать такого процесса, по которому всё будет безукоризненно работать.
Обычно в команде есть два-три инициативных сотрудника, которые закрывают дыры, а потом учат этому других. Без них не поможет никакой Scrum. Для того чтобы эффективнее строить коммуникацию с людьми, следую простому правилу — заведи файлики про них и записывай туда минимальные факты: за что ответствен, где участвует, в чём помог, в чём не помог, отвечает ли без напоминаний.
Самая сложная задача, которую мне когда-либо приходилось решать, — упорядочить информацию, которая приходит в виде писем, встреч, знакомств, документов. Мечтаю о таких палатах разума, как у Шерлока.
Жизнь «по календарю»
Работа настолько динамичная, что за 8 месяцев я кардинально изменился как профессионал: начиная с первых митингов с заказчиками, когда я просил говорить за меня коллегу, и заканчивая теперешним автономным состоянием. Я научился лучше планировать время и быстрее переключаться между задачами. Это привело к жизни «по календарю», когда даже время на «подумать об отпуске» заносится в расписание. Планирование помогло мне привести в порядок не только работу, но и всю остальную жизнь.
Помимо этого, работа в качестве Solution Architect помогла мне справляться с личными психологическими проблемами: не думать о том, как тебя оценивают другие, принимать некоторые удары за себя и за других, чтобы проект двигался вперед. Тем не менее сложно работать, когда результаты твоих действий могут быть очень растянуты во времени.
Моя самооценка колеблется между «Если я уйду с этого проекта, через неделю ему конец» и «Если я уйду с этого проекта, через месяц никто и не заметит».
Помимо проектных активностей, EPAM дала много возможностей расти в любом направлении — от eye-contact-тренингов до обзора новостей из мира архитектуры. Есть возможность делиться знаниями с сообществом в рамках Центра мобильной компетенции, пройти обучение в так называемом Solution Architecture University — программе, направленной на рост специалистов уровня Senior и Lead. Подобные инициативы всегда поддерживаются руководством. За время работы в этой компании я понял: ты можешь заниматься здесь всем, чем можешь и хочешь. Главное, чтобы позволяло время.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.