Технічне завдання на сайт: зразок від digital-агентства

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

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

Щоб уникнути таких наслідків, Вам необхідне технічне завдання на розробку сайту.

Що це і навіщо потрібно

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

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

Технічне завдання (коротко "ТЗ") - це документ, який максимально докладно та однозначно відображає вимоги до Вашого майбутнього сайту.

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

ТЗ на створення сайту - як закон, не повинно допускати трактувань та різночитань.

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

1. Хто пише ТЗ

Хто має складати технічне завдання на розробку сайту? На це питання є лише два варіанти відповіді: замовник чи виконавець.

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

1. Зрозуміти, який саме сайт Вам потрібний;
2. Зафіксувати бюджет (інакше Вам потім виставлять рахунок, мама не журись);
3. Контролювати розробника (терміни, обсяг робіт, функціонал, переробки тощо).

1. Зрозуміти та з першої спроби задовольнити заявлені Вами побажання;
2. Уникнути безкоштовних доробок та коригування.

Таким чином, Ви обидва – і замовник, і виконавець сайту, зацікавлені дійти максимального розуміння.

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

2. Бриф на розробку сайту

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

І навіть самі його складуть. У цьому немає нічого поганого.

ТЗ на розробку сайту можна скласти лише на основі Ваших побажань та ніяк інакше.

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

Звичайно, докладно заповнений бриф підписаний двома сторонами може замінити технічне завдання.

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

Якщо окремі пункти викликають труднощі, то не соромтеся ставити розробнику запитання на кшталт "Що це означає?", "Як це вплине на роботу мого сайту?"

Або у графі “Додаткова інформація” обов'язково вкажіть усі Ваші побажання, які не увійшли у відповіді на запитання. Якщо ця графа відсутня, просто допишіть в кінці брифа. Головне не залишати недомовленості.

Основа технічного завдання

Ще не визначились, кому довірити створення Вашого сайту? Можна написати технічне завдання самому, розіслати його декільком потенційним виконавцям та порівняти їх цінові пропозиції.

Майте на увазі, що у Вас вийде тільки основа, малюнок технічного завдання.

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

Надалі технічне завдання неодноразово редагуватиметься обома сторонами. Це нормальний робочий процес.

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

Передпроектне проектування

Цей пункт є невід'ємною частиною технічного завдання створення сайту, хоча фактично він до нього не належить.

Справа в тому, що після того, як Ви заповнили бриф, підписали технічне завдання і розробник вивчив все це (включаючи ринок та конкурентів), то він робить передпроектне проектування.

Передпроектне проектування - це створення прототипу Вашого сайту, його скелета, який потім обростатиме дизайном, контентом та функціоналом з фішечками.

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

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

І так, сам прототип можна зробити за допомогою звичайних аркушів паперу та кольорових фломастерів.

Кожен аркуш – окрема сторінка сайту (або екран односторінника). Або можна скористатися простими офісними програмами на кшталт Microsoft World чи Microsoft Excel.

Особисто ми під час розробки landing page використовуємо спеціальні програмні продукти.

З їхньою допомогою можна швидко і легко складати проекти навіть складних сайтів - це, наприклад, Balsamiq. Втім, як ми робимо весь прототип, уже розповідали в статті.

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

Цікаво. Не забудьте встановити систему коментування. Так, користувачі зможуть ділитися своєю думкою і навіть підштовхувати до покупок інших відвідувачів (а ще це позитивно впливає на SEO). Клікайте та дізнавайтесь докладніше -> Сackle

Лайфхакі зі складання ТЗ

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

1. Де взяти сайти-зразки

Хорошим помічником можуть стати широко представлені в мережі рейтинги та ТОП Інтернет-ресурсів.

Наприклад, ресурс allawards.ru підійде для цього. Тут збирають найкращі, з погляду юзабіліті, дизайну, креативу та ефективності сайти.

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

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

Але сліпо не копіюйте, наш російський менталітет все ж таки відрізняється і це не просто слова.

2. Як визначити колірну гаму

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

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

Не зайвим буде вивчити питання сприйняття кольору в рекламі. Або звернутися до Google за допомогою.

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

Секрет. Підкрутить перші відгуки, оцінки та інші фактори поведінки на Вашому сайті і тоді інші користувачі будуть до Вас більш лояльні. Рекомендуємо для накрутки TaskPay, самі ним користуємось. Клацніть -> TaskPay

