Чекліст: що повинно містити технічне завдання на сервіс, сайт, інтернет-магазин

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

Все почалося з того, що на великі інтернет-проекти нам почали надсилати техзавдання, написані на 25-40 аркушах А4. Раніше ми завжди віддавали ТЗ на прочитання і оцінку розробникам, але коли за тиждень приходить 3 або 4 подібних документи, навіть на те, щоб їх уважно прочитати, виписати список питань і зрозуміти, чого в цьому документі не вистачає, може піти весь тиждень, а то і більше.

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

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

Основні розділи техзавдання

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

Загальна інформація про проект

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

Зустрічається заперечення, що "ми не будемо описувати, для чого і для кого цей проект, це комерційна таємниця, нас цікавить тільки реалізація" . Навіть, якщо це проект для ЦРУ, ФБР, СБУ або інших служб держбезпеки, потрібно розповісти розробнику ваші цілі, щоб він зміг включитися і працювати над проектом не просто як "руки". Ризики витоку конфіденційної інформації вирішуються шляхом підписання Договору про нерозголошення (NDA).

Концепція продукту – потреба або проблема, яку продукт вирішує, загальна логіка рішення, цільова аудиторія;
Мета та завдання проекту – коротко описати, які є конкретні цілі проекту в цифрах (KPI): досягти трафіку 10 000/ міс., збільшити продажі на 20% і так далі;
Словник термінів, використаних в ТЗ – назви особливих систем клієнта, технічні терміни, в яких в контексті даного техзавдання може бути своє значення;
Перелік документів, на підставі яких створюється проект - посилання на зовнішні документи, прототипи, вихідні коди дизайну для того, щоб не шукати по тілу документа;
Карта розділів або сторінок проекту – в форматі дерева або хоча б просто ієрархічного списку для того, щоб був відразу зрозумілим обсяг ресурсу, що розробляється.

Прототип і дизайн

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

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

Функціональна частина проекту

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

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

Організаційна частина проекту

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

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

Специфіка, яка залежить від проектів

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

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

Тема по серверах обов'язково доповнюються конкретними параметрами серверів (CPU, RAM, HDD): інтерфейси доступу і сертифікати (SSH, FTP / SFTP, SSL), операційна система на сервері, оточення, системи, розширення, які мають бути встановлені (apache / nginx / iis /...).

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

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

Специфіка техзавдання на розробку великого сайту або інтернет-магазину

Для великих проектів потрібно відразу в тех. завданні робити SEO-проектування і описувати вимоги до первинної внутрішньої оптимізації і базових вимог до коду для пошукових систем.

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

Якщо є вимоги до платформи розробки або конкретної системи управління сайтом або магазином, вони також повинні бути вказані.

правила генерації URL;
правила автогенерації TDH: title, description, h1;
генерація карти сайту (sitemap.xml);
мікро-розмітка (семантична розмітка).

ТЗ на розробку сайтуа або магазину на новій платформі, коли вже є існуючий

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

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

збереження url або 301-редіректи;
збереження TDH або автогенерація нових;
редіректи з беклінків;
перенесення контенту, особливо, якщо контенту багато і потрібен перенос за допомогою парсера або використовуючи старий дамп бази;
правила наповнення та внесення нового контенту на сайт, які alt, title, description вказувати для картинок і так далі.

Готовий чекліст технічного завдання

Готовий чекліст технічного завдання доступний в форматах Google Spreadsheet (онлайн-таблиця) і MS Excel (надішлемо за запитом).

Бонус №1: ознаки неправильного техзавдання. У версії чекліста, доступній для завантаження, ми також внесли ознаки поганого техзавдання.

Бонус №2: після заповнення чеклісту, ми підраховуємо загальний бал якості вашого техзавдання від -5 (все дуже погано) до 5 (прекрасно).

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

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

Так, цей чекліст доцільний, у першу чергу, для складних проектів, розробка яких коштує десятки тисяч доларів. І ціна помилки тут велика. І ми не чекаємо, що це буде робити власник бізнесу. Найчастіше на таких проектах у замовника вже є команда з маркетолога, SEO-фахівця, внутрішнього менеджера проектів, і для нас зібрати за чеклістом основні вимоги не складно. Міжнародні компанії, коли запрошують у тендер на розробку веб-проектів, надсилають RFP (Request For Proposal), який містить те, що тут вказано і навіть більше, наприклад, матрицю коефіцієнтів при виборі підрядника. Очевидно, що вони не готові робити вибір підрядника за ціною, сформованою за кілька годин на підставі опису на 2-3 сторінках, і усвідомлюють, що без якісного матеріалу для оцінки ціна, яку назвуть на початку, буде сильно відрізнятися від кінцевої вартості проекту.

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