Чому сервісна компанія — найкраще робоче середовище для більшості інженерів. Руйнуємо міфи про «галери»
Привіт! Мене звати Юрій Рощенко, я відповідаю за Delivery у сервісній компанії Proxet. Дехто скаже, аутсорс — галера, на якій розробникам нудно веслувати, де від кінцевого продукту інженера відділяє нездоланна дистанція, роками одне й те саме.
А я стверджую, що це абсолютно не так, і саме сервісна компанія — найкраще робоче середовище для більшості інженерів.
За понад 20 років роботи саме у сервісних компаніях я отримав різноманітний і багатогранний досвід — наче прожив декілька різних життів і перевтілювався у різні ролі та на різних проєктах. Тому із задоволенням виступлю руйнівником міфів та стереотипів про сервісні компанії.
Иллюстрация Марии Рыбак
Наша робота — програмування, наш результат — код. Міф перший
Багато разів чув від розробників, що їхня робота полягає суто в написанні коду. Принципово не погоджуюся з цим.
За моїми спостереженнями кодування становить не більше як 2/3 роботи Software-інженера. Окрім кодування, треба ще читати й розуміти контекст, вимоги, ставити правильні питання, пропонувати та обговорювати варіанти, інтегрувати свою роботу з роботою інших людей. Проєктування, планування, ознайомлення з готовими рішеннями, врешті-решт R&D і прототипи. А ще документація, тести, зустрічі, демо, естимейти...
Якщо у вас не так, навряд чи вас можна назвати кваліфікованим інженером з погляду сучасної дисципліни промислової розробки. Або ви просто кодер і вас з часом замінять No Code/Low Code системи, або вам байдуже і ви втрачаєте можливості впливати на продукт, або ви просто лінивець і не бажаєте розвиватися.
Weeks of coding save you hours of planning.
Jason Statham, probably
Гребці на галері. Міф другий
Часто сервісну компанію, або аутсорс, уявляють у вигляді галери, на якій поволі веслують гребці, роками прикуті кайданами до одних і тих самих проєктів.
Мені ж ближчий образ сервісної компанії як своєрідного готелю (або інкубатора, якщо бажаєте) для багатьох продуктових компаній та проєктів. Останнім не завжди зручно чи вигідно утримувати постійний штат, тому звертаються по допомогу до професіоналів (проєктна робота) або «поселяються» всередині сервісної, яка може ці послуги надати та стати «хостом». Так з’являються проєкти, навколо них — команда.
Уявіть собі: компанія з США відкриває представництво, у якому 7 співробітників. Це нонсенс, бо з’явиться занадто багато специфіки та різних додаткових витрат. Набагато простіше звернутися до сервісної компанії й облаштувати команду того ж самого розміру. На стороні замовника буде працювати вся адмін-команда, досвід і репутація сервісного партнера.
Для ілюстрації наведу кілька наших проєктів.
- Компанія, яка розробляє одну з найбільших торговельних онлайн-платформ у світі. Це американський єдиноріг у галузі електронної комерції. Компанія купує різноманітні інтернет-магазини, інвестує в них гроші та розвиває. Тут є Java, Python, RoR, Airflow.
- E-commerce компанія — розробник системи телеветеринарії для однієї з найбільших у своїй галузі компаній в США. З початком локдауну власникам тварин стало складніше відвідувати ветеринарні клініки, і наш клієнт вирішив перенести послуги в онлайн — тепер огляд доступний по відеозв’язку. Команда проєкту використовує Java, Node.js, Vue.js, React, платформу OpenVidu.
- Всесвітньо відомий бренд, розробник хостингу анімованих GIF-файлів і системи пошуку та індексації цих зображень за ключовими словами. Для забезпечення більш точного пошуку застосували Machine Learning, а також Python та Scala.
На кожному проєкті свій стек, тому перехід з одного на інший може бути нетривіальною задачею: бізнесу треба знайти заміну «гребцю» і виконати зобов’язання перед клієнтом.
Сервісна компанія як «готель» завжди зацікавлена в тому, щоб надати найякісніший сервіс клієнтам. Останній неможливий без задоволених, розумних, сповнених енергії та ідей працівників, яким цікаво розвиватися у своїх напрямах. Намагатися «прикути» їх кайданами — це зрештою не в інтересах сервісної компанії, а запропонувати project change і провести ротацію — навпаки, реальна можливість. І у нас таких прикладів вистачає.
Один з наших інженерів працював у невеликому стартапі на Java-стеку. Повідомивши компанію, що хоче змінити стек, за декілька місяців перейшов на Python і в ньому теж досяг рівня Senior. Також розробники в нас часто переходять в Data-інжиніринг — це допомагає набагато глибше осягнути бізнес через процеси, стикаючись безпосередньо з його даними.
Треба веслувати, не можна керувати. Міф третій
Основна бізнес-модель сервісних компаній — співпраця з клієнтами. Отже, розвивати можна лише клієнтський продукт, а розробляти власний — прерогатива продуктових компаній.
Цей міф неодноразово руйнували самі розробники, щойно у них з’являлися ідеї та бажання щось зробити.
Якщо розробляємо продукти для інших компаній, чому б нам не спробувати створити його для себе? Адже в нас є бачення ринку, його потреб. Такий підхід повністю відповідає американському вислову «Eating your own dog food» — тобто користуйся власним продуктом чи сервісом.
Так сталося і з нами: ми розвиваємо свої продукти MatchMaster та MatchScout на базі власного рішення Employa. Платформа допомагає спростити етапи рекрутингу завдяки технологіям AI/ML. Система створена для пошуку та збору резюме релевантних кандидатів і дозволяє автоматизувати багато рутинних процесів, а отже зекономити кошти та зусилля. Ми самі користуємося власною системою, а також проводимо пілоти з клієнтами.
Тому сервісна компанія — не щось протилежне продуктовій, а навіть дещо більше. І з точки зору співробітників до досвіду праці на різних проєктах нерідко додається досвід розробки власного продукту з нуля.
Дистанція між продуктом і розробником. Міф четвертий
У продуктовій компанії до продукту рукою сягнути. У сервісній все заплутано: клієнт — Delivery-менеджер — PM — тімлід — технічна команда. Не дивно, що у такому ланцюжку інженеру іноді властиво втрачати відповідальність за продукт. А логіка функціоналу продукту і його розвитку іноді не доходить до інженера або спотворюється у процесі передачі інформації. Отож у певний момент сервісна компанія видається галерею, на якій працюється погано і без зацікавлення. Архітектура, якість коду не важливі, та й загалом нічого значущого немає, якщо не усвідомлюєш, куди й навіщо веслуєш.
Відстань від продукту до технічного виконання в сервісній компанії і справді може бути більша. Щоб наблизити себе до розуміння продукту і бізнесу, всього лише треба: а) захотіти, б) докласти трохи зусиль, щоправда, часто поза межами своїх звичних обов’язків.
Бракує розуміння продукту? Запитай!
Незрозумілі бачення і пріоритети? Запитай!
Не відповідають — нагадай, пропонуй варіанти, ініціюй дискусію. Головне — продуктивну. Ваші колеги теж зайняті люди.
Брак будь-якої інформації можна (і треба!) компенсувати активною комунікацією. І в цьому велика можливість для розвитку і вдосконалення.
Гнучкі методології та робота в невеликих командах сприяють покращенню ситуації.
Я переконаний, що річ не в компанії чи форматі роботи, а у ставленні людей і часто штучних, надуманих обмеженнях. Якщо у вас є бажання спілкуватися прямо з клієнтом, навряд чи менеджери або сам замовник будуть проти. Подзвоніть клієнту та дізнайтеся в нього про бачення продукту, загальну стратегію, користувачів, пріоритети — і ваша робота буде наповнена сенсом, а ви самі навчитеся багато чого і станете співавтором продукту!
Кривавий ентерпрайз. Міф п’ятий
Говоримо «сервісна компанія», маємо на увазі різноманіття клієнтів, в тому числі ентерпрайз. Словосполучення «кривавий ентерпрайз» декому знайоме і може лякати: монструозний проєкт, легасі-код, бюрократизовані процеси, жодного натяку на швидкість ухвалення рішень — певно, найяскравіші недоліки роботи з ентерпрайзом. Це все може сильно виснажувати.
Справді, великі системи потребують великої кількості узгоджень та перевірок. І ентерпрайз завжди передбачає певний рівень формальностей. Однак це абсолютно виправдано, адже від змін у системі можуть залежати навіть життя людей.
Уявімо ситуацію: щось виходить з ладу на продакшені healthcare-платформи. Це торкнеться тисяч пацієнтів, дехто опиниться в черзі, а хтось вчасно не отримає медичної допомоги.
Тож якщо ми дивимось на такий ентерпрайз з позиції відповідальності, ціни помилки, уникнення катастроф, здорового глузду, то кожне рішення має бути зваженим, узгодженим, перевіреним декілька разів, а якість коду відповідати вимогам. А що в цьому поганого? Якби ця відповідальність була на вас, як би ви вчинили?
Водночас в ентерпрайз-проєктах здебільшого достатньо часу та ресурсів для спокійної роботи, досягнення якості, самовдосконалення, вивчення предметної галузі, спілкування з колегами та професійне зростання, а часом і ротації всередині проєкту. Декому з нас потрібно саме це!
Наведені міфи — лише відмовки та обмеження, які ми часто самі створюємо і поширюємо. Відмова від стереотипів, магічного мислення і перехід до критичного і позитивного допоможе багатьом з нас відкрити у сервісних компаніях такий потенціал розвитку і реалізації, який раніше не помічали та про який годі було й думати.
Найкращі коментарі пропустити