3. Як підібрати шрифти для сайту

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

Тільки не дивіться колекцію шрифт Microsoft World, їх вже на сто рядів усі використовують. Найкраще скористайтеся бібліотеками шрифтів в інтернеті, наприклад, allfont.ru.

Помилки під час написання ТЗ

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

Тому виділяю найголовніші зі списку ті, що у Вас з ймовірністю в 80% будуть, якщо це Ваша перша розробка тз.

Важливо. Допилювати сайт до ідеалу, звичайно, добре, але багато хто забуває про найголовніше - систему оплати. І наш вибір – Yookassa. Впроваджується легко і є рішення для надсилання чеків до податкової. Клікайте -> Yookassa

1. Немає обмежень у часі

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

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

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

2. Втрата даних доступу

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

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

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

Тому запам'ятайте, що дані доступу до хостингу та доменного імені – це Ваші особисті дані.

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

До речі. Інтегруєте CRM-систему з Вашим сайтом, щоб відвідувачі сайту відразу потрапляли до Вас у базу, тож Ви не втратите жодного клієнта. До того ж там багато фішок, які допоможуть зробити із сайту просто бомбу продажу та ще автоматизувати бізнес-процеси. Клікайте -> Мегаплан

3. Відсутність наочності

Принцип "краще 1 раз побачити, ніж 100 разів почути" працює тут на повну. В ті самі слова замовник і виконавець можуть вкладати різний зміст.

І напевно ця помилка взагалі має стояти на першому місці нашого хіт-параду, тому що така картина відбувається постійно: "Хочу абстракцію", - пише замовник, маючи на увазі щось подібне (приклад на малюнку нижче)

Абстракція - вид замовника

"Ок, тримайте", - каже розробник. І пропонує замовнику абстракцію такого виду.

Абстракція – подання виконавця

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

За чий рахунок переробляти – незрозуміло. А приклади замовник до технічного завдання картинку зі зразком, нічого такого не трапилося б.

4. Якісні прикметники

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

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

А комусь цей дизайн здався красивим..)

Лише конкретика.Наприклад, "На два тони світліше", "Зміщуємо на 5 сантиметрів" або "Гострі кути біля кнопки".

5. "На розсуд розробника"

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

Ви повинні розуміти, що "На розсуд розробника" означає "що хочу, те і ворочу" або "Все, що не обумовлено, виконується на розсуд виконавця". І повірте, це не просто лазівка, а ціле вікно для розробника до Європи.

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

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

І трохи про невиразні формулювання, які викликають окремий біль:

• "Сайт має сподобатися замовнику". Та гаразд? А як не зможе?
• "Сайт має бути зручним". Навіщо і для кого?
• "Сайт повинен витримувати великі навантаження." На скільки відвідувачів?
• "Якісний експертний контент." Ну. тут без коментарів.

Коротко про головне

Ви точно не пошкодуєте про час, витрачений на складання та узгодження технічного завдання для створення сайту чи лендінгу.

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

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

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

До речі. Створіть свій сайт через конструктор за один день і без програмістів. В арсеналі готові шаблони, мобільна версія, кошик, платежі та ще +10 інструментів. Клікайте та тестуйте -> InSales (за промокодом "inscale" +30 днів безкоштовно).

Знайшли помилку у тексті? Виділіть фрагмент та натисніть ctrl+enter

Як скласти технічне завдання

Розповідаємо, як скласти технічне завдання. Яка інформація має бути в ньому і як правильно структурувати дані в ТЗ.

Що таке технічне завдання?

ТЗ - це постановка завдання, план дій та обговорення майбутньої роботи в одному документі. Технічне завдання необхідне у сфері діяльності. Будуєте будинок? Потрібний чіткий план та вимоги. Робите веб-сайт? Той самий сценарій. Будь-яка діяльність супроводжується хотівками замовника та нормативами, яких зобов'язується дотримуватись виконавець. Вони й заносяться до ТЗ.

Навіщо потрібне ТЗ

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

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

Також ТЗ формує очікуваний результат та дає можливість оцінити результат виконаної роботи.

Яким має бути ТЗ

Насправді дотримання чітких правил при складанні ТЗ не потрібне. Різні компанії та підприємці оформлюють завдання по-різному. Питання з метою.

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

Потрібно написати невеликий текст на тему "Душеві кабіни". Текст має бути для людей. Без переспаму.

