Підбір IT персоналу при формуванні команди з розробки: ключові гравці

Рубрика:
Підбір IT персоналу
||
Підбір IT персоналу при формуванні команди з розробки: ключові гравці

Сьогодні ми продовжимо тему, яку розпочали у попередній публікації. Розглянемо яким чином різні методології управління відображаються на рівні структури команди, що безсумнівно повинно вплинути на підбір IT персоналу для проекту.

Підбір IT персоналу при формуванні командиМинулого разу ми говорили про фактори які впливають на формування команди. Читайте детальніше за посиланням:

ПІДБІР IT ПЕРСОНАЛУ ПРИ ФОРМУВАННІ КОМАНДИ З РОЗРОБКИ: КЛЮЧОВІ ФАКТОРИ
Концепція Waterfall

Традиційна концепція (Waterfall, або методологія водоспаду) заснована на чітко визначеній ієрархії в команді, де процес розробки продукту здійснюється лінійно, крок за кроком, як водоспад. Кожен етап процесу розробки продовжує попередній і не може бути запущений, якщо попередній не завершено. Склад команди в підході Waterfall – це типова структура команди розробників програмного забезпечення, яка складається з розробників, тестувальників, аналітиків та менеджерів. Кожен має певну роль і несе за неї повну відповідальність. Кожен етап точно спланований, і команда розробників дотримується цього плану, оскільки цей підхід не передбачає жодних змін або модифікацій після складання технічного завдання.

Цей підхід добре підходить для проектів із чітко визначеними межами та вимогами. Немає обмежень щодо розміру команди, але ось які ключові ролі організаційної структури програмного проекту в методології Waterfall.

Роль менеджера

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

Дизайнер

Дизайнер — це креативний спеціаліст, який займається User eXperience (UX) — візуалізацією продукту та User Interaction — взаємодією з користувачем (UI). UX-дизайн — це один з основних етапів розробки продукту, який включає досвід, який користувач отримує під час взаємодії з продуктом. Дизайн інтерфейсу користувача (UI) – це візуалізація UX-дизайну. Дизайнер інтерфейсу має справу з формами, кольорами, іконками, картинками тощо. Їхнє головне завдання — зробити інтерфейс привабливим та зручним для користувача. Зазвичай дизайнери UI та UX працюють у тандемі, хоча це може бути один спеціаліст. Знову ж, ми тут чітко бачимо, що підбір IT-персоналу, його якісне виконання, важко переоцінити.

Розробник програмного забезпечення

Розробник програмного забезпечення — це «чарівник» продукту — інженер, який фактично кодує веб-сайт або додаток. Той, хто створює видиму частину веб-сайту або програми для користувача, є Front-End розробником. Вони також гарантують, що веб-сайт добре працює на будь-якому пристрої (комп’ютері, смартфоні чи планшеті) чи операційній системі. Back-End розробник працює з внутрішнім вмістом системи та сервера, іншими словами, з усім, що користувач не може побачити. А наступним етапом після кодування є тестування, де в справу вступає інший фахівець – тестувальник продукту.

Гарантія якості

Основне завдання QA – протестувати продукт і переконатися, що все працює правильно. Фахівці з контролю якості не лише виявляють помилки, але й перевіряють, чи відповідає асортимент продукції встановленим вимогам. Коли впроваджуються нові функції, до процесу також бере участь інженер із забезпечення якості. Його відповідальність — написати автоматизований сценарій, який перевірятиме продукт, відображаючи поведінку користувачів.

waterfall vs agile
Концепція Agile

Методологія Agile управління є протилежністю Waterfall. Цей метод заснований на принципі самоуправління без певного лідера. Таким чином, члени команди можуть самостійно розставляти пріоритети та організовувати свою роботу, маючи більш демократичну структуру команди. Ролі є міжфункціональними, тому ІТ-спеціалісти несуть спільну відповідальність за кінцевий результат, допомагаючи один одному та працюючи за межами своєї компетенції. Таким чином, команди, як правило, є невеликими, з 6-9 учасників, що сприяє швидкій синхронізації та співпраці. Ще один важливий момент: Agile набагато гнучкіший, ніж Waterfall. Для Agile-команд важливіше реагувати на зміни та залишатися гнучкими, ніж дотримуватися початкового плану. Такий підхід дозволяє частіше спілкуватися з клієнтом або користувачами, а отже, і частішим зворотним зв’язком. Agile має більш сучасну структуру команди розробників програмного забезпечення , ця методологія виділяє такі ключові ролі.

Менеджер з продукту

Це фахівець, який гарантує, що продукт задовольняє потреби користувачів і досягає цілей компанії. Менеджер з продукту відповідає за аналіз ринку, політику портфеля продуктів, просування, визначення пріоритетів функцій і планування KPI. У Agile цю роль можна визначити як лідера продукту, який співпрацює з командою розробників, щоб допомогти реалізувати нові функції та вивести продукт на ринок.

Керівник команди

У Agile-команді цю роль можна описати як службовець керуючої ланки. Головна відповідальність – направляти команду та підтримувати її. З технічної точки зору, керівник команди також розподіляє навантаження між розробниками та має переконатися, що робочий процес проходить добре. Ця позиція також передбачає підвищення мотивації команди та відстеження їхньої діяльності.

Інженери програмного забезпечення, дизайнери, тестувальники

Це основні члени команди, які безпосередньо беруть участь у процесі веб-розробки. Команда складається з розробників програмного забезпечення, інженерів із забезпечення якості, UX/UI дизайнерів та інших спеціалістів. На відміну від концепції Waterfall, спеціалісти з технологій Agile не мають певних ролей, тому всі несуть однакову відповідальність за кінцевий продукт.

Типовий приклад структури команди розробників програмного забезпечення

На основі методології Agile деякі технологічні компанії використовують Scrum – гнучкий підхід до розробки. Його організаційна структура команди розробників програмного забезпечення (як у Agile) передбачає три ключові ролі: менеджер з продукту, scrum-майстер і сама команда розробників. Дотримуючись принципів Agile, Scrum — це підхід, завдяки якому ця методологія працює. Процес розробки підрозділяється на спринти. Це відрізки часу від тижня до місяця. Команда розробників має вирішувати, як довго триватиме спринт і які завдання вони хочуть виконати в цьому спринті. Як тільки спринт закінчується, команда обговорює його результати і починає новий спринт. Давайте подивимося на приклад нижче.

Sift — американська ІТ-компанія, яка створює власні продукти для цифрової довіри та безпеки. Її рішення допомагають великим компаніям відстежувати незаконні дії, різні шахрайства. Через швидкий розвиток Sift вирішив найняти  спеціальну команду розробників в Україні. Українські хедхантери подбали про підбір IT персоналу, щоб найняти технічних спеціалістів із рідкісними навичками. В результаті 17 технічних спеціалістів для Sift були найняті менше ніж за рік, і в результаті бос отримав свою неповторну команду спеціалістів. Компанія використовує Scrum із 2-тижневими спринтами, а її українські інженери програмного забезпечення працюють у різних командах, які відповідають за різні сфери розробки продуктів. Таким чином, 5 старших бек-енд розробників розширили свою команду API, а інші розробники бек- та фронт-енду приєдналися до основної команди розробників продуктів. IT-рекрутерам вдалося не лише забезпечити пошук розробників, а й талановитих продуктових дизайнерів, інженерів інфраструктури, закрити посаду керівника відділу програмної інженерії.

Останні думки

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

За матеріалами https://alcor-bpo.com

Метки:

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Заполните поле
Заполните поле
Пожалуйста, введите корректный адрес email.
Вы должны согласиться с условиями для продолжения

Меню