Як скласти ТЗ на сайт для грантового проєкту: що важливо врахувати ГО

Якщо в грантовому проєкті передбачено створення сайту, одного опису на кшталт «потрібен сучасний сайт ГО» буде недостатньо.

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

Що має бути в ТЗ

1. Мета сайту

Спочатку варто описати сам проєкт:

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

Наприклад: сайт потрібен для інформування ВПО про можливості отримання правової допомоги.

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

2. Вимоги донора

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

У ТЗ можна окремо прописати:

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

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

3. Структура сайту

Складіть попередню карту сторінок. Наприклад:

Головна;
Про проєкт;
Команда;
Новини;
Корисні матеріали;
Результати проєкту;
Контакти.

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

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

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

4. Доступність

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

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

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

5. Адміністрування

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

Наприклад:

публікувати новини;
додавати документи та звіти;
редагувати сторінки;
змінювати контакти;
додавати фото.

Якщо для кожної такої зміни доведеться звертатися до розробника, сайт швидко стане незручним у використанні. Ми завжди записуємо відео про те, як користуватись сайтом. І зазвичай з адмінки можна змінити 98% всього, що можна побачити.

6. Технічні вимоги

Тут можна зафіксувати:

CMS або іншу платформу;
адаптивність для смартфонів і планшетів;
SSL;
налаштування аналітики;
захист форм і персональних даних;
інтеграції, якщо вони потрібні.

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

SSL — це така штука, яка захищає дані на сайті. Зараз Google жорстко штрафує за його відсутність. Бачили попередження про незахищене з’єднання? Його лякаються і на сайт не заходять.

7. Що ви отримуєте після завершення

Цей пункт часто недооцінюють. У ТЗ варто прописати передачу:

доступу до домену та хостингу;
доступу до CMS;
інструкції для команди.

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

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

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

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

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