Проєкт від початку і до релізу очима Project Manager

Привіт! Мене звати Андрій, я Head of Project Management Department в Cadabra Studio. Я переконаний, що успіх проєкту залежить від багатьох факторів: добре підібраної команди, правильного розподілу задач, якісного зворотного зв’язку та наявності всіх необхідних ресурсів для роботи.

Цією статтею я хочу відповісти на питання, чому важливо мати професійного РМа в команді, та розглянути етапи, які проходить проєкт від початку і до релізу.

Словник

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

Тож пропоную одразу ознайомитися з базовою лексикою, яку я записав у форматі словника.

1. Workflow (робочий процес): послідовні кроки або етапи, які потрібно виконати для досягнення конкретної цілі. Наприклад, у процесі розробки програмного забезпечення workflow може визначати порядок виконання задач, від створення коду й до його тестування та розгортання.
2. Sprint (спринт): короткий період часу (зазвичай від 1 до 4 тижнів), протягом якого команда розробників фокусується на виконанні певної кількості задач. Спринт часто використовується в agile-методології розробки, для того щоб забезпечити більш гнучке та ефективне планування роботи і досягнення результатів.
3. Epic (епік): це значне чи великомасштабне завдання чи функціональність, що необхідно досягти в процесі розробки. Епік може бути представлений у вигляді широкої області роботи, яка містить кілька пов’язаних завдань або функцій. Він зазвичай описує більш загальну мету, яку потрібно досягти, і може бути розбитий на дрібніші завдання або підзавдання для зручнішого планування та виконання. Епіки мають стратегічне значення для проєкту та допомагають команді розробників орієнтуватися на досягнення високих результатів.
4. Story (історія): самостійна задача, яка має бути виконана в рамках розробки. Story (або user stories) зазвичай записуються в форматі «як [користувач], я хочу [функціонал], для того щоб [ціль]».
5. Sub-task (підзадача): додаткова задача, яка може бути пов’язана з основною задачею або історією. Підзадачі допомагають розбити складні задачі на менш складні, за рахунок цього вони стають більш керованими одиницями роботи.
6. Hotfix (раптове виправлення): швидкий спосіб виправлення помилки чи проблеми, яке виконується поза межами звичайного цикла розробки і тестування. Hotfix застосовується для того щоб вирішити термінові питання і забезпечувати безперервну роботу системи.
7. Rollback (відкат): процес повернення системи або додатка до попередньої стабільної версії. Відкат виповнюється за потреби відновити працездатність системи, якщо нова версія ПЗ викликає проблеми або видає неочікувані помилки (і якщо немає можливості виправити за допомогою hotfix).
8. Automatic/manual deploy: розгортання стосується процесу установки й запуску програмного забезпечення на цільовій системі або сервері. Автоматичне розгортання означає, що цей процес виконується автоматично з використанням спеціальних інструментів або скриптів, водночас ручне розгортання потребує людського втручання.
9. Repository (репозиторій): централізоване сховище, де зберігаються і скеровуються вихідні коди та файли проєкту. Репозиторій часто використовується для контролю версій та для спільної роботи розробників.
10. Dev-server (серевер розробки): серверне оточення використовують розробники для створення і тестування ПЗ. На dev-server розробники можуть проводити експерименти, вносити зміни і перевіряти працездатність своїх додатків.
11. Staging server (стейдж-сервер): сервер для тестування і перевірки вебсайту перед його розгортанням в робочому середовищі (production). На стейдж-сервері відбуваються фінальні перевірки та виправлення помилок перед випуском додатка.
12. Production server (продакшн): оточення, у якому розгортається і працює кінцева версія додатку або вебсайту. Продакшн-оточення призначене для використання реальними користувачами і зазвичай має високий рівень надійності у вигляді безперебійного функціонування.
13. Release notes (нотатки про випуск): документація, що містить інформацію про нові функції, виправлення помилок та про інші зміни в кожній версії ПЗ. Нотатки про випуск зазвичай надають користувачам та розробникам, щоб вони могли бути в курсі змін у нових версіях.

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

Вибір хостингу

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

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

Види хостингу:

• Спільний (Shared) хостинг.
  Сайт розміщується на сервері разом з іншими сайтами.
• Віртуальний приватний сервер (VPS) хостинг.
  Хостинг, який встановлюється безпосередньо на фізичний сервер і розділяє його на декілька віртуальних машин.
  
• Спеціалізований (Dedicated) хостинг.
  Хостинг з певним форматом контенту: наприклад, відео, музикою, зображеннями, документами.
• Хмарний хостинг (Cloud hosting).
  Сайт розміщується на групі взаємопов’язаних віртуальних серверів.
• Керований (Managed) хостинг.
  Постачальник хостингу бере на себе управління сервером, забезпечує підтримку, безпеку й інші аспекти.

Процес розробки

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

Наступний етап — розподіл задач. Наші команди працюють спринтами, об’єм робіт формується в епіках, які далі розпадаються на story-завдання і sub-завдання. Але спочатку розробник виконує естімейт задач, які йому поставив РМ.

Статусна модель задач

