Техническое задание на разработку сайта: правила по составлению

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

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

Что собой представляет техническое задание по разработке веб-сайта

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

Основная задача ТЗ — обеспечить взаимопонимание между заказчиком и исполнителем.

Чем полезно техническое задание на разработку сайта для клиента и подрядчика?

Плюсы для заказчика:

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

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

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

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

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

Плюсы для исполнителя:

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

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

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

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

• ТЗ существенно ускоряет процесс разработки. В нем прописана структура веб-проекта, указаны все функции и элементы, которые должны быть на каждой странице сайта. Поскольку все собрано в одном документе, дело остается за дизайном и написанием кода.

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

Почему нужно обязательно составлять техническое задание на разработку интернет-сайта

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

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

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

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

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

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

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

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

Это важное условие эффективной разработки сайта.

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

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

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

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

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

Помимо ответов на вопросы вы можете указать свои требования в пункте «Дополнительная информация».

Если такого раздела нет, пропишите пожелания в конце опросника. Очень важно прояснить все детали до начала работ.

Кому поручить составление технического задания на разработку сайта

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

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

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

• Он должен объяснить разработчику, что представляет собой организация, каков её продукт и целевая аудитория.

• Рассказать о том, с какой целью создается сайт.

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

• Продемонстрировать понравившиеся веб-ресурсы.

• Дать ответы на вопросы, которые появятся у разработчика.

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

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

Будьте готовы к тому, что ваш вариант ТЗ будет не окончательным.

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

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

Как правильно составлять техническое задание на разработку сайта

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

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

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

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

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

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

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

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

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

Что нужно указывать в техническом задании на разработку сайта

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

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

• «Веб-ресурс должен понравиться клиенту». А вдруг он будет не в настроении?

• «Веб-ресурсом должно быть удобно пользоваться». Что в данном случае означает «удобно»?

• «Веб-ресурс должен легко выдерживать огромный трафик посетителей». Какие цифры тут имелись в виду? 10 000 пользователей? 20 000 000?

• «Контент от экспертов». Ну, здесь уже не нужно комментировать.

Поищите в текстах неоднозначные формулировки. Если нашли, то переделайте их. Все задачи должны звучать максимально конкретно.

• Вместо «быстрая загрузка ресурса» напишите, что все страницы сайта должны загружаться со скоростью более 80 баллов при проверке через сервис Google PageSpeed Insights.

• Фразу «Большая нагрузка» замените на «60 тыс. пользователей одновременно».

• «Список статей выводится на главной странице» переформулируйте так «На главной странице показываются 6 новых статей».

• Вместо «лаконичный и удобный дизайн» напишите «кнопка подписки должна выглядеть так» и сопроводите задачу картинкой.

Это все, что касается формулировок в ТЗ. Теперь рассмотрим его структуру.

1. Укажите общую информацию

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

   Также нужно прописать цель веб-ресурса, кратко обозначить его функционал. В противном случае вы рискуете получить блог вместо интернет-магазина.

2. Поясните сложные термины

   

   Главное в ТЗ — составить его так, чтобы всем было ясно, что должно получиться в результате. Если приходится использовать новую для заказчика терминологию, понятным языком объясните ему, что вы имеете в виду (только не надо отсылать его на страницы «Википедии»):

   • Под контентом подразумеваются тексты, картинки, гифки, видеозаписи, размещенные на сайте.

   • Чтобы управлять контентом, добавлять и редактировать его, нужна CMS, пользоваться которой можно и без знания веб-разработки.

   • Блок внизу каждой страницы называется подвалом.

3. Опишите инструменты и требования к хостингу

   

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

   Чтобы избежать неприятной ситуации, заранее проинформируйте его о том, какие движки, библиотеки и инструменты вы обычно используете. Объясните ему, каковы требования к хостингу. Ведь может получиться так, что сервер клиента размещается на .NET, а вы сделаете сайт на PHP.

4. Перечислите требования к работе сайта

   

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

   Готовый сайт должен соответствовать следующим технологическим требованиям:

   1.1. Он должен одинаково отображаться в браузерах Chrome1+, IE9+, Safari4+, Opera10+.

   1.2. Он должен адаптироваться под самые популярные размеры устройств:

   • монитор компьютера — 1600 х 992 px;

   • ноутбук — 1280 х 802 px;

   • планшет — 768 х 1024 px;

   • телефон — 320 х 480 px.

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

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

5. Укажите структуру сайта

   Перед тем как обрисовывать дизайн и делать верстку, согласуйте структуру веб-ресурса с заказчиком.

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

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

   

   Структура веб-ресурса — это его основа. Если вы плохо её проработаете, то получите неудачный сайт.

6. Объясните, что будет на каждой странице

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

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

   

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

   Блог (главный раздел)

   • Заголовок верхнего уровня.

   • Перечень постов в таком формате: картинка — название статьи — один абзац в качестве анонса.

   • Кнопки для перемещения по страницам. Одна страница содержит не более 10 постов.

   Блог (колонка сбоку)

   • Перечень разделов блога.

   • Кнопка подписки на рассылку.

   • Иконки соцсетей для перехода на страницу компании во «ВКонтакте», Facebook, YouTube.

   Это описание дает представление о том, каким будет блог.

