Як створити ТЗ (технічне завдання) для проєкту? 8 Як створити ТЗ (технічне завдання) для проєкту? 9 Як створити ТЗ (технічне завдання) для проєкту? 10

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

#SaaS #Бізнес

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

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

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

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

Як виглядає чекліст ТЗ під час заповнення

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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