Как написать грамотное тз на разработку сайта – Паньшин Групп

Что в нем должно быть и чего нет. Формулировки

Техническое задание — это документ, часть договора (не важно это договор с печатями и подписями или же только устная договоренность), которая регламентирует, какие работы должны быть выполнены. Всё что описано в ТЗ должно допускать возможность объективной оценки. Т.е. должны быть объективные критерии, по которым можно определить, сделан ли тот или иной пункт работ или нет.

Исходя из этого получается, что в техническом задании не должно быть речи о дизайне. Да и вообще, задание техническое, а не художественное. Дизайн не поддается объективной оценке, что одному нравится, другому — нет, и не существует объективных критериев, по которым можно сказать, хороший дизайн или нет.

Реализация дизайна с формулировкой задачи «в зеленых тонах, и что бы дерево», может быть как плохой работой, так и шедевром (и что особо печально, оба варианта могут не нравиться заказчику). Короче говоря, выполнение объективных критериев описывающих дизайн может приводить к плохому результату.

Вообще, ТЗ надо писать так, как будто вы с заказчиком не сошлись во мнениях и ваш спор будут разбирать в суде, основываясь на тексте тех. задания. А у вас в ТЗ написано «сделать дизайн, который понравится заказчику». Судья спрашивает: «Заказчик, Вам нравится дизайн?». Заказчик: «Нет, Ваша честь!». Судья: «Исполнитель, присуждаю — 2 года уборки снега в Сибири за невыполнение условий ТЗ!».

Формулировки должны быть «закрытыми», т.е. четко указывать границу нашей работы. В ТЗ не может быть написано «админка должна быть удобной». Удобство — субъективный фактор, кому-то удобно так, кому-то иначе, и в случае спора трудно будет установить, кто прав. Формулировка «админка должна быть удобной» может привести к бесконечным переделкам: «добавьте в админку к списку товаров сортировку по столбцам и фильтрацию. Без этого не удобно. И загрузку товаров из экселя, по одному добавлять не удобно».

«Всё, что не оговорено, выполняется на усмотрение исполнителя» — не смотря на суровость этого заявления, эта фраза должна присутствовать в ТЗ. Она проистекает из самой сути задания: заказчик хочет получить некий продукт, но он не может и не должен указывать каким образом будет достигнут конечный результат.

Этот пункт защищает от вмешательства в глубины работы (не хватало, чтоб заказчик начал рассказывать, как именовать функции в коде и какие пакеты использовать), но также перечеркивает возможность заказчика иметь любые хотелки. На мой взгляд, стоит идти на встречу заказчику в хотелках, пока это не выходит за рамки приличия.

Когда же терпение лопается, нам и пригодится этот пункт. Как в песне поется: «Мы мирные люди, но наш бронепоезд стоит на запасном пути». (Фразу «что не оговорено — на усмотрение исполнителя», лучше всунуть под конец ТЗ, в начале она может быть встречена в штыки. Но если ТЗ нормальное и в конце стоит эта фраза, против неё не будут протестовать).

Тех. задание — это документ, который нам дает заказчик (Не важно, что его пишем мы. По смыслу это задание, техническое задание, а задание дает заказчик исполнителю, т.е. нам). А из этого следует, что в ТЗ должны быть формулировки, которые указывают нам, что делать (типа «сайт должен содержать», «должна быть возможность»).

10 Сдача и приемка

Описание тех условий, при наступлении которых должен состояться расчет за работу.

Возможны варианты, например, перенос на хостинг заказчика после 100% оплаты. Или же оплата после переноса на сайт заказчика плюс неделя на обкатку.

Кстати, 100% оплата, я думаю, не должна означать окончание исправления багов. На мой взгляд, на баги должна даваться пожизненная гарантия, и исправляться они должны всегда и бесплатно. Хотя, думаю, тут будут и иные взгляды на эту проблему.

5 Данные и списки

Ключевой раздел ТЗ. Можно сказать его сердце. Это не самый многословный, но самый важный и трудный пункт ТЗ. Если он сделан как надо, можно быть уверенным, что автор задания понимает, что именно нужно сделать. Наличие этого пункта накладывает очень сильные ограничения на создаваемый продукт. Один только этот пункт, думаю, «весит» больше половины всего ТЗ.

