Як скласти грамотне техзавдання на розробку сайту

Пам’ятайте закон Мерфі? Якщо вас можуть неправильно зрозуміти, вас обов’язково зрозуміють неправильно. Це справедливо не тільки спілкування між людьми, але і в створенні сайтів. Клієнт хотів другий «Фейсбук», а отримав форум юних собаківників. Розробник не вгадав списку бажань замовника — витратив час даремно.

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

Стаття буде корисна:

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

Щоб матеріал вийшов слушна, я зібрав коментарі кількох розробників, дизайнерів, проект-менеджерів і власників діджитал-студій. Найцінніші додав в кінець статті. Поїхали розбиратися.

Що таке техзавдання і навіщо воно треба

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

Користі від технічного завдання багато. Для кожної сторони вона своя.

Користь для клієнта:

• Зрозуміти, за що він платить гроші, і яким буде сайт. Можна відразу побачити структуру, зрозуміти, що і як буде працювати. Прикинути, чи все влаштовує. Якщо немає — без проблем поміняти ще до початку розробки.
• Побачити компетентність виконавця. Якщо техзавдання зрозуміле і чітке — довіра до виробника підвищується. Якщо там написано каша — можливо, варто бігти і не озиратися.
• Застрахуватися від несумлінності виконавця. Коли сайт готовий, його можна перевірити за технічним завданням. Є невідповідності? Розробник зобов’язаний їх виправити. Якщо ви співпрацюєте офіційно і укладали договір — можна навіть примусити через суд.
• Спростити заміну виконавців. Якщо клієнт і розробник посварилися і розбіглися, створення сайту може сильно затягнутися. Коли є детальне техзавдання, його можна передати новій команді — вона втягнеться в роботу в рази швидше.
• Дізнатися вартість розробки складного продукту. Оцінити точні терміни і вартість розробки складного веб-сервісу сходу не можна. Спочатку потрібно зрозуміти, як буде працювати сервіс, і які в ньому будуть функції. Для цього і потрібно підготувати техзавдання.

Користь для виконавця:

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

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

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

Техзавдання становить виконавець

Взагалі техзавдання може скласти хто завгодно. «Потрібен сайт-візитка для стоматологічної клініки» — це вже техзавдання. Але чи буде вона виконувати свої функції? Навряд чи.

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

Це не означає, що клієнт зникає і з’являється в самому кінці, щоб написати: «Збс, схвалюю». Він теж повинен брати участь в процесі:

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

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

Пишіть однозначно і точно

Ця рада випливає з головної мети техзавдання — «Переконатися, що клієнт і виконавець правильно зрозуміли один одного».

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

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

Те ж саме — з незрозумілими формулюваннями, які нічого самі по собі не значать:

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

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

• Сайт повинен завантажуватися швидко → Кожна сторінка сайту повинна мати більше 80 балів в Google PageSpeed Insights.
• Великі навантаження → 50 тисяч відвідувачів одночасно.
• На головній сторінці відображається список статей → На головній сторінці відображається список останніх 6 опублікованих статей.
• Зручний мінімалістичний інтерфейс підписки → Полі «Залиште e-mail» і кнопка «Підписатися» → *намальований ескіз*.

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

Введіть загальну інформацію

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

А ще варто вказати мета сайту і описати його функціонал в двох словах — щоб не отримати інтернет-магазин замість блогу.

Поясніть складні терміни

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

Опишіть інструменти та вимоги до хостингу

Уявіть, що ви 2 місяці робили крутий сайт. Кожен етап узгоджували з клієнтом — він у захваті. І ось прийшов час здавати роботу. Ви показуєте адмінку, а клієнт кричить: «Це що таке? Модэкс?! Я думав, ви зробите на «Вордпрес»!»

Щоб таких проблем не було, опишіть використовувані інструменти, механізми та бібліотеки. Заодно вкажіть вимоги до хостингу. Мало, ви зробите на PHP — а у клієнта на сервер .NET.

Перерахуйте вимоги до роботи сайту

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

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

Вкажіть структуру сайту

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

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

Можна показати структуру списком, можна намалювати блок-схему. Як вам зручніше.

Це один з найважливіших етапів роботи сайтом. Структура — це фундамент. Якщо вона невдала — сайт вийде кривої.

Поясніть, що буде на кожній сторінці

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

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

Перерахування елементів — лінива альтернатива прототипу. Просто напишіть, які блоки повинні бути на сторінці, і що вони роблять.

Розпишіть сценарії використання сайту

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

• Дія користувача.
• Відповідь сайту.
• …
• Результат.

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

Детальніше про сценарії використання читайте в «Вікіпедії».

Визначте, хто відповідає за контент

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

Придумати об’єктивні критерії оцінки якості текстів досить складно. Краще не пишіть нічого, чим Якісний, цікавий і продає контент, корисний для цільової аудиторії». Це сміття, він нікому не потрібен.

Опишіть дизайн (якщо зможете)

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

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

Замість висновку: структура техзавдання

Для різних завдань структура ТЗ буде своя. Нерозумно робити однакові технічні завдання для нової соціальної мережі і лендинга з оптового продажу моркви. Але в цілому вам потрібні такі розділи:

