«Щоб рейки зійшлися в одній точці»: 8 ключових ролей у команді розробки

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

Склад IT-команди залежить від проєкту, його складності, цілей та темпів росту. Але є «стандартний набір», якого частіше за все достатньо для створення продукту і його запуску на ринок.

Що це за ключові ролі у команді розробки, які обов’язки вони передбачають і чому їх не варто ігнорувати — розібралися з Миколою Клєстовим, co-founder та CTO у ITExpert. Він має понад шість років досвіду у підборі персоналу на менеджерські позиції в топові IT-компанії України. Микола консультував та допомагав закривати кандидатів на керівні позиції для таких клієнтів, як Нафтогаз, Райффайзен Банк, Parimatch, а також в інші продуктові та аутсорсингові компанії.

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

Команда розробників проєкту VS група зі спільними інтересами: у чому різниця

За словами CTO ITExpert, у ідеальному світі група програмістів зі спільними інтересами могли б розробити продукт самостійно. Це популяризує Scrum, та й звучить логічно незалежно від методології. Але ми не живемо в ідеальному світі, тому потрібні менеджерські ролі, які допоможуть моніторити процеси та спрямовувати технічну команду.

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

Ролі в IT-проєкті VS посади: чи є відмінність

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

Основні ролі у команді розробників

Technical-ролі полягають у правильному виборі архітектури, технологій та інструментів — все для того, щоб продукт відповідав заявленим цілям з технічного боку.

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

Обов’язки розробника

Роль розробника — обов’язкова в IT-команді, але кількість та необхідність в експертизі девелоперів залежать від:

• складності рішення (чим вона вища — тим більше фахівців рівня Middle+ найчастіше потрібно);
• стеку технологій.

Наприклад, просту програму або сервіс може розробити один девелопер на кросплатформових фреймворках на зразок Flutter або React Native. Якщо команда створює продукт для iOS та Android, потрібно залучати фахівців з відповідними скілами: розробники SWIFT/Objective-C, Java/Kotlin та інші. Для створення бекенду продукту потрібні backend-девелопери, наприклад, Node.js, Python або .NET-розробники.

Обов’язки QA (Manual і Automation тестувальники)

Цей спеціаліст перевіряє продукт на наявність багів (помилок), тестує User Scenario, допомагає забезпечувати відповідність продукту техзавданню та безвідмовну роботу на різних пристроях.

QA Automation інженер відрізняється від Manual (ручного) тестувальника тим, що останній не пише автотести. Йому потрібно вручну повторювати тести для певного функціоналу або UI, який може бути «слабкою ланкою». Крім того, QA Manual Engineer не може перевірити деякі властивості продукту: зробити тестування навантаження, щоб зрозуміти, чи витримає він наплив мільйона користувачів.

QA Automation фахівець повинен розумітися на особливостях розробки, вміти програмувати, а також:

• володіти базовими знаннями технологій та мов програмування;
• вміти працювати із системою контролю версій (Git).

Є думка, що вище рівень технічної команди, тим менше потреба у ролі QA у процесі розробки ПЗ. В основному досвідчені розробники припускаються менше помилок, покривають код unit-тестами, самі можуть розібратися та усунути баги.

Обов’язки UI/UX дизайнера

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

Якщо команда також виводить продукт на ринок або масштабує його, у команді можуть з’явитися такі ролі:

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

Головний челлендж у роботі дизайнера — зробити так, щоб продукт сподобався і замовнику, і користувачам. UI/UX дизайнер повинен вміти досліджувати психологію поведінки користувачів, а також застосовувати результати тестування у дизайні: будувати CJM, виділяти інсайти після jobs-to-be-done інтерв’ю та формувати персони. До списку обов’язків також входить проєктування деталей дизайну — від нотифікацій до помилок та звуків.

Крім технічних навичок у UI/UX дизайнера мають бути критичне мислення, смак та наламане око. А ще — вміння співпрацювати. Дизайнер може не знати всіх технічних чи бізнес-аспектів продукту. Щоб дизайн вийшов хорошим, потрібні знання та експертиза всієї команди.

Ролі у координації команди: Project Manager і Scrum Master