7 Требования к надежности

Если планируется сайт с высокой нагрузкой, об этом стоит сказать заранее, чтоб не было конфуза. Высоконагруженный сайт вполне может потребовать специфические действия по настройке серверов или написанию кода. И выяснить, что сайт должен держать огромную нагрузку в момент сдачи проекта, не лучшее развитие ситуации.

Стоит отдельно сказать, что для надежности, необходимо настроить бэкапы, т.к. «случаи разные бывают» и никто не застрахован от злобных хакеров которые могут попортить базу данных или хостеров, которые могут сгореть синим пламенем, как это уже бывало.

Как написать тз на разработку сайта?

Концепция должна быть прозрачной и четкой, тогда не нужно будет долго гадать, как написать ТЗ на разработку сайта. Главная задача профессионала на данном этапе – учесть все необходимые детали и желание клиента, создать правильное представление о проекте, так, чтобы все ключевые аспекты были визуализированы правильно, т.е. так, как их видит заказчик.

Не менее важно определить ряд ключевых элементов:

• целевую аудиторию будущего сайта;
• его задачи;
• информацию, которую необходимо донести потенциальным клиентам;
• принципы работы сайта.

Как только концепция сформирована, можно приступать к разработке ТЗ. В него обязательно войдут такие моменты:

• тип сайта;
• стиль исполнения;
• функционал;
• структура страниц;
• навигация.

На плечи разработчиков ложиться важная задача, ведь именно написание ТЗ начинает разработку технических сайтов и дает четкую картину для всех специалистов, которые будут задействованы в этом процессе – программистов, дизайнеров, верстальщиков, копирайтеров. В среднем, длительность написания технического задания нашими специалистами составляет 7-14 дней, однако в особо сложных ситуациях, где нужно провести предварительный анализ и уточнить какие-то вопросы, это срок может увеличиться на 3-5 дней.

Объединение дизайна и системы управления ресурсом

Зачем это нужно? Дело в том, что благодаря такому объединению, программистам удается обработать графический макет и оснастить сайт качественным функционалом. Специалисты агентства «Паньшин Групп» осуществляют несколько операций на данном этапе:

• Верстают страницы – переводят разработки дизайнеров в HTML-код, что позволяет обеспечить сайт бесперебойной работой с разными разрешениями в различных браузерах.
• Создают систему управления – формируют простую и понятную систему управления, которая позволит клиенту собирать статистику, руководить готовым ресурсом самостоятельно и использовать методы ценового воздействия на потенциальных клиентов. Заказчики также получают возможность редактировать и пополнять базу контента.
• Интегрируют систему управления с результатами верстки.

Последний процесс делает сайт готовым к работе функционально, но пустым. В среднем, процедура интеграции может занимать от 1-2 недель до 1,5-2 месяцев. В данном случае все зависит от сложностей верстки и оптимизации ресурса, его направленности и пожеланий клиента.

Проработка дизайн-проекта и его согласование с заказчиком

Создание дизайн-проекта начинается после того, как написание ТЗ на разработку сайта полностью завершено. Важно абстрагироваться от собственных предпочтений и вкусов, делая стиль веб-ресурса соответствующим сфере деятельности Вашей компании. Задача специалистов не усложнить дальнейшее продвижение, при этом, соблюдая главную цель разработки. Еще один важный момент – наличие отличительных характеристик, которые качественно выделяют новую разработку от ресурсов конкурирующих организаций.

Заказывая разработку технического сайта в агентстве «Паньшин Групп», клиенты могут ознакомиться с несколькими готовыми концепциями и выбрать ту, которая подходит больше. Этот этап разработки сайта в среднем занимает 2,5-3 недели.

Нередко компании предлагают уже готовый шаблон, который ускоряет процедуру верстки и позволяет сэкономить время на прорисовке деталей. Да, выбрать шаблон можно, но он не всегда позволяет добиться хороших результатов и вывести сайт в ТОП выдачи поисковиков. Профессионалы предпочитают работать с уникальными проектами, которые сделаны под конкретную организацию.