• Інформація про компанії і цільової аудиторії, мети і завдання сайту.
• Глосарій термінів, які можуть бути незрозумілі клієнту.
• Технічні вимоги до верстання і роботі сайту.
• Опис використовуваних технологій і список вимог до хостингу.
• Детальна структура сайту.
• Прототипи сторінок або опису елементів, які мають на них бути.
• Сценарії використання нестандартного інтерфейсу (опціонально).
• Список контенту, який робить розробник.
• Вимоги до дизайну (опціонально).

Також рекомендую почитати

• Правила складання Software Requirements Specification. SRS — наступний щабель еволюції техзавдання. Потрібна для великих і складних проектів.
• Стандарти і шаблони ТЗ на розробку ПЗ. Описи різних Гостів і методологій створення технічних завдань.

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

Коментарі розробників

Я поспілкувався з кількома розробниками, щоб дізнатися, як вони складають техзавдання. Передаю мікрофон їм.

Аша Саакян, веб-дизайнер, фрілансер

Техзавдання повинен писати менеджер проекту, тимлид або сам розробник (якщо він фрілансер і працює один). Клієнт не розбирається в сайтах — він не зможе врахувати всі важливе.

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

Чим складніше завдання, тим детальніше повинно бути ТЗ. Коли я брала участь у великих проектах, я бачила техзавдання і на 30 сторінок.

Гурам Сипки, засновник діджитал-студії Udix Media

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

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

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

Ми вказуємо:

• Інформацію про компанії та мета сайту.
• Вимоги до дизайну, колірну гаму.
• Використовувані технології і CMS.
• Хто займається контентом — ми або клієнт.
• Структуру сайту аж до кожної сторінки.
• Описи кожної сторінки. Ми не робимо прототипи, але зазначаємо, які елементи повинні бути на сторінці, і як вони повинні працювати.

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

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

Дмитро Кузьмін, менеджер проектів

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

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

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

Олександр Курочкін, засновник студії Etalon Idea

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

Завдання проект-менеджера — зібрати всю необхідну інформацію, продумати рішення, створити сайт у себе в голові. А потім описати його в документі. Фактично, ТЗ — це вже півшляху до готового продукту.

Техзавдання — це еталон, з яким ви і ваші клієнти будете порівнювати сайт. Воно потрібне всім:

• Розробник рівняється на речі, описані в ТЗ.
• Тестувальник перевіряє, чи все працює так, як задумано.
• Клієнт розуміє, що отримає в результаті.
• Менеджер проекту може оцінити вартість і строки розробки.

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

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

У ТЗ ми вказуємо:

• мета сайту;
• вимоги до сервера;
• опис роботи сайту та окремих його елементів;
• використовувані технології та бібліотеки;
• макет дизайну інтерфейсу;
• структуру і логіку внутрішніх переходів;
• ролі і сценарії роботи з сайтом для кожної з них;
• архітектуру бази даних (опціонально).

Моя порада читачам — в першу чергу налагодьте комунікацію. Якщо члени команди не можуть зрозуміти один одного і клієнта — ніяке техзавдання вам не допоможе.

Юрій Кетов, фронтенд-розробник, фрілансер

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

Наприклад, так:

Сайт для Лялькового театру. Завдання — розповісти відвідувачам про театр і репертуарі, надати можливість замовити квиток онлайн.

У цьому разі для мене головне — референси. Я подивлюся, що зробили в цьому тематиці Студія Лебедєва, Nimax, RedCollar, ONY, Сибирикс і ще приблизно 10 компаній, виберу 2-3 найбільш вдалих проекту, погоджу з клієнтом і буду орієнтуватися на них.

Або так:

Промостраница для продажу хни для биотатуажа.

Тут головне зробити сайт, з допомогою якого можна досягти потрібних KPI. Дивимося, які сайти роблять IT-Agency і Convert Monster і робимо також, не треба нічого винаходити.

Чим більше контенту дає клієнт, тим краще. Якщо ви дасте мені 1000 фотографій, 20 відео, 50 сторінок тексту — супер. Я сам все отфильтрую і виберу те, що потрібно. Я трохи перебільшую, але, загалом, це так. Чим більше контенту на вході, тим краще, але залиште за мною право вибирати.

Олександр Бєлов, проект-менеджер «Текстерры»

Технічне завдання потрібно будь-якого проекту. У кожному ТЗ, обов’язково повинні бути вказані:

• Цілі і завдання, які буде виконувати сайт.
• Цільова аудиторія.
• Опрацьована до дрібниць, структура сайту.
• Інтерфейсні елементи сайту.

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

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

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

Як ми готуємо техзавдання:

• Аналізуємо ТЗ, прислане клієнтом.
• Вивчаємо прототип і дизайн-макет сайту.
• На основі отриманих даних починаємо підбирати функціональні модулі для сайту, які будуть використовуватися 100 % і які, можливо, буде потрібно використовувати.
• Прописуємо елементи, які будуть потрібні при роботі з інтерфейсом.
• Виходячи з цих даних і оцінки «ваги» сайту, обчислюємо відповідні системні вимоги до хостингу сайту.
• Після цих базових пунктів починаємо розписувати ТЗ більш детально на кожній сторінці.