Рев'ю pull request: чеклист для продакт-менеджера

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

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

У Котокормі, інтернет-магазині кормів для тварин, був баг: після того як клієнт редагував кошик, кнопка оформлення замовлення лишалася сірою. Веброзробник 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 рік.

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

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

Для дрібних точних правок (текст, число, посилання) не пояснюйте, що не так. Напишіть правильний рядок. На панелі коментаря є кнопка, яка вставляє блок 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 — це не грубість, а точність, якщо в підсумку чітко сказано, що саме блокує мердж і чому. Не просіть змін через кому і не схвалюйте з надією, що проблему, яку ви помітили, виправить хтось інший.

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

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

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

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

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

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

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

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

Вважати «схвалено» тим самим, що «на сайті». Схвалення дозволяє мердж. Чи побачать зміну клієнти, залежить від того, коли її змерджать і викладуть, а іноді ще й від фіча-флагу.

Чеклист рев'ю pull request для продакта

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

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

Попросіть техліда додати вас рев'юером до наступного pull request, який змінює щось видиме для клієнтів.
З'ясуйте, чи ваша команда викладає preview для pull requests і де з'являється посилання.
Прочитайте три нещодавно змерджені pull requests і рев'ю до них, щоб зрозуміти, як у команді прийнято говорити.
Збережіть чеклист вище поруч із шаблоном 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 крок за кроком розбирає повне рев'ю виправлення чекауту в Котокормі, а наприкінці ви пишете власне рев'ю, яке перевіряє ШІ. Перед ним урок Анатомія pull request пояснює кожну вкладку й панель сторінки, а Іконки й кольори вчить з першого погляду читати стани рев'ю й перевірок. Усе це частина безкоштовного курсу Git і GitHub для продактів.

Як робити рев'ю pull request, якщо ви продакт, а не розробник