# Code review для продакта: чеклист рев'ю pull request без читання коду

> Code review для продакт-менеджера: як робити рев'ю pull request без читання коду, що лишити інженерам, коли обрати Approve чи Request changes, і чеклист.

- Джерело: https://productovi.com/uk/blog/how-to-review-a-pull-request
- Автор: Sergey Bruh
- Опубліковано: 2026-10-02
- Теми: Рев’ю pull request, Будова pull request, Іконки та стани GitHub

Code review від продакт-менеджера починається з простої думки: **ви перевіряєте не код, а зміну такою, якою її побачить клієнт.** Прочитайте issue (задачу), яку має розв'язати pull request, перевірте зміну на preview, спробуйте сценарії, яких ніхто не записав, звірте тексти й пошукайте все, про що issue не просило. Назви змінних, структуру коду й швидкодію лиште інженерам. А потім надішліть усі коментарі одним рев'ю з чітким вердиктом: `Comment`, `Approve` чи `Request changes`. Так виглядає рев'ю pull request від продакта: цього достатньо, щоб воно було корисним, і командний рядок для цього не потрібен.

## Приклад: виправлення бага, яке змінило колір кнопки

У Котокормі, інтернет-магазині кормів для тварин, був баг: після того як клієнт редагував кошик, кнопка оформлення замовлення лишалася сірою. Веброзробник Daniel відкрив pull request з виправленням і попросив двох людей зробити рев'ю: бекенд-розробника Oscar для коду і продакт-менеджера для всього, що побачать клієнти.

Oscar схвалив код за годину. Рев'ю продакта почалося з іншого: з preview, тимчасової копії сайту, зібраної з гілки Daniel. Кроки з опису працювали, і випадки, про які опис мовчав, теж: прибрати товари по одному, застосувати промокод і потім змінити кількість, редагувати той самий кошик у двох вкладках.

Дві речі знайшлися у вкладці `Files changed` («змінені файли»), де показано diff. Нова підказка під неактивною кнопкою звучала як повідомлення про помилку: «Cart is empty. Add items to checkout.» До того ж тут потрібне дієслово «check out», а не іменник «checkout». А один рядок у файлі стилів перефарбовував кнопку оформлення із зеленого на помаранчевий. У звіті про баг про колір не було ні слова, в описі pull request теж.

Рев'ю пішло одним пакетом: запропонована нова підказка, питання про колір і вердикт `Request changes` («запит на зміни») з підсумком: виправлення працює, блокує лише колір. Daniel застосував пропозицію одним кліком, повернув зелений і відкрив окреме issue, щоб чесно протестувати помаранчевий. Після цього вердикт продакта змінився на `Approve` («схвалити»), і наступного ранку виправлення змерджили. Рев'ю коду не мало причин зупиняти нешкідливу на вигляд зміну кольору, а рев'ю продакта мало, бо ставило інше питання.

## Як продакту робити рев'ю коду: що перевіряєте ви, а що інженери

| Перевіряєте ви                                                | Лишаєте інженерам                          |
| ------------------------------------------------------------- | ------------------------------------------ |
| Чи робить зміна те, про що просило issue?                     | Як названо функції й змінні                |
| Чи правильні тексти: орфографія, тон, терміни, числа?         | Як код структуровано й поділено на частини |
| Чи не робить вона того, про що issue не просило (межі зміни)? | Швидкодію, безпеку, запити до бази даних   |
| Що буде поза щасливим сценарієм (граничні випадки)?           | Яку бібліотеку чи підхід варто було обрати |
| Чи добре все виглядає на телефоні й малому екрані?            | Чи достатньо добрі автоматичні тести       |
| Чи надсилаються ті аналітичні події, про які домовлялися?     | Чи відповідає код стилю команди            |

Якщо щось у коді здається дивним, поставте питання замість вказівки. «Що робить це налаштування?» — чесне питання від продакта. «Візьміть іншу бібліотеку» — судження, яке вам нічим підкріпити.

## Рев'ю pull request крок за кроком

GitHub час від часу переставляє кнопки; назви нижче актуальні станом на 2026 рік.

