Александр Борисович: ТЗ это, в первую очередь, постановка цели и задач. А затем перечень объективных критериев оценки конечного (или промежуточного) результата. Для самого простого примера, возьмём лендинг:
- цель (повышение узнаваемости бренда / расширение аудитории и тд)
- задачи (привлечение посетителей, клиентов / продажа / сбор регистрационных данных / информирование и тд)
- целевая аудитория (пол, возраст, география, предпочтения, сфера деятельности и тп)
- общее описание сайта, схематичная структура
- смысловые блоки
- шрифты, цветовая гамма, формы и нюансы графического решения (с утверждением первичного макета)
- тексты, их стилистика и объём (исходя из целей)
- изображения, инфографика
- поддержка браузеров (исходя из целевой аудитории)
- seo
- мобильная версия / адаптивный дизайн
- мультиязычность (если необходима)
- наличие back end (да (простой, сложный) / нет) и его характеристики
- дополнительные технические характеристики и нюансы реализации проекта (как то валидность вёрстки, прохождение тестов google speed и тп)
- хостинг (его география, исходя из целевой аудитории, тех. характеристики, исходя из планируемой нагрузки) и домен
- тестирование (отрисовка на целевых устройствах, отказоустойчивость, UX и тд)
Исходя из своего опыта и специфики конкретных заказов каждый может дополнить и модифицировать этот список. Словарь терминологии сюда включать смысла нет, т.к. при необходимости можно воспользоваться той же википедией. Надо просто понимать, что ТЗ это не способ прикрыть халтуру, а обоюдно полезный документ, как для заказчика, так и для разработчика, позволяющий максимально снизить смысловой шум и повысить эффективность сотрудничества.
Александр Борисович: Именно поэтому я и призываю составлять максимально чёткое техническое задание. А уж кто с какой ответственностью подходит к этому - дело индивидуальное. Равняться нужно на удачные примеры, а не на отписки. Да, халтура в составлении ТЗ, особенно у небольших провинциальных студий и филиалов, встречается довольно часто. Но это не повод брать с них пример или вообще отказываться от каких-либо попыток задокументировать желания заказчика. Любая устная договорённость не имеет никакой силы, ни юридической (в случае конфликта), ни фактической (заказчик всегда может сослаться на то, что он вам всё говорил, все разъяснял, а вы сделали не так).
Александр Борисович: Нормальное ТЗ не подразумевает, что оно составлено раз и навсегда. Зачастую это промежуточный документ. Если хотите, можете назвать это сметой. После выполнения первого этапа работ, оговоренных в ТЗ, обе стороны могут сравнить, насколько прописанные ожидания совпали с полученным результатом, при этом сводя к минимуму субъективизм. И затем, скорректировать либо исполнение, либо пункты ТЗ. Это не бюрократия, а деловой подход, выгодный обеим сторонам. В итоге, заказчик получает свой сайт, разработчик - оплату, пропорциональную затраченным усилиям.
А заниматься телепатией каждый раз, да ещё и удалённо, не видя заказчика в живую, но при этом, чтобы в итоге все остались довольны - вот это настоящий миф.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
- цель (повышение узнаваемости бренда / расширение аудитории и тд)
- задачи (привлечение посетителей, клиентов / продажа / сбор регистрационных данных / информирование и тд)
- целевая аудитория (пол, возраст, география, предпочтения, сфера деятельности и тп)
- общее описание сайта, схематичная структура
- смысловые блоки
- шрифты, цветовая гамма, формы и нюансы графического решения (с утверждением первичного макета)
- тексты, их стилистика и объём (исходя из целей)
- изображения, инфографика
- поддержка браузеров (исходя из целевой аудитории)
- seo
- мобильная версия / адаптивный дизайн
- мультиязычность (если необходима)
- наличие back end (да (простой, сложный) / нет) и его характеристики
- дополнительные технические характеристики и нюансы реализации проекта (как то валидность вёрстки, прохождение тестов google speed и тп)
- хостинг (его география, исходя из целевой аудитории, тех. характеристики, исходя из планируемой нагрузки) и домен
- тестирование (отрисовка на целевых устройствах, отказоустойчивость, UX и тд)
Исходя из своего опыта и специфики конкретных заказов каждый может дополнить и модифицировать этот список. Словарь терминологии сюда включать смысла нет, т.к. при необходимости можно воспользоваться той же википедией. Надо просто понимать, что ТЗ это не способ прикрыть халтуру, а обоюдно полезный документ, как для заказчика, так и для разработчика, позволяющий максимально снизить смысловой шум и повысить эффективность сотрудничества.