Техническое задание на разработку бизнес сайта

Разработать сайт можно без технического задания, но выйдет это дорого и, скорее всего, неэффективно. Как же составить правильное и продуманное ТЗ для сайта? Специалисты «Веб-Центра» объясняют и отвечают на важные вопросы:

7148 просмотров

• Зачем нужно ТЗ?
• Кто его составляет?
• Что должно включать в себя техническое задание?

Что такое ТЗ на разработку сайта

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

Зачем нужно техническое задание на создание сайта

Сайты делаются не один день, иногда на это уходит несколько месяцев. За это время может случиться все что угодно, например:

• У вас может смениться менеджер проекта. Новый человек будет не в курсе всех деталей проекта без ТЗ.
• Вам может потребоваться перерыв в разработке сайта: будь то финансовые трудности или фокусирование внимания на другом направлении бизнеса.

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

Образец ТЗ на разработку сайта. Шаблон технического задания на разработку портала или веб-сервиса.

Разберем плюсы технического задания для обеих сторон.

Для заказчика, составление ТЗ позволяет:

• Узнать предварительную стоимость разработки сайта.
• Понять, за что конкретно он будет платить деньги и какой ему сделают сайт: структура сайта видна сразу, и если на промежуточном этапе что-то не устраивает, изменения можно внести еще до начала разработки.
• Оценить компетентность исполнителя: грамотно составленное и понятное техзадание повышает доверие к разработчику.
• Ускорить согласование базовых вопросов.
• Собрать все пожелания и требования по проекту в одном документе.
• Защитить себя от недобросовестности исполнителя. Готовый сайт можно проверить на соответствие техническому заданию. Есть неточности? Разработчик их исправит. При наличии официального договора его можно принудить сделать это через суд.
• Упрощает замену исполнителей. Бывает, что заказчик и исполнитель ссорятся и не могут продолжать совместную работу. В такой ситуации с созданием сайта возникают проблемы. Однако при наличии подробного техзадания их можно легко решить: заказчик просто передает ТЗ новой команде, и она сразу же включается в работу.

Для исполнителя:

• Понимает желания заказчика. Для этого ему придется задать клиенту десятки вопросов, показать примеры, предложить решения. Потом записать все в соответствующий документ и согласовать с заказчиком. Он одобрил? Значит, исполнитель понял его правильно.
• Страховка от внезапных «хотелок» заказчика. Случается, что в ходе создания сайта заказчик вдруг решает кардинально поменять задачу. Если разработчик согласовал и подписал ТЗ, он может быть спокоен: даже суд встанет на его сторону.

ТОП-9 советов как написать техническое задание? (ТЗ или техзадание за 9 шагов)

Важно: правильно оформленное техзадание имеет юридическую силу и защищает исполнителя и клиента в случае споров и нештатных ситуаций.

• Показывает свою компетентность. Четко и понятно составленное ТЗ говорит о профессионализме разработчика.
• Зарабатывает деньги. Иногда составление технического задания размещается как отдельная услуга.
• Облегчает и ускоряет работу. Благодаря качественному техническому заданию становится понятна структура сайта и функционал каждой страницы: можно сразу переходить к написанию кода и разработке дизайна.

В итоге стороны получают защиту на случай возникновения претензий. Например, если при сдаче проекта заказчику не понравится выбранная CMS или дизайн, всегда можно указать на соответствующий пункт ТЗ, где прописаны детали.

Обратите внимание: ТЗ не заменяет договор, это разные виды документов.

Что будет, если не составить ТЗ или сделать это некачественно

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

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

Также некачественным ТЗ считается, если в нем используются необъективные и общие понятия, например: «Сделайте мне красивый, продающий сайт» или «Подключите мне систему оплаты к сайту». Однако понятия «красивый» и «продающий» понимаются заказчиком и исполнителем абсолютно по-разному, а платежных систем сейчас существует огромное количество. Заказчик, например, подразумевал работу с одной системой, но не знал, есть еще множество других, которые удобнее и проще.

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

Кто составляет ТЗ на разработку сайта

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

В идеале составлять техническое задание исполнитель и заказчик должны вместе, чтобы поделиться своим видением проекта и его воплощением.

• знакомит исполнителя с компанией, товарами или услугами, целевой аудиторией;
• объясняет цель создания сайта;
• рассказывает о своих желаниях и делится идеями;
• показывает примеры хороших (как ему кажется) сайтов;
• отвечает на вопросы исполнителя.

Заказчик может сильно помочь исполнителю, если заполнит бриф на создание сайта. В этом документе нужно дать ответы на базовые вопросы о том, каким вы видите свой проект. Чаще всего – это Excel-файл или опросник из сервиса Google Формы. Но можно и собрать ответы, используя интеллект-карты, или mindmap.

Источник: vc.ru

Техническое задание на разработку сайта

