Фев. 20

Как я работаю: Роман Шрамков, Technology Director в EPAM

[В рубрике «Как я работаю» мы приглашаем гостя рассказать о своей работе, организации воркспейса, полезных инструментах и лайфхаках]

Роман Шрамков сотрудничает с EPAM больше 8 лет, прошел путь от обычного программиста до Technology Director. Его главная обязанность — растить архитекторов, которые смогут решать любые архитектурные задачи и находить свежие решения самостоятельно.

Роман возглавляет и развивает центр компетенций Java. В рамках этого проекта он проводит консультации для клиентов ЕРАМ, посещает международные конференции, в том числе форум глав центров компетенции в Минске и Global Solution Architecture Team Gathering.

О себе

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

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

Университет я закончил в 2000-м году. Решил, что с физикой связывать жизнь не буду: несмотря на сильную школу, в этой области в Украине не было перспектив. Тогда я задумался о программировании — меня всегда привлекала эта компьютерная магия. О деньгах речь не шла, программирование еще не было распространенной, популярной и высокооплачиваемой профессией. В то время разработкой ПО занимались всего несколько компаний, а платили программистам максимум $100.

Я устроился на работу в государственную организацию и по ночам зубрил языки программирования, чтобы подтянуть прикладные навыки. Спустя год-полтора получил первую работу в маленькой конторе. Мы разрабатывали систему учета для школ, использовали Visual Basic и продукты Microsoft Office.

Дальше — первая «промышленная» работа в продуктовой компании, где делали биллинговую систему и всерьез говорили о терабайтах данных. Сначала я разрабатывал базы данных, писал запросы и хранимые процедуры. Затем попал в R&D-отдел и перешел на Java. После стека Microsoft этот язык мне понравился своей открытостью, наличием Open Source и сильного сообщества.

Затем я сменил еще 3-4 компании и в 2010 году устроился в EPAM на позицию Lead Software Engineer. С ходу попал на интересный проект. Мы дорабатывали систему для бронирования отелей. Предыдущая платформа заказчика была настолько плохого качества, что когда мы втроем с коллегами одновременно зашли на сайт, он упал. И нам дали карт-бланш на то, чтобы все переделать. Мы разрабатывали продукт и показывали заказчику графики роста производительности и надежности, а он нам в ответ — графики роста прибыльности. И это давало понимание, что мы все делаем правильно.

Роль и обязанности

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

Затем в 2014 году EPAM начал развивать дисциплину Solutions Architecture, которая впоследствии трансформировалась во внутреннюю школу для Solutions Architects. В отличие от Software Architect, Solutions Architect отвечает не за код, а за общение с заказчиком, прояснение требований и формирование высокоуровнего решения для всей системы. Он выбирает, какие технологии использовать, почему именно их — исходя из того, чтобы инструменты соответствовали бизнес-целям разрабатываемого продукта. Если над проектом работают несколько команд, этот специалист синхронизирует понимание архитектуры между ними.

После того, как я около 10 лет работал только с кодом, работа с людьми стала новым вызовом и полем для роста. Было интересно разобраться, понять, как это делать правильно.

Затем я задумался, как можно распространить свой опыт управления процессами с уровня одного проекта на больший масштаб. В прошлом году EPAM предложил мне позицию Technology Director. Как и прежде, я выступаю в роли посредника между бизнесом клиентов и техническими командами, но только на уровне всей компании. Общаюсь с заказчиками, консультирую внутренние процессы, внедряю best practices.

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

Ещё одна моя роль в компании — руководитель центра компетенций Java. Я поставил себе цель сформировать пул экспертов, которые могли бы выезжать к заказчику и грамотно обсуждать технические решения. Чтобы построить процессы, изучал примеры компаний Oracle и IBM, где центры компетенций по некоторым темам работают как выделенные структуры.

Ядро нашей команды — 5-6 архитекторов, которые занимаются пресейлом, консалтингом и кейсами, в которых необходима серьезная инженерная поддержка. Я как руководитель центра компетенции возглавляю архитектурную группу. Через меня проходят большинство «красных», сложных и важных кейсов.

Другая наша задача — образование. Мы создаем тренинговые и менторинг-программы, ведем рассылки новостей про технологии и группы по обсуждению обновлений. Подробнее о работе центра компетенций я рассказывал в отдельной статье на DOU.

Типичный рабочий день

8:00. Я рано прихожу на работу. Обычно в это время в офисе нет никого, кроме охранника и уборщицы, и я могу почитать технические новости и статьи, посмотреть какие-то технологии, написать прототип. В общем, занимаюсь обучением, которое позволяет расти как специалисту.