Гілка координації у структурі IT-команди — це люди, які допомагають розробникам рухатися в одному напрямку, ділити між собою завдання так, щоб командна робота була максимально ефективною.

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

Обов’язки Project Manager

Один беклог, 100 тасків та сім розробників — щоб уникнути пожежі в такому режимі, Project-менеджер визначає, яка методологія підійде проєкту, як пріоритизувати завдання та допомогти команді досягти потрібного результату. Він несе відповідальність за проєкт, команду та ризики. Важливо: у класичному скрамі немає позиції Project Manager.

Вибір правильної методології координації команди (наприклад, Scrum, Kanban або Waterfall) — половина успіху проєкту та роботи спеціаліста. 50%, що залишилися, — організація автономної роботи в команді, налагодження комунікації між стейкхолдерами, планування змін і термінів за допомогою методологій PMI, PMBOK або PRINCE2.

А що ще? PM у команді розробки:

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

Основні ризики у project-менеджменті — зірвати терміни, не вкластися до бюджету та не набрати потрібних спеціалістів на проєкт вчасно. Наприклад, кандидати можуть виявитися дорожчими, ніж планувалося, фахівці підуть з проєкту в процесі роботи або їх «захантить» конкурент. Тоді продукт не вийде у реліз.

У project-менеджменті критично важливе — soft skills: емоційний інтелект, уміння слухати, спілкуватися та вирішувати конфлікти. Близько 80% роботи PM становить комунікація. Хард-скіли та технічний бекграунд теж важливі, але PM необов’язково бути «найзнаючою людиною» у команді з тех. питань.

Ще проджекту потрібно володіти скілами, які входять до PMI talent triangle:

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

Обов’язки Scrum Master

Scrum — один із найпопулярніших фреймворків методології Agile, який використовують великі компанії. Гнучкі методології використовують у Amazon, Netflix, Etsy та Spotify.

У Agile-командах, які працюють по скраму, часто є окрема роль — Scrum-майстер. РМ у таких колективах найчастіше відповідають за продукт та робочі процеси (або відсутній), а SM — за наявність Scrum-ритуалів та артефактів: стендапів, дейлі та фасилітацій.

Виділяти цю роль full-time необов’язково, навіть якщо команда працює за фреймворком. Наприклад, у компанії MacPaw обов’язки Scrum-майстра поділили серед команди. Крім того, не всі компанії чітко дотримуються артефактів фреймворку, здебільшого його підлаштовують під себе — головне, щоб був результат.

Скрам-майстер:

• керує Scrum та Scrumban-командами за допомогою методології Agile та практики Scrum або Kanban;
• бере участь у командному плануванні, розстановці пріоритетів, розподіляє обсяг завдань на спринти;
• організовує покер-планування (Planning Poker, Scrum Poker) — техніку оцінку завдань для Agile-команд до 50 осіб;
• допомагає проводити мітинги: спринт-планування, дейлі, демо, ретро;
• гнучко реагує на зміни: без втрати якості та зриву дедлайнів.

Для Scrum-майстра важливе знання Agile-фреймворків, інженерних та продуктових практик. А ще — системне мислення, коучинг, навички планування, управління конфліктами та вміння давати зворотний зв’язок.

Найчастіше наймати в команду і проджект-менеджера, і скрам-майстра не потрібно. Буває, PM наймають у великі проєкти зі стійкою ієрархією IT-фахівців, де розпорядження надходять зверху вниз і потрібний спеціаліст, який працюватиме і з продуктом, і з командою, і з Product-оунером. Однак, це не поширена практика.

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

Ролі в бізнес-менеджменті: Product Manager, Product Owner і Business Analyst

Гілка бізнес-менеджменту включає ролі і фахівців, які пояснюють команді розробки, що потрібно бізнесу від продукту.

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

Обов’язки Product Manager

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

Product-менеджер — роль поміж технологій, дизайну та People Management, тому перелік компетенцій для неї довгий. Головні soft- та hard-скіли спеціаліста:

• аналітичне та критичне мислення — продуктом потрібно керувати на підставі даних та постійно піддавати сумніву свої теорії;
• стратегічне мислення — важливо складати стратегію, roadmaps та розуміти, куди рухається проєкт;
• базовий дизайн — вміння зробити мокап заощадить час на спілкування з дизайнерами та визначить, як швидко фіча дійде до продакшену;
• навичка комунікації — product-менеджер повинен знаходити спільну мову з розробниками, дизайнерами, маркетологами, data-аналітиками та іншими членами команди з різними стеками технологій, підходами та мисленням.

