ТЗ на розробку сайту – як скласти?

959

ТЗ на розробку сайту – як скласти?

 

ТЗ на розробку сайту – як правильно скласти?

Функціональність сучасного інтернет-ресурсу оптимізується під завдання клієнта, а дизайн та наповнення – під особливості цільової аудиторії. Усі ці невід'ємні частини процесу розробки регламентуються єдиним документом – технічним завданням чи ТЗ.

Навіщо потрібне технічне завдання?

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

Замовнику гарантується виконання всіх зазначених у ТЗ вимог за зазначену вартість, виконавцю – відсутність кардинальних змін на пізніх етапах. Все це дозволяє уникнути спірних ситуацій, конфліктів та непорозуміння.

Постановка завдання виконавцю

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

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

З чого складається ТЗ?

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

  1. Глосарій. У цьому розділі наводиться роз'яснення всіх понять та термінів, які будуть використовуватися в документі.
  2. Загальні відомості. Це один із найважливіших розділів. Тут необхідно вказати адресу майбутнього сайту, його найменування, визначити порядок узгодження різноманітних питань. Не менш важливо формалізувати у цьому розділі та поетапний графік виконання робіт, вказати порядок узгодження результатів. Однак ця інформація стає відомою вже після завершення написання ТЗ, тому її можна винести і до окремого блоку, який розміщують наприкінці документа.
  3. Цілі і завдання. У цьому розділі вказуються способи подальшого використання ресурсу, описується його цільова аудиторія.
  4. Програмне забезпечення. Необхідно позначити, з якими браузерами має бути сумісний новий сайт, а також які технології використовуватимуться для його реалізації.
  5. Вимоги до дизайну. Це досить вільний блок, у якому замовник формулює свої вимоги до вигляду майбутнього сайту. Можна вказати стилістику, використовувані гарнітури шрифтів, визначити колірну гаму і не тільки. Також варто зазначити тут необхідність використання анімованих елементів, банерів тощо.
  6. Вимоги до структури. Цей блок зазвичай є найбільшим. Тут зазначаються всі необхідні сторінки сайту, їх структура, зв'язок між ними. Також коротко описується призначення та вміст кожного розділу.
  7. CMS. Система керування контентом сайту дозволяє спростити його подальше наповнення та використання. Використання такого програмного продукту також дозволяє знизити вартість та терміни розробки.
  8. Вимоги до контенту Цей розділ докладно розписується в ТЗ на створення сайтів під ключ, де розробник повинен підготувати все необхідне наповнення. У такому разі слід визначити кількість, обсяг та формат статей, новин, різних медіаматеріалів і не лише.
  9. Порядок передачі результату роботи. Необхідно узгодити, в якому саме вигляді замовник отримає веб-сайт. Він може бути розміщений у мережі, на хостингу або, наприклад, передано на якомусь носії для подальшої роботи.

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

Як скласти і зразок

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

Перше — використовуйте об'єктивні чи вимірні критерії. Наприклад, якщо ви хочете, щоб заголовки на сайті були зеленого кольору, краще вказати точний код RGB або HEX. Те саме стосується і CMS: краще витратити якийсь час на пошук відповідної системи (для цього, наприклад, можна проконсультуватися з виконавцем), ніж вказувати розмиті терміни на кшталт «зручна», «проста в освоєнні» тощо..

Друге – максимально докладно описуйте всі елементи сайту. Це допоможе уникнути двояких трактувань, додаткового часу на узгодження ТЗ, уточнення вимог тощо. У цьому випадку надлишковий опис кращий за недостатній.

ТЗ як основа основ.

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

  • залучення нових клієнтів;
  • зміцнення лояльності покупців та партнерів;
  • презентація портфоліо або асортименту;
  • формування певного іміджу компанії тощо.

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

Опис розділів сайту

Важливо детально описати зміст усіх статичних та унікальних розділів. Необхідно послідовно, в міру докладно описати всі елементи, які мають бути представлені.

Крім текстового опис буде корисно додати сюди і схематичні макети сторінок. Для його створення можна використовувати спеціальне програмне забезпечення для прототипування. Макет дуже бажаний для головної сторінки, оскільки це основна точка входу відвідувачів на сайт. Робити макети для всіх внутрішніх розділів не обов'язково, тому що вони мають схожу структуру. Достатньо додати окремі прототипи для унікальних сторінок, а також один, загальний – для типових.

Опис функціональної частини

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

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

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

Погодження готового ТЗ

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

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

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

Сподобалася сторінка? Поділися з друзями:
Лінкануть
Вайбернути
Телеграмнути
Вотсапнуть