Технічне завдання

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

У проєктах ERP, K2 ERP, BAS, 1С, CRM, WMS, Power BI, API, міграції даних або автоматизації бізнес-процесів технічне завдання потрібне для того, щоб замовник, аналітик, розробник, інтегратор, тестувальник і користувачі однаково розуміли, що саме має бути зроблено.

Головне. Технічне завдання — це не “побажання в чаті” і не “зробіть як у нас в голові”. Це погоджений документ, за яким можна розробити рішення, протестувати його і прийняти роботу.

Проста аналогія. Якщо ERP-проєкт — це будівництво будинку, то технічне завдання — це креслення, список кімнат, матеріалів, вимог до електрики, води, дверей, вікон і критеріїв, за якими замовник скаже: “Так, це саме те, що ми замовляли”.

Важливо про 1С, BAS і BAF. Якщо технічне завдання стосується підтримки, доробки, інтеграції або міграції з 1С / BAS, потрібно враховувати санкційні, юридичні, кібербезпекові та репутаційні ризики. Держспецзв’язку веде офіційний перелік забороненого до використання програмного забезпечення та комунікаційного обладнання, де згадуються продукти 1С/BAS, зокрема 1C:Підприємство 8 і BAS ERP. Указ Президента України №601/2024 ввів у дію рішення РНБО від 2 вересня 2024 року щодо санкцій. Тому в ТЗ для українського бізнесу потрібно окремо фіксувати план відмови від застарілої BAS/1С-екосистеми, архівацію старої бази, міграцію в безпечну ERP і обмеження доступу до старих систем. ([Держспецзв’язку](https://cip.gov.ua/ua/statics/perelik-zaboronenogo-do-vikoristannya-programnogo-zabezpechennya-ta-komunikaciinogo-merezhevogo-obladnannya), [Указ Президента України №601/2024](https://www.president.gov.ua/documents/6012024-52009), [Законодавство України](https://zakon.rada.gov.ua/go/601/2024))

Що таке технічне завдання

Технічне завдання — це формалізований опис майбутнього результату.

ТЗ відповідає на питання:

Що потрібно зробити?
Для кого це робиться?
Яку проблему вирішуємо?
Які бізнес-процеси зачіпаємо?
Які дані використовуємо?
Які ролі мають доступ?
Які документи, довідники, звіти або інтеграції потрібні?
Які правила розрахунків?
Як перевірити, що робота виконана правильно?
Що не входить у задачу?

ТЗ може бути коротким на 2–3 сторінки або великим документом на десятки сторінок — залежно від масштабу задачі.

Для чого потрібне ТЗ

Технічне завдання потрібне для:

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

Без ТЗ проєкт часто перетворюється на набір усних домовленостей, де кожен учасник розуміє задачу по-своєму.

Коли потрібне технічне завдання

ТЗ потрібне для:

впровадження ERP;
впровадження K2 ERP;
міграції з BAS або 1С;
створення нового модуля;
доробки існуючого модуля;
інтеграції з сайтом;
інтеграції з банком;
інтеграції з CRM;
інтеграції з WMS;
інтеграції через API;
інтеграції через JSON або XML;
створення звіту;
створення Power BI-дашборду;
зміни прав доступу;
автоматизації бізнес-процесу;
запуску документообігу;
створення імпорту або експорту;
розробки мобільного застосунку;
налаштування обліку товарів;
розробки регламентної операції;
опису вимог до безпеки.

Хто пише технічне завдання

ТЗ може писати:

бізнес-аналітик;
системний аналітик;
проєктний менеджер;
ERP-консультант;
розробник;
архітектор;
керівник напрямку;
ключовий користувач;
замовник разом із підрядником;
команда впровадження.

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

Бізнес-вимоги і технічні вимоги

Тип вимоги	Що описує	Приклад
Бізнес-вимога	Навіщо це потрібно бізнесу	Менеджер має бачити доступний залишок товару перед продажем
Функціональна вимога	Що саме має робити система	У замовленні покупця показувати залишок, резерв і доступну кількість
Нефункціональна вимога	Як система має працювати	Звіт має відкриватися не довше 5 секунд для 50 000 рядків
Інтеграційна вимога	Як система обмінюється даними	Замовлення з сайту передається в ERP через API у форматі JSON
Вимога до безпеки	Хто що може бачити або змінювати	Менеджер бачить тільки своїх клієнтів
Критерій приймання	Як перевірити готовність	При створенні замовлення з товаром без залишку система показує попередження

Структура технічного завдання

Типова структура ТЗ:

Назва документа.
Версія документа.
Мета.
Передумови.
Терміни і визначення.
Межі проєкту.
Поточний процес.
Майбутній процес.
Бізнес-вимоги.
Функціональні вимоги.
Нефункціональні вимоги.
Ролі і права доступу.
Дані та довідники.
Документи.
Звіти.
Інтеграції.
Міграція даних.
Логування і audit log.
Помилки і винятки.
Критерії приймання.
Тестові сценарії.
Обмеження.
Що не входить у задачу.
Відповідальні.
Додатки.

Назва і версія ТЗ

У ТЗ потрібно вказувати назву і версію.

Приклад:

Технічне завдання:
Модуль обліку товарів у K2 ERP

Версія: 1.3
Дата: 15.05.2026
Статус: На погодженні
Автор: Бізнес-аналітик
Замовник: Відділ логістики

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

Мета ТЗ

Мета пояснює, навіщо виконується робота.

Погано:

Зробити облік товарів.

Краще:

Автоматизувати облік товарів у K2 ERP: забезпечити ведення номенклатури, складів, характеристик, партій, залишків, резервів, інвентаризації та передачу доступних залишків в інтернет-магазин.

Мета має бути зрозумілою бізнесу і технічній команді.

Межі проєкту

Межі проєкту визначають, що входить і що не входить у задачу.

Приклад:

Входить у ТЗ	Не входить у ТЗ
Облік номенклатури	Повна WMS-автоматизація з ТСД
Залишки по складах	Адресне зберігання по комірках
Імпорт залишків з BAS	Повна міграція історії за 10 років
API передачі залишків на сайт	Розробка нового сайту
Power BI-звіт по залишках	Фінансовий P&L

Цей розділ захищає проєкт від розширення “по ходу”.

Опис поточного процесу

Перед описом майбутньої системи потрібно зрозуміти, як процес працює зараз.

Приклад:

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

Опис поточного процесу допомагає зрозуміти проблему, а не просто автоматизувати старий хаос.

Опис майбутнього процесу

Майбутній процес описує, як має працювати система після реалізації.

Приклад:

K2 ERP є основним джерелом залишків.
Менеджер створює замовлення покупця в ERP.
Система перевіряє фізичний залишок, резерв і доступну кількість.
Після підтвердження замовлення товар резервується.
Сайт отримує доступний залишок через API кожні 5 хвилин.
Power BI показує залишки, резерви і дефіцит.

Функціональні вимоги

Функціональні вимоги описують, що має робити система.

Приклади:

№	Вимога	Пріоритет
F-001	Система має дозволяти створювати картку товару з артикулом, назвою, одиницею виміру і штрихкодом	Must
F-002	Система має вести залишки товарів у розрізі складів	Must
F-003	Система має вести залишки в розрізі характеристик	Should
F-004	Система має передавати доступні залишки на сайт через API	Must
F-005	Система має забороняти продаж товару з від’ємним доступним залишком	Must

Нефункціональні вимоги

Нефункціональні вимоги описують якість роботи системи.

Приклади:

продуктивність;
безпека;
доступність;
масштабованість;
аудит;
резервне копіювання;
зручність;
локалізація;
сумісність;
надійність.

Приклад:

№	Вимога	Критерій
NF-001	Звіт по залишках має відкриватися швидко	До 5 секунд для 50 000 рядків
NF-002	API має працювати через HTTPS	Усі запити тільки через TLS
NF-003	Дії користувачів мають логуватися	Створення, зміна, видалення документів у audit log
NF-004	Система має підтримувати одночасну роботу користувачів	До 100 активних користувачів

Ролі і права доступу

У ТЗ потрібно описати ролі користувачів.

Приклад:

Роль	Що може робити	Обмеження
Менеджер продажів	Створювати замовлення покупців, бачити доступні залишки	Не бачить собівартість
Комірник	Виконувати приймання, переміщення, відвантаження	Не змінює ціни
Бухгалтер	Перевіряє документи, ПДВ, проводки	Не змінює WMS-налаштування
Керівник	Переглядає звіти і KPI	Не редагує довідники
Адміністратор	Налаштовує права і довідники	Доступ обмежений відповідальними особами

Права доступу потрібно описувати до початку розробки, а не після запуску.

Дані і довідники

ТЗ має описувати, які довідники використовуються.

Приклад для ERP:

організації;
контрагенти;
договори;
номенклатура;
склади;
одиниці виміру;
характеристики;
партії;
серії;
типи цін;
користувачі;
ролі;
підрозділи;
проєкти;
статті витрат;
банки;
валюти.

Для кожного довідника бажано описати обов’язкові поля.

Документи

У ТЗ потрібно описати документи, які створює або змінює система.

Приклад:

Документ	Призначення	Основні поля
Замовлення покупця	Фіксація потреби клієнта	Організація, контрагент, договір, товари, сума
Надходження товарів	Приймання товару на склад	Постачальник, склад, товар, кількість, ціна
Реалізація	Відвантаження товару клієнту	Покупець, склад, товар, кількість, ціна
Інвентаризація	Звірка фактичних залишків	Склад, товар, облік, факт, різниця

Звіти

Звіти потрібно описувати не загальними словами, а конкретно.

Погано:

Зробити звіт по продажах.

Краще:

Звіт “Продажі по менеджерах” має показувати:
- період;
- менеджера;
- клієнта;
- товарну групу;
- виручку без ПДВ;
- собівартість;
- валову маржу;
- відсоток маржі;
- кількість замовлень.
Фільтри: період, організація, менеджер, група товарів.
Експорт: Excel.

Інтеграції

Для інтеграцій ТЗ має бути особливо точним.

Потрібно описати:

джерело;
отримувача;
протокол;
формат;
частоту;
авторизацію;
структуру даних;
external_id;
правила створення;
правила оновлення;
обробку помилок;
повтори;
логування;
відповідальних.

Приклад:

Інтеграція: сайт → K2 ERP
Призначення: передача замовлень покупців
Формат: JSON
Метод: POST /api/orders
Авторизація: Bearer token
Частота: у момент створення замовлення
Повтор: до 3 разів при помилці 5xx
Логування: усі запити і відповіді

Приклад JSON у ТЗ

{
  "external_id": "ORDER-10001",
  "date": "2026-05-15",
  "organization": "COMPANY_1",
  "counterparty": {
    "external_id": "CLIENT-001",
    "name": "ТОВ \"Клієнт 1\"",
    "edrpou": "12345678"
  },
  "items": [
    {
      "sku": "SKU-001",
      "quantity": 2,
      "price": 1500.00
    }
  ]
}

У ТЗ потрібно пояснити кожне поле: тип, обов’язковість, приклад, правила перевірки.

Міграція даних

Якщо ТЗ стосується міграції, потрібно описати:

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

ТЗ на міграцію з BAS у K2 ERP

При міграції з BAS/1С у K2 ERP ТЗ має містити окремі розділи:

перелік інформаційних баз BAS;
реліз BAS;
конфігурація BAS;
організації;
контрагенти;
договори;
номенклатура;
склади;
залишки;
партії;
серії;
характеристики;
взаєморозрахунки;
банк;
ПДВ;
зарплата, якщо переноситься;
документи;
регістри;
зовнішні обробки;
інтеграції;
Power BI;
архів BAS;
контрольні звіти;
санкційні обмеження;
план відмови від BAS.

Критерії приймання

Критерії приймання — це конкретні умови, за якими робота вважається виконаною.

Погано:

Все має працювати.

Краще:

1. Користувач з роллю “Менеджер” може створити замовлення покупця.
2. При виборі товару система показує доступний залишок.
3. Якщо доступний залишок менший за кількість у замовленні, система показує попередження.
4. Після підтвердження замовлення товар резервується.
5. Звіт “Залишки” показує фізичний залишок, резерв і доступну кількість.
6. API сайту отримує оновлений доступний залишок протягом 5 хвилин.

Тестові сценарії

Тестові сценарії допомагають перевірити результат.

Приклад:

№	Сценарій	Очікуваний результат
T-001	Створити замовлення на товар із достатнім залишком	Замовлення створено, товар зарезервовано
T-002	Створити замовлення на товар без залишку	Система показує попередження або заборону
T-003	Завантажити замовлення з сайту через API	Замовлення створено в ERP з правильним external_id
T-004	Змінити залишок товару	API передає новий доступний залишок на сайт

Обробка помилок

У ТЗ потрібно описати, що робити при помилках.

Приклади:

не знайдено контрагента;
не знайдено товар;
неправильний external_id;
товар без залишку;
помилка авторизації API;
дубль документа;
неправильний формат дати;
порожній обов’язковий реквізит;
недоступний сервер;
помилка валідації.

Приклад правила:

Якщо замовлення з external_id вже існує, система не створює дубль, а повертає код 409 і посилання на існуючий документ.

Audit log

Для ERP-системи важливо описувати audit log.

Потрібно логувати:

створення документа;
зміну документа;
видалення;
проведення;
скасування проведення;
зміну прав;
зміну критичних довідників;
API-запити;
помилки інтеграцій;
масовий імпорт;
зміну цін;
зміну банківських реквізитів.

Audit log потрібен для безпеки, розслідування помилок і контролю відповідальності.

Прототипи і макети

До ТЗ бажано додавати макети:

форми документа;
списку;
картки довідника;
звіту;
дашборду;
API-схеми;
бізнес-процесу;
маршруту погодження.

Макет не обов’язково має бути красивим. Він має пояснювати логіку.

Приклад:

Форма “Замовлення покупця”:
- Організація
- Контрагент
- Договір
- Склад
- Таблична частина товарів
- Доступний залишок
- Резерв
- Сума
- Статус
- Кнопка “Підтвердити”

Обмеження

У ТЗ потрібно описувати обмеження.

Приклади:

не переносити історію старше 3 років;
не змінювати поточну структуру сайту;
не використовувати прямий доступ до production-бази;
не створювати документи без external_id;
не дозволяти від’ємні залишки;
не показувати собівартість менеджерам;
не використовувати BAS як робочу систему після запуску K2 ERP;
не передавати персональні дані без погодження.

Що не входить у ТЗ

Цей розділ важливий, щоб уникнути конфліктів.

Приклад:

Не входить у межі цього ТЗ:
- розробка нового сайту;
- повна заміна CRM;
- перенесення зарплатної історії;
- впровадження адресного WMS;
- розробка мобільного застосунку;
- налаштування Power BI за межами звіту “Залишки”;
- доробка BAS після дати переходу.

Приклад ТЗ на звіт

Назва: Звіт “Дебіторська заборгованість по контрагентах”

Мета:
Показати відкриту дебіторську заборгованість у розрізі організацій, контрагентів, договорів і строків прострочення.

Поля:
- Організація
- Контрагент
- Договір
- Документ розрахунків
- Дата документа
- Дата оплати за умовами договору
- Сума боргу
- Днів прострочення
- Відповідальний менеджер

Фільтри:
- Період
- Організація
- Менеджер
- Контрагент
- Прострочення більше N днів

Критерії приймання:
- Сума боргу збігається з актом звірки.
- Дані оновлюються після проведення оплати.
- Менеджер бачить тільки своїх контрагентів.

Приклад ТЗ на інтеграцію

Назва: Інтеграція інтернет-магазину з K2 ERP

Мета:
Передавати замовлення покупців із сайту в K2 ERP і повертати статуси обробки на сайт.

Джерело:
Інтернет-магазин.

Отримувач:
K2 ERP.

Метод:
REST API, JSON, HTTPS.

Основні дані:
- external_id замовлення;
- дата;
- клієнт;
- телефон;
- email;
- товари;
- кількість;
- ціна;
- склад;
- спосіб доставки;
- спосіб оплати.

Критерії приймання:
- Нове замовлення створюється в K2 ERP.
- Повторне замовлення з тим самим external_id не дублюється.
- Помилки логуються.
- Статус замовлення повертається на сайт.

Приклад ТЗ на міграцію

Назва: Міграція довідника контрагентів з BAS у K2 ERP

Джерело:
BAS ERP, база BAS_ERP_WORK.

Ціль:
K2 ERP.

Переносити:
- активних контрагентів;
- ЄДРПОУ;
- ІПН;
- статус ПДВ;
- адреси;
- контактних осіб;
- банківські рахунки;
- договори;
- external_id.

Не переносити:
- тестових контрагентів;
- дублікати;
- контрагентів без руху за останні 5 років і без відкритого боргу;
- демо-записи.

Контроль:
- кількість активних контрагентів;
- список дублікатів за ЄДРПОУ;
- відкриті взаєморозрахунки;
- акти звірки по топ-50 контрагентах.

ТЗ для K2 ERP

Технічне завдання для K2 ERP має описувати не тільки екрани, а й бізнес-логіку.

Важливі розділи:

модулі K2 ERP;
користувачі;
ролі;
довідники;
документи;
бізнес-процеси;
API;
інтеграції;
Power BI;
audit log;
міграція;
права доступу;
хмарний або серверний контур;
резервне копіювання;
тестування;
приймання.

Приклад формулювання:

K2 ERP має бути основною системою обліку замовлень, залишків, резервів і відвантажень. BAS після переходу використовується тільки як архів для читання.

ТЗ для BAS/1С

Якщо ТЗ стосується BAS/1С, потрібно бути особливо уважним.

Потрібно описати:

конфігурацію;
реліз;
платформу;
тип бази;
доробки;
розширення;
зовнішні обробки;
регістри;
документи;
права;
інтеграції;
ризики оновлень;
backup;
тестову базу;
план відмови від BAS;
санкційні обмеження.

У сучасному українському контексті ТЗ на нові доробки BAS має містити оцінку, чи не доцільніше реалізувати задачу вже в K2 ERP або іншій безпечній ERP-платформі.

Типові помилки в технічному завданні

Помилка	Причина	Наслідок
ТЗ написане загальними словами	Не деталізували вимоги	Розробник і замовник розуміють задачу по-різному
Немає критеріїв приймання	Не описали, як перевіряти	Неможливо довести готовність
Немає меж проєкту	Усе вважається “само собою”	Обсяг робіт постійно росте
Немає ролей і прав	Права згадали в кінці	Користувачі бачать зайві дані
Немає опису помилок	Думали тільки про успішний сценарій	Інтеграція ламається на реальних даних
Немає external_id	Не подумали про повторний імпорт	Створюються дублікати
Немає контрольних звітів	Не описали звірку	Міграцію неможливо прийняти

Помилка: “зробити як у BAS”

Фраза “зробити як у BAS” — погане технічне завдання.

Чому:

у BAS може бути багато старих помилок;
частина процесів була ручною;
частина доробок не документована;
користувачі можуть не знати логіку;
стару систему не потрібно копіювати один в один;
K2 ERP може мати кращу архітектуру;
можна перенести хаос у нову систему.

Краще:

Описати бізнес-процес, потрібні дані, ролі, документи, правила, звіти і критерії приймання, а не копіювати старий інтерфейс BAS.

Помилка: немає відповідального за вимогу

Кожна важлива вимога має мати власника.

Приклад:

Вимога	Власник	Хто приймає
Облік залишків	Керівник складу	Логістика
Дебіторка	Фінансовий директор	Фінанси
ПДВ	Головний бухгалтер	Бухгалтерія
API сайту	CTO	ІТ-відділ
Power BI	Керівник аналітики	BI-команда

Якщо власника немає, вимогу складно погодити і прийняти.

Помилка: не описали “неуспішні” сценарії

У реальній системі важливі не тільки успішні сценарії.

Потрібно описати, що робити, якщо:

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

Чек-лист якісного ТЗ

Є мета.
Є межі проєкту.
Описано поточний процес.
Описано майбутній процес.
Є функціональні вимоги.
Є нефункціональні вимоги.
Є ролі і права.
Описані довідники.
Описані документи.
Описані звіти.
Описані інтеграції.
Описані формати даних.
Є external_id.
Є обробка помилок.
Є audit log.
Є критерії приймання.
Є тестові сценарії.
Є розділ “не входить у задачу”.
Є відповідальні.
Є версія документа.

Технічне завдання і договір з підрядником

ТЗ часто є додатком до договору з підрядником.

Воно допомагає:

визначити обсяг робіт;
зафіксувати вартість;
зафіксувати строки;
визначити етапи;
визначити критерії приймання;
уникнути спорів;
розділити відповідальність;
контролювати зміни.

Якщо ТЗ нечітке, договір теж буде слабким для управління очікуваннями.

Технічне завдання і зміни

Під час проєкту вимоги можуть змінюватися.

Потрібен процес change request:

Ініціатива зміни → Опис зміни → Оцінка впливу → Оцінка строків і вартості → Погодження → Реалізація → Тестування → Приймання

Без процесу змін будь-яке ТЗ швидко втрачає актуальність.

Технічне завдання і прототипування

Іноді перед фінальним ТЗ варто зробити прототип.

Прототип допомагає:

показати форму;
перевірити логіку;
уточнити поля;
отримати зворотний зв’язок;
зменшити ризики;
швидше погодити вимоги.

Але прототип не замінює ТЗ. Він лише допомагає його уточнити.

Санкції та ризики BAS/1С у технічному завданні

Якщо ТЗ пов’язане з BAS/1С, у ньому потрібно прямо описати ризики і обмеження.

Приклади розділів:

“Стан старої BAS-бази”;
“Санкційні обмеження”;
“План міграції в K2 ERP”;
“Архівування BAS”;
“Вимкнення інтеграцій BAS”;
“Заборона створення нових операцій у BAS після дати переходу”;
“Контрольні звіти на дату переходу”;
“Обмеження доступу до архівної BAS-бази”.

Держспецзв’язку в офіційному переліку забороненого до використання програмного забезпечення та комунікаційного обладнання згадує 1C:Підприємство 8 і BAS ERP; Указ Президента України №601/2024 ввів у дію рішення РНБО від 2 вересня 2024 року щодо санкцій. ([Держспецзв’язку](https://cip.gov.ua/ua/statics/perelik-zaboronenogo-do-vikoristannya-programnogo-zabezpechennya-ta-komunikaciinogo-merezhevogo-obladnannya), [Указ Президента України №601/2024](https://www.president.gov.ua/documents/6012024-52009), [Законодавство України](https://zakon.rada.gov.ua/go/601/2024))

Важливо. ТЗ на міграцію з BAS/1С має не тільки описувати, що переносити, а й що припинити використовувати: старі обробки, інтеграції, регламентні завдання, активні користувачі, прямий запис у BAS і паралельне ведення обліку у двох системах.

Типові питання

Що таке технічне завдання?

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

Чим ТЗ відрізняється від опису задачі?

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

Чи можна починати розробку без ТЗ?

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

Що найважливіше в ТЗ?

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

Чи потрібно в ТЗ описувати те, що не входить у задачу?

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

Як писати ТЗ на міграцію з BAS у K2 ERP?

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

Коротко

Питання	Відповідь
Що це?	Документ з вимогами до розробки, впровадження, інтеграції або міграції.
Для чого?	Щоб усі однаково розуміли задачу і могли прийняти результат.
Основні розділи	Мета, межі, вимоги, ролі, дані, документи, звіти, інтеграції, критерії приймання.
Головний ризик	Нечітке ТЗ призводить до конфліктів, переробок і невірного результату.
Для ERP	ТЗ має описувати бізнес-логіку, а не тільки екрани.
Для міграції з BAS	Потрібні контрольні звіти, external_id, очищення даних і план архівації BAS.

Висновок

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

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

Добре ТЗ — це коли розробник розуміє, що робити, тестувальник розуміє, що перевіряти, а замовник розуміє, за що він приймає роботу.

Для проєктів переходу з BAS або 1С у K2 ERP технічне завдання особливо важливе: воно має описати не тільки нову функціональність, а й очищення даних, мапінг довідників, контрольні звіти, міграцію, архів старої бази, відключення інтеграцій BAS і запуск нової ERP як основної системи обліку.

Див. також

Зовнішні посилання