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

Все почалося з того що на великі інтернет-проекти нам почали надсилати техзавдання, написані на 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 (прекрасно).

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

11.10.2016
Рейтинг: 0 / 5 (0)