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

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

Ключові висновки

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

Зміст

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

Навіщо замовнику технічне завдання

ТЗ потрібне не виконавцю «для порядку», а вам. Воно закриває чотири задачі.

Оцінка. Виконавець рахує години з обсягу робіт, тож без опису обсягу будь-яка цифра — здогад. Магне Йоргенсен, який досліджує оцінювання програмних проєктів, серед своїх порад прямо радить уникати ранніх оцінок, зроблених на дуже неповній інформації (M. Jørgensen, IEEE Software / InfoQ). Технічне завдання і є тією інформацією, на якій оцінка тримається.

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

Модель оплати. Мартін Фаулер звертає увагу: коли кажуть «фіксована ціна», зазвичай мають на увазі, що фіксують одразу ціну, строк і обсяг, а для цього потрібні детальні, стабільні й точні вимоги (Martin Fowler, Fixed price). Тобто якщо ви хочете погодити фіксований обсяг, без детального ТЗ не обійтися. Якщо вимоги ще з'ясовуються, чесніше обрати оплату за фактичні години або фіксований бюджет зі змінним складом функцій.

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

Звідси головний принцип для всього документа: кожну вимогу можна зрозуміти однозначно і перевірити.

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

Назви розділів у різних команд відрізняються, але зміст майже завжди такий:

1. Мета і контекст. Яку задачу бізнесу розв'язує програма, як ви працюєте зараз і що вважатимете успіхом.
2. Користувачі й ролі. Хто працює з програмою: клієнт, менеджер, бухгалтер, склад, адміністратор. Для кожної ролі — що вона бачить і що може змінювати.
3. Сценарії і функції. Що робить кожна роль. Зручний формат — коротка історія: «Як менеджер, я хочу бачити нові замовлення одним списком, щоб не шукати їх у пошті». Друга половина речення пояснює, навіщо функція, і допомагає виконавцю запропонувати простіше рішення.
4. Дані. Що зберігає програма, звідки беруться дані і чи треба переносити старі — з таблиць чи попередньої системи. Персональні дані клієнтів — окремим рядком: які саме і хто має до них доступ.
5. Інтеграції. Облікова програма, оплата карткою, служба доставки, програмний РРО, пошта, месенджери. Для кожної системи — які дані передаються і в який бік, хто дає доступи й документацію.
6. Нефункціональні вимоги. Як швидко має працювати програма і скільки людей користуватиметься нею одночасно, які вимоги до безпеки й доступів, на яких пристроях і в яких браузерах вона працює, якими мовами інтерфейс, де і як довго зберігаються дані.
7. Обмеження і припущення. Бюджет чи дата, якщо їх уже визначено, системи, які треба зберегти, і все, що вам здається очевидним, — саме таке найлегше забути записати.
8. Що не входить. Функції, які свідомо відкладено. Без цього розділу межі обсягу кожна сторона розуміє по-своєму.
9. Критерії приймання. Як перевірити, що кожен сценарій працює. Про це — окремий розділ нижче.
10. Відкриті питання. Що ще не вирішено і хто з вашого боку це вирішить.

Пріоритети: що обов'язково в першій версії

