×

Как я работаю: Роман Шрамков, 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 позволяет быстрее генерировать контент и давать информацию по новым технологиям, чем традиционные издательства.

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

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

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

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному1
LinkedIn

Схожі статті




27 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Романе, як зараз працюється на позиції СЕО (судячи з Лі) після стількох років технічних посад?

Интересная статья! Спасибо

Так а сколько он сейчас получает? тема $ не раскрыта

Женя, я уверен, что тему $ можно легко раскрыть придя к нам на собеседование. У нас в каждой локации есть интресные позиции.

в 2000 хороший разраб получал 300 — 1000. да в госах было 150 — 200 сотка зп джуна

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

Согласен на все 100%. Очень часто, самое сложное — это сделать первый шаг. А когда его сделаешь, то понимаешь, что оказывается не все так страшно, как казалось :) Самое смешное, что с опытом понимаешь, что в итоге все получится, и все равно страх неудачи присутствует :)

Отличная статья, спасибо ! Удачи Вам !

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

Расскажите про интересный проект, что требовал нетривиальной экспертизы зашел в компанию и успешно вышел в прод, где тех решение было концептуально вами разработано или вашими архитекторами. Технологии/Архитектурный стиль/Домен/Команда.

В компании я стартовал несколько высокотехнологичных экспертиз. Одна из них была в области in-memory решений на базе GigaSpaces XAP, в том же стриме довелось работать и c Apache Ignite. В последнее время, мы много работаем над темой микросервисов и контейнерных платформ, соотвественно это Docker, Kubernetes, Open Shift немного Pivotal Cloud Foundry.

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

Предыдущая платформа заказчика была настолько плохого качества, что когда мы втроем с коллегами одновременно зашли на сайт, он упал.

Правильно, в любій непонятній ситуації валимо на папєрєдніків

Нравится, что ответы есть под каждым комментарием) в целом крутая статья и есть к чему стремиться) и круто, что всё сделано на любви к ИТ и новаторству)

П. С. Как семья относится к такому графику? Не сильно жена расстраивается, что дома совсем мало проводите?

Максим, конечно, график моей рабочей недели выглядит довольно плотно, но благодаря тому, что нерабочее время я максимально посвящаю семье и близким, я думаю, что они этого сильно не замечают.

Если подумать, то большинство из нас заканчивают работу около шести — семи вечера и проводят с семьей практически столько же времени, сколько и я.

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

Нужно просто найти свой ритм.

А и ещё такие два вопроса. Как контролируете достижение целей?

И я так понял выполняете планы с помощью календаря (outlook). Как можно грамотно всё планировать?

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

Если делать такое планирование\анализ регулярно, то можно довольно быстро разобраться насколько Вы эффективны в реализации Ваши задумок.

Вообще рекомендую почитать книгу Глеба Архангелького «Тайм Драйв», там много простых техник, которые с этим хорошо помогают.

Щоб дорости до власного кабінету, потрібно батрачити 10 років. Сумно. Особливо сподобалось коротке прев‘ю до статті про 100 доларів. Це напевне, щоб теперішні джуніори відчули себе богатими ))
Я б радив собі 6 років тому дивитися відразу на глобальний ринок з глобальними рейтами.

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

Не уверен, на основании чего, вы сделали вывод, что я «батрачил». Думаю мне вряд ли пришло бы в голову таким заниматься :).

Хорошая статья, но вы таки трудоголик. С учетом дороги это 11 часов в офисе и 1 час на дорогу. В итоге получилось как в анекдоте если будуте хорошо работать то станете начальником и будете работать еще больше и лучше.

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

В первом видео Арнольд советует спать по 6 часов, спать «немного шустрее». Я думаю что сейчас он так не считает. Этот совет давали раньше, когда не было так понятно насколько важен сон. Я сплю 7-8 часов, а то и больше. И если я сплю 6 часов то работать я могу разве что работу охранника или дворника (несмотря даже на конские дозы кофе и модафинила). И очень жаль что я слушал подобные советы раньше и пытался «вставать на час раньше» не ложась на час раньше, «меньше спать» и т.п.
Тоже могу дать ссылку на интервью Рогана с профессором Беркли на тему сна: www.youtube.com/watch?v=pwaWilO_Pig

Возможно вы из тех, кто может «спать шустрее», но таких немного. Возможно вам кажется, что «раз я могу, то и вы можете». Но это не всегда так, и даже почти никогда не так.

Хотя в целом Арнольд прав, время есть, можно меньше читать ДОУ, меньше писать комментарии, можно... время найти можно, короче говоря.

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

Если пару часов самообразование к работе не относить, то обычный график получается. Другое дело, что иногда сложно разделить «прикольно, надо покрутить, может пригодится» и «это может решить нашу проблему, надо срочно проверить»

Да, иногда приходиться в это время делать разные ресерчи связанные с конкретным проектом. Но все равно оставляйте хотя бы один день на то что прикольно!

Підписатись на коментарі