Технічне завдання за $0: чому погано сформульована задача може коштувати бізнесу тисячі доларів

У розробці є одна парадоксальна річ: найдешевша частина IT-проєкту може виявитися однією з найдорожчих. Йдеться про постановку задачі.

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

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

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

«Зробіть як у конкурента» — це не технічне завдання

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

Для людини, яка бачила сайт конкурента, усе може здаватися очевидним. Але для розробника виникає десятки питань.

Що саме потрібно повторити? Логіку роботи? Дизайн? Поведінку користувача? Які дані система повинна зберігати? Що відбувається, якщо користувач не заповнив поле? Які права доступу має адміністратор? Що відбувається після натискання кнопки? Чи повинна функція працювати на мобільних пристроях? Чи потрібна інтеграція з CRM?

Без відповідей на ці питання команда починає робити не те, що потрібно бізнесу, а те, як вона зрозуміла поставлену задачу.

І це принципова різниця.

Хороше ТЗ не обов'язково має бути величезним документом на 50 сторінок. Воно повинно прибирати невизначеність там, де вона може вплинути на результат, бюджет або строки.

Кожне невизначене рішення має свою ціну

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

Задача звучить просто: «Додати калькулятор, щоб користувач міг порахувати ціну».

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

А може не уточнювати і реалізувати базову версію на власний розсуд.

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

Формально розробник виконав задачу. Але бізнес отримав функцію, яка не вирішує потрібну проблему.

І тут виникає найдорожче слово в IT — «переробити».

Чим пізніше знаходять помилку, тим дорожче її виправляти

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

Якщо ту саму помилку знаходять після розробки, потрібно змінити код.

Якщо після інтеграції — можуть знадобитися зміни ще в кількох системах.

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

Саме тому в IT існує простий принцип: чим раніше виявлена проблема, тим дешевше її виправити.

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

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

Найнебезпечніше ТЗ — те, яке здається всім зрозумілим

Парадоксально, але найбільше проблем виникає не завжди зі складними задачами.

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

А ось прості задачі часто отримують формулювання на кшталт:

«Додати оплату».

На перший погляд усе зрозуміло. Але що саме це означає?

Підписуйтеся на наші соцмережі

Які способи оплати потрібні? Чи повинна система підтримувати Apple Pay та Google Pay? Що відбувається при невдалій транзакції? Чи потрібно автоматично змінювати статус замовлення? Чи надходить повідомлення клієнту? Що бачить адміністратор? Як обробляється повернення?

Одна коротка фраза може приховувати цілий окремий проєкт.

Тому хороший менеджер або бізнес-аналітик не намагається зробити задачу максимально короткою. Його завдання — зробити її однозначною.

«Розробник сам розбереться» — дорога стратегія

Ще одна поширена помилка — перекладати бізнес-рішення на розробника.

Наприклад, власник каже: «Зробіть зручну форму замовлення».

Але «зручна» — це не технічна вимога.

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

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

Розробник відповідає за те, як реалізувати рішення. Бізнес має визначити, яке рішення йому потрібно.

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

Погане ТЗ створює конфлікт, якого можна було уникнути

Є ще одна проблема нечітких задач — вони ускладнюють оцінку результату.

Коли немає чітко визначених критеріїв готовності, замовник може сказати: «Це не те, що я хотів».

Розробник у відповідь може сказати: «Але саме це було написано в задачі».

І обидві сторони можуть бути праві.

Проблема не обов'язково в некомпетентності команди. Вона могла виникнути ще до початку роботи, коли очікування бізнесу залишилися тільки в голові замовника.

Тому хороша постановка задачі повинна відповідати не лише на питання «що зробити?», а й на питання «як ми зрозуміємо, що це зроблено правильно?»

Це називається критеріями приймання.

Критерії приймання економлять час усій команді

Наприклад, замість:

«Додати фільтри до каталогу».

можна сформулювати:

«Користувач повинен мати можливість відфільтрувати товари за категорією, ціною та брендом. Фільтри мають працювати без перезавантаження сторінки. Після застосування фільтра URL повинен оновлюватися, щоб результат можна було передати за посиланням. На мобільному пристрої фільтри відкриваються через окрему кнопку».

Це вже не просто побажання.

Команда розуміє, що саме потрібно реалізувати, QA розуміє, що тестувати, а замовник — що саме він отримає в результаті.

Чим чіткіші критерії, тим менше простору для суб'єктивного трактування.

ТЗ — це не тільки документ для розробника

Хороша постановка задачі потрібна не лише програмісту.

Для PM це спосіб оцінити обсяг роботи, залежності та строки.

Для дизайнера — розуміння того, який сценарій користувача потрібно підтримати.

Для розробника — конкретні функціональні вимоги та обмеження.

Для QA — критерії, за якими перевіряти результат.

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

Тобто якісне ТЗ фактично стає спільною точкою синхронізації для всієї команди.

Не потрібно описувати в ТЗ абсолютно все

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

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

Тому хороший підхід — деталізувати саме те, що впливає на результат.

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

А те, що команда може визначити самостійно на рівні технічної реалізації, не обов'язково перетворювати на окремий пункт.

Технічне завдання має прибирати невизначеність, а не створювати бюрократію.

Як зрозуміти, що задача сформульована достатньо добре

Перед передачею задачі в розробку можна поставити кілька простих запитань.

Чи зрозуміло, навіщо потрібна ця функція?

Чи зрозуміло, хто буде нею користуватися?

Чи описаний основний сценарій роботи?

Чи зрозуміло, що повинно відбуватися у нестандартних ситуаціях?

Чи визначені залежності від інших систем?

Чи зрозуміло, які дані система отримує та що повинна зробити з ними?

Чи можна однозначно перевірити, що задача виконана?

І головне — чи зможе інша людина прочитати задачу та зрозуміти її так само, як автор?

Якщо відповідь на останнє питання негативна, задачу ще рано віддавати в розробку.

Найдорожче в IT — не написати код, а написати не той код

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

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

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

Якщо команда витратила 40 годин на функцію, яка після релізу виявилася непотрібною або неправильною, ці 40 годин не можна повернути. А якщо для виправлення потрібно ще 20 годин, бізнес фактично заплатить за одну функцію півтора рази.

Саме тому якісна постановка задач — це не бюрократія і не «робота заради документа».

Це інструмент управління бюджетом.

Висновок

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

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

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

У результаті бізнес отримує не просто більш зрозумілий процес розробки. Він отримує контроль над бюджетом, строками та результатом.

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