Бриф замовника — це не технічне завдання. Це опис проблеми людиною, яка не зобов'язана знати, як влаштована платформа. Ваша робота починається з того, щоб перетворити його на щось, за що можна назвати ціну й не помилитися.
Крок 1. Читайте задачу, а не список побажань
Спершу знайдіть у брифі відповідь на три питання: що зараз не так, що має стати замість цього і де саме це живе. Якщо хоч одна відповідь відсутня — її треба отримати до пропозиції, а не після.
Поля «Цілі» і «Обсяг робіт» часто суперечать одне одному: у цілях «підняти конверсію», в обсязі — «перенести товари». Це не помилка замовника, а нормальний стан живого брифу. Ваша перевага в тому, щоб побачити суперечність першим і запитати.
Окремо перечитайте «Обмеження». Саме там лежить те, що перетворює просту задачу на складну: не ламати наявні адреси, не чіпати чинний дизайн, вкластися в поточний хостинг.
Крок 2. Розберіть обсяг на перевірювані пункти
Кожен рядок обсягу має бути таким, щоб на приймання можна було відповісти «зроблено» або «ні». Формулювання на кшталт «зробити зручно» доведеться переписати разом із замовником — інакше приймання перетвориться на суперечку про смаки.
Особливу увагу — фразам зі словом «просто»: «просто перенести товари», «просто додати блок». Майже завжди за ними ховається те, чого в брифі немає: варіанти, які були опціями, старі адреси, які треба зберегти, аналітика, яка має продовжити рахувати.
Крок 3. Порахуйте суму й назвіть її чесно
Бюджет у брифі — орієнтир замовника, а не ваша межа. Якщо реальна оцінка вища, так і напишіть у пропозиції: «бюджет потрібно розширити, без дизайну виходить близько тридцяти годин». Це нормальна практика, і замовник має право її прийняти або відхилити.
Що варто закласти в оцінку, окрім самої роботи:
- перенесення й перевірку того, що вже працює, — цього майже ніколи немає в брифі;
- зворотну сумісність адрес, якщо магазин уже в індексі;
- час на приймання й правки після нього.
Пропозиція на відкритий бриф закріплює замовлення за вами, щойно замовник її прийме. До цього моменту доступу до сайту у вас немає — і це нормально.
Крок 4. Ведіть роботу всередині замовлення
У замовленні є чат — користуйтесь ним, а не месенджерами. Причина практична: усе, що домовлено в чаті замовлення, лишається прив'язаним до задачі й доступним обом сторонам під час приймання. Домовленість у приватному месенджері на прийманні не важить нічого.
Якщо робота довга, розбивайте її на етапи. Замовник приймає кожен окремо, і ви отримуєте частину коштів, не чекаючи кінця. Для нього це теж вигідно: він бачить прогрес, а не порожнечу на місяць.
Крок 5. Приймання
Кошти лежать в escrow і йдуть вам лише після того, як замовник прийме роботу. Тому підготуйте приймання так, щоб його було легко зробити:
- пройдіться списком пунктів обсягу й покажіть кожен;
- окремо назвіть те, що ви зробили понад бриф, і те, що свідомо не робили;
- не залишайте «дрібниць на потім» без письмової згоди — на прийманні вони спливуть.
Чого не варто робити
- Починати роботу до прийняття пропозиції. Доки замовлення не в роботі, у вас немає ні доступу, ні гарантії оплати.
- Мовчки розширювати обсяг. Зроблене «в подарунок» не оплачується, але створює очікування на майбутнє.
- Складати кастом у ядро. Дозволені зони — конфігурація, публічні файли, шаблони, кастомні теки й переклади. Усе поза ними відхиляється збіркою цілком, а не частково.
- Обіцяти термін, не спитавши про обмеження. Половина зривів — це не складність задачі, а те, чого не запитали на початку.
Якщо бриф слабкий
Слабкий бриф — не привід відмовлятися, а привід поставити три-чотири питання в чаті ще до пропозиції. Замовники, які відповідають, зазвичай і далі поводяться передбачувано. Ті, хто не відповідає, — теж цінна інформація: краще дізнатися про це до escrow, ніж на прийманні.