Почему техническое задание на сайт — не панацея?
Мы часто сталкиваемся с тем, что техническое задание написано просто потому, что нужно. В итоге, оно либо написано слишком сложно, либо накладывает ненужные ограничения на проект. Важно также понимать, что техническое задание не дает гарантию отсутствия изменений в процессе разработки проекта. Поэтому, важно составить такое техническое задание, которое будет полезно обеим сторонам и уменьшит риски на проекте.
Когда разработка технического задания не нужна?
Если кратко — техническое задание необходимо только на сложных проектах. В остальных случаях — это пустая трата времени. Нет смысла разрабатывать техническое задание для несложных корпоративных сайтов, промо-сайтов и лендингов. Это также ограничит решения по дизайну на проекте.
На подобных проектах нужно составить структуру сайта, кратко описать функционал страниц и зафиксировать базовые технические требования к проекту (поддерживаемые браузеры, требования к серверу и системе управления сайтом и т.д.). Хватит нескольких листов A4, чтобы это описать. Остальные нюансы (например, анимации) обсуждаются после сдачи дизайна.
На нашей практике не было ни одного проекта в процессе разработки которого не происходило изменений. Главный принцип — не менять количество страниц и функциональную составляющую. Если это происходит — то стоимость проекта увеличивается.
Когда техническое задание необходимо?
Если проект сложный — например, корпоративный сайт с личным кабинетом и разными типами пользователей или интернет-магазин — то в этом случае рекомендуется написать техническое задание. Также для такого проекта лучше выбрать поэтапную реализацию.
На первом этапе происходит исследование и разрабатывается техническое задание на функционал проекта. Затем происходит финальный просчет проекта, где каждый сложный этап разбивается на части. После этого проект реализуется по частям. Таким образом, клиент в быстрый срок получает готовую часть проекта.
Ошибки при разработке технического задания
Перечень ошибок, которые часто встречаются в техническом задании:
- Много «воды» и абстрактного текста. Например — описание задач сайта и целевой аудитории, фиксация излишних требований к дизайну, чрезмерное использование канцелярского языка и т.д.
- Подробное описание каждой страницы текстом, вплоть до требований по дизайну к каждому элементу, вместо использования графики, прототипов или дизайна (если он уже подготовлен).
- Копирование кусков технических заданий без понимания сути текста. Например, устаревшие технические требования (поддержка браузеров Internet Explorer).
- Сложное графическое оформление: мелкий шрифт, разный размер текста, неправильное выравнивание и т.д.
Как выглядит идеальное техническое задание?
Хорошее техническое задание содержит:
- Четкое описание результата проекта.
- Этапы проекта, сроки, правила приемки каждого этапа.
- Ссылку на прототип. Возможно краткое описание структуры и функционала, если потребуется.
Главный вывод — ни в каком проекте нельзя предусмотреть все заранее. И техническое задание — не панацея. Но оно может упростить процесс разработки проекта для обеих сторон, если будет составлено правильно.
Прочел статью и остался в недоумении. Вроде бы автор работает в сфере дизайна и веб-проектирования, но при этом имеет какие-то фундаментальные ошибки в представлении о том что такое ТЗ, когда и для чего оно пишется.
Ваша статья содержит на половину воду, а на половину какие-то предрассудки. Также крайне странно требовать от клиента прототипа (он по вашему должен спроектировать варйфреймы, сам все продумать, натянуть первичный ui и еще и прототипировать? Это редкость.
Первые 2 пункта из вашей "рекомендации" для "хорошего" тз, это вещи, которые должны быть в уставе проекта, на худой конец в концепции. То что вы описываете как прототип, который должен быть в ТЗ, это вообще отдельный материал, почему он должен быть в ТЗ загадка.
А уж то, что в описываете как минусы, это вообще user story, говорить что это минус... Ну не знаю, как минимум овер странно.
Артем, спасибо за комментарий. Отвечу сразу на этот и следующий.
В статье мы нигде не указали, что написание ТЗ на стороне заказчика. Естественно, это наша задача. Особенно, когда речь касается прототипов и всех технических вопросов. Поэтому, я с вам тут полностью согласен.
Цель статьи была в другом — опровергнуть известный миф о том, что ТЗ спасает от всего, для сложных проектов оно лишнее и как раз, что писать ТЗ нужно грамотно, а это смогут сделать только специалисты. Т.е., по сути то, о чем вы пишете.
Я думаю, просто недостаточно правильно донесли мысль, не раскрыли суть, но наша статья, повторюсь, для клиентов, которые, как правило, вообще не разбираются во всех тонкостях.
Что касается наличия прототипов в техническом задании. Мы считаем, что это обязательная функция, поскольку читать текстом состав каждой страницы довольно сложная задача с точки зрения восприятия и понимания. Куда проще "потыкать" готовый прототип со всем функционалом.
User story это часть аналитического этапа, который мы тоже делаем. Он к техническому заданию никак не относится.
согласна, что все должно быть по существу. Но описывать все пожелания и требования обязательно, чтобы потом не было "Мы это видели по-другому"...
Мы пишем о том же самом. Вопрос лишь в том, как это описывать, насколько сложно и нужно ли описывать слишком развернуто.
Ожидать от обычных клиентов профессионального ТЗ также крайне странно, как минимум вы должны или предоставлять шаблон и рекомендации, как максимум сами реализовывать это как платную услугу.
Комментарий недоступен
У нас был печальный опыт в этом вопросе, как с нашей стороны (отсутствие компетенций), так и со стороны заказчиков (непонимание процессов). В результате, мы хотели найти такое решение, которое бы обезопасило нас и клиента, но не усложняло никому жизнь. Об этом мы и попытались написать.