Якщо трохи поділитися думками з цього питання. Коли ми проводимо переговори з клієнтами, з самого початку нашої розмови часто доводиться чути про ТЗ (технічне завдання). Зазвичай замовник впевнений, що це його робота і намагається розпитати про це якумога детальніше…Якщо ви хотіли би дізнатися про це більш докладніше , зверніться за посиганням тз для сайта разом з фахівцями вам буде значно легше пояснювати свої вимоги.
Технічне завдання ( тех. завдання, ТЗ) – це документ на проектування певного технічного об’єкта. У нашому випадку це веб-сайт. У ТЗ встановлюється основне призначення об’єкта (сайту), визначаються технічні характеристики, склад і спеціальні вимоги до проекту.
Питання, яке ми хотіли поставити в цій невеликій статті звучить приблизно так:
Чи може клієнт написати ТЗ на свій проект без допомоги виконавця?
Я ні в якому разі не занижую здібностей Замовника, але якщо хтось не особливо знається в машинах, то не стане розбирати двигун:-)
Що ж показує практика? Зазвичай замовник отримує від виконавця (веб-студії) короткий бриф для заповнення з такими графами:
- Структура сайту
- Функціональні елементи
- Інтеграція
- Побажання щодо використання CMS
- Платіжні системи: які будуть використовуватися?
Також можуть бути присутніми й інші пункти, які пропонують заповнити замовнику самостійно. А відповіді на ці пункти-питання і стають тим самим технічним завданням. Хочу зауважити, що так працюють безумовно не всі, але багато. Результат такої роботи залишає бажати кращого. Так чому ж так відбувається?
Давайте трохи конкретніше пройдемося по цих пунктах, щоб зрозуміти специфіку робіт і їх обсяг.
Структура сайту
Для того, що б зробити нормальну структуру сайту , необхідно розуміти «проектування взаємодій» і «інформаційну архітектуру», але не будемо вдаватися в докладні пояснення кожного з них. Суть в тому, що потрібно хороше розуміння цих елементів і певний досвід. Людина, що замовляє сайт, часто не має такого досвіду і навичок. Він фахівець у своєму профілі і йому буде вкрай важко зробити правильну «структуру сайту» без консультацій фахівця. Такий підхід призведе до помилок на ранньому етапі проекту. А такого своєму сайту ніхто не побажає.
Функціональні елементи
Хочу поділитися випадком зі своєї практики. Останній бриф-ТЗ, який мене особливо вразив виходив від одного клієнта, який звик працювати по-старому. Завдання було створити інтернет-магазин. У розмові з маркетологом фірми ми розбирали раніше заповнений ним бриф сторонньої веб-студії. Я запитав: «у вас вказано» можливість замовлення”. Що ви мали на увазі? Давайте цей пункт розшифруємо. Це буде кошик, заявка, телефонний дзвінок або інші можливості”. На це питання я не отримав адекватної відповіді, так як маркетолог тільки як користувач міг згадати які бувають «кошики» і як відбувається замовлення.
Або, наприклад, коли ми з клієнтом говоримо про геотаргетинг він найчастіше не розуміє, що це таке. І в цьому немає нічого страшного, адже замовник не зобов’язаний розбиратися в термінах і можливостях. Виконавець сам може викласти всі пропозиції і показати всі плюси і мінуси використання конкретного функціонального рішення. Наприклад: потрібно визначати місце розташування користувача і видавати йому інформацію для його міста. Ось тут то і буде потрібен “Геотаргетинг”. Функціональність потрібно підбирати виходячи з потрібних процесів на сайті.
У брифі, один на один з аркушем паперу замовник просто не зможе відобразити все необхідне. Про більшість технологій і рішеннях в сайтобудуванні він не чув або ж не розуміє, як пояснити, що конкретно йому потрібно.
Інтеграція
В одному з наших проектів ми почали з того, що клієнт хотів тільки 1С інтеграцію. Потім з’явилася потреба сповіщати клієнта по телефону про те, що замовлення прийнято і обробляється. Так в ТЗ був доданий “СМС білінг”. Замовник до того ж хотів надалі робити розсилки своїм передплатникам, і ми зупинилися на інтеграції з американським сервісом «MailChimp». Клієнт не знав про нього і не підозрював, що розсилку можна зробити саме так. Просто спочатку були завдання, а потім з’являлися рішення, які народжувалися в процесі «Інтерв’ю з клієнтом».
Побажання щодо використання CMS
Це питання досить спірне. І ці суперечки не замовкають ні на день. Безкоштовні, платні, студійні, професійні CMS: які краще? Професійна спільнота щодо переваг у цьому питанні ділиться на безліч таборів. І кожна Жаба, Як то кажуть, хвалить своє , рішення тут досить просте: CMS повинно вирішувати поставлені вами завдання. Це головний критерій при його виборі. Також необхідно, щоб воно було зручним у використанні і давало можливість знайти альтернативну тех.підтримку.
