Віктор Богданов
Колись давно я мав нагоду працювати піарником в одній з найбільших та найвідоміших IT-компаній України. Вона мала серед своїх численних клієнтів провідну ecommerce-компанію, що на той час була популярніша за eBay у Швейцарії.
Як маркетолог, я мав робити періодичні інтерв’ю з клієнтами стосовно їх досвіду співпраці з нами та з метою отримання клієнтського кейса. Саме так я зустрівся і познайомився з Філіпом Пероном — людиною, що побудувала та керувала величезною командою програмістів на вищезазначеному швейцарському проєкті.
Філіп – француз, що переїхав до нашої країни для того, щоб майже цілодобово тримати руку на пульсі, мотивувати команду, та гарантовано отримати найкращі результати за ті гроші, що були інвестовані в аутсорсинг.
Потім я пішов з компанії й наші шляхи розійшлися, щоб знову зустрітися вже за інших обставин, багато років потому.
Було цікаво дізнатися, що всі ці роки Філіп жив і працював в нашій країні, перейшов з провідної швейцарської компанії в провідну британську foodtech-компанію, відкрив власний бізнес і успішно інтегрував його в британський консалтинг Evolve з R&D центром в Україні, котрим зараз керує. Але не будемо забігати наперед!
Я поговорив з Філіпом про його досвід життя і праці в Україні, про відмінності наших програмістів і програмістів у Франції та Британії, та багато іншого, і хотів би поділитися найцікавішими епізодами інтерв’ю з читачами Na chasi.
— З чого почалася твоя IT-історія? Як саме ти потрапив у світ програмування?
— Коли мені було 11 років, батьки подарували мені найперший комп’ютер на Різдво. Це був домашній комп’ютер Commodore 64. На той час існували журнали (під назвою Hebdogiciel), що містили сотні й сотні рядків коду, які я міг набирати та зберігати на ньому. Я використовував цей код для створення найбазовіших програм.
Потім був комп’ютерний клуб на базі середньої школи, де я отримав загальне розуміння програмування (маю на увазі всі ці If, then, else, loop, goto (так, це жахливо!), hello world) та почав здобувати нові навички.
Після цього я почав експериментувати з більш складними програмами, використовуючи перший справжній ПК під назвою HP Vectra CS. Саме на ньому я спробував справжнє програмування, розробивши програми з функціями та процедурами, і нарешті, зі складною графікою
Загалом, мій шлях в IT був доволі типовим: спочатку університет, потім – школа ІТ-інженерії в Парижі.
— І як надалі складалася твоя кар’єра та як саме ти потрапив до України?
— Я отримав свою першу роботу в провідній туристичній компанії. Там я глибоко вивчив операційну систему реального часу для основних комп’ютерів від IBM (TPF) та мову Assembler для мікропроцесорів. Це був мій перший офіційний комерційний досвід.
Після цього я приєднався до фінтех-стартапу, де відповідав за бази та експлуатацію даних. Ми отримували дані про різні фондові ринки з потоків у реальному часі, я зберігав їх у базах даних, а потім розробив програму, яка аналізувала їх та забезпечувала автоматичний технічний аналіз.
Ми продавали цей контент вебсайту voila.fr, що в той час був еквівалентом Google у Франції. Він мав кілька розділів, таких як новини, гороскоп, прогноз погоди та фінанси. Коли хтось натискав на діаграму, то міг бачити прогнози фондового ринку. Весь цей зміст базувався на нашій унікальній формулі технічного аналізу.
На жаль, той стартап закрився через брак інвестицій, і я потрапив у щось дещо більш «екзотичне» – індустрію мега-яхт. На той час всі яхти довжиною від 60 до 90-100 метрів вважалися мега-яхтами. Вони мали свої ІТ-потреби, які я допомагав задовольняти: я розробляв програмне забезпечення, яке дозволяло відстежувати всі матеріали, що використовувалися для будівництва яхт, а також під час їх експлуатації. Потім я мав його встановити або на етапі будівництва на корабельнях по всьому світу, або пізніше, коли човни знаходились у морі чи на суші
Я мав приголомшливий досвід круїзу на цих човнах, коли вони плавали по морю. Я просто сідав на яхту із рюкзаком та необхідними речами й проводив там 2-3 дні, оскільки ніколи не знав, коли закінчу свою роботу.
Після цього я приєднався до ricardo.ch, яка на той момент була беззаперечним лідером онлайн торгівлі у Франції. Вони мали науково-дослідний центр на півдні Франції. Мене найняли в основному як адміністратора даних (MS-SQL), але за потреби я також писав код.
Тут я отримав свій перший управлінський досвід. Через три роки, у 2008 році, у мене з’явилася пара розробників, і відтоді моя пристрасть до керування людьми не припиняла зростати.
ricardo — це компанія, яка змусила мене більше розумітись на аутсорсингу, і я отримав власний досвід роботи з українськими розробниками.
Оскільки компанія зростала і процвітала, їм було потрібно більше технічних ресурсів, щоб забезпечити досягнення своїх амбітних цілей.
Однак топменеджмент не хотів інвестувати 100% бюджету компанії на дослідження та розробки у Франції. У 2011 році мені було доручено поїхати в Україну та зустрітися з офшорним постачальником послуг, який найбільше сподобався нашому технічному директору у порівнянні з іншими потенційними провайдерами
Цей технічний директор був молодим, спритним і прагматичним. Він зовсім не боявся аутсорсингу та попросив мене поїхати вивчити можливості в Україні й допомогти йому прийняти остаточне рішення.
Після того, як я відвідав компанію в Україні та поспілкувався з деякими її розробниками, я був вражений їх пристрастю, відкритою душею та готовністю бути реальними вкладниками в успіх проєкту. Мені дуже сподобався цей дух, я розказав про це своєму начальнику, і ми вирішили рухатися вперед з командою розробки в Україні.
У вересні 2011 року я почав щотижня їздити із Франції в Україну та навпаки, доки не було прийнято рішення переселити мене тимчасово в Україну для тісної співпраці з командою. Але як ми знаємо, немає нічого більш постійного ніж щось тимчасове.
Я створював команду з нуля між 2011 і 2014 роками й збільшив її до 35 спеціалістів, до складу яких входили розробники .Net, JavaScript, BI та QA, а також мобільні розробники
У 2014 році відбулася зміна керівництва. Новий технічний директор не настільки підтримував аутсорсинг і фокусувався на іншій стратегії. Тож невдовзі ми попрощалися один з одним.
У той період я випадково зустрів директора Just Eat, провідної британської FoodTech-компанії, яка мала свою розширену команду в Україні з тим же провайдером. Врешті-решт він запросив мене приєднатися до їхньої компанії на тій самій посаді, що і в ricardo.
Я погодився, однак цього разу все було інакше, оскільки Just Eat мав іншу мету аутсорсингу. Я успадкував команду з 25 професіоналами, і саме так розпочалася моя фантастична подорож з Just Eat
Компанія планувала збільшити свою українську команду, а також відкрити третій центр розробки ПЗ в Бристолі як доповнення до основної команди, що базується в Лондоні. Це відбувалося приблизно з кінця 2014 року до початку 2015 року і спричинило певні корективи між різними локаціями. Після Революції Гідності Україну розглядали як нестабільну країну, тому збалансування ризиків та впливів було правильним, особливо в період виходу Just Eat на біржу у 2014 році.
До 2018 року моїми зусиллями українська команда Just Eat збільшилась до більш ніж 85 осіб.
Потім в мене був свій невеликий бізнес, який я успішно інтегрував у британську консалтингову компанію Evolve-IT Consulting, де я зараз обіймаю посади Chief Delivery Officer та Managing Director.
— Ти давно працюєш в українському IT-аутсорсингу. В чому взагалі сенс для західних компаній будувати команди в Україні?
— Коли я працював у Франції менеджером IT-проєктів, то завжди стикався з однією і тією ж проблемою — швидкість найму була повільною, вартість ресурсів була великою. Ба більше, Франція має конкретну практику, якої потрібно дотримуватися, щоб відповідати трудовому законодавству країни.
Наприклад, якщо ви наймаєте когось, хто пройшов випробувальний термін, звільнити його буде майже неможливо, якщо пізніше ви дізнаєтесь, що ця людина не підходить вашому проєкту або не відповідає вашим очікуванням. У більшості випадків доводиться виплачувати заробітну плату працівникові протягом кількох місяців після звільнення.
А що, якщо ваша компанія переживає період фінансової турбулентності? Або ви знаєте, що конкуренти створюють схожий продукт і вам вщент потрібно вивести його на ринок якомога швидше, але найняття програмістів таке повільне, що ви місяцями не можете зворушитися з міста.
Це створює величезний ризик і додає серйозні обмеження навіть для найнадійніших компаній
Я не маю на увазі, що добре, коли можна швидко звільнити когось в середині проєкту. Зовсім ні! Однак, ви повинні мати трохи гнучкості й мати змогу швидко замінити недостатньо ефективний ресурс або перерозподілити свої ІТ-витрати, коли це потрібно. У Франції це майже неможливо.
Інша перевага — це, звісно, вартість ресурсів. Вартість приватного підприємця в Україні становить від 30% до 50% нижче, ніж вартість підрядника у Великій Британії чи Франції
З точки зору керівництва західних компаній, розширена команда розглядається як органічне продовження внутрішньої команди й до неї ставляться так само. Саме тому багато українських айтішників вмотивовані вивчати англійську мову, щоб мати змогу працювати напряму з замовником у розподіленій команді. Їм подобається ставлення з боку іноземних замовників, «плюшки», пов’язані з роботою, можливість мати подорожі в країну клієнта з метою обміну знаннями, відвідувати оффлайн-івенти тощо.
— А щодо якості українських розробників у порівнянні з Францією чи Великою Британією?
— Це гарне запитання. Справа не в якості, а більше в зрілості, і зрілість – це складна тема. В Україні програмісти не такі «балакучі», як у Франції, але вони добре знаються на своєму. Ви можете покластися на них, і вони проявлять ініціативу, якщо будуть належним чином уповноважені та/або навчені керівництвом. Вони не вважатимуть свою роботу виконаною, просто обробляючи задачі. Їм потрібен реальний результат.
Українські програмісти прагнуть постійно вдосконалюватися, інвестуючи у свої інженерні навички та технічний досвід, щоб сприяти успіху проєкту. Таким чином, вони схожі на британських інженерів, за винятком того, що британські програмісти часто поводять себе зверхньо та обожнюють створювати хайп навколо себе
Іноді важко отримати прозорі відгуки через вашу значну повагу до так званої ієрархії. Це явна культурна різниця, наприклад, з Францією. Будь-який фідбек – безпрограшна ситуація, оскільки вона допомагає кожному покращитися, хоча іноді вам доведеться трохи забути про своє его.
— Ти мав нагоду працювати з agile-командами на боці замовника й на боці провайдера послуг. То в чому секрет успішної командної роботи?
— Розширена модель команди передбачає, що на певному етапі (при досягненні певного розміру команди) наймання «місцевого органу влади» (тобто менеджера ділянки, tech lead) є ключовим фактором управління та координації роботи команди. Дійсно, віддалена співпраця покладається на надійність віртуальних мостів, які ви будуєте у різних локаціях. Усунення відстані та перешкод між розподіленими командами є одним із найважливіших аспектів.
Як клієнт, ви є головним фактором впливу, драйвером та мотиватором. Ви, а не ваш технічний партнер! Тому вам потрібно додати зусиль, аби зробити віддалену команду частиною вашої корпоративної ДНК. Тільки в цьому випадку ви отримаєте очікувану якість продукту
Як провайдер аутсорсингу, ви повинні переконатися, що у вас є достатня кількість внутрішніх можливостей для підключення віддаленої команди до корпоративної культури та середовища клієнта загалом.
Як би дивно це не звучало, але дуже часто компанії, що потерпають від інтеграції віддаленої команди у внутрішню (in-house), усвідомлюють, що вони не мають ніякої корпоративної культури, або що проблеми, які вони мають з віддаленою командою, показують наявні внутрішні проблеми компанії.
— А як уникнути невдачі?
— Це залежить від того, чого ви намагаєтесь досягти. Якщо у вас є довготривала потреба, саме тоді вам потрібно подумати про зусилля, які потрібно буде вкласти у свою розширену команду, щоб досягти успіху. Тут немає дива. І я тут не про гроші. Ви можете мати багато грошей, але в підсумку матимете повне фіаско.
Потрібно переконатись, що ваш технічний партнер, що керуватиме вашою проєктною командою, розуміє вашу культуру, оскільки це має вирішальне значення для успіху вашої команди
На жаль, ваша віддалена команда може бути досить стійкою до того, що може сприйматися як загроза або недобросовісна конкуренція. Чесне і прозоре спілкування керівництва на цю тему (реальні причини, плани) є обов’язковим для успішної співпраці команд.
Перш ніж вирушати в проєктну подорож з командою, ви повинні бути готові пережити кілька болючих моментів: від того, що щось пішло не так із найняттям до необхідності звільняти когось по дорозі.
Усі ці моменти слід передбачити та чітко обговорити зі своїм технічним партнером
Будьте зосередженими та наполегливими, будьте справедливими, підтримуйте та не дозволяйте ніяким стінам розділяти ваші команди. Зв’язок – це цемент, який створює міцний фундамент. Розгляньте свою розподілену чи віддалену ІТ-організацію як продукт. Як і будь-який продукт, ви його будуєте, перевіряєте та адаптуєте.
Якщо ви стартап і маєте кошти лише на створення свого першого MVP, і у вас на це є менш ніж пів року, ви не можете мати довгострокову дорожню карту через фінансову незрозумілість. Але вам потрібно десь починати. Таким чином, ви можете залучити стороннього постачальника для розробки MVP, а пізніше, коли ви отримаєте більше фінансування, ви зможете перетворити віддалену команду на свою постійну команду або успішно інтегрувати її у внутрішнє корпоративне середовище.