Дев'яносто відсотків конфліктів між бізнесом та IT починаються з однієї фрази: «Ну це ж було очевидно!».
Для замовника очевидно, що кошик в інтернет-магазині має резервувати товар на складі. А для програміста очевидно лише те, що написано в рядку 45 технічного завдання. Якщо там цього немає — ви отримаєте продукт, який працює виключно в ідеальному вакуумі.
Індустрія розробки переповнена красивими казками про «індивідуальний підхід». Темна сторона полягає в тому, що слабке або розмите ТЗ — це золота жила для недобросовісних виконавців. Ви пишете «зробіть сучасний сайт зі зручною адмінкою», а розробник читає це як «ставимо безкоштовну CMS, накидуємо зверху двадцять важких плагінів, забираємо гроші і зникаємо». Коли через три місяці ваша база даних ляже від напливу сотні користувачів, вам просто скажуть: «У ТЗ про навантаження нічого не було, платіть за рефакторинг».
Щоб розробка не перетворилася на спалювання бюджету, ТЗ має бути інженерним документом, а не листом до Діда Мороза.
Правило 1. Описуйте бізнес-проблему, а не колір кнопок
Найгірше ТЗ починається з того, що клієнт намагається працювати архітектором. Ви пишете: «Нам потрібна кнопка, яка вивантажує замовлення в Excel, щоб менеджер потім руками забивав їх у службу доставки».
Ви замовляєте милицю, і розробник радісно вам її продасть.
Як треба: «Менеджери витрачають дві години на день на ручне перенесення даних в кабінет Нової Пошти. Потрібно повністю прибрати людський фактор з цього процесу». Професійний інженер на основі цього ТЗ не робитиме кнопку завантаження. Він побудує інтеграцію по API, яка автоматично генеруватиме ТТН в момент оплати. Ви платите за вирішення проблеми, а не за написання коду заради коду.
Правило 2. Закладайте негативні сценарії (Corner Cases)
Всі описують в ТЗ ідеальний шлях користувача: зайшов, поклав у кошик, оплатив, отримав. Але реальний інтернет складається з помилок, обривів зв'язку та глюків сторонніх сервісів.
Реальний приклад з практики фінансових інтеграцій. Замовник просить підключити оплату через еквайринг. Сторонній банк обробляє платіж і надсилає на ваш сервер вебхук про успішну оплату. Але сервер на 4 секунди зависає. Банк не отримує відповіді і кидає повторний запит. Той самий ID транзакції, той самий статус. Якщо в ТЗ не була прописана ідемпотентність (здатність системи не дублювати дії при повторних однакових запитах), ваш код просто забронює клієнту послугу двічі, або видасть подвійний доступ. І клієнт дивитиметься на це з повним нерозумінням.
ТЗ має містити розділ «Що відбувається, якщо...»:
Відвалився платіжний шлюз під час транзакції.
Користувач двічі швидко натиснув кнопку «Оплатити».
Стороння CRM лежить і не приймає ліди.
Правило 3. Архітектура та обмеження технологій
Якщо ви плануєте масштабувати бізнес, це має бути в першому рядку ТЗ. Більшість дешевих рішень на ринку робляться через конструктори або шаблонні системи, які неможливо доопрацювати. Якщо вам потрібен кастомний функціонал, наприклад, власна ERP-система чи специфічна логіка складського обліку, вимагайте розробку на чистому коді без CMS.
API-first архітектура — це коли ваш бекенд є незалежним ядром, до якого можна підключити що завгодно: веб-сайт, мобільний додаток, термінал у магазині. Вказуйте в ТЗ жорстку вимогу: відсутність прив'язки до вендора (No Vendor Lock-in). Ви маєте володіти кодом і базою, а не сидіти на голці щомісячних підписок на сторонні плагіни.
Де дивитися виворіт розробки
Правильне ТЗ вимагає розуміння базової механіки того, як працює IT в реальному світі, а не на презентаціях маркетингових агенцій. Ми розбираємо архітектуру, фатальні помилки при проектуванні систем та логіку автоматизації бізнесу без прикрас у нашому телеграм-каналі https://t.me/vgrb_expert.
Якщо ж ви хочете побачити, як виглядають серйозні інструменти, спроектовані під реальні навантаження — від кастомних e-commerce платформ до AI-ERP систем, які створюються під ключ і передаються у вашу повну власність, вивчіть підходи на https://crm-saas-bot.cx.ua/. Це місце, де бізнес-задачі перетворюються на чистий код, а не на колекцію плагінів.
Погляд скептика
Якби я був тим самим читачем, який давно втомився від SEO-статей, води та інфоциганських обіцянок «зробити стартап за тиждень», цей текст став би для мене тригером довіри.
Чому я готовий застосувати це на практиці прямо зараз? Тому що тут ніхто не намагається продати мені «ідеальний дизайн» чи «кнопку, яка збільшить конверсію на 300%». Стаття б'є у найболючіше місце будь-якого замовника — втрату контролю над проектом. Приклад із зависанням сервера на 4 секунди і подвійним списанням — це маркер того, що автор тексту реально сидів у консолі і дебажив помилки на продакшені, а не просто перекладав західні блоги.
Коли мені кажуть «вимагайте ідемпотентність і API-first замість Вордпресу», я бачу експертизу. Я розумію, що якщо завтра піду до розробників із таким списком вимог, половина халтурників відсіється сама собою на етапі переговорів, бо вони просто не вміють писати системи, які не падають. І саме тому я без вагань скопіюю ці три правила у свій наступний бриф, а потім перейду за посиланнями, щоб подивитися, що ще ці інженери можуть розповісти про технічний бекграунд моїх конкурентів.
