Технічне завдання на додаток: як скласти, щоб не переплатити

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

Я керую розробкою й найчастіше бачу дві крайнощі. Одні пишуть ТЗ на пів сторінки в стилі «зробіть як Uber, тільки для нас». Інші видають стос на сто аркушів, де важливе тоне серед води. Обидва варіанти дорогі, бо не дають виконавцю однозначної картини.

Навіщо ТЗ насправді

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

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

Що має бути в ТЗ

Мінімум, без якого ТЗ не працює:

• Мета й аудиторія. Яку задачу користувача закриває додаток і для кого він.
• Платформи. iOS, Android чи обидві, і чому.
• Список екранів і сценаріїв. Що людина робить крок за кроком, від входу до цільової дії.
• Ролі користувачів. Гість, зареєстрований, адміністратор і що кожному доступно.
• Інтеграції. Оплата, карти, пуші, аналітика, зовнішні сервіси й API.
• Нефункціональні вимоги. Мови, офлайн-режим, вимоги до швидкодії.
• Критерії готовності. За якими ознаками фіча вважається зробленою.

Цього достатньо, щоб виконавець оцінив роботу однозначно, а не діапазоном від і до.

Критерій готовності це число, а не прикметник

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

Порівняйте: «каталог відкривається швидко» проти «екран каталогу показує перші товари за 2 секунди на 4G при 500 позиціях». Друге можна виміряти й прийняти, перше можна лише обговорювати. Правило просте: якщо критерій не перевіряється секундоміром, кількістю кроків, кодом відповіді або скріншотом, це не критерій, а побажання. Саме на таких формулюваннях зриваються прийомки, бо переробка починається там, де мало б стояти «прийнято».

Де ловлять непорозуміння за копійки

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

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

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

Як не роздути ТЗ

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

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

Часті питання

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

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

Що робити зі змінами після старту?
Фіксувати їх окремо як зміну обсягу з новою оцінкою. Зміни це нормально, ненормально робити їх непомітно й потім сперечатися про ціну.

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

Підсумок

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

Автор: Ілля Денисов, Head of PM, Chyzh Agency.