А хтось описує все в деталях і структурує кожен аспект:

Потрібно написати текст на тему "Душеві кабіни" обсягом 3500 знаків. Рівень спаму – до 55%, рівень води трохи більше 18%, унікальність – від 90%. Слово "душові" використовувати не більше 15 разів. Уникати стоп-слів (і, або, але, а).

Далі ми розглянемо пункти, що входять до базового шаблону ТЗ.

Технічні характеристики

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

У випадку текстів сюди можна віднести:

• кількість знаків на абзац,
• тип та розмір шрифту,
• кількість використовуваних ключових слів,
• правила структурування тексту за допомогою підзаголовків,
• необхідні формати даних (таблиці, списки, цитати тощо).

У технічне завдання програмістів можна включити:

• вибір системи управління даними (WordPress, Joomla тощо),
• вибір фреймворків (React, Angular тощо),
• кількість спливаючих вікон,
• ширину контентної частини сторінки,
• розташування форм зворотного зв'язку у додатку,
• Додаткові функції.

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

Маркетингові характеристики

Характеристики, що допомагають просуванню сайту, складніше поставити так само чітко, як технічні.

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

Замовник розповідає про цільову аудиторію та її особливості. Завдання виконавця – скористатися цією інформацією та зробити підсумковий проект/текст найбільш привабливим для зазначеної ЦА.

Етапи роботи

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

1. Етап розробки ідей та доповнення існуючого плану дій.
2. Демонстрація першого прототипу.
3. Приймає першу тестову версію продукту.
4. Тестування функціональності.
5. Розробка дизайну.
6. А/Б-тестування візуальних компонентів та CTA-елементів.

Це приблизна схема, яку можна змінювати на власний розсуд, якщо є чіткі терміни виконання завдання.

Інші аспекти

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

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

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

Приклади ТЗ

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

Для розробників

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

Сайт має бути виконаний відповідно до зазначеного макету. Палітра кольорів, розташування об'єктів, шрифти, текст та інші елементи з Figma повинні бути перенесені на підсумковий проект.

Текст ТЗ може містити більш конкретну інформацію про наявні функції:

• На сайті має бути форма для завантаження файлів (тільки у форматах JPG, PNG).
• При скролі має з'являтися повідомлення із пропозицією зареєструватися.
• Якщо користувач довго не діє (більше 20 секунд), повинен з'являтися робот-помічник (його функціональність описана нижче).
• Під кожним матеріалом на сайті має бути секціями з коментарями.

Також до ТЗ можна внести вимоги до дизайну та оформлення коду:

• Колір підзаголовків беремо з макету (#CD6326).
• Списки мають бути оформлені у форматі ul > li > a.
• Блокові структури мають бути реалізовані за допомогою властивості селекторів flex.

Окремо можна вказати технічні засоби, що використовуються у роботі:

• Робота має бути доступна у репозиторії my-new-project.
• Кожна зміна має супроводжуватись окремим коммітом.
• Як база даних використовується технологія MongoDB.

Для копірайтерів

Текст на тему «Чи варто використовувати WordPress у 2020 році?».

Загальні вимоги до тексту:

1. Стаття має бути поділена на частини. Кожен підзаголовок відокремлює один логічний блок.
2. У тексті необхідно використовувати одну таблицю та мінімум один список.
3. Між списками, таблицями, цитатами та підзаголовками має бути відстань щонайменше 400 знаків.
4. У тексті мають бути підзаголовки другого рівня, мінімальний проміжок між підзаголовками – 750 символів, максимальний – 900 символів.
5. Ключові фрази мають бути використані стільки разів, скільки вказано у дужках поруч із словом.
6. Ключові фрази мають бути рівномірно розподілені за текстом. Відстань між ключовими фразами не менше ніж 1000 знаків. Перше ключове слово має використовуватись у першому абзаці.

Об'єм тексту: від 10 000 знаків.

Орієнтовна структура тексту:

1. Що таке WordPress?
2. Основні переваги WordPress.
3. Порівняння WordPress з іншими CMS.

Ключові фрази:

• WordPress (8)
• Теми для ВордПрес (1)
• CMS WordPress (2)
• Для розробників (1)
• Для новачків (2)
• Як встановити на сайт WordPress (1)
• Joomla (2)
• Drupal (1)

Замість ув'язнення

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