10:00. Начинаются стендапы с командами и созвоны с заказчиками из Европы.

11:30. Занимаюсь работой по проектам: подготавливаю какие-то документы, заполняю артефакты.

12:30. Иду на обед. Считаю, что очень важно делать перерыв на отдых, немного отвлечься от работы. Если человек перестает ходить на обед — это первый признак, что он перегружен. Я часто обедаю с командой, мы болтаем на отвлеченные темы, обсуждаем новости. Получается что-то вроде тимбилдинга :)

13:30. Еще час-полтора работаю над проектами и своими задачами.

15:00. Просыпаются заказчики из США и начинают бомбить запросами и созвонами :)

Вообще я стараюсь, чтобы встречи занимали не больше 60% рабочего времени. Как правило, у меня получается выдерживать этот баланс. Но иногда бывают дни, когда расписание рушится, и общение с заказчиками или командами продолжается нон-стоп. А бывает, что я сам отменяю все встречи, чтобы срочно сделать или доделать какую-то работу. К примеру, разработать какой-то прототип, чтобы донести до команды свое видение архитектуры — иначе программисты потратят время на неправильную реализацию. Или другой пример: в январе компания закрывала финансовый год, и нужно было провести 1-на-1 со всеми ребятами, чтобы распределить годовые бонусы.

18:30. Заканчиваю работу. Стараюсь уходить из офиса не позже 19-ти часов, чтобы успеть отдохнуть и провести время с женой и детьми, у меня их четверо. В молодости было время, когда зависал на работе днями и ночами. Но когда появилась семья, принял решение ограничить рабочее время.

Получается, я провожу в офисе 10-11 часов с учетом обеда. Но не все это время занимают исключительно рабочие задачи. На сфокусированную техническую работу уходит примерно 3-4 часа. Остальное — общение и самообразование.

Инструменты и продуктивность

Все, что мне нужно для работы, — ноутбук и интернет. Я часто езжу в командировки, поэтому привык «все свое носить с собой». В Харькове у меня есть кабинет, фактически он играет для меня роль комнаты для совещаний. Кроме ноутбука, у меня нет в кабинете других личных вещей — люблю лаконичность и минимализм, когда ничего не отвлекает.

Каждый день я начинаю с вопроса: какие дела я должен выполнить сегодня? Затем расставляю приоритеты и под этот список планирую временные слоты в календаре. Чтобы во время рабочего дня не приходилось постоянно переключаться между разными задачами, я стараюсь разделять контексты. К примеру, до обеда работаю над одним проектом, после обеда — над другим. Такой подход позволяет вести несколько проектов одновременно и не упускать важные задачи.

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

Помимо краткосрочных целей, я записываю и средне- и долгосрочные — на квартал, год и 3-5 лет. Это помогает развиваться, а не топтаться на одном месте. Подхожу к этому гибко: моя цель не обязательно имеет четкую формулировку и дедлайн. Скорее, она просто задает направление движения. К примеру, несколько лет назад я поставил себе цель возглавить центр компетенций Java. Для этого узнавал, как это работает, какие нужны навыки и знания, чтобы попасть на эту позицию. Я не ставил конкретные сроки, просто держал цель в фокусе и выделял время на подготовку. По такой же схеме подхожу и к личным целям — например, похудеть: за последние полгода сбросил около 10 кг.

Мне очень нравится методика Getting things done. Я обязательно фиксирую все задачи, которые ко мне приходят. Для этого использую Outlook, так как большинство запросов поступает в виде писем, заметок или follow-ups по митингам. Периодически просматриваю свой список задач, чтобы не забыть о делах, которые имеют дедлайн.

Для кодирования использую IntelliJ IDEA, для трекинга задач — Jira. Информацию по проектам веду в Excel — это очень универсальный инструмент, который удовлетворяет все мои запросы. Например, планирую там задачи, обозначаю open issues, которые надо обсудить с заказчиками, расписываю SWOT-анализ.

Книжки и самообразование

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

Новости об украинском сегменте IT читаю на DOU и AIN. Об инновациях и всемирных стартапах — на TechCrunch. Много интересных материалов для архитекторов выходит на InfoQ.com.

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

Что касается фундаментальных книг для архитекторов, я советую почитать:

«Software Architecture in Practice» by Len Bass, Paul Clements, Rick Kazman;
«Documenting Software Architectures» by Paul Clements, Felix Bachmann, Len Bass;
«Software Systems Architecture» by Nick Rozansk;
«Just Enough Software Architecture» by George Fairbanks;
«97 Things Every Software Architect Should Know» by Richard Monson-Haefel.

Ретроспектива и планы на будущее

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

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