Як я працюю: Роман Шрамков, 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. Її зона відповідальності — підказувати колегам, як правильно застосувати інновації під завдання клієнта в кожному конкретному проекті. Це творчий виклик, і мені цікаво розібратися, як правильно вибудувати процеси такого рівня.

Опубліковано: 19/02/19 @ 11:00
Розділ Різне

Рекомендуємо:

Чим незадоволені українські програмісти? Глас народу 2018
Можна просунути в ТОП магазин з вузьким асортиментом?
Python дайджест #19: Pandas припиняє підтримку Python 2.7
З чого почати роботу з ML і DL. Огляд кращих бібліотек
Кириличний домен або домен на латиниці – що краще для SEO