Коли список функцій довгий, кожній варто дати пріоритет. Поширений спосіб — метод MoSCoW, який описує Agile Business Consortium: вимоги ділять на ті, що мають бути (Must Have), бажані (Should Have), можливі (Could Have) і ті, яких цього разу не буде (Won't Have this time). Must Have — це мінімальний набір вимог, за якого результатом уже можна користуватися. Won't Have — те, що команда погодилася не робити в цьому періоді. Консорціум радить, щоб на Must Have припадало зазвичай не більше 60 % зусиль: більша частка додає ризику, якщо оцінки, підхід і команда не перевірені (Agile Business Consortium, MoSCoW).

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

Зразок технічного завдання: шаблон для заповнення

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

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

Як ТЗ відрізняється для інтеграції, SaaS чи кабінету клієнта

Структура та сама для будь-якої розробки на замовлення, але в кожного типу проєкту свій розділ, від якого залежить найбільше.

Інтеграція. Коли треба з'єднати облік, оплату, доставку чи програмний РРО, головний розділ ТЗ — інтеграції. Для інтеграції систем через API опишіть кожну систему: які дані передаються, у який бік і як часто, хто дає доступи й документацію, що має статися, коли інша система не відповідає. Якщо в програми немає API, так і напишіть: тоді шукають інший спосіб обміну даними, а це інший обсяг роботи.

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

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

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

Перша версія продукту. Коли ви запускаєте MVP, щоб перевірити ідею на перших користувачах, ТЗ коротше, а пріоритети важливіші. Розділи «не входить» і «відкриті питання» тут не формальність: вони показують, що свідомо відкладено на потім.

Технічне завдання на сайт: що змінюється

Сайт — один із випадків тієї самої структури, але з власними розділами. Крім мети, ролей та інтеграцій, у ТЗ на сайт варто записати:

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

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

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

Критерії приймання: як записати, що роботу виконано

Критерій приймання — це перевірка, яку можна виконати і отримати відповідь «так» чи «ні». «Зручний пошук» не перевіриш, а «пошук знаходить товар за частиною назви і за артикулом» — перевіриш.

Зручний формат для таких перевірок — «Дано — Коли — Тоді» (Given — When — Then). Його розробили Деніел Терхорст-Норт і Кріс Маттс у межах підходу Behavior-Driven Development. «Дано» описує стан до дії, «Коли» — саму дію, «Тоді» — зміни, які мають статися в результаті (Martin Fowler, Given when then). Наприклад:

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

Крім критеріїв для окремих функцій, корисно домовитися про загальні ознаки готовності для всієї роботи. У Scrum їх називають Definition of Done — формальним описом стану результату, коли він відповідає вимогам до якості продукту. Робота, яка цим ознакам не відповідає, не вважається готовою і не випускається (The Scrum Guide). Для вашого ТЗ це може бути короткий список: перевірено на телефоні й комп'ютері, тестові дані прибрано, є інструкція для адміністратора, код лежить у вашому репозиторії.

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

Часто проблема ТЗ не в тому, чого бракує, а в тому, як написано те, що є.

• Оцінні слова замість перевірок. «Швидко», «зручно», «сучасний дизайн» кожен розуміє по-своєму. Замініть їх на те, що можна перевірити.
• Рішення замість задачі. «Зробити як у конкурента» чи «на технології X» без пояснення навіщо. Опишіть задачу, а рішення залиште тим, хто його проєктуватиме, або попросіть обґрунтувати вибір.
• Немає розділу «не входить». Тоді розмова про те, що входило в роботу, починається наприкінці, а не на старті.
• Забуто дані. Перенесення старих даних — окрема робота з власними ризиками. Якщо її немає в ТЗ, її немає і в оцінці.
• Усе обов'язкове. Без пріоритетів неможливо вирішити, що відкласти, коли бюджет чи дата підтискають.
• Немає того, хто вирішує. Коли вимоги погоджують кілька людей і ні в кого немає останнього слова, у документі з'являються правки, що суперечать одна одній. Назвіть одну людину, яка ухвалює рішення.
• Документ, який ніхто не дочитав. Сотня сторінок загальних фраз не допомагає: важливі вимоги губляться серед шаблонних.

Хто пише ТЗ і що робити, якщо його немає

Є три робочі варіанти, і їх можна поєднувати.

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

Разом із виконавцем. Вимоги можна формулювати разом із командою на короткому етапі дослідження перед розробкою. У нас перший крок такий: коли ви надсилаєте ідею, ми розбираємо обсяг, ризики й архітектуру, а тоді повертаємося з чіткою пропозицією та планом. Жодних зобов'язань, доки ви не впевнені в плані. Документ розкриває ваші процеси, тож про конфіденційність варто домовитися до деталей. Ми підписуємо NDA до будь-якого детального обговорення.

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

Хоч би який варіант ви обрали, ТЗ не застигає в день підписання. У Scrum Guide перелік робіт — Product Backlog — описано як впорядкований перелік того, що потрібно для покращення продукту, який постійно змінюється, а його елементи розбивають і уточнюють під час роботи (The Scrum Guide). Для замовника важливо інше: щоб кожну зміну було записано і погоджено, а приймали роботу за актуальною версією.

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

Висновок

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

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

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

Чи потрібне технічне завдання для гнучкої розробки?

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

Чим технічне завдання відрізняється від брифу?

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

Хто має писати технічне завдання — замовник чи виконавець?

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

Наскільки детальним має бути технічне завдання?

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

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

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

Джерела

1. Martin Fowler — Fixed price
2. Magne Jørgensen — What we do and don't know about software development effort estimation (IEEE Software, InfoQ)
3. Agile Business Consortium — What is MoSCoW prioritization?
4. Martin Fowler — Given when then
5. Ken Schwaber, Jeff Sutherland — The Scrum Guide (листопад 2020)