Структура команди розробників ПЗ

При розробці програмного забезпечення важливим аспектом є структура команди. Структура та кількість членів команди залежить від складності та поточного етапу створення програмного продукту. Якщо зі складністю, як не дивно, все відносно просто: чим більше та складніше проєкт, тим більше по кількості та вище за кваліфікацією мають бути учасники команди. То з етапністю справи дещо інші.

На етапі старту проєкту, під час діскавері фази, як правило, нам необхідні: проєктний менеджер, бізнес-аналітик, дизайнер та, обов’язково, технічний архітектор. Бізнес-аналітик описує вимоги проєкту та формує базу під майбутні задачі програмістам, дизайнер створює та погоджує базовий UI/UX, а задача архітектора – запропонувати технічну основу для майбутнього софту та обрати найефективніші технології, зпрогнозувати необхідні сервісні та людські ресурси. Проєктний менеджер на всіх етапах керує процесом створення ПЗ.

Під час розробки ми формуємо core-команду, додаючи програмістів (можуть бути бекенд, фронтенд, мобайл або фулстек – кількість та рівень, визначається потребами на попередній фазі) та тестувальників – мануальних або автоматизаторів. Доволі часто до core-команди можуть приєднатися девопси, тех.ліди або скрам-майстри, але дані ролі можуть бути замінені більш сильними бекенд розробниками на заміну девопсів та тех. лідів, функції скрам-майстра може виконувати проєктний менеджер. Ролі дизайнера, бізнес-аналітика та архітектора – на етапі другої фази зберігаються, але обсяг їх роботи значно зменшується.

На фінальному етапі, під час запуску проєкту в “go life”, кількість розробників може бути зменшено, але при цьому є сенс збільшити кількість тестувальників. Щодо інших ролей: дизайнер може виконувати роль UX-тестувальника, аналітик перевіряє функціональні можливості системи, архітектор вносить корективи у разі виявлення проблем під час перформанс-тестування. Але роль останніх значно менша ніж під час діскавері фази.

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