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

Не історична довідка
Технічні вимоги – це
Технічне завдання – це
Блок практичних питань

Не історична довідка

Після того, як сформувався процес розробки програмного забезпечення та стало очевидно, що програми створюються на основі запитів користувачів, на світ з’явились поняття «функціональні» та «нефункціональні вимоги». Про що вони?

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

1. Директор фірми-замовника та фірми-виконавця домовились про співпрацю та визначили робочі групи проекту.
2. Робоча група фірми виконавця проводить верхньоповерхневе опитування ТОП-менеджмента фірми-замовника щоб порахувати вартість робіт.
3. Один із менеджерів озвучує наступну вимогу: «Нова система повинна пришвидчити процес покупки наших товарів в чотири рази».
4. Менеджер проекту розуміє, що мова йде про Інтернет-магазин, або особистий кабінет, в якому користувачі зможуть оформлювати замовлення.
5. Аналітик проводить збір інформації від зацікавлених сторін, на основі чого готує технічні завдання для дизайнерів та розробників.
   1. Вітрина з товарами виробника, яку може переглянути будь-який користувач інтернету.
   2. Захищена частина порталу, доступ до якої можливий після авторизації.
   3. Формування та оплата замовлення.
   4. Можливість відстежити процес доставки замовлення
   5. Перегляд історії замовлень.

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

Технічні вимоги – це

В нашому житті технічні вимоги почали масово з’являтись після впровадження тендерних процедур в 2016 році. Цей документ мав пояснювати, на що будуть витрачені кошти. Якщо почитати Wikipedia, то це нормативний документ, що встановлює внутрішні технічні вимоги, яким повинна відповідати продукція, процес або послуга, та визначає процедури, за допомогою яких може бути встановлено, чи дотримані такі вимоги. Але оскільки ще до війни тендерний процес перетворився в картотеку договорняків, то і на технічні вимоги почали класти. 

Оскільки я практична людина, і переношу свій практичний підхід на робочий процес в тому числі, то для мене має значення дві речі:

1. Як зробити більш ефективними ті речі, які приносять прибуток?
2. Як найскоріше позбутись тих факторів, які не приносять практичної користі?

Оскільки ці питання залишаються для мене безкомпромісними, то я не бачу цінності технічних вимог в сучасному українському процесі розробки програмного забезпечення. Я часто задаюся питанням: «Що буде, якщо всі технічні вимоги водночас зникнуть?» І знаєте що? Нічого не зміниться. Ця сутність стала виключно бюрократичною.

Технічне завдання – це

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

З чого складається технічне завдання

Стандартів можна знайти багато. Але на практиці 99% систем в Україні, – це набір простих сутностей: CRM- та ERP-системи, інтернет-магазини, сайти комунальних служб, і так далі. Будь-яка нова функція буде формуватись за наступним принципом: взяти дані з однієї таблиці, зробити з ними певні дії, і покласти в іншу таблицю. Варто наголосити, що ці принципи будуть єдиними для web-додатків, мобільних додатків, та desktop-додатків. Єдина різниця може бути в тому, що в деяких процесах дані обробляються автоматично по заданим правилам, а в інших, –  користувачами.

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

1. Детальний опис бізнес-процесу потрібен для розробника, щоб розібратись в процесі.
2. Опис back-end частини, де брати дані. Не забуваємо, що чим детальніший опис, тим краще. Можна одразу формувати завдання у вигляді SQL-запитів.
3. Що має робити з даними система або користувач, – опис front-end частини.
4. Опис back-end частини, куди передавати вже нові дані.
5. Нестандартна поведінка системи. Крім позитивного сценарію, необхідно передбачити максимальну кількість помилок, щоб користувач розумів, що далі робити

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

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

Блок практичних питань