Що спільного між супергероями Marvel та українськими айтівцями? Усі челенджі їм до снаги подолати разом. Кожен знає не лише свої переможні скіли, а й сильні сторони колег. А коли всі на одній хвилі — то й проєкт вдається вивести на якісно новий рівень. 

У цьому на власному досвіді впевнився Дмитро Автіонов, Project Manager у NIX. Про класичний склад супергеройської IT-команди дізнайтеся зі слів експерта.

Для початку давайте дамо визначення життєвому циклу проєкту — це всі етапи, які проходить проєкт від зародження ідеї до випуску готового продукту/рішення. У процесі втілення ідеї виділяють декілька фаз.

Зазвичай проєкт ґрунтується на семи основних етапах:

• З’ясування вимог
• Створення дизайну
• Розробка продукту
• Тестування
• Запуск продукту
• Технічна підтримка
• Виведення продукту з експлуатації.

Пропоную детальніше розглянути кожен з них.

Збираємо вимоги до продукту — перетворюємо ідею на перелік функціоналу

Уявімо, що до вашої команди звернувся замовник із проханням розробити вебзастосунок. Спершу треба зібрати вимоги до цього продукту. Sales Manager розпитує замовника про всі подробиці.

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

• Для розробки візуальної складової продукту знадобиться допомога дизайнера.
• Впоратися з версткою макету зможе фронтенд-розробник.
• За побудову логіки, створення алгоритмів та обробку даних відповідатиме бекенд-розробник.
• Тестувальник перевірить продукт на наявність помилок і вкаже програмістам на знайдені вразливості.
• На етапі обговорення вимог до Sales Manager долучається бізнес-аналітик. Він ставить додаткові запитання на кшталт: “Що собою являє продукт?”, “Для чого він потрібен?”, “Які функції має виконувати?”

Головне завдання аналітика — деталізувати кожну вимогу й оформити Software requirements specification (далі — SRS). Це документ, який описує продукт загалом: його призначення, цільову аудиторію, функції та ключові параметри, інтерфейси. На основі специфікацій кожен у команді розуміє, який тип проєкту перед ними.

В IT виділяють наступні різновиди проєктів:

• MVP (Minimum viable product) — мінімально життєздатний продукт. Це пробна версія товару або послуги, яку компанія випускає на ринок.
• POC (Proof of concept) — невеликий проєкт, призначений для перевірки гіпотез перед початком повноцінної розробки.
• Product — робоча модель продукту. Використовується для представлення будь-якої частини розробки, виявлення та усунення помилок у ній, отримання фідбеку від користувачів.

У залежності від типу проєкту Sales Manager може презентувати замовнику бачення складу команди та назвати приблизні строки виконання роботи. Визначити це все допомагає Project Manager.

Фахівець ще раз перевіряє вимоги до продукту, прораховує ймовірні ризики та кошторис. У нашому випадку продукт — це вебзастосунок. Як тільки всі деталі затверджено, Sales Manager підписує контракт, і всі фахівці беруться за справу.

Створюємо дизайн продукту

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

• Mockup — макет, який дозволяє побачити, як продукт виглядатиме в реальності.
• Wireframes — чернетка, яка показує, де та як необхідно розташувати елементи на сайті. З цим дизайнеру допомагає бізнес-аналітик. Він добре розбирається в предметній області проєкту. А отже, може запропонувати, наприклад, як втілити функціонал оплати за меншу кількість часу і з використанням мінімальної кількості ресурсів.

Перетворюємо візуальну ідею на технічне рішення

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

Паралельно візуальна складова переходить до рук бекенд-розробника. Він налаштовує програмно-апаратну частину ресурсу. Це все те, що відбувається за лаштунками застосунку. Бекенд поєднує базу даних із фронтендом і має відобразити дані у зручному для користувача форматі.

Тестуємо продукт

До того, як презентувати розробку замовнику та кінцевим користувачам, команда має впевнитись у працездатності продукту. Важливо вчасно виявити критичні баги та перевірити відповідність розробки заявленим на початку вимогам. За ці кроки відповідає тестувальник. Для перевірки продукту QA-інженеру можуть знадобитися різні види тестів. Наприклад:

• Мануальні тести. Класичний метод оцінки якості програми. Спеціалісти вручну проходять тестові сценарії користувача і складають звіти про помилки.
• Автотести. Виконуються за допомогою спеціальних скриптів. При цьому втручання людини зводиться до мінімуму, а точність і швидкість перевірок тут набагато вища за мануальне тестування.

Виділяють і фахівців, які спеціалізуються на тих чи інших різновидах тестів — Manual або Automation QA. Це може бути й один фахівець — General QA.

Головна задача тестувальника — знайти помилку і повідомити про неї розробнику або проєктному менеджеру. Знайдені баги QA вносить до баг-репорту. Документ містить детальний опис дефекту та причину його виникнення. Спираючись на отриманий звіт, девелопери виправляють помилку. Потім тестувальники повторюють перевірку і дивляться, чи вирішена проблема.

Запускаємо розробку у світ

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

До основних обов’язків DevOps відносять:

• налаштування хмарних технологій (мереж, сервісів), встановлення зв’язків між ними;
• впровадження оновлень і доповнень для продукту;
• допомога в масштабуванні проєкту;
• прийом та обробка зворотного зв’язку від користувачів ресурсу/продукту.

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

Виводимо продукт з експлуатації

Життєвий цикл проєкту вважається завершеним, коли вже ніхто не користується продуктом. Так і в наведеному прикладі якийсь час люди активно користуються сервісом, клієнт отримує прибуток. Однак поступово попит на його застосунок може зменшитись. Це нормальна ситуація в мінливому і стрімко зростаючому світі технологій. До цього треба бути готовим як клієнту, так і команді розробки.

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

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