1. **Спершу прочитайте issue.** Pull request має вказувати, яке issue він розв'язує, зазвичай рядком на кшталт `Fixes #131`. Відкрийте його й пригадайте, що просили і навіщо. Це мірило для всього, що далі.
2. **Прочитайте опис.** Добрий опис каже, що змінилося, чому, як перевірити, і має скриншоти. Якщо цього немає, попросіть дописати, а не вгадуйте цілу годину.
3. **Гляньте на заголовок і стан.** Рядок під назвою показує напрямок, наприклад `main` ← `fix/checkout-button`. Сіра позначка `Draft` («чернетка») означає, що автор ще не чекає рев'ю. Червоний хрестик біля перевірок означає, що щось упало; спитайте, чи це важливо, перш ніж тестувати.
4. **Перевірте на preview.** Багато команд викладають кожен pull request на тимчасову копію сайту з окремим посиланням. Пройдіть кроки з «How to test», а тоді зійдіть зі щасливого шляху: порожній стан, довга назва, промокод, кнопка «назад», дві вкладки, телефон. Якщо preview немає, спитайте автора, як побачити зміну.
5. **Відкрийте `Files changed` і читайте те, що можете оцінити.** Файли з текстами, тексти на сторінках, ціни й ліміти в налаштуваннях, зображення. У кожного файлу є позначка `Viewed` («переглянуто»): відмічайте прочитані або лишені іншим, і вони згорнуться.
6. **Звірте diff з issue.** Кожен змінений файл має мати причину в issue чи описі. Зміна кольору у виправленні бага, нове значення за замовчуванням у налаштуваннях чи зайва сторінка — це питання про межі зміни.
7. **Коментуйте рядки.** Наведіть курсор на рядок і натисніть синій `+`. Обирайте `Start a review` («почати рев'ю»), а не `Add single comment` («додати окремий коментар»): тоді коментарі чекатимуть зі статусом `Pending` («очікує»), їх бачитимете лише ви, і підуть вони разом.
8. **Надішліть рев'ю з вердиктом і підсумком.** Кнопка рев'ю вгорі `Files changed` (`Submit review`, «надіслати рев'ю»; у старішому інтерфейсі `Review changes`) відкриває поле для підсумку й три вердикти.

## Запропонована зміна: напишіть виправлення, а не опис проблеми

Для дрібних точних правок (текст, число, посилання) не пояснюйте, що не так. Напишіть правильний рядок. На панелі коментаря є кнопка, яка вставляє блок `suggestion` із поточним рядком, готовим до редагування:

```suggestion
  "checkoutDisabledHint": "Your cart is empty. Add a treat to check out.",
```

Автор бачить це як маленький diff із кнопкою `Commit suggestion` («закомітити пропозицію»). Один клік, і ваш рядок стає комітом у гілці автора, а вас зазначено співавтором.

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

## Comment, Approve чи Request changes

| Вердикт                            | Що він означає               | Коли обирати                                                                          |
| ---------------------------------- | ---------------------------- | ------------------------------------------------------------------------------------- |
| `Comment` (коментар)               | Відгук без вердикту          | Є питання чи дрібні нотатки, а думки щодо мерджу ще немає                             |
| `Approve` (схвалити)               | Це можна зливати             | Зміна розв'язує issue, тексти правильні, нічого зайвого                               |
| `Request changes` (запит на зміни) | Щось має змінитися до мерджу | Справжній блокер: неправильна поведінка, помилка в тексті для клієнтів, зайве в зміні |

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

![«Ні» щодо поведінки, текстів чи обсягу означає Request changes; відкриті питання — Comment; інакше — Approve](/blog/how-to-review-a-pull-request/diagram-uk.png)

У багатьох командах `main` захищена правилами: певна кількість обов'язкових схвалень, успішні перевірки, усі обговорення розв'язані. За таких правил `Request changes` від людини з правом запису тримає мердж, доки ця людина не схвалить зміни або її рев'ю не відхилять, навіть якщо інший рев'юер уже схвалив. Тож якщо ви блокуєте, лишайтеся на зв'язку: коли автор попросить повторне рев'ю, подивіться того ж дня, позначте свої обговорення розв'язаними (`Resolve conversation`) і схваліть.

## Коментарі, які приємно отримувати

Над цією зміною автор працював кілька днів. Кілька звичок відрізняють відгук від тертя:

- **Коментуйте зміну, а не людину.** «Ця підказка читається як помилка» замість «Ви написали повідомлення про помилку».
- **Пишіть, чому.** «Зміни кольору немає в #131, а вона стосується кожного клієнта» дає автору, з чим погодитися чи посперечатися.
- **Питайте, коли маєте сумнів.** «Ліміт 500 навмисний? В issue сказано 150.»
- **Позначайте дрібниці як необов'язкові.** «Необов'язково: "Your cart" звучить привітніше, ніж "Cart".»
- **Кажіть, що вдалося.** «Перевірено промокоди й дві вкладки, кнопка щоразу працює» показує автору, про що вже можна не хвилюватися.

## Типові помилки

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

**Читати diff раніше за issue.** Без issue в голові не видно, що зайве, а розповзання меж зміни інженери помічають найрідше.

**Схвалювати, не перевіривши.** Diff показує, що рядок тексту змінився; лише preview покаже, чи він вміщається на екрані телефона.

**Вважати «схвалено» тим самим, що «на сайті».** Схвалення дозволяє мердж. Чи побачать зміну клієнти, залежить від того, коли її змерджать і викладуть, а іноді ще й від фіча-флагу; від [стратегії гілок](/uk/blog/github-flow-vs-git-flow) у команді залежить, чи це хвилини, чи тижні.

## Чеклист code review для продакта

Скопіюйте його в нотатки й проходьте на кожному рев'ю pull request:

- Пов'язане issue прочитано, і зрозуміло, що саме просили.
- Опис каже, що, чому і як перевірити; це не чернетка, і перевірки не падають.
- Кроки з «How to test» і щонайменше три граничні випадки працюють на preview, зокрема на телефоні.
- Тексти правильні: орфографія, тон, продуктові терміни, числа.
- Кожен змінений файл має причину в issue; для зайвого є питання.
- Коментарі зібрано в одне рев'ю, для точних правок тексту є запропоновані зміни.
- Підсумок каже, що працює, що блокує (якщо блокує) і що необов'язкове.

## Що зробити цього тижня

1. Попросіть техліда додати вас рев'юером до наступного pull request, який змінює щось видиме для клієнтів.
2. З'ясуйте, чи ваша команда викладає preview для pull requests і де з'являється посилання.
3. Прочитайте три нещодавно змерджені pull requests і рев'ю до них, щоб зрозуміти, як у команді прийнято говорити.
4. Збережіть чеклист вище поруч із шаблоном issue, щоб кожне рев'ю починалося з issue.

## Головне

- Продакт переглядає зміну з боку клієнта; код належить інженерам.
- Спершу issue, потім опис, потім preview, потім diff.
- Найбільше користі рев'ю продакта дає на межах зміни: питайте про все, чого issue не просило.
- Для точних правок тексту використовуйте запропоновані зміни, а коментарі надсилайте одним рев'ю.
- `Comment` для питань, `Approve`, коли все готово, `Request changes` для названого блокера.

## FAQ

### Чи взагалі продакт-менеджерам робити рев'ю pull requests?

Так, для змін, які побачать клієнти: тексти, ціни, сценарії, верстка, листи. Схвалення інженера каже, що код надійний; рев'ю продакта каже, що це правильна зміна. У багатьох командах схвалення інженера обов'язкове за правилами, а рев'ю продакта — за домовленістю.

### Чи треба розуміти код, щоб робити рев'ю pull request?

Ні. Достатньо читати diff настільки, щоб знаходити тексти, числа й назви файлів і помічати файли, які не мають стосунку до issue.

### Чим коментар відрізняється від рев'ю на GitHub?

`Add single comment` публікує один коментар одразу. `Start a review` збирає коментарі як чернетку й надсилає їх разом, із підсумком і вердиктом, коли ви надсилаєте рев'ю.

### Чи можна схвалити власний pull request?

Ні. GitHub не дає авторам схвалювати власні pull requests: схвалення має дати інший рев'юер, а на захищених гілках зараховуються лише рев'ю від людей з правом запису.

## Спробуйте на практиці

Урок [Рев'ю очима PM: коментарі, пропозиції, approve](/uk/courses/git-for-product/reviewing-as-a-pm/theory) крок за кроком розбирає повне рев'ю виправлення чекауту в Котокормі, а наприкінці ви пишете власне рев'ю, яке перевіряє ШІ. Перед ним урок [Анатомія pull request](/uk/courses/git-for-product/pull-request-anatomy/theory) пояснює кожну вкладку й панель сторінки, а [Іконки й кольори](/uk/courses/git-for-product/icons-and-colours/theory) вчить з першого погляду читати стани рев'ю й перевірок. Усе це частина безкоштовного курсу [Git і GitHub для продактів](/uk/courses/git-for-product).

## Пов’язані уроки

- [Рев'ю pull request очима PM: коментарі, пропозиції, approve](https://productovi.com/uk/courses/git-for-product/reviewing-as-a-pm.md)
- [Що таке pull request: анатомія сторінки PR](https://productovi.com/uk/courses/git-for-product/pull-request-anatomy.md)
- [Іконки, кольори й перевірки: що означає кожен стан GitHub](https://productovi.com/uk/courses/git-for-product/icons-and-colours.md)