• Backlog — статус присвоюють новоствореній задачі, яка перебуває в плані на наступний реліз. Це певна «черга» завдань, які ще не виконані, але плануються бути реалізованими.
• To do — статус, що надають задачі, доданій у список на реліз. Розробник бере собі наступну задачу для виконання саме зі списку задач зі статусом To do.
• In progress — задачу переносить в цей статус розробник, який почав її виконання. У цьому статусі на одному виконавці може бути максимум дві задачі.
• Paused — задачу переносять у цей статус, якщо пріоритети змінилися і з’явилася критична таска. Критичність та пріоритет задач визначає PM проєкту.
• On hold — задачу переносять у статус, якщо розробнику недостатньо даних для реалізації завдання, є затримки на «третій стороні», баг не відтворюється тощо. Під час переведення в цей статус виконавець обов’язково має написати в коментарі причину, чому задача переходить у On hold.
• Code Review (рецензія коду) — цей статус присвоюють задачі, коли розробник вже завершив роботу над нею і готовий передати її на перевірку. Після завершення написання коду, розробник відправляє його на рецензію іншому члену команди для підтвердження якості, дотримання кодових стандартів та виявлення можливих помилок. Після рецензії в задачі можуть відбутися коригування або внесення змін, якщо це необхідно, а тоді вона може перейти в статус In progress для виправлення надалі.
• Ready for QA — задачу переносить у цей статус виконавець, також змінюється Assignee на наступного відповідального.
• QA Done — у статус задачу переносить, як правило, тестувальник. Цей статус означає, що завдання пройшло перевірку та готове до релізу. У момент зміни статусу необхідно заповнити блок Test cases.
• Reject — у цей статус задачу переносить зазвичай тестувальник або тімлід розробників. Цей статус означає, що завдання не пройшло перевірку та необхідне доопрацювання. У момент зміни статусу потрібно заповнити блок Test cases.
• Done — у статус задачу переносить винятково PM проєкту. Це означає, що завдання зроблено, виконано реліз на PROD-сервер, і воно може бути закритим.

Кожен спринт ми закінчуємо готовим функціоналом,який можна показати клієнту. Це теж відповідальність РМ. Після демонстрації, проєктний менеджер робить реліз нотс і звіт, які подає клієнту разом з інвойсом на оплату.

Покриття коду тестами

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

Головна причина написання юніт-тестів — перевірка окремих модулів. Оскільки кожен модуль пишеться окремо, тестувати його також можна ізольовано, без зв’язки з іншими. Так виходить проста схема: програміст написав модуль → протестував його → продовжив розробку для зв’язки з іншими модулями та інших тестів.

Якщо пропустити етап юніт-тестування, на наступних етапах (а саме code review) не вийде зрозуміти, що саме викликало помилку: якийсь із модулів чи неправильно налаштована інтеграція між ними. Доведеться розбиратися, витрачати час і однаково тестувати окремі юніти.

Автоматичне чи ручне розгортання

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

Для того, щоб забезпечити безперебійні релізи нових версій продукту, потрібно звертати увагу на спосіб доставки і застосування нової кодової бази на серверах, автоматичний чи ручний. Manual deploy (ручний спосіб доставки) краще використовувати тільки на prod- серевері, натомість automatic deploy (автоматичний спосіб доставки) ліпше ставити для процесів на dev- та stage-серверах.

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

Перевірка коду

Після того, як розробники написали код і покрили юніт-тестами, його обов’язково потрібно перевірити на якість. Є два варіанти того, як команда розробників може це зробити. Перший варіант (solo review): обирається одна людина (зазвичай це сеньйор-розробник або тімлід), який самостійно передивляється написані коди і дає фідбек (задача йде далі за флоу або повертається на доробку). Другий варіант (cross review) полягає в тому, що розробники перевіряють роботи одне одного, але форма фідбеку залишається незмінною (задача йде далі за флоу або повертається на доробку).

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

Рух кодової бази середовищами

Проте іноді трапляється так, що на релізі система видає помилку. Для таких випадків у розробників теж є план дій: hotfix або rollback. Принципова різниця полягає в швидкості та оточені, яке використовується для виправлення помилки.

Hotfix — це невеликий фрагмент коду, розроблений для швидкого виправлення основної помилки програмного забезпечення або несправності системи. Rollback призначений для вирішення більш складних помилок. Після rollback система повертається на останній стабільний стан.

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

Наприклад, якщо зміни були перенесені на stage-сервер, вони повинні бути також внесені на dev-сервер; якщо зміни були зроблені в hotfix-репозиторії, вони також повинні бути перенесені на stage- та dev-сервери.

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

Release ver. 1.2.5

Наприкінці додам ще цікавої інформації про числа у версії з релізу.

Версії релізів зазвичай змінюються згідно з певним принципом, він може відрізнятися, залежно від обраної командою розробників схеми керування версіями. Однак найбільш поширеним принципом є застосування трьох чисел у форматі major.minor.patch (головна.другорядна.виправлення).

Ось як зазвичай інтерпретуються ці числа:

1. Major (головна версія): це число, яке змінюється, коли випущено значну версію продукту із суттєвими змінами та новими функціями. Оновлення головної версії може вказувати на великі зміни у продукті, які можуть вимагати оновлення та адаптації користувачів.
2. Minor (другорядна версія): це число, яке збільшується, коли випущено нову версію продукту з додаванням невеликих функціональних покращень, які не призводять до суттєвих змін у роботі або сумісності з попередніми версіями.
3. Patch (виправлення): це число, яке збільшується, коли випускається виправлення помилок або невеликі оновлення, які не вносять нових функцій або змін до функціоналу, що існує. Виправлення дозволяють коригувати виявлені проблеми чи недоліки у продукті.

У прикладі Release ver. 1.2.5 головна версія дорівнює один, другорядна версія дорівнює два, а номер виправлення дорівнює пʼять. Тобто це друге значне оновлення продукту з деякими функціональними змінами та виправленням п’яти помилок.

Висновок

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

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

Розкажіть про свій досвід роботи РМ у коментарях!