Як зробити вибір на замовлення без написання технічної специфікації.

Не потрібно починатися з базової діаграми. Потрібно пояснити роботу, яку хтось повинен бути в змозі завершити і результат його бізнес-потрібності.

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

Починати з користувачем і завданням

«Побудувати портал» імена типу програмного забезпечення. «Затверджений клієнт подає запит на обслуговування і див. його прогрес» описує корисний перший робочий процес.

Ім'я користувача, дія та результат. Потім виявляти, хто керує іншим боком процесу. У цьому прикладі співробітник повинен ознайомитися з запитом та оновити його статус. Це означає, що короткий вже містить дві різні ролі та загальний запис.

Уникайте від «на додаток для всіх». Різні користувачі можуть потребувати різні дозволи, екрани та інформацію. Вирішуйте, які ролі стосуються більшості в першому випуску.

Скажіть, що відбувається сьогодні

Опишіть поточні кроки в звичайній мові. Можливо, інформація електронної пошти клієнтів, її співробітник копіює її в таблицю та іншу людину надсилає оновлення прогресу. Стан, де відбувається плутанина або повторне зусилля, не допускаючи програмного забезпечення, вирішить кожну зовнішню проблему.

Почервоний приклад поточної форми або запису може бути більш корисною, ніж полірована презентація. Видаліть персональні дані та конфіденційні дані перед їх поширенням.

Опишіть одну повну подорож

Яка інформація потрібна? Хто робить наступне рішення? Як це позначається?

У тому числі один або два важливі винятки. Запит може бути неповним, рецензент може відхилити його або користувач може знадобитися виправити помилку. Ті випадки допомагають відрізняти робочу заявку від демонстрації ідеального шляху.

Не потрібно забувати про будь-які рідкісні події на цьому етапі. Концентрат на винятках, які зупинилися на головному робочому шляху з корисною.

Ім'я даних та залежностей

Список важливих записів: користувачів, запити, продукти, бронювання, файли або інший набір інформації.

Для інтеграції, ім'я іншої служби та надання її документації при наявності. «Підключення до нашої CRM» залишає за собою основні питання, відкриті. Корисна деталь полягає в тому, що запис повинен переміщатися, в якому напрямку та після якої захід.

Визначте, чи доступні ціни, вміст товару, доступ до облікового запису або правила ведення бізнесу. Місячні матеріали не автоматично блокуються, але вони потребують власника і місця в плані.

Визначте першу корисну версію

Відокремити основні поставки з пізніх ідей. Перший портал може підтримувати створення запиту, переглядаючи його і показати статус. Обмін повідомленнями, просунутий звіт і мобільний додаток може бути пізніше обговорень, а не вирішених вимог першого будівництва.

Це не інструкція з побудови чогось неповного. Вибраний робочий процес повинен працювати від початку до кінця. Обмежена межа між повними робочими процесами, не між привабливим екраном і логікою, яка все ще потребує.

Напишіть приклад прийняття

Спробуйте вирок, хто може перевірити:

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

Це ілюстративна вимога, не опис існуючого проекту клієнта. Вона робить очікувану поведінку набагато більш чіткіше, ніж «сучасний, надійний портал». Подіяльність може рефінансувати дозволи і крайові випадки.

Додати практичні обмеження

Якщо ви хочете, чи є це перевага або фіксована дата, а також бюджетний діапазон, де відомий. Назва особи, яка може затвердити рішення і пояснити, як конструкції або зворотний зв'язок буде подано.

Опишіть видачу і очікування віддачі. Хто буде володіти хостингом і рахунками? Чи потрібен інший розробник для отримання коду? Ці питання впливають на доставку навіть коли вони не з'являються на екрані.

Коротко можна використовувати

Ми хочемо, щоб побудувати: Додаток або робочий процес. Основні користувачі: люди і ролі. Їм потрібно: Головне завдання і завершений результат. Сьогодні це відбувається через: поточний процес. У першому варіанті необхідно включити: необхідний повний робочий процес. Необхідно підключитися до: відомі системи та документація. У нас вже є: дизайн, зміст, облікові записи або прикладні дані. Ще не визначилися: питання для вирішення. Терміни, бюджет та прийняття рішень: практичні обмеження.

Використовуйте кілька чітких вироків для кожної частини. Бриф є стартовою точкою для визначення проекту, не потрібно пройти тест, перш ніж говорити з розробником.

Дискусії користувацького веб-додатку або надішліть опис проєкту.