Більшість перевитрат у проєктах починається до першого рядка коду: команда робить те, що зрозуміла, а не те, що потрібно бізнесу. Зрозумілий бриф - найдешевший спосіб цього уникнути, і для нього не потрібні технічні знання.
Почніть із мети
Опишіть, навіщо потрібен проєкт, мовою бізнесу: більше заявок із сайту, менше ручної роботи в офісі, запуск нової послуги, заміна застарілої системи. Додайте, як ви зрозумієте, що все вдалося, - наприклад, за кількістю заявок на місяць чи часом на процес. Мета допомагає команді ухвалювати сотні дрібних рішень у правильному напрямку.
Опишіть користувачів
Хто користуватиметься продуктом: клієнти, співробітники, партнери, адміністратори? Що їм потрібно зробити й у яких ситуаціях - з телефона в дорозі, за комп’ютером цілий день, раз на рік? Навіть короткий абзац про кожну групу корисніший за список функцій.
Перелічіть ключові сценарії
Опишіть головні дії простими історіями: «Клієнт обирає послугу, час, оплачує й отримує підтвердження». П’яти-десяти таких історій вистачає, щоб охопити ядро більшості проєктів. Їх легко обговорювати, оцінювати й перевіряти наприкінці.
Чесно назвіть обмеження
Діапазон бюджету, термін, наявні системи, які треба підключити, юридичні вимоги, мови, хто керуватиме контентом після запуску. Обмеження - не слабкість брифу, а те, що дає змогу команді запропонувати реалістичне рішення замість ідеального.
Розставте пріоритети
Позначте, що обов’язково має бути в першій версії, а що може зачекати. Запуск, у якому добре працюють головні сценарії, майже завжди кращий за пізній запуск, де все зроблено наполовину.
Що можна не писати
Не потрібно обирати технології, малювати кожен екран чи описувати базу даних - це робота команди. Приклади сайтів або продуктів, які вам подобаються, з поясненням, що саме подобається, часто цінніші за детальні ескізи.
Коротко
Корисний бриф відповідає на п’ять запитань: навіщо, для кого, що мають уміти користувачі, у яких межах і що найважливіше. Двох-трьох сторінок зазвичай достатньо, щоб заощадити тижні переробок.