• Техническое задание на создание сайта – документ, в котором прописываются все нюансы и этапы разработки веб-ресурса. Фактически представляет собой текстовое описание сайта и формулирует критерии для контроля и проверки результатов работы разработчиков.

Техническое задание (ТЗ) составляется с целью создания руководства к работе дизайнеров, верстальщиков, программистов и контент-менедженов, а также для обеспечения безопасности заказчика. Обычно оно является приложением к договору и служит гарантией выполнения digital-агентством взятых на себя обязательств.

Особенности создания и назначение ТЗ

Создание ТЗ на разработку сайта требует проведения объемной аналитической работы и диалога с заказчиком, в ходе которого определяется круг стоящих перед создаваемым ресурсом задач. После сбора всей необходимой информации и получения данных от аналитиков, специалист приступает к написанию технического задания. Какие разделы включает в себя ТЗ на создание сайта:

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

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

Стоимость услуг – от 25 000 руб.

Почему стоит заказать техническое задание на создание сайта в O`Es?

Техническое задание на разработку сайта. Шаблон ТЗ

Большинство заказчиков очень поверхностно относятся к созданию технического задания (ТЗ) на проект. Именно в этом корень многих проблем. Поэтому давайте разберем подробно какие проблемы решает ТЗ и как необходимо его составлять.

Нужно ли создавать ТЗ?

1. программисты по-своему понимают как надо делать систему;
2. выявляются новые детали, которые требуют дополнительного времени и бюджета;
3. требования меняются по ходу проекта (очередная гениальная идея от заказчика, которая требует немедленной реализации).

Экономия на создании ТЗ в итоге оборачивается большими дополнительными расходами на переработки системы.

В некоторых случаях это доходит до того, что все наработки бросаются. Делается новое решение с нуля, с новой командой в надежде, что теперь-то все будет по-другому.

Скорее всего, по-другому не будет — заказчик ведь тот же. Если он не сделал верных выводов относительно процесса разработки, то история повторится.

Что важно знать при создании технического задания

ТЗ нужно как заказчику, так и разработчику

Заказчик получит в точности, что он хочет, что он прописал и согласовал в ТЗ.

Исполнитель четко понимает, что ему нужно сделать. Ни больше, ни меньше.

ТЗ должно быть понятно обеим сторонам и содержать все значимые детали по реализации задачи.

Если заказчик не понимает ТЗ, то как он собирается принимать работы по нему?

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

Не нужно писать ТЗ сразу целиком на большую систему

Дело в том, что пока вы его допишете, некоторые требования уже нужно будет менять/актуализировать. В процессе реализации могут возникнуть новые идеи.

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

Лучший вариант — написать базовое ТЗ на первую простую версию программы и отдельно написать план развития программы.

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

ТЗ пишет технарь в соавторстве с заказчиком

Если создание ТЗ поручили одному программисту, то получится очень точное техническое задание на систему, которой никто не будет пользоваться. Программа формально будет корректно работать, но при этом абсолютно бесполезна для бизнеса.

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

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

ТЗ — это совместная работа двух сторон.

Иногда встречаются ситуации, когда одна сторона начинает предъявлять претензии другой по поводу «почему вы не предупредили или не заметили этот подвох». В этом случае надо четко разделять зоны ответственности.

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

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

ТЗ — это отличное место для заказчика заявить, что он хочет видеть в проекте. Исполнитель должен развить ваше видение в понятный простой интерфейс с правильной структурой данных.

ТЗ лучше писать с будущим исполнителем системы. Так вы сэкономите на ознакомлении команды разработки с бизнес-логикой. Будет более точное понимание проекта и его нюансов.

Если вы — заказчик, то имеет смысл сначала в произвольной форме изложить своими словами суть проекта в виде концепции проекта. Здесь вы можете посмотреть шаблон концепции веб-проекта.

ТЗ — основание для договора

ТЗ определяет, что нужно сделать, и это является основанием для договора об оказании услуг по разработке.

На основе ТЗ создается смета работ и определяются сроки.

Заказчика-дилетанта очень легко узнать по его желанию определиться с точным бюджетом на ранней стадии, когда есть только «Нужно сделать аналог Авито».

Хороший вариант построения работы между подрядчиком и заказчиком — это работа по этапам, где каждый этап состоит из ТЗ, сметы на этап и срока.

1. невозможно определить детально смету, разработчик будет перезакладываться там, где требования написаны общими словами (например, «интеграция 1С»);
2. сроки скорее всего не будут выдержаны, т.к. в ходе работ появятся новые неучтенные требования;
3. очень сложно будет принимать работы. Будут постоянные споры, что входит / не входит в состав работ.

ТЗ — это рабочий документ, а не формальность

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

На создание ТЗ есть ГОСТЫ. Но имеет ли смысл им следовать? Множество требований просто не актуальны (они созданы более 30 лет назад), документы очень громоздкие, создание подобных ТЗ — это отдельный большой проект.

Считаю, что ТЗ должно решать главную задачу, а не быть формально правильным с точки зрения внешнего стандарта.

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

ТЗ как описание ЧТО + КАК

ТЗ не обязательно должно содержать чисто описание «что нужно реализовать».

В некоторых случаях целесообразно сразу в этом документе проработать и вопрос «как» — детали проектирования системы.

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

Все, что не вошло в ТЗ, оплачивается отдельно

ТЗ имеет свои рамки.

Все, что выходит за рамки ТЗ, является дополнением к заданию, на которое должна составляться новая смета отдельно.

Логика простая — изначально смета составляется на основе того, что написано в ТЗ. Если там это не описано, то почему оно должно быть оплачено как бы в рамках ТЗ?

В некоторых случаях сталкивался с таким откликом: «Это вы забыли это включить в ТЗ, поэтому это ваша недоработка».

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

Во-вторых, если работа не описана в ТЗ, значит не учтена в смете, т.е. изначально не заложена в бюджет.

Как мы создаем ТЗ для сайтов на Falcon Space

Далее мы рассмотрим наш вариант создания ТЗ — документа проектирования системы на Falcon Space.

В конце статьи вы найдете ссылку на шаблон документа проектирования, который вы можете взять за основу описания вашей системы.

Немного предыстории. Ранее мы использовали более полный шаблон ТЗ, где было множество дополнительных разделов с терминами, «стандартными требованиями», которые кочевали из одного документа в другой.

На практике подобные «пухлые» документы только усложняли чтение и размывали фокус на проекте. Все же основная цель — это именно реализация системы, а не ввести заказчика в религиозный трепет перед 100 страницами описания его проекта, где основа описана на 10-20 листах.

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

Давайте пройдемся по разделам нашего шаблона

Общие сведения о создаваемой системе

Раздел дает понимание исполнителю (зачастую и заказчику) для чего стоит делать систему, и в чем заключается ее ключевая особенность.

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

Профилей пользователя может быть несколько. Мы называем их ролями (директор, оператор, кассир и т.д.)

Какие задачи решает пользователь? Кратко определитесь со спектром задач пользователя. Этот список дает возможность быстро вникнуть в суть системы и ее назначение.

Как потребитель решает свою задачу сейчас без системы? Какую добавленную ценность будет давать система для пользователя?

Потребитель и раньше мог обходиться без нее? Зачем ему переходить на нее, если и так все хорошо без нее можно делать? Должен быть весомый стимул (внутренний или внешний).

Не понимая стимула пользователя, вы просто сделаете еще никому не нужную систему.

Почему такой упор идет на пользователя? Да потому что именно он будет работать в вашей системе.

Именно пользователь определяет успех системы. Нет пользователя — нет системы.

Закройте все потребности пользователя, и ваша система будет на коне.

Можно сюда еще много вопросов добавить относительно пользователя, но важно выдержать баланс — вам нужно знать, кто ваш пользователь, и что ему нужно. При этом важно добавлять только те вопросы, которые будут влиять на решения по интерфейсу системы, а не все подряд.

Роли и объекты системы

Детальнее определитесь с ролями: кто есть ваши пользователи, каковы их возможности в системе.

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

Подобное описание позволит в дальнейшем учесть все необходимые нюансы при создании структуры базы данных.

Необязательно сразу все учесть с первого раза. В ходе работы над другими блоками, вы в любом случае будете что-то дописывать.

Действуйте итеративно, опишите базово, двигайтесь дальше и дописывайте возможности по ходу появления новой информации.

Бизнес-процессы

Определите основные бизнес-процессы. Начните с главных.

1. Опишите базовую последовательность действий. В случае сложных процессов с ветвлениями логики можно сделать блок-схему.
2. Используйте артефакты. Артефакт — это некий вещественное доказательство, что очередное действие было совершено. Это может быть запись в журнале, документ, уведомление, клеймо (минутка для шутки).
3. Не усложняйте излишне новый процесс. Лучше внедрить сначала простой процесс, а потом постепенно его шлифовать и видоизменять по необходимости. Сложно описанный процесс сложно реализовать, сложно внедрять в практику и переделывать.
4. Укажите для процесса, что является фактором, триггером и результатом на выходе. Триггер запускает процесс, актор (actor) выполняет основную работу в процессе, результат — это артефакт на выходе после выполнения всех действий процесса.

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

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

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

Также в этом разделе имеет смысл описать ключевые ограничения бизнес-логики, на которые следует обратить внимание исполнителям (например, что Сотрудник может быть привязан к одному Управлению).

Структура проекта и требования к страницам

Это самый важный для исполнителя раздел. Именно здесь мы описываем, что конкретно надо реализовать на страницах приложения.

Первое — опишите структуру страниц по ролям в виде таблицы. Есть неавторизованная область (куда может зайти любой желающий) и кабинет для каждой роли.Для каждой страницы укажите URL и краткое описание. Данная таблица является картой всего проекта, неким скелетом приложения.

После определения структуры приложения описываем каждую страницу более детально.