Yev Rachkovan
Публікація може бути опублікована виключно на комерційній основі. Для комерційної співпраці звертайтеся до [email protected]
Коли я прийшов у Scrimmage, там вже була команда з 3 інженерів. Всі вони були “дешевими” розробниками з таких країн, як Індія та Пакистан. На додаток до цього, вони були початківцями, тож продукт був у важкому становищі. Я приїхав з місця, де чистота коду була пріоритетом №1, і без ретельного рефакторингу ви не могли навіть відправити свій код на віддалений сервер. Тут же всі писали код в єдиній master-гілці без ревью, без лінтерів і без архітектури. На додаток до цього вони використовували банальний JS, який змушував мене плакати знову і знову, коли я бачив функції з 10 параметрами і не мав жодного уявлення про те, що ці параметри означають.
Коли я став технічним директором, всі вже розуміли, що прийдуть зміни. Спочатку я прагнув, щоб усе працювало так, як є. Я почав додавати більше структури в розробку, впроваджувати рецензування, лайнери. Але потім я помітив, що недостатньо просто дати інструментарій, потрібно, щоб люди щиро вірили в нього і знали, як ним користуватися. Я почав говорити з кожним членом команди в режимі 1 на 1 про те, що вони повинні почати вивчати чистий код і купу інших ресурсів, які я їм надсилаю. Для мене було звичайною практикою витрачати 2-3 години на день на вивчення нових технологій, але я знав, що це далеко не кожен може собі дозволити, тому мені було трохи дискомфортно просити про це. Дійшло до того, що я навіть запропонував платити за час, який вони витрачають на вивчення цих технологій, тому що вигода від цього була для мене очевидною.
Після 3 місяців намагань я зрозумів, що тепер я витрачаю більшу частину часу на спілкування з людьми, перегляд коду та виправлення помилок, ніж на власне його написання. Час летів непомітно, а якість коду практично не покращувалася. Так я дійшов висновку, що іноді краще бути самому, ніж у команді з 3 джунів. Я сприймаю себе як ще одного хлопця у вашій команді, у якого теж є власне життя, власні проблеми. Іноді я також втомлююся, іноді я дуже вмотивований, іноді щасливий. Зрештою, я будую міцний зв’язок з командою і формую лояльність, що є кінцевою метою мого управлінського підходу.
Перевага такого підходу полягає в тому, що працювати легко. Ти можеш сказати мені все, що хочеш, і ніколи не почуєш докорів чи холодної відповіді. Однак є й недоліки… Я дуже прив’язуюся до людей, з якими працюю, і коли приходить час звільняти, це все ускладнює. Я пам’ятаю коли вперше довелось когось звільняти. Я взяв навіть вихідний, щоб заспокоїти свої емоції і переконати себе, що прийняв правильне рішення.
Зрештою, я звільнив усіх, окрім одного фронт енд розробника, який допомагав мені з елементарною дизайнерською роботою. Працювати стало набагато краще, тепер я мав повний контроль над кодом і міг змусити проект рухатися швидше, ніж він робив це раніше, що мене здивувало. Як висновок: більша кількість інженерів не завжди дорівнює більшому прогресу.
У пошуках нового інженера
Я знав, що у нас є достатньо фінансів для ще одного інженера, але я не хотів наймати когось з досвідом меншим, ніж у мене. І я знав одну таку людину. Це був хлопчина, з яким я познайомився на попередній роботі. Ми пропрацювали з ним близько 2 місяців, але він вразив мене своєю чесністю та відданістю справі. Найбільш разючим фактом було те, що він програмував у свій вільний час. Він також був найкращим інженером, якого я коли-небудь знав, тому я наполегливо за ним ганявся. Щомісяця я писав йому, чи не шукає він новий проект, і таки отримав задовільну відповідь. На той момент мої співзасновники вже були певні, що він дійсно відповідає критерію «ціна-якість», тож решта – це була лише моя розмова з ним.
Це був найбільш незграбний дзвінок, який у мене коли-небудь був, тому що зазвичай ти не знаєш людину, яку наймаєш, але тут ми знали один одного до певної міри. Я намагався позиціювати Scrimmage як потенційно великий стартап з моєю чудовою командою. Моя довіра до нього змусила мене сказати, що наш код – фігня, а наш другий розробник – джуніор, що ледь не змусило його відкинути пропозицію, лол. Не кажіть інженерам, що ваш код – це фігня на першій зустрічі, ніколи)
Зрештою, він попросив більшу зарплату, я довго сумнівався, але таки погодився. Це був час великих змін для технічної команди Scrimmage, тому що цей хлопець змінив все. У мене були високі стандарти написання коду, а в нього вони були до неможливості високі. Я навіть вирішив переписати весь код після того, як він став членом команди.
2 місяці збігли швидко, і ми домоглися чималого прогресу у написанні коду. На той момент ми намагалися змусити працювати команду із трьох осіб, включаючи молодшого фронт енд розробника. Щоб змусити його працювати, ми запровадили жорсткі лінчери, суворе управління проектами та подвійну верифікацію коду, але врешті-решт, ми його звільнили. Нас лишилося лише двоє, і це був переломний момент в історії компанії. Під час проходження Techstars компанія вирішила зробити акцент на web3-продукті. Це був наш шанс переробити весь застарілий код і впровадити нову архітектуру з абстракціями і типами.
Я не думаю, що коли-небудь зробив би це без нього. Я був хлопцем, який був створений для того, щоб бути засновником. Я вкладаю свій час у все, включаючи маркетинг, продукт, бізнес, дизайн тощо. Він був хлопцем, який був створений для того, щоб бути технічним лідером. Він інвестує весь свій час у вивчення нових технологій та принципів програмування. Коли у нього з’являється натхнення, він організовує невеликі хакатони на вихідних. У понеділок я пишу йому з питанням “Як пройшли твої вихідні?”, очікуючи відповіді на кшталт “Добре, добре виспався і пограв у кілька ігор”. Натомість отримую відповідь на кшталт “Добре, написав модель ШІ, яка може класифікувати, хто виграв гру за скріншотом”. Коли ви чуєте таке від когось, незалежно від того, що у вас є зараз, зробіть так, щоб ця людина співпрацювала з вами.
Якщо хтось готовий витрачати свій вільний час на навчання або на те, чим займається під час роботи – це найбільша ознака мислення, спрямованого на розвиток, і пристрасті до того, що він робить. З таких людей виходять чудові кофаундери, і саме така людина має бути вашим першим найманим працівником. Перші 3 людини, яких ви наймете, сформують атмосферу у вашій команді на все подальше майбутнє. Не наймайте людей, які не є надійними та відданими своїй справі. Навіть одна така людина у команді може зруйнувати цілу систему.
Підсумки
Коли Scrimmage тільки почав розвиватися, більшість девелоперів не горіли бажанням до своєї справи, і це були не найперспективніші часи. В процесі ми знайшли тих людей, яким можна довіряти, і які вкладали душу у створення нашої культури. І мій перший найманий працівник зробив найбільший внесок у це. Потім були другий і третій, які прийшли на вже сформований ґрунт корпоративної культури та архітектури програмного забезпечення. Стандарти якості, відданість справі та культура зростання – це не те, чого ми хочемо досягти, це вже частина нас і частина кожного нового працівника, який приєднується до нашої команди.