7. Распишите сценарии использования сайта

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

   • Действие посетителя.

   • Реакция со стороны сайта.

   • …

   • Итог.

   Пример сценария.

   Сделать заказ:

   • Посетитель кликает на «Заказать».

   • Появляется форма для заявки.

   • Пользователь заполняет заявку, а сайт в ответ отправляет уведомление о том, что заказ принят.

   • Менеджер получает на электронную почту письмо с контактными данными клиента.

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

8. Определите, кто отвечает за контент

   

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

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

   Пример. Исполнитель должен написать тексты и разместить их вместе с картинками на сайте. Также он должен добавить заголовки Title и метатеги Description для:

   • home page;

   • страницы «О нас»;

   • всех страниц в разделе «Наши услуги»;

   • политики конфиденциальности.

   Сложно определить критерии, которые давали бы объективную оценку текстам. Не нужно указывать, что статьи должны быть интересными и увлекательными: такие характеристики слишком абстрактны.

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

9. Опишите дизайн (если сможете)

   

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

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

   Какими могут быть требования к дизайну и контенту веб-ресурса? Вот пример.

   Контент:

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

   Дизайн:

   • Белый используется в качестве фона.

   • Зеленый — это фирменный цвет.

Вариант описания дизайна в техническом задании на разработку сайта

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

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

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

Идеальный вариант — если вы максимально подробно опишете то, каким вы видите дизайн своего веб-ресурса. Кроме того, можно перечислить в ТЗ сайты, которые совпадают с вашей тематикой. Каждому примеру дайте краткое описание.

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

Как описать структуру ресурса в техническом задании на разработку сайта

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

Сквозные элементы

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

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

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

• Сайдбары — это боковые колонки, которые имеют различные виджеты. В качестве примера можно привести боковую панель с фильтрами и меню категорий на странице интернет-магазина.

• Окна и формы, которые появляются, если кликнуть на кнопку или совершить иное действие.

Уникальные страницы

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

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

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

• Новостная в блоге. Имеет сквозные элементы (шапку и подвал) и дополнительные (заголовок статьи, анонс, картинку в качестве обложки, дату выпуска, текст и форму для комментариев).

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

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

Прочие страницы

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

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

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

• Страница результатов поиска — это важный блок на сайте. Если результаты поиска представлены удобно, то это может увеличить конверсию в продажи.

• Страница авторизации/регистрации. Форма для регистрации или входа в личный кабинет должна быть удобной.

Как правильно описать функционал ресурса в рамках технического задания на разработку сайта

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

• CMS (WordPress, Joomla!, «Битрикс» и др.).

• Форма для заявки.

• Модальные окна.

• Слайдеры.

• Модули галереи.

• Модули страниц и поисковой оптимизации.

• Модули сжатия и кеширования.

• Карта с отметкой о местоположении.

• Онлайн-калькулятор для расчета стоимости.

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

В качестве примера дадим шаблон технического задания на разработку сайта.

5 типичных ошибок при составлении технического задания на разработку web-сайта

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

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

В ТЗ не указаны сроки разработки сайта

Зачастую тщательно проработанное техническое задание не содержит информации о сроках работы.

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

А можно проявить педантичность и проставить сроки по каждому пункту работы над сайтом.

Потеря данных для доступа к сайту

Исполнитель помимо разработки веб-ресурса часто занимается регистрацией домена и поиском хостинга.

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

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

К логину и паролю для доступа к сайту нужно относиться как к своим личным данным.

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

Отсутствие наглядности

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

Это вообще самая распространенная ситуация.

Например, заказчик хочет, чтобы в результате получилась абстракция (картинка ниже).

Абстракция с его точки зрения:

В итоге исполнитель отдает клиенту нечто подобное.

Абстракция по версии исполнителя:

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

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

Описание этапов разработки с использованием качественных прилагательных

Помните разряды прилагательных, о которых вам рассказывали в школе?

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

Читайте также!

«Онлайн-оплата на сайте: как выбрать сервис и настроить» Подробнее

К примеру, слово «красивый». Это прилагательное можно использовать для сравнения объектов: красивее, страшнее. То же самое со словами «умный», «модный» и т. д.

Их невозможно интерпретировать однозначно, так как у каждого из нас есть свое представление о моде и красоте.

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

«На усмотрение разработчика»

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

Скачайте полезный документ по теме:

Чек-лист: Как добиваться своих целей в переговорах с клиентами

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

Автор статьи

Дмитрий Свистунов

Руководитель SEO-отдела и разработки

Статья опубликована: 05.06.2020

Последние статьи этого автора:

• Адаптивная верстка сайта: гайд для начинающих
• Анкор ссылки: виды, правила составления, влияние на продвижение
• Белая раскрутка сайта без перехода на темную сторону

Забрать подарки
из закрытой базы

Скачать 7,4 MB

Полезные
материалы
для руководителей

Скачать 3,2 MB