Як підготувати технічне завдання на автоматизацію бізнесу

1. Визначте проблему, а не майбутній інтерфейс

Запит «зробіть кабінет із дашбордом» описує форму, але не потребу. Краще почати з події: менеджер збирає статус замовлення з трьох джерел і не бачить, де воно затрималося. Тоді можна обговорювати різні рішення: налаштування поточного звіту, обмін даними або окремий інструмент. Не фіксуйте найдорожчий варіант до перевірки.

Укажіть, хто отримує результат і що саме зможе зробити інакше. Наприклад, керівник має знайти підтверджені замовлення без наступної дії та призначити відповідального. Це конкретніше за «покращити контроль». Додайте приклад поточної проблеми без клієнтських даних і спосіб перевірити, що вона існує.

Відокремте ціль від показника. Менше ручного перенесення — напрям зміни; кількість передач або час підготовки — можливі вимірювання. Числовий результат погоджуйте після початкового вимірювання. Не вставляйте в ТЗ довільну обіцянку скорочення витрат, яку ніхто не може обґрунтувати.

2. Обмежте процес і перший етап

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

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

Опишіть зовнішні залежності. Хто надає експорт, доступ до тестового середовища й пояснення полів? Що відбудеться, якщо постачальник не підтримує потрібну операцію? Невідоме позначайте відкритим питанням із власником. Не перетворюйте припущення на приховану гарантію в кінцевому документі.

3. Перетворіть побажання на сценарії користувача

Atlassian пояснює user stories через користувача, його мету та користь. Такий підхід допомагає почати розмову, але коротка історія сама по собі не замінює повного опису даних і перевірок. Наш подальший шаблон — практична структура Routio, не обов’язковий стандарт Atlassian.

Навчальний приклад: «Як менеджер, хочу бачити замовлення, які не передалися на склад, щоб опрацювати винятки». Далі уточніть, що означає «не передалися», за який період, які записи бачить менеджер і яку дію йому дозволено виконати. Без цих деталей два розробники можуть реалізувати різні результати й обидва формально виконати фразу.

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

4. Узгодьте словник даних і джерела

Для кожного об’єкта потрібні визначення та ідентифікатор. «Клієнт» може означати людину, компанію або обліковий запис; «замовлення» — документ із кількома позиціями. Уточніть, що означає один рядок, які поля обов’язкові та де вони створюються. Це запобігає помилкам зіставлення ще до написання коду.

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

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

5. Опишіть інтеграцію як набір домовленостей

Фраза «інтеграція з CRM» не визначає обсяг. Укажіть об’єкти, напрям передачі, подію запуску та систему, яка є основною для кожного поля. Зміна адреси після передачі замовлення може мати інші правила, ніж створення нового запису. Не припускайте, що двосторонній обмін потрібен для всіх даних.

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

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

6. Зробіть критерії приймання перевірними

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

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

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

7. Не забудьте про доступ, навантаження й підтримку

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

Для продуктивності вкажіть реальне навантаження: обсяг записів, одночасну роботу й характер піків. «Має працювати швидко» не дає умов тестування. Не плутайте кількість користувачів із кількістю одночасних запитів. Якщо вимірювань немає, включіть їх до підготовчого етапу й не вигадуйте точний норматив.

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

8. Як пріоритезувати без нескінченного списку функцій?

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

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

Коли вимога змінюється, оцініть вплив на дані, інтеграції, тести, інструкції й відкриті операції. Запишіть рішення та версію документа. Не змінюйте погоджений зміст непомітно: команда й підрядник повинні розуміти, яку саме версію зараз реалізують і приймають.

9. Перевірте ТЗ спільним проходом

Зберіть власника процесу, майбутнього виконавця й технічного відповідального. Пройдіть контрольний сценарій за документом, не доповнюючи його усними домовленостями, яких ніде немає. Якщо учасники зупинилися на різних очікуваннях, зафіксуйте питання й внесіть рішення до тексту.

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

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

10. Структура, яку можна використати у власному проєкті

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

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

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