Як обрати оптимальний стек та побудувати команду для Embedded продукту: досвід Head of Software Development Department у PocketBook

Дивитись детальніше

Вибір архітектури проєкту і стеку розробки — це одне з найхардовіших завдань IT-фахівця та менеджера. Потрібно враховувати сферу застосування, бюджет, можливості масштабування та багато іншого. Цьому не навчать на інтенсиві по розробці, а помилки коштують сотні тисяч доларів…

Саме тому ми запускаємо у блозі нову рубрику, де ділитимемося досвідом Head та CTO технічних відділів IT-компаній. Ми розповімо про їхню експертизу, що таке стек технологій з точки зору роботи компанії, поділимося порадами про те, як краще побудувати процеси в команді та найманні, а також познайомимо вас з різними продуктами. І вже готові поділитись першим інтерв’ю!

Що за компанія? PocketBook — міжнародна компанія у сфері e-book з українським корінням. Вона входить до топ-3 виробників електронних книг та супутньої інфраструктури (від онлайн-магазину до додаткових аксесуарів). Вже продано мільйони пристроїв у всьому світі.

А з ким інтерв’ю? Андрій Каляка — Head of Software Development Department, який вже понад 11 років допомагає створювати та розвивати продукти в PocketBook. До роботи в цій компанії він працював у сферах телекомунікацій, білінгу та мережевих технологій. У PocketBook пройшов шлях від PM до керівника відділу розробки, брав активну участь у прийнятті архітектурних рішень.

Як ви обрали поточний стек для вашого продукту?

Я брав участь у виборі архітектури і стеків розробки наших проєктів ще багато років тому. Звичайно, за цей час багато що змінилося і у виборі технологій, і в самих процесах. Наприклад, зараз ми дійшли світових стандартів SDLC, сучасних принципів розробки (використовуємо CI інструменти). Зараз ми близькі до ідеального стану процесів, наскільки це можливо на реальному продукті.

Але раніше ми присвятили цьому безліч часу та обговорень у команді, щоб прийти до єдиного рішення. Ми враховували особливості роботи з нашим обладнанням (електронні книги), необхідність забезпечити кросплатформність та додати конкурентних переваг нашим продуктам.

Поточний технічний стек нашого проєкту має такий вигляд: C++, Qt, QML. Звісно, кандидати, які подаються на вакансії, також мають розуміти і супутні технології: бази даних, мати досвід роботи з криптографією, мережами, багатопотоковістю.

Що вплинуло на вибір технологій у вашому проєкті? Чому приділяли особливу увагу?

При виборі стека систем ми орієнтувалися на те, щоб оптимізувати код на мобільній платформі. Загалом для нас були критичними три принципи:

• швидкодія,
• енергоефективність (у PocketBook кращі показники e-book щодо енергоефективності та тривалості роботи на одному заряді батареї у сфері),
• кросплатформність.

Як нам це вдалося? Ми уникали зайвих надбудов над ядром Linux у пристроях для читання. Без зайвої скромності скажу, що нашу розробку можна назвати окремою операційною системою PocketBook на базі Linux, тоді як конкуренти найчастіше обирають рішення на Android.

Серед можливих мінусів лише те, що відносно нові електронні читалки на базі Android можуть залучати користувачів тим, що можна легко завантажити стороннє ПЗ на пристрої. Однак такі рішення сильно здорожчають продукти в зв’язку необхідністю використання більш потужної апаратної спеціфікації та зменшують автономність.

Які технології ви плануєте запровадити?

Ми постійно займаємося ресерчем нових ринків і ніш для застосування E-Ink екранів (електронний папір). У нас є колосальний досвід у цій сфері і ми плануємо розширювати спектр наших продуктів, створюючи не тільки електронні книги.

З того, що можу розкрити: планується залучити до лінійки наших продуктів пристрої eNotes з великим розміром E-Ink екранів та використанням Android OS. Також ми зараз досліджуємо нові напрямки, в яких E-Ink екрани були б доречними та зручними.

Дивитись детальніше

Який поточний склад та структура вашої команди?

У моєму департаменті 30 осіб. 70–80% із них — сініорні Embedded та Application програмісти, кілька Middle, які виросли у нашій компанії. Поки ми призупинили наймання джуніорів, оскільки орієнтовані на максимально швидкі рішення з розробки. Також у нашій команді є декілька ID, UI/UX дизайнерів, Hardware Developers, Technical Writers, DevOps та QA Engineers.

Як побудований рекрутинг-процес у вашу команду?

З кандидатами ми проходимо такими стандартними етапами:

• Інтро-дзвінок (до 30 хвилин) — на ньому я розповідаю про поточні та нові проєкти, про наш стек технологій. Зазвичай це на 99% покриває всі основні запитання розробників. На цьому дзвінку я «продаю» можливість попрацювати над відомим продуктом на довгостроковому проєкті.
• Тестове завдання (до 5 годин) — допомагає перевірити, наскільки професійним і ефективним є код кандидата за певними крітеріями. Ми звертаємо увагу на якість коду та використання сучасних підходів. Кожного кандидата ми запрошуємо на наступний етап, щоб обговорити технічні питання на прикладі складових виконаного ТЗ на тех. співбесіді. Був буквально лише декілька кейсів, коли кандидатам відмовили у подальшому спілкуванні за якістю коду.
• Технічна співбесіда — ще ближче знайомимося з кандидатом, обговорюємо результати тестового, перевіряємо знання C++ на практичних прикладах.
• Офер.

Дивитись детальніше

На що звертаєте увагу першою чергою: soft skills VS hard skills?

Тут немає правильної відповіді. Я однаково приділяю увагу і тому, і іншому. У нас високі вимоги до знань та сініорності кандидатів, тому ми ретельно проходимося з кожним кандидатом по його hard skills.

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

Чому IT-фахівці хочуть працювати з вами та залишаються в компанії на роки?

Кандидатів приваблює те, що можна довго працювати над одним продуктом, бачити результат своєї роботи та позитивний фідбек користувачів. Це не конвеєрний підхід, коли треба здати проєкт та забути про нього після релізу. Ще неодноразово чув, що IT-фахівцям імпонує те, що плоди своєї праці можна побачити в магазинах в Україні та по всьому світу, почути відгуки реальних користувачів. Бути частиною міжнародної компанії — додаткова цінність.

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

До війни ми також часто вибиралися на тімбілдінги та корпоративи, разом проводили свята. Зараз такі активності, на жаль, призупинено. Але те, що не можна «поставити на холд» — кількість спілкування, допомоги та взаємопідтримки, які задають атмосферу в команді.

БЛІЦ-ЗАПИТАННЯ

Що у резюме/відповідях спеціаліста для вас точно червоний маркер?

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

Яка мінімальна кількість резюме потрібна, щоб закрити технічну позицію у вашій команді?

У команді ми намагаємося дотримуватись правила «трьох резюме». Ми стараємося поспілкуватися хоча б з кількома кандидатами, щоб об’єктивніше порівняти їх між собою та ухвалити рішення. Але зовсім недавно був кейс-виключення з ITExpert — перший кандидат на позицію отримав і прийняв офер, це було пряме влучення.

Якби ви не займалися розробкою, ким би хотіли стати?

Чесно кажучи, навіть не думав. Тоді як мої однолітки мріяли стати космонавтами, мене вже у дитинстві приваблювали технології та створення нових речей. Тому я саме там, де б і хотів бути.