fbpx

Каталог статей

Каталог статей для размещения статей информационного характера

Технології

Хто повинен складати технічне завдання?

Цим питанням часто задаються представники замовника, коли виникає необхідність автоматизувати будь-який бізнес-процес. Чомусь сьогодні з боку більшості замовників немає повного розуміння того, наскільки це важливий етап, а не проста бюрократична тяганина. І наскільки скрупульозно обидві сторони підійдуть до цього етапу робіт, настільки буде більш точним, правильним, очікуваним швидким і результат проекту.
Що ж спробуємо розібратися. Давайте для початку все-таки визначимося, що ж таке технічне завдання?
Технічне завдання (ТЗ) — вихідного документа на проектування технічного об’єкта (виробу). Технічне завдання встановлює основне призначення розроблюваного об’єкта, його технічні характеристики, показники якості і техніко-економічні вимоги, припис щодо виконання необхідних стадій створення документації (конструкторської, технологічної, програмної тощо) та її склад, а також спеціальні вимоги.
Можна сказати, що ТЗ – документ, в якому описується, ЩО потрібно замовнику, на відміну від подальшої проектної документації, в якій акцент переноситься на відповідь на питання, ЯК цього досягти.
(Матеріал з Вікіпедії).
Дане визначення, на мій погляд, повністю розкриває суть терміна. Отже, основне призначення ТЗ повністю розкрити і описати всі вимоги, що пред’являються до бажаного результату замовником. Від того, як сформульовані ці вимоги, залежить успіх або неуспіх проекту. І на даному етапі зацікавленість в успіху повинні проявляти максимально обидві сторони. Замовник – щоб витрачати менше коштів на переробку невдалого проекту, виконавець – щоб меншими зусиллями успішно завершити проект і отримати прибуток. І як раз на цьому етапі виникає резонне питання: хто повинен писати цей документ?
З одного боку, здавалося б, це має робити замовник, т. к. він і тільки він повністю знає, що ж він хоче бачити в результаті. Але чи зможе дана сторона, не володіючи технічними знаннями в області розробки програмного забезпечення, коректно викласти всі свої вимоги? Провести їх аналіз на предмет того, що кожна вимога має бути зрозумілим, конкретним, тестованим, як того вимагають правила складання ТЗ. «Хочу кнопку червоного кольору, дає точні дані по продажах за місяць!». Напевно, нічого зрозумілого на основі даного ТЗ виконавець не реалізує.
Тоді ТЗ повинен писати сам виконавець? Теж не ідеальний варіант. Виконавець, отримавши від замовника виклад завдання, може інтерпретувати її трохи в іншому руслі, як розуміє завдання сам. І сухий технічний мову, на якому будуть викладені всі поняті виконавцем вимоги, не дасть відповіді замовнику – то він мав на увазі, описуючи бажаний результат. Особливо комічно виглядає ситуація, коли на стіл керівника замовника потрапляє документ, багатий технічною термінологією, специфічними словами, найчастіше англійською мовою, який він повинен підписати і, відповідно, підтвердити, що все написане це те, що вони і просили!
Тому найбільш оптимальний варіант – це робота в тандемі. Саме при повному зануренні виконавця в предметну область замовника, розмову однією мовою при побудові списку вимог, коли сходяться воєдино мову споживача-неспеціаліста і мова розробника, народжується документ, на підставі якого буде створений продукт, максимально наближений до вихідної поставленої мети. Такий синтез дасть обом сторонам повне розуміння описуваного процесу. Не буде сумнівів в тому, що якась частина технічного документа залишилася «білою плямою» і у що ця частина перетвориться в результаті.
Так, написання ТЗ складне завдання, але краще тимчасові вкласти інвестиції у даний етап, ніж знайти пролом і з’ясувати, що потрібно переробляти фундамент, коли прийшов час покласти дах.
І головне, перед тим, як створювати документ, замовнику потрібно зрозуміти, що саме він хоче бачити в результаті, а виконавцю – відмовитися від реалізації нездійсненних вимог.
Успішних вам проектів!