На початку було – технічне завдання чи дизайн?
Звучить як «яйце чи курка», але будьте певні, що ми не заглиблюватимемося в такі філософські нетрі. А розглянемо цілком практичну ситуацію і, можливо, навіть змінимо вашу думку про усталену послідовність, коли дизайн створюється тільки після вивіреного та затвердженого ТЗ.
Отже, що ми маємо? Насамперед, повна відсутність регламенту. Якщо в математиці завжди зрозуміло, що двічі два – чотири, то у розробці та просуванні сайту стовідсотково діючих формул ще не виявлено. Тому експерименти тільки вітаються – і особливо експерименти, що призводять до успіху.
Саме про експеримент і йтиметься. Погодьтеся, що раніше будь-який проект розпочинався з узгодження ТЗ. Техзавдання служило сполучною ланкою між дизайнером і розробником, описувало, що має вийти у результаті. Його благополучно поміщали в ящик, а потім вели конструктивний діалог у процесі роботи.
Потім з'явилися агентства – до них клієнти зверталися зі своїм ТЗ. Але його часто доводилося переробляти та узгоджувати. А після складання технічного завдання «переклали» на плечі агентств, зробивши ще одну додаткову послугу в кейсі пропозицій.
Досі більшість компаній не представляє своєї роботи без ТЗ, проте підхід до його використання може бути формальним чи реальним. Формальний – це коли ТЗ складається, але фактично не використовується, а лише «завантажує» стіл, а реальний – коли створюється документ, що працює, як загальний пакет вимог, регламент.
Структуруємо техзавдання
Саме собою ТЗ – це продукт. Це образ майбутнього продукту, але образ максимально достовірний та однозначний. А тому тут буде багато сторінок та безліч підпунктів.
- Термінологія, загальні засади.
- Інтерфейси сторінок.
- Компоненти сторінок (блоки інтерфейсу).
- Вимоги до сайту CMS.
- Права, ролі.
- Блок-схеми, функціональні описи розробників.
- Можливі сценарії користувача, тобто функціональні описи для користувачів.
- Структура даних: список сутностей, атрибутів, предметів.
Виходить значне ТЗ, з яким слід переходити до розробки дизайну та наступної верстки. Як правило, техзавдання легко узгоджується з клієнтом, після чого готується дизайн та знову узгоджується. І на цьому етапі виникають виправлення. Вони можуть стосуватися шрифтів та кольорів, і вноситись безперешкодно, не змінюючи структури та інші фундаментальні параметри.
Але є правки та іншого роду – суперечать ТЗ. Коли клієнт пригадав необхідність налаштування фільтрів в іншій послідовності, з'явилася необхідність включення нового підрозділу і так далі. Ці виправлення вимагають глобальних змін, оскільки торкаються практично всіх розділів вихідної структури.
В результаті виникає невідповідність - дизайн коригується під вимоги клієнта, і затверджується дизайн-макет, який не має нічого спільного з раніше складеним та підписаним (і взятим за основу!) ТЗ. Адже розробник орієнтувався саме на техзавдання і вже спланував своє робоче навантаження.
Метод вирішення спірних ситуацій
Неточності, що виникли, вимагають рішень. І тут компаніями вибирається один із трьох шляхів. Перший - це буквально "куди крива вивезе". ТЗ благополучно відкладається, розробник присвячується новий проект – цього разу за узгодженим дизайн-макету. Ось тільки це робота на свій страх і ризик, коли клієнт знову може забути, не врахувати і так далі.
Другий метод – це збільшення кошторису, включення до нього додаткових витрат. Начебто б і все логічно, ось тільки замовник навряд чи таку логіку зрозуміє.
І третій – це очевидна благодійність, коли техзавдання доопрацьовується самостійно без виставлення будь-яких додаткових рахунків. Але готуйтеся до того, що таке старання не оцінять.
Вихід із ситуації – є!
Якщо ТЗ так чи інакше доведеться переписувати під дизайн, чому б і не зробити спочатку дизайн? А дизайнер працюватиме за прототипами! Адже документація набагато менш «мобільна» в порівнянні з дизайном – легше змінити картинку, ніж формулювати юридично та технічно грамотною мовою чергові пункти «посібника до дії». Крім того, візуалізація позбавляє неточностей сприйняття.
Тим більше що прототипів цілком достатньо для попереднього узгодження проекту. Використовуючи цю методику, ви отримуєте спроектований з погляду функціональних можливостей та інтерфейсів продукт. І вже його описуватиме ТЗ, спираючись на візуалізовану конкретику, закріплюючи обране рішення.
Переваги очевидні
Створюючи спочатку дизайн, та був ТЗ, отримують економію часу, і навіть нові змогу розширення бази послуг. Адже тепер можна пропонувати клієнту прототипування – як наслідок це призводить до виправданого підвищення вартості проекту.
Команда, яка працює над завданням, при такому підході швидше впорається з обов'язками: дизайнер спокійно втілює ідеї клієнта, проектувальник позбавляється постійних правок громіздкої документації, а менеджер «веде» клієнта без валеріанки та головного болю. І проект рухається вперед, до свого логічного завершення, а не повертається знову і знову до пройденого етапу.
Із прототипами зручніше працювати і проектувальникам, і клієнту. Адже дизайнер отримує для роботи картинки, зрозумілі його сприйняттю, а клієнт може однозначно оцінити попередній «макет», а не заглиблюватися в читання багатотомника з тисяч літер. Таким чином, виключається ризик різних очікувань від продукту у клієнта та компанії-розробника.
Розробляти дизайнерські прототипи набагато краще, ніж постійно керувати буквеною специфікацією. Адже при коригуванні безлічі взаємопов'язаних між собою розділів такий ризик помилитися.