Технічне завдання, ТЗ, це документ, який усі хочуть мати й ніхто не хоче писати. Клієнт вважає, що ТЗ має написати виконавець, адже він фахівець. Виконавець вважає, що ТЗ має дати клієнт, адже це його бізнес. Зрештою ТЗ пишеться поспіхом, в останній момент, на дві сторінки загальних слів, і проєкт стартує з фундаментом із піску.
Я бачив, як погане ТЗ вбивало проєкти, які могли б стати прекрасними. І бачив, як добре ТЗ рятувало проєкти з посередньою командою. Це не перебільшення: ТЗ це контракт між бізнесом і розробкою. Що воно чіткіше, то менше конфліктів під час приймання робіт, то точніша оцінка і то менше грошей іде на переробки.
Креслення, а не побажання
Жоден архітектор не почне будувати будинок за фразою «хочу гарний і зручний». Він спитає: скільки поверхів, скільки людей житиме, чи потрібен гараж, який бюджет, яка ділянка, де сходить сонце. А потім намалює креслення, на якому видно кожну стіну й кожне вікно. І лише після того, як замовник підпише це креслення, будівельники візьмуться до роботи.
У розробці програм чомусь вважається, що можна обійтися без креслення. «Давайте почнемо, а дорогою розберемося». Це працює рівно до першої суперечки, яка звучить так: «Я ж казав, що мені потрібно...», а у відповідь: «Ні, не казали». І обидва мають рацію, бо кожен памʼятає свою версію розмови. ТЗ потрібне саме для того, щоб версія була одна.
Що обовʼязково має бути в ТЗ
Цілі та бізнес-логіка. Навіщо створюється система, яку проблему вона розвʼязує, хто нею користуватиметься. Це перший розділ, і він найважливіший. Якщо розробник не розуміє мети, він ухвалюватиме рішення наосліп. Коли мета зрозуміла, команда сама пропонує простіші й дешевші шляхи її досягнення.
Ролі користувачів. Хто працює із системою і що кожному дозволено. Клієнт, менеджер, адміністратор, бухгалтер: у кожного свій набір екранів і дій. З цього розділу народжується половина архітектури.
Детальний опис функціоналу. Не «система має керувати замовленнями», а конкретні сценарії: клієнт оформлює замовлення, обирає доставку, оплачує, отримує сповіщення; менеджер бачить замовлення в списку, змінює статус, звʼязується з клієнтом. Кожен сценарій із початком, кроками, розгалуженнями й результатом.
Структура даних. Які сутності є в системі і як вони повʼязані. Клієнт, замовлення, товар, оплата. Це мова, якою говоритимуть і бізнес, і код. Якщо назви в ТЗ і в програмі не збігаються, за рік ніхто не зрозуміє, що є що.
Вимоги до дизайну. Хоча б схеми екранів, хоча б від руки. Один ескіз інтерфейсу знімає десяток питань.
Нефункціональні вимоги. Швидкість роботи, безпека, кількість користувачів, резервне копіювання, підтримка браузерів і пристроїв. Про них забувають найчастіше, і саме вони потім стають найдорожчими сюрпризами. Я писав про них окрему статтю й дуже раджу до неї повернутися.
Критерії приймання. Як ми зрозуміємо, що система готова. Конкретні умови, які можна перевірити, а не «усе працює добре».
Правила, які я виніс із практики
Перше: пишіть для людини, яка не була на Ваших зустрічах. ТЗ читатиме новий програміст за пів року, тестувальник, який прийшов посеред проєкту, інший підрядник, якщо з першим не складеться. Усе, що «й так зрозуміло», зрозуміло лише Вам.
Друге: одна вимога, одна думка. Вимогу «система має бути швидкою, зручною й безпечною» неможливо перевірити. Розділіть її на три, і для кожної напишіть, що саме означає швидко, зручно й безпечно.
Третє: описуйте, що робити, коли щось іде не так. Більшість ТЗ описують лише щасливий шлях: користувач усе ввів правильно, оплата пройшла, сервер відповів. А реальність складається з помилок, скасувань, порожніх полів і збоїв звʼязку. Саме на цих розгалуженнях і народжуються баги та суперечки.
Четверте: ТЗ це живий документ, але з правилами змін. Вимоги змінюватимуться, це нормально. Але кожна зміна має фіксуватися, оцінюватися й погоджуватися, а не просто прилітати в чат. Інакше ТЗ за місяць перестає відображати реальність, і всі знову працюють за памʼяттю.
Пʼяте: не намагайтеся описати все одразу. Для першої версії продукту потрібне ТЗ на першу версію. Докладний опис функцій, які зʼявляться за два роки, це змарнований час, бо на той момент усе зміниться.
Хто має писати ТЗ
Моя відповідь: разом. Клієнт знає свій бізнес, але не знає, як перетворити його на програму. Виконавець знає, як будувати програми, але не знає бізнесу клієнта. Добре ТЗ народжується в діалозі, де бізнес-аналітик чи архітектор ставить питання, а клієнт відповідає, і де обидві сторони малюють і правлять одну й ту саму картину.
Якщо виконавець береться за проєкт без ТЗ або за ТЗ із двох абзаців і одразу називає фіксовану ціну, будьте обережні. Або він заклав величезний запас, або Ви скоро дізнаєтеся, що «це не входило в домовленість».
Як ми робимо це в Ingello
Ми пішли далі за класичне текстове ТЗ. В Ingello Systems частина технічного завдання пишеться не прозою, а формальними описами: схемою даних на SFL, картою екранів і сценаріїв на ISFL, розміткою інтерфейсів на IFL. Генератор Fractal перетворює цей опис на робочий прототип із базою, API та адмінкою. Клієнт бачить не документ на пʼятдесят сторінок, а систему, у якій можна клікати вже за кілька днів. І сперечатися стає значно простіше: ось екран, ось дані, це те, що Ви хотіли, чи ні?
Але навіть без генераторів принцип той самий: що ближче ТЗ до креслення і що далі від побажання, то успішніший проєкт. Якщо завтра Ви починаєте новий проєкт, почніть не з пошуку розробників, а з відповіді на питання, яке поставив би архітектор: що саме ми будуємо, для кого і як зрозуміємо, що збудували.
