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