Коли компанія невелика, багато речей можна вирішити розмовою (грубо кажучи – “всі в одній кімнаті”). У команди високий загальний контекст і велика автономність (“людей не вистачає”). Якийсь процес поверх цього потенційно може уповільнити роботу, не додавши користі.
Коли команда зростає, з’являється більше зв’язків, знижується загальний контекст – з’являється потреба в процесах і ритуалах.
Наприклад, якщо у вас один і той самий продукт змінює десяток продакт-менеджерів – вони почнуть перетинатися. З’явиться питання – а чи немає у нас ситуації лебеді-рака-щуки, чи рухаємо ми продукт до однієї мети?
Одне з рішень тут – продуктовий пітч. Ще його називають RFC (request for comment, request for change), PRD (product requirement document), narrative, design doc та іншими словами.
На певному етапі розвитку компанії ця штука дає змогу досягти двох речей:
- Дати фідбек щодо майбутньої зміни до того, як у неї почали активно вкладатися. Усіх фруструє ситуація, коли зміна довго в роботі, а тут з’являється керівник із “треба робити по іншому”.
- Отримати свіжий погляд і фідбек на свої рішення. Це завжди дуже корисно.
В інтернеті можна знайти цілий розсип різних темплейтів таких документів різного ступеня якості. Від простих до абсолютно монструозних.
Свого часу я подивився на них усі і зробив собі свій: взяв із різних документів те, що подобається, і викинув те, що вважаю зайвим.
Вийшов ось такий темплейт: https://docs.google.com/document/d/1J-7_GFZvIPixT6cKOHAaCeF5npkOpw-_gakT5GfnKQc/edit?usp=sharing (англійською)
На мій погляд, у цьому документі правильний баланс – запитуються потрібні речі, але не запитуються непотрібні.
Особливо хочу звернути вашу увагу, що Problem Alignment і Solution Alignment – різні секції, і їх можна (а часто й треба) писати окремо. Одна з частих проблем – готове рішення в голові, яке диктує проблему. Щоб позбутися цього, проблему варто описувати окремо, не намагаючись описувати конкретні рішення і зміни.
