# GitHub Projects: дошка проєкту від issue до релізу

> GitHub Projects для продакта: макети канбан-дошки, таблиці й roadmap, поле статусу й власні поля, вбудовані воркфлоу, що рухають картки, і як провести фічу від issue через pull request, мердж і реліз до фіча-флагу. Чому «Done» на дошці не завжди означає, що клієнти вже можуть цим користуватися, і що показати CEO.

- Курс: [Git і GitHub для продактів](https://productovi.com/uk/courses/git-for-product.md)
- Модуль: GitHub у продуктовій роботі
- Урок 14/15, ~43 хв
- Джерело: https://productovi.com/uk/courses/git-for-product/project-boards

## Дошка для запуску

**Alex Tutor:** Вівторок третього тижня, друга половина дня, і ти з продуктовою командою Котокорму досі працюєш над запуском лояльності. Майлстоун каже, скільки елементів лояльності закрито. Але сьогодні зранку CEO питав про інше: «Хто що робить цього тижня і чи встигаємо ми?»

**Sofia:** А Daniel хоче перетягувати картки замість писати повідомлення про статус. Таблиця поруч із GitHub застаріє вже до середи.

**Alex Tutor:** Тож тримай план там, де робота. **GitHub Projects** це інструмент GitHub для керування проєктами: простір для планування поверх issues і pull requests. Проєкт належить організації чи людині, а не окремому репозиторію.

**Daniel:** І кожен елемент у ньому це справжнє issue чи pull request, а не копія. Коли сьогодні зранку закрилося #159, кожен проєкт, де воно є, одразу про це дізнався.

**Alex Tutor:** Проєкт може містити елементи з кількох репозиторіїв, а ще **чернеткові елементи** (draft items): швидкі нотатки, які живуть лише в проєкті, доки хтось не перетворить їх на issues.

**Sofia:** Тоді створюю «Loyalty launch» в організації catchow і додаю туди елементи з майлстоуна. З репозиторію нічого не переїжджає.

> **Вправа:** Проєкт GitHub належить одному репозиторію й може показувати лише issues і pull requests цього репозиторію.

**Alex Tutor:** Не все на дошці починається як issue. У Sofia є сира ідея з ранкового планування.

> **Вправа:** У проєкті Sofia записує чернетковий елемент: «Ask support for a loyalty FAQ». Що про нього правда?

## Дошка, таблиця й roadmap: один проєкт, три макети

**Alex Tutor:** Проєкт має **подання** (views), збережені як вкладки вгорі. Кожне подання використовує один із трьох макетів, станом на 2026 рік: `Table` («таблиця»), `Board` («дошка») або `Roadmap` («дорожня карта»).

**Alex Tutor:** `Table` це електронна таблиця: рядок на кожен елемент, поля як колонки, сортування, групування й редагування просто в клітинці. Найшвидший спосіб розібрати двадцять нових issues.

**Alex Tutor:** `Board` це канбан-дошка: картки в колонках, по колонці на кожне значення поля, зазвичай `Status`. Перенесли картку в іншу колонку, і значення поля змінилося.

**Daniel:** Там я й житиму. Перетягую картку в `In progress`, коли починаю, і в `In review`, коли мій pull request готовий до рев'ю.

**Alex Tutor:** `Roadmap` розкладає елементи на часовій шкалі за полем дати чи ітерації, з позначками на кшталт дедлайну майлстоуна. Він відповідає на «коли?», тож це подання для CEO.

**Sofia:** Ті самі елементи, три способи на них дивитися. Змінюєш поле в одному поданні, і це видно в усіх.

![Ті самі кольорові картки показано тричі: рядками в таблиці, по колонках на дошці й уздовж часової шкали.](https://productovi.com/courses/git-for-product/inline/project-boards-illustration-2.webp)

*Зміни картку в одному поданні, і її побачать усі інші.*

> **Вправа:** Зістав кожну потребу з частиною GitHub Projects, яка найкраще її закриває.

## Статус і власні поля: звідки беруться колонки

**Alex Tutor:** Колонки беруться з полів. `Status` вбудоване поле, на початку зі значеннями `Todo`, `In Progress` і `Done`. Додай четверте, `In review`, між двома останніми, і на дошці з'явиться четверта колонка.

**Alex Tutor:** Issues приносять із собою власні поля: виконавців, мітки, майлстоун, пов'язані pull requests, навіть прогрес sub-issues. А понад це проєкт може мати **власні поля** (custom fields).

**Sofia:** Додаю три: `Priority` зі значеннями від P1 до P3, `Target date` («цільова дата») і `Iteration` («ітерація»), тижневі відрізки з понеділка по п'ятницю.

**Daniel:** Ітерації зручні. «Що в нас цього тижня?» стає фільтром, а не зустріччю.

**Alex Tutor:** Власні поля належать проєкту: #163 може мати P1 тут і не мати жодного пріоритету в іншому проєкті. На сторінці самого issue вони видні в розділі `Projects` бокової панелі.

**Alex Tutor:** Перш ніж дивитися на дошку, одна перевірка: де живуть власні поля.

> **Вправа:** Issue #163 має `Priority` P1 у проєкті «Loyalty launch». Якщо його додати до іншого проєкту, там у нього теж буде P1.

```text
«Loyalty launch», подання Board, середа
- [Open] Switch on loyalty points for all customers #164: Todo · Sofia · ціль 10 листопада
- [Open] Launch loyalty points before Black Friday #147: In progress · Sofia · закрито 1 з 4 sub-issues
- [Open] Spend points at checkout #163: In progress · Daniel · P1 · ціль 5 листопада
- [Draft] Write loyalty programme page #157: In progress · Emma · P2
- [Open] Show points balance in the account #162: In review · пов'язаний pull request #166 · Daniel · P1
- [Closed as completed] Points counted before promo discount #159: Done · закрито через #165
```

*Кожна примітка починається з колонки Status, у якій лежить картка.*

**Sofia:** Чотири колонки справжньої роботи, а батьківське issue в `In progress` з позначкою «1 of 4».

**Alex Tutor:** Читай дошку справа наліво: що завершено, що чекає на рев'юера, що будується, що ще не почато. Колонка очікування це місце, де продакт може допомогти найбільше.

> **Вправа:** Завтра Daniel не працює. Судячи з цієї дошки, який із його елементів найближчий до завершення і на що він чекає?

## Вбудовані воркфлоу: хай картки рухає GitHub

**Sofia:** А хто підтримуватиме все це в актуальному стані? Не хочеться щоп'ятниці бігати за людьми, щоб вони перетягували картки.

**Alex Tutor:** Частково GitHub. У проєкті є вбудовані **воркфлоу** (workflows) в меню `Workflows`, станом на 2026 рік. Два з них увімкнені в новому проєкті одразу: коли елемент закривають і коли pull request зливають, `Status` стає `Done`.

**Daniel:** Я ввімкнув ще два. «Item added to project» ставить `Todo`, а «Auto-add to project» автоматично додає кожне нове issue з catchow/website з міткою `loyalty`.

**Alex Tutor:** Тож нове issue лояльності саме опиняється в `Todo`. Змерджений pull request з `Fixes #162` закриває #162, а закрите issue переїжджає в `Done`. Середні колонки люди досі рухають вручну або скриптом GitHub Actions.

![Невелика роботизована рука переставляє картку в наступну колонку дошки, коли поруч крізь ворота проїжджає посилка.](https://productovi.com/courses/git-for-product/inline/project-boards-illustration-3.webp)

**Sofia:** Якщо тільки хтось не напише `Part of #162` замість `Fixes #162`.

**Daniel:** Тоді #162 лишиться відкритим, його картка зависне в `In review`, і дошка брехатиме, доки хтось не помітить. Тепер ключове слово закриття важить удвічі.

> **Вправа:** О 9:15 Daniel зливає #166 у `main` через squash. У проєкті ввімкнено два стандартні воркфлоу. Що станеться на дошці?

## Done ще не означає запуск

**Alex Tutor:** У четвер по обіді команда публікує `v1.5.0`: з часу `v1.4.1` туди увійшли #156, #160, #165 і #166. Дві картки лояльності в `Done`, нотатки до релізу перелічують їхні pull requests, а клієнти досі нічого не бачать.

```text
Граф комітів, від найстарішого: main від v1.4.1 до v1.5.0
1. коміт e5f81a3 у main "Hide loyalty menu link when flag is off (#158)", тег v1.4.1
2. коміт b2e6f10 у main "Earn points on paid orders (#156)"
3. коміт 6e0b4d8 у main "Add issue templates (#160)"
4. коміт 7a1d9c3 у main "Count points after discounts (#165)"
5. коміт c3f7a05 у main "Show points balance in the account (#166)", тег v1.5.0 (виділено)
```

*Кожен коміт лояльності тут змерджено, викладено й випущено у v1.5.0, і він досі прихований: флаг loyalty-points увімкнено лише для працівників.*

**Sofia:** Отже, `Done` на нашій дошці означає «змерджено» або «закрито». У Котокормі це ще й «викладено за кілька хвилин». Але приховано.

**Alex Tutor:** Так. Чи можуть клієнти користуватися балами, записано там, куди дошка не бачить: у панелі флагів. Кожне питання має власне джерело правди.

![Колонка дошки, повна завершених карток, стоїть поруч із вимкненим настінним вимикачем, від якого тягнеться дріт до темної вивіски крамниці.](https://productovi.com/courses/git-for-product/inline/project-boards-illustration-4.webp)

*Дошка показує роботу, а фіча-флаг — що отримують покупці.*

**Alex Tutor:** Деякі команди додають колонку `Released` і в день релізу переносять туди картки. Ми лишаємо `Done` чесним, а запуск робимо окремою карткою: #164, перемикання флагу, чекає в `Todo` до 10 листопада.

**Daniel:** І коли мене питають «це вже на сайті?», будь ласка, не зачитуйте мені дошку. Дивіться `production` у `Deployments` і флаг.

**Sofia:** Отже: дошка показує роботу, pull request показує рев'ю, сторінка релізу показує версію, а флаг показує, що отримують клієнти.

![Дошка показує роботу, pull request — рев'ю, сторінка релізу — версію, а панель флагів із Deployments — те, що отримують клієнти.](https://productovi.com/courses/git-for-product/diagrams/m5-l2-sources-of-truth-uk.png)

> **Вправа:** Зістав кожне питання про бали лояльності з місцем, де на нього є надійна відповідь.

**Alex Tutor:** Тепер виріши, як сама дошка має показувати запуск. На столі два варіанти.

> **Вправа:** Два способи показати запуск лояльності на дошці. Який із них лишає дошку **чесною**?

## Від issue до клієнтів

**Alex Tutor:** Тепер розставмо по порядку весь шлях одного шматка. Візьмімо #163, списання балів під час оформлення, над яким зараз працює Daniel.

**Daniel:** Його pull request буде #167. Після рев'ю й мерджу він увійде в реліз наступного четверга, `v1.6.0`, і досі буде прихованим.

**Sofia:** А 10 листопада флаг вмикають для всіх. Саме тоді клієнти зможуть витрачати бали.

**Alex Tutor:** Розстав кроки від першого issue до цього моменту.

> **Вправа:** Розстав по порядку шлях «Spend points at checkout»: від issue до моменту, коли клієнти ним користуються.

## «Наполовину запущено?»

**Sofia:** CEO щойно відкрив дошку й пише: «2 з 4 sub-issues у Done, тобто ми наполовину запустилися?»

**Alex Tutor:** Чесне прочитання дошки, яку робили не для нього. Корисна відповідь розводить три речі: що вже зроблено, що бачать клієнти і що далі.

**Daniel:** Згадай флаг. Йому подобається знати, що є перемикач, який ми контролюємо.

**Alex Tutor:** Два-три речення, як відповідь у чаті.

> **Вправа:** CEO пише: «На дошці 2 з 4 sub-issues лояльності в Done, тобто ми наполовину запустилися?» Флаг `loyalty-points` увімкнено лише для працівників. Напиши відповідь у 2–3 реченнях.

## Оновлення в п'ятницю

**Alex Tutor:** П'ятниця. Замість відповідати на питання поодинці, надішли одне щотижневе оновлення й дай CEO власне подання, яке він зможе відкрити будь-коли.

**Sofia:** Що має бути в оновленні? Усе, що є на дошці?

**Alex Tutor:** Що змінилося за тиждень, що під загрозою і що далі, словами CEO, а не дошки. А тоді виріши, який макет матиме його подання і що воно не показуватиме.

**Daniel:** Один ризик від мене: списання балів зачіпає оформлення замовлення, тож Oscar хоче два повні дні на рев'ю #167. Моя ціль, 5 листопада, під тиском.

**Sofia:** Тобто дата запуску залежить від того, чи встигне #167 вчасно для тестування працівниками.

> **Вправа:** Напиши п'ятничне оновлення статусу балів лояльності для CEO й опиши подання проєкту, яке ти для нього налаштовуєш.

**Alex Tutor:** Ось що таке дошка проєкту: ті самі issues і pull requests, розкладені для планування, які рухають частково люди, а частково воркфлоу, і з поданням для кожного читача.

**Sofia:** І що б не казала дошка, вона стежить за роботою команди. А що отримують клієнти, перевіряю в `Deployments` і в панелі флагів.

**Daniel:** Наступного тижня мій шматок з оформленням. І до речі, на сторінці доставки вже кілька місяців висить одрук. Підтримка сьогодні зранку знову його переслала.

**Alex Tutor:** Тоді на наступному уроці цей одрук твій: від першого кліку в браузері до живого сайту, і як скасувати зміну, якщо знадобиться.

- Попередній урок: [Баг-репорт і GitHub issues: шаблони, мітки й майлстоуни](https://productovi.com/uk/courses/git-for-product/issues-labels-milestones.md)
- Наступний урок: [Перша зміна в браузері і як її відкотити через revert](https://productovi.com/uk/courses/git-for-product/first-change-in-the-browser.md)

---
Productovi Learning. Безкоштовно, читати можна без реєстрації.