Упс! Не вдала спроба:(
Будь ласка, спробуйте ще раз.

Маленька, але потужна: як створити невелику технічну команду, яка замінить пів сотні людей

Сергій Марієха
Сергій Марієха Principal Software Engineer
21 березня 2025 7 хвилин читання

Грамотно підібрати технічний персонал — нелегке завдання. Часом пошуки досвідчених технічних спеціалістів можуть тривати до півроку, особливо якщо проєкт нестандартний для ринку і потребує інноваційних рішень.

Із 2019 по 2021 він керував командою з семи інженерів, і коли прийшов час передавати їхню роботу на іноземну команду в Аргентині — для неї мусили найняти аж 40 інших спеціалістів. Що допомогло побудувати невелику, але ефективну команду — далі по пунктах. 

1. У нас не було розподілення ролей 

Наша команда працювала над створенням нової платформи для VIP-послуги камер спостереження Ring. Нам потрібно було зробити так, щоб зайняті клієнти, які сидять на Wall Street, не отримували 101 сповіщення, коли біля їхнього будинку, наприклад, пробігала білка. Завдання було не з простих — ми з нуля створювали систему, яка б справлялася з великою кількістю запитів, працювала швидко і направляла їх, куди потрібно. 

Команда мала бути максимально гнучкою і швидко реагувати на зміни, а для цього було важливо, щоб кожен інженер розумів всю архітектуру і міг працювати з різними частинами системи. Тому ми вирішили, що не варто шукати окремих спеціалістів для front-end, back-end чи principals ролей. Ми наймали інженерів, які могли б робити все — від налаштування інфраструктури до розробки інтерфейсів. 

Це виявилося ефективним рішенням, бо кожен у команді розумів всю структуру системи і процес роботи. Завдяки цьому ми швидко адаптувалися до змін чи технічних проблем і разом знаходили рішення. Крім того, кожен інженер міг швидко взятися за будь-яку задачу, не чекаючи, поки хтось інший її розгляне. 

2. Ми ставили програмістів у їхнє “природне” середовище 

Підписуйтеся на наші соцмережі

Щоб знайти спеціалістів потрібного рівня, ми створили воронку, яка б привела тільки найкращих. Ми орієнтувалися на досвід і були готові за нього платити. Однак ми не вимагали від кандидатів знання всіх алгоритмів на світі. Просто не вірили, що хтось може комфортно під тиском співбесіди розв’язувати задачі, наприклад, крутити червоно-чорні дерева на папірці.

Тому першим етапом був технічний тест, який був максимально наближений до того, з чим кандидати справлялися б на проєкті. Нам хотілося побачити, як інженер працює в своєму “природному” середовищі, в комфортному для нього темпі. Усі кодять по-різному: хтось слухає музику, хтось п’є чай, хтось може відволіктися на Youtube.

Не всі кандидати добре орієнтуються в теоретичних завданнях під тиском. Часто вони можуть показати себе значно краще, коли їм дають задачу, схожу на реальну роботу. Тому не варто їх зайвий раз залякувати чи ставити в штучні умови — просто дайте їм завдання в комфортному середовищі, і тоді побачите справжній результат. 

Такі технічні завдання давали нам все, що нам було потрібно знати про навички кандидата. Після цього ми просто рухалися далі.

3. Ми не розтягували процес найму на мільйон степів 

Якщо з технічним завданням все було окей, ми запрошували кандидата на співбесіду. І все — це був останній крок. Далі — тільки оффер. Щоправда, інколи співбесіди тривали по дві години. Якщо я бачив, що у кандидата багато досвіду, то за годину, на жаль, не зміг би все обговорити з ним. Для того, щоб обрати людину, здатну працювати зі складним проєктом, потрібно більше часу. Але ми не хотіли затягувати процес на кілька днів, тому одразу попереджали: ось вам водичка, печиво, будемо говорити більше години.

У нас була така стратегія: спочатку ми точково обговорювали досвід кандидата, а потім робили стрибок у глибину цього досвіду, щоб зрозуміти, як він мислить і що реально може зробити. Був один кандидат, який міг напам’ять розповідати, на якій архітектурі виконуються певні процесорні інструкції. 

Виявилося, що час на співбесіду — це дуже хороша інвестиція. Ми робили все максимально спокійно: без допитів, просто говорили з людиною про те, що вона вміє і знає. Так ми й розкопували справжні діаманти.

4. Ми давали можливість робити помилки

Якщо говорити уже не про найм, а про щоденну організацію команди, я думаю, саме це допомагало нам досягати хороших результатів. Оскільки у нас не було чіткого розподілення ролей, кожен міг внести своє бачення і запропонувати своє рішення.По правді, спочатку було нелегко. Були ситуації, де люди палко сперечалися про те, які рішення краще впроваджувати. Ті, чиє рішення “програвало”, могли навіть втратити мотивацію. Тому ми вирішили тестувати пропозиції — знаходили час, щоб запускати їх як прототип, як експеримент на невелику кількість трафіку. 

Виходило, що ми не рубали ідеї одразу на корінні, а аналізували усе. Сідали разом і проговорювали, що спрацювало, що ні, чому так, а не інакше. Так ми давали людині змогу помилитися або, навпаки, довести своє рішення. 

5. Ми пропагували blameless культуру

Для того щоб люди почувалися комфортно, коли помиляються, і не боялися цього робити знову, ми ніколи нікого не звинувачували. Ми не казали: “Вася зробив ось це, через нього все навернулося, і ми втратили гроші та час”.  Та водночас ми пропагували відповідальність: людина, яка пропонувала певне рішення, мала пояснити, чому не вийшло, які висновки ми з цього винесли, та як рухаємося далі. 

Дуже цікаво було спостерігати за командою та розбирати, хто як бере на себе відповідальність. Якщо людина тягнула якесь рішення, але не визнавала цього, ми надавали їй правдивий зворотній зв’язок. Бо попри те, що це була командна робота, всі брали участь в код-рев’ю, в архітектурі, ми розуміли, що кожен несе відповідальність за свою частину роботи.

Підсумки: що справді важливо?

У мене не було якогось конкретного стилю лідерства, який допоміг побудувати сильну команду. Я вважаю, що все повинно будуватися на взаємній повазі та довірі. Тому всі вище зазначені пункти відповідають цим цінностям. Хоча фактично я був техлідом, всі в команді брали активну участь у розробці, плануванні та визначенні фінального стеку. Останнє слово було за мною, але рішення ми приймали колективно. Кожен міг запропонувати свою ідею, і ми йшли тим шляхом, за який голосувала більшість. Команда була талановита, вмотивована; ми створювали таку атмосферу, щоб ці талановиті люди не боялися приносити свої рішення. Тому цей проєкт і вийшло зробити у складі сімох.

Якщо ви хочете поділитися з читачами SPEKA власним досвідом, розповісти свою історію чи опублікувати колонку на важливу для вас тему, долучайтеся. Відтепер ви можете зареєструватися на сайті SPEKA і самостійно опублікувати свій пост.
0
Icon 0

Підписуйтеся на наші соцмережі

Інші матеріали

СЕС для бізнесу: як уникнути помилок на етапі проєктування?

Антон Березинський 25 квітня 2025 09:00

Лайфхаки для українців за кордоном: як легко повернути читання у своє життя

Валерій Старик 2 години тому

Вкрадена Батьківщина: історія загубленого покоління

Валерій Старик 3 години тому

​Рекомендація книги «Sapiens: Людина розумна. Коротка історія людства» Юваля Ноя Харарі

Валерій Старик 2 години тому

Що таке індивідуальна податкова консультація та як її отримати ФОП?

Inna Sharova 25 квітня 2025 15:30