Основний обов’язок продакта — не генерація «фічів», а скоріше вирішення проблем (болей) користувача. Продукт, який не вирішує проблему, — марний. Більше того, одного неправильного рішення достатньо, щоб відштовхнути від проєкту більшу частину ЦА. Розберемо цей аспект на прикладі McDonald’s.

Мережа закладів фастфуду запустила спеціальну функцію: відвідувачі могли зробити бургер на свій смак. Можна було прибрати або додати інгредієнт та соус. Результати показали: клієнти найчастіше додають у традиційний Big Tasty бекон.

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

Обов’язки Product Owner 

В Agile-фреймворку Scrum є окрема позиція власника продукту. У ролі багато спільного з product-менеджером: якщо ввести запит Product Owner на платформах вакансій, у видачі частково будуть результати для продакт-менеджера — і навпаки.

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

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

Серед обов’язків Product-оунера:

• організація робочих процесів у команді розробки продукту;
• інформування колег про клієнтські запити;
• фідбек про беклог з термінами продакт-менеджеру, робота з діаграмою Ганта;
• оцінка прогресу (контроль виконання).

Необхідність у Product Owner часто залежить від того, чи впроваджений у команді Scrum. Наприклад, Amazon, Spotify та Atlassian не використовують у роботі цей фреймворк, і вакансій для PO у них немає — вони відкриті для продакт-менеджерів.

Якщо компанія працює над великим продуктом і в процесі розробки задіяна велика кількість команд, Product-оунер буде жирним плюсом: він «розвантажить» продакт-менеджера. У таких командах одночасно можуть працювати PO і PM.

Обов’язки Business Analyst

Якщо ви хоч раз переглядали вакансії Business Analyst на job бордах, то точно відчували подив. Справа в тому, що є два напрямки бізнес-аналітиків (IT та non-IT), які не перетинаються. Поговоримо про кожен з них.

У не IT-сферах Business Analyst знаходить проблеми та пропонує data-driven рішення для розвитку продукту. У цьому випадку, коли бізнес має проблеми, він «іде» до бізнес-аналітика. А що робить аналітик? Шукає бізнес-потреби, формує вимоги та координує зміни. Бізнес-аналітик — незамінна людина в компанії.

Чотири стадії роботи BA: період стабільної роботи компанії -> період перед змінами -> зміни -> період після змін. Аналітик збирає та досліджує дані, вивчає продуктові метрики (у збільшенні кількості, утриманні, залученості користувачів), відстежує вплив змін у продукті на поведінку користувачів.

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

Business Analyst в IT допомагає розбиратися, який продукт потрібний клієнту, як правильно його описати, щоб команда зробила те, що потрібно. Всі рішення, що приймаються у розробці, повинні відповідати потребам клієнта. Бізнес-аналитик це і реалізує. Цей спеціаліст також:

• Складає карту поточних технічних процесів;
• бере участь у сесіях користувацього тестування;
• пише технічну документацію: User Story, SRS, нотатки до випуску, керівництва для користувача;
• знайомить з декомпозицією та моделюванням функціональності (UML, BPMN).

Для цієї ролі важливим є досвід роботи з блок-схемами (MS Visio, Lucidchart, draw.io), інструментами UX (Balsamiq), User Story, Use Cases, UML- та BPMN-діаграмами.

Найчастіше Business Analyst росте у Product Owner. Сильних фахівців можна зустріти у Outsource та Outstaff-компаніях, де є більше практики взаємодії з різними клієнтами. У продуктових компаніях часто немає бізнес-аналітика, або цю роль виконує людина на іншій посаді. Це пов’язано з тим, що клієнт продукту — кінцевий користувач, це трохи спрощує процес.

Окей, Google: як зрозуміти, хто мені потрібний, а без кого можна обійтися

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

Спочатку формуються цілі. Наприклад, фахівці створюють MVP (мінімально життєздатний продукт). Потім можна визначати вимоги до команди розробників: складу, компетенцій та обов’язків.