Проєкт від початку і до релізу очима 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 дуже відповідальна. Він підтримує настрій команди і її темп, розуміється на тонкощах кожного з етапів розробки і стежить, щоб у його команди було все необхідне, від інформації з проєкту до технічних аспектів роботи.

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

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

👍ПодобаєтьсяСподобалось8
До обраногоВ обраному4
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Ставлю лайк, але автор забув додати що він «не дід з трамваю»

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

В той же час наведений, наприклад, повний перелік хостингів — не дуже зрозуміло нащо.

Не дуже зрозуміло, що ви мали на увазі: «чому ж важливо мати професійного ПМа», ... імхо, дана стаття про досвід, як в невеликих аутсорсних компаніях на невеликі і нескладні проекти є тендеція хотіти мати PM+BA «в одному флаконі».

фраза

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

— це пряма цитата з самої статті, не з голови

Іі? Що не так в статті?
Судячи з вашого першого повідомлення => у вас претензія, що тема ризик менеджменту не розкрита, а також піддаєте сумніву нахіба PMу мати поверхневе розуміння архітектури продукту, що буде розроблятися.

Віталій, Ви раптом не ПМ? Людина задала чітке питання, вказала цитатою звідки воно виникло. А Ви шось воду мутите...

upd. подивився профіль, питання знято.

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

Прісейл-арїітект оцінив в три раз менше, ви це продали.
Програмістів з бенча дали які є, а не яких треба.
Строки попливли з самого початку
*кожну ітерацію
Йой, що вони тулять на ревью, це ж зовсім не те.
Вони ж це пофіксили, звідки знову ті самі помилки?
В сенсі у девопса відпустка, реліз же заплановано
Мідл звільнився, замість ейчари тулять джуна з курсів
Синьор вигорів
Клієнт натякає на знижку
*перед здачею проекту
Клієнт починає тикати кнопочки і присилає правки на фічі дворічної давності
Треба поміняти базу, бо на проді буде оракл, вам про це забули сказати
Девопс звільнився
Ніхто не може розібратися, що там з релізами
Воно заводиться, половіна фіч не працює
З горем новпіл продаєш 1 синьора і 2 джунів на безкінечну підтримку
Відкриваєш віскі
Дзвінок від менеджменту, ти молодець, допоможи тому проекту, бо там гузно, виділяємо 5% часу

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

Як юніт тести впливають на код рев’ю?)

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

ПМ не може розумітись на тонкощах, бо він не спеціаліст.
Пункт про вплив юніт тестів на код рев’ю якраз тому підтвердження, бо це те саме що сказати «міняти мастило в машині треба вчасно бо коли закінчиться паливо, ви не будете знати що не так». Тобто смислу в тому 0.

Як юніт тести впливають на код рев’ю?)

Якщо тімлід щось розуміє і не хоче виходити по вихідних безкоштовно, та сидіти по ночах, як реліз та строки летять в трубу, що софт одна загальна регресія та баг — то дуже сильно впливає. По голові отримаєш та догану. Що правда є такі розумники та розумниці які одразу побіжать менеджеру жалітись, що мене ображають та харасять злі дяді та теті, не дають накручувати багато закритих за спринт сторі пойнтів. Тому краше поставити статичний аналіз коду в СI/CD. Той самий Sonar Qube наприклад чи щось подібне, на автомат жалобу не подаси він показує — «не покрито тестами, білд не прийнято», та і просто на код ревью на це не треба витрачати час очима провів, щоб там не було якоїсь уж зовсім дичи і порядок.

ПМ не може розумітись на тонкощах, бо він не спеціаліст.

Просто питання хто є хто, тобто яка лиска за що відповідає по різних компаніях, та навіть і по різних віділках однієї компанії це дуже абтрактна штука. От тут нещодавно чувачек з Google пояснював, що там вимоги до мідла як на більшості аутсорсу до архітекта чи навіть CTO. Щоправда там це компенсується щонайменше в 210 тисячами доларів на рік в бейсі + бонуси в акціях. Далеко не кожний власний бізнес дасть такий прибуток.

Як юніт тести впливають на код рев’ю?)

Покриття менше 80% — нема ревью, бо воно червоне.

Покриття менше 80% — нема ревью, бо воно
червоне.

А чого не 50% або 99%?)
Те що ти собі в конфізі поставив мінімум 80% не робить код якіснішим.

Читайте Кента Бека Extreme Programming, покриття вище 80% теж вважається over engineering тобто ви занадто багато часу витрачаєте на покриття тестами, та покриваєте ті ділянки які в принципі не мають жодної логіки. Хоча мені траплялись команди в яких гейт виставлено на 97%. Но вони чітери, в них тести були написані після коду, при чому код був не від них, а від індійського вендора то вони поставили перевірку тільки на нові коміти. Після того щоб внести якісь зміни в початковий код, його вважай можна реверс інженерити та переписувати. Методологія працює не так зовсім, ви маєте писати тести до того як написали код ? Як це так так? А так, що ви не можете їх написати технічно, якщо вам не відомі вимоги до ПЗ максимально формально і ви не спроектували і не узгодили API до модуля, який пишите. Мідли та джуніори на 80% займаються експериментальним програмуванням як підходом до створення софту, тобто пишуть його вважай в дебагері та вставляють костилі, коли тестувальники дали по шапці. Це вельми не продуктивний метод, але відповідає навчанню у універі де на «лабораторних роботах» не важливо як ти зробив код, треба швидко щось зробити, здати та отримати оцінку після чого цей код нікому більше не потрібен. В комерційній розробці це дуже сильно не так, особливо в продукті — цей код треба ще підтримувати. І чим гірше його структурна якість — тим важче його підтримувати.

Питання було «як тести впливають на рев’ю», а не чи має це практичний сенс)

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

А що із вимогами? І визначенням навіщо це все робити?

Я так розумію, що вони були десь за лапками?

Ну методологія «гребем на дрібній шлюпці, трохи схоже на XP» ми колись і такого не знали. Лише одне питання, якщо усе роблять девелопери — нащо взагалі треба прожект менеджер, окрім «підтримує настрій» ? Якій сенс від його присутності на проекті крім витрати грошей на позицію ? Напевно десь там ще мають бути строки, бюджети, найми, звільнення, відпустки, мотивації, підвищення кваліфікації тощо. Бо як це усе у великому колективі будуть робити девелопери з тестуавальтниками їм буде сильно меньше часу працювати. Коротше де про біт, пророка та естімейт, підписання контрактів, вибивання з клієнта проплат, робота з конфліктами, керування ризиками, нормалізації комунікацій і т.д. Тема цицьок не розкрита.

Путь к славе шел по рецепту: в шесть часов вечера солдаты получат гуляш с картошкой, в половине девятого войско «опорожнится» в отхожем месте, а в девять все идут спать. Перед такой армией неприятель в ужасе удирает. ©

Підписатись на коментарі