Содержание

Как составить грамотное ТЗ на разработку сайта / Хабр

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

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

Что такое техническое задание

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

Следовательно, результат удовлетворит и заказчика, и исполнителя. Польза от технического задания очевидна:

1. Заказчик:

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

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

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

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

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

2. Исполнитель:

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

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

  • Показывает свою компетентность. Четко и понятно подготовленное ТЗ говорит о профессионализме разработчика.

  • Зарабатывает деньги. Иногда составление технического задания оценивается как отдельная услуга.

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

Техническое задание составляет разработчик

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

Он:

  • знакомит исполнителя с компанией, товарами или услугами, целевой аудиторией;

  • объясняет цель создания сайта;

  • рассказывает о своих желаниях и делится идеями;

  • показывает примеры хороших (как ему кажется) сайтов.

  • отвечает на вопросы исполнителя.

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

Пишите однозначно и точно

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

Например, этот дизайн кому-то показался красивым, и он использовал его на своем сайте:

То же самое относится и к невнятным формулировкам. Например:

  • Сайт должен понравиться заказчику. А если не сможет?

  • Сайт должен быть удобным. Для чего и для кого?

  • Сайт должен выдерживать большие нагрузки. Сколько конкретно посетителей?

  • Качественный экспертный контент. Ну, это понятно.

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

  • не «загрузка сайта должна быть быстрой», а «у каждой страницы должно быть более 80 баллов в Google PageSpeed Insights»;

  • не «большая нагрузка», а «50 тысяч пользователей одновременно;

  • не «на главной странице размещен список статей», а «на главной странице выведен список последних шести опубликованных статей»;

  • не «разработка минималистичного удобного интерфейса подписки», а «поле «Оставьте e-mail» с кнопкой «Подписаться»».

Донесите до коллег общую информацию

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

Разъясните сложные термины

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

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

Допустим, вы в течение двух месяцев разрабатывали сайт. Каждый этап был согласован с заказчиком. И вот работа сделана. Во время показа админки заказчик возмущается: «Это «Модэкс»?! Я рассчитывал, что сайт будет на «Вордпрессе»!»

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

Составьте список требований к работе сайта

Готовый сайт должен работать в любом браузере и на всех устройствах. Это нужно обязательно прописать в ТЗ.

Также нужно указать требования к следующим параметрам:

  • скорость загрузки сайта;

  • устойчивость к нагрузкам;

  • защита от хакерских атак и т.д.

Создайте структуру сайта

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

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

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

Структура — фундамент сайта. Ее создание — самый важный этап работы. Если она получится неудачной, сайт будет «кривым».

Объясните содержание страниц

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

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

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

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

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

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

Определитесь с контентом

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

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

Опишите дизайн

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

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

Вывод: структура ТЗ

Одинаковых технических заданий не бывает: для каждой задачи пишется отдельное ТЗ. Грамотное техническое задание должно содержать:

1. Информацию о компании и целевой аудитории, целях и задачах сайта;

2. Глоссарий терминов, непонятных заказчику;

3. Требования к верстке и работе сайта;

4. Описание применяемых технологий и список требований к хостингу;

5. Подробную структуру сайта;

6. Прототипы страниц и описания содержащихся на сайте элементов;

7. Сценарии использования интерфейса, если он нестандартный;

8. Список контента;

9. Требования к дизайну (в общих чертах).

ТЗ на разработку сайта: как составить, основные требования

ТЗ (техническое задание) – очень полезный документ, в котором описаны все разделы сайта, все элементы страницы и функциональность всех модулей. Польза будет как для заказчика, так и для исполнителя.

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

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

Услуга на разработку ТЗ сайта


Содержание

  • Зачем нужно техническое задание?
  • Как правильно составить ТЗ
    • 1.
      ТЗ составляет отдельный специалист
    • 2. Писать нужно без двусмысленностей
    • 3. Укажите информацию о компании
    • 4. Создайте глоссарий
    • 5. Распишите инструменты и требования к хостингу
    • 6. Распишите требования к работе сайта
    • 7. Распишите структуру сайта
    • 8. Опишите содержание страниц
    • 9. Распишите сценарии работы с сайтом
    • 10. Определите поставщика контента
    • 11. Опишите дизайн
  • Вывод

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

Плюсы для клиента

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

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

Как правильно составить ТЗ?

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

1. ТЗ составляет отдельный специалист

Для написания ТЗ должен выделяться отдельный специалист. Конечно же, заказчик самостоятельно может написать техническое задание. Собственно фраза «Нужно разработать интернет-магазин с товарами для животных» – это уже своего рода ТЗ. Оно отражает конечную цель, но не даёт представление о том, из чего состоит сайт, какие функции нужны, нужна ли интеграция и т.д. Остаётся много вопросов, без ответов.

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

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

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

2. Писать нужно без двусмысленностей

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

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

Красивый, удобный, современный – это субъективно.

То, что может показаться красивым и удобным специалистам, совсем не значит, что будет удобным клиенту. И наоборот – часто клиент называет современным дизайн и функционал, которые были в ходу десятки лет назад. Большие нагрузки также надо расписывать – сколько человек планируется на сайте одновременно? 100, 1000 или миллион?

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

Пример однозначных желаний:

  • Сайт должен загружаться быстро. → Нужно подключить композитную технологию.
  • Сайт должен выдерживать высокие нагрузки. → На сайте одновременно может быть до 100 тысяч посетителей.
  • На главной должен быть список новостей. → На главной должен выводится список из 3-х последних новостей.

3. Укажите информацию о компании

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

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

4. Создайте глоссарий

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

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

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

Можно представить себе ситуацию, когда после уже выполненной работы, клиент узнаёт, что сайт сделан на 1С-Битрикс, а клиент предпочитает работать с WordPress.

Клиент разгневан, недоволен работой, даже если до этого всё устраивало.

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

6. Распишите требования к работе сайта

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

7. Распишите структуру сайта

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

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

Подходите к этому этапу внимательно. Структура – это основа сайта. Если её не продумать именно со всеми связями, то навигация будет неочевидной, пользователи могут запутаться в ней и уйти с сайта, так и не совершив целевое действие.

8. Опишите содержание страниц

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

У разработчика есть несколько вариантов показать вид страниц.

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

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

9. Распишите сценарии работы с сайтом

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

  1. Пользователь совершает действие.
  2. Сайт отвечает на это действие.
  3. Дополнительные действия пользователя (если требуются).
  4. Результат.

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

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

Услуга на Веб-разработку

10. Определите поставщика контента

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

Варианты работы по созданию контента:

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

Если исполнитель принимает на себя обязательство создать контент, необходимо описать требования к нему. И опять же, следует избегать обтекаемых формулировок в стиле: «продающий, интересный, качественный» – они не дают никакой информации ни исполнителю, ни клиенту. А вот слова «достоверный, экспертный, уникальный» помогают защитить клиента от недобросовестности исполнителя.

Размещение контента тоже обговаривается заранее:

  • исполнитель полностью заполняет сайт;
  • исполнитель заполняет сайт определённым количеством контента;
  • исполнитель оставляет на сайте тестовое наполнение.

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

11. Опишите дизайн

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

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

Вывод

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

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

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


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

Источник — Хабрахабр

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

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

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

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

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

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

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

Если «вычесть» одну картинку из другой, сделать, так сказать, diff, то мы получим разницу в ожиданиях заказчика и планах разработчика. И разница эта может быть весьма существенной:

И вот здесь возникает конфликт, где каждая из сторон права: заказчик не получил то, что ожидал за оговоренную цену, его пытаются «прокидать»; исполнитель же считает, что сделал все в точности с заказом, а остальные «хотелки» — это попытка «прокидать» его. Этот конфликт может решиться по-разному: либо заказчик примет, то что есть, либо разработчик доделает все бесплатно, либо обе стороны пойдут на взаимные уступки. Но в любом случае, будут пострадавшие.

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

Однако, есть очень важный момент: тех. задание не должно и не может свести diff к нулю! Поясню почему.

И diff и ТЗ имеют свою стоимость, причем стоимость нужно понимать более широко, чем просто деньги. Это деньги, время, потраченные нервы, испорченные отношения и т.д.
Стоимость diff — это стоимость изначально неоговоренных доработок, стоимость ТЗ — это, собственно, стоимость ТЗ. Чем более подробное и детализированное техническое задание, тем выше его стоимость, но тем меньше величина и стоимость diff-а, и наоборот.

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

Синяя линяя — стоимость ТЗ, она растет с ростом детализации, красная линия — стоимость diff-а, его стоимость, напротив, падает с ростом детализации.

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

Отсюда важный вывод: ТЗ должно хорошо описывать проект, но не более того.

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

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

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

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

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

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

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

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

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

3. Разделы ТЗ

3.1 Общие слова

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

3.2 Эксплуатационное. назначение

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

3.3 Функциональное назначение

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

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

3.4 Термины и определения

Этот раздел дает уверенность, что заказчик и исполнитель говорят об одном и том же.
Термины могут «вводится» с двух сторон: от вас к заказчику, например вы ему втолковываете, что такое хостинг и SMTP-сервер, и от заказчика к вам.

Во втором случае, как правило, не нужно описывать термины специфичные для предметной области, но не имеющие отношения к реализации проекта. Например, для магазина торгующего запчастями для парусных судов, не стоит выносить в термины такое, как стаксель и ванты. Здесь нужны расшифровки терминов, которыми оперирует заказчик и вкладывает в них некий смысл, который может быть нами истолкован неверно. Какие-то простые слова, но в данном контексте, принимающие особое значение. Например, заказчик говорит: «Сеанс работы с сайтом стоит 100 тугриков». Фраза «сеанс работы с сайтом» — претендент на описание. Этот термин может означать продолжительность времени от входа на сайт до выхода, или же период работы пока на счету пользователя не закончатся деньги. Т.е. нам нужно точно знать, что такое «Сеанс работы». Ошибочное понимание такого простого термина может создать реальную проблему.

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

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

Данные

Этот раздел содержит перечень сущностей, которые используются в проекте. Это очень близко к описанию таблиц в базе данных или моделей, если говорить о фреймворках с MVC. Например, у нас на сайте есть новости. А что такое новость? Как гласит военное определение, куст — это совокупность веток и листьев торчащих из одного места. Так и новость, это совокупность заголовка, текста и даты публикации. Для чего нужно это определение? Как и всё в ТЗ — прояснить, что делать и подстраховаться от хотелок.

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

Для примера, та же самая новость:

  • Заголовок
  • Текст
  • Дата публикации

Предположим, в процессе работы выясняется, что забыли анонс новости (коротенький текст, который отображается в списке новостей). Добавить его не проблема: нужно в таблицу добавить поле «анонс» типа «текст» и дополнительное поле ввода в создании/редактировании новости. Доработка несложная.

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

Списки

Как подсказывает Кэп, новость — это новость, а список новостей — это список новостей.
Зачем это описывать? Допустим мы должны отобразить на главной странице «последние новости». Вот последние новости, это как раз такой список. А что есть «последние новости»? Это уже можно понять по разному, это могут быть последние 5 новостей, а может это новости за последние 24 часа? Приведенный пример прост, его недорого исправить и при сдаче проекта. Но есть более тяжелые случаи.

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

3.6 Страницы с описанием

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

Тут будет уместно описать не только, что отображается, но и как. Не в том смысле, что мы описываем дизайн: «Большими красными буквами отображается название новости», а в смысле, как работает: «Слева плавно выезжает окошко с предложением ввести логин и пароль». Или так: «при нажатии кнопки „Отправить комментарий“, комментарий появляется на странице без перезагрузки, с помощью AJAX».

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

Естественно, будет очень здорово добавить к каждой странице эскиз вроде такого:

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

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

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

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

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

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

3.8 Требования к хостингу

Очевидно, что вполне может возникнуть, например, такая ситуация. Наша веб-студия делает красивые сайты, но пишет исключительно на Django. Заказчик нашел наш сайт, увидел красивые дизайны и сделал заказ. Приходит пора выкладывать сайт на хостинг, к другим десяти сайтам заказчика, а там, естественно PHP. И начинается, «а я думал что все на PHP делают…, у меня другого хостинга нет, надо переделывать на PHP».

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

Сюда стоит включить требования к интерпретаторам, библиотекам, пакетам, гемам, требования к дисковому пространству, памяти, smtp, pop, ftp, внешним программам и прочему, что имеет значение для работы проекта.

3.9 Наполнение контентом

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

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

Описание этого раздела предостережет нас от разного понимания того, кто должен залить 500 фотографий и наполнить каталог товарами.

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

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

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

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

Заключение

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

Да, это ТЗ имеет пробелы, например, не сказано, как быть если у сайта должно быть API. Однако, имея хороший раздел «данные и списки», расширить ТЗ на эту область будет достаточно просто.

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

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

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

Зачем оно нужно

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

Начинать работу без чёткого плана — всё равно что вообще её не начинать. Есть такая поговорка: «Без внятного ТЗ результат ХЗ». Заказчик и исполнитель могут по-разному видеть даже одинаковые задачи. В результате придётся всё переделывать, а это траты времени, денег и нервных клеток.

Цели написания технического задания для сайта:

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

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

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

Виды технических заданий

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

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

В зависимости от желаний и возможностей клиента, мы выделяем 3 типа ТЗ на разработку сайта. Рассмотрим подробнее каждый из трёх типов.

Задание на разработку сайта для бизнеса

Самая распространенная задача — сайт для себя или своего бизнеса. Это может быть лендинг, корпоративный сайт, интернет-магазин. Обычно в таких случаях не нужны сложные технологические решения. Эти проекты разрабатываются на типовых системах управления типа Битрикс, Tilda, Canape CMS и др. Для них не нужно описывать подробно технические требования, например, корректную работу во всех браузерах или на мобильном устройстве. Современные платформы по умолчанию включают в себя актуальные технические возможности и типовые интерфейсы.

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

От вас требуется:

  1. Рассказать о целевой аудитории сайта: кто и для чего должен прийти на ваш сайт.
  2. Указать пожелания по дизайну: есть ли фирменный стиль, указать примеры сайтов, которые вам нравятся, написать пожелания по использованию фотографий и видео.
  3. Написать, какие модули и функции должны быть: корзина, онлайн-оплата, интеграция с CRM, калькулятор подбора, языковая версия.
  4. Расписать примерную структуру разделов на сайте: разделы о компании, структуру каталога.
  5. Указать примерный объем товаров и услуг на сайте.
  6. При наличии указать доменное имя и хостинг.

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

Задание на разработку сайта с нестандартным функционалом

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

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

Что будет требоваться от вас:

  1. Для чего этот модуль разрабатывается: какую пользу он должен принести посетителю сайта.
  2. Описание логики работы модуля: можно своими словами, к примеру, «хочу чтобы пользователь ввел в поле А данные своего адреса, а сайт в ответ выдал тип дома (кирпичный или панельный), показав это в формате таблицы».
  3. Источник данных: программы, базы данных, сервисы, откуда сайт должен получать данные.
  4. Примеры подобных модулей: ссылки на другие сайты, где есть аналогичные или похожие решения.
  5. Пожелания по внешнему виду модуля.

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

Вот пример подобного ТЗ для модуля интеграции сайта по доставке еды с системой автоматизации ресторанов IIKO.

Задание на разработку сайта по ГОСТу

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

Состав документа четко регламентирован ГОСТ 34.602-89 или ISO / IEC / IEEE 29148: 2018.

Создание подобного документа не самый простой процесс, и не каждый разработчик имеет такой опыт. В 90% случаев разработка такого ТЗ — это отдельная услуга. Мы часто сотрудничаем с госзаказчиками, на эту работу уходит не менее 50 человеко-часов.

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

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

Этапы составления техзадания на разработку сайта:

  1. Оценка необходимости стандарта: если нужен, читаем ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы». Если нет, пропускаем пункт.
  2. Определить цели и задачи бизнеса: для чего нужен сайт, кому он будет интересен, какие материалы на нём размещать — информацию о компании, товары и т. д.
  3. Анализ сайта: выявить проблемы текущего сайта при его наличии: технические — долгая загрузка, ошибки и т. д., юзабилити — насколько сайтом удобно пользоваться, качество контента.
  4. Изучение продукта и рынка: его особенности, предлагаемые товары и услуги, бизнес-модель компании.
  5. Работа с целевой аудиторией: разделение на сегменты, создание портрета типового клиента, путь клиента, изучение требований, потребностей и возражений ЦА.
  6. Анализ конкурентов: дизайн и юзабилити их сайтов, ассортимент, контент, сервис.
  7. Работа с уникальным торговым предложением: сравнение с УТП конкурентов, составление УТП для каждого сегмента ЦА.
  8. Разработка структуры сайта: с учётом поисковых запросов, ассортимента, потребностей клиентов — сколько разделов и категорий, как они расположены относительно друг друга.
  9. Создание прототипов страниц: схема расположения объектов на странице, подбор базовой палитры.
  10. Определение объёма контента: сколько нужно фотографий, текстов, видео.
  11. Утверждение технических требований: хостинги и тарифные планы, варианты доменных имён, CMS, необходимые интеграции, например, 1С-Предприятие.
  12. Оценка стоимости и сроков: в зависимости от количества страниц, времени работы над сайтом, объёма контента и интеграций устанавливается цена за разработку или реконструкцию сайта.

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

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

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

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

Хотите заказать качественное техническое задание на разработку эффективного сайта? Свяжитесь с нами по телефону:+7 (800) 200-94-60, доб. 321 или оставьте запрос на электронную почту [email protected].

Как составить техническое задание (ТЗ) на разработку сайта

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

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

Содержание
  • Что такое техническое задание на сайт
  • Для кого пишется ТЗ на разработку сайта
  • Зачем нужно техзадание для разработки сайта
  • Кто составляет техническое задание
  • Что должно содержать техзадание
  • Что не должно быть в ТЗ (ТОП 10 ошибок)
  • Как написать грамотное техническое задание на разработку сайта
  • Пример техзадания для разработки сайта
  • Резюме по техническому заданию на разработку сайта

Что такое техническое задание на сайт

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

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

Для кого пишется ТЗ на разработку сайта

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

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

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

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

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

  1. Структурировать на бумаге замыслы и идеи для сайта
  2. Получить визуальное подтверждение идеи или, наоборот, необходимость в доработке, с помощью созданных прототипов страниц сайта
  3. Спросить с исполнителя выполнение задач, определенных в ТЗ

Для исполнителя важно получить индивидуальное задание по следующим причинам:

  1. Понять желания и цели заказчика
  2. Рассчитать объем и стоимость работ. Установить реальные сроки для выполнения всех задач
  3. Минимизировать количество возможных доработок и исправлений после сдачи сайта заказчику

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

Кто составляет техническое задание

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

Что обязательно должно содержать техзадание по разработке сайта

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

  • Цели сайта, например, привлечение трафика, увеличение продаж или расширение клиентской базы
  • Производимая или реализуемая продукция, целевая аудитория
  • Способ взаимодействия с клиентами
  • Примеры других сайтов и дизайнов, которые вам нравятся (референсы)
  • Фирменный стиль компании, если он у вас есть
  • Желаемые корпоративные цвета, шрифты, слоганы
  • Логотип бренда (если он есть или его нужно разработать)
  • Создание контента (с указанием, является ли это частью работы или нет)

Пример содержания ТЗ

1. Терминология (глоссарий)

2. Общая информация

2. 1. О компании

2.2. Цель и задачи сайта

2.3. Целевая аудитория

2.4. Тип сайта

2.6. Домен

3. Технологические требования

3.1. Платформа сайта

3.2. Требования к хостингу

3.3. Требований к работе сайта

3.4. Требования к интеграциям

4. Структура страниц сайта

5. Дизайн-макет сайта

6. Контент сайта

8. Функционал и анимации сайта

9. SEO-оптимизация

10. Веб-аналитика

Полезно знать: Что такое SEO-оптимизация сайта – продвижение в Яндекс и Google

Рекомендуем заказать: SEO продвижение сайта в ТОП-3 с оплатой по KPI

Что не должно быть в ТЗ (ТОП 10 ошибок)

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

10 распространённых ошибок и недочётов при составлении ТЗ

ТОП 10 ошибок в техническом задании:

  1. Расплывчатые формулировки, нет конкретики. Например, не указали тип сайта
  2. Не предоставили примеры сайтов, которые вам нравятся
  3. Не прописали пользовательские сценарии
  4. Не указали целевые действия
  5. Не регламентировали семантическую разметку сайта
  6. Не оговорили вопрос установки счетчиков веб-аналитики
  7. Использовали качественные прилагательные: красивый, стильный и пр
  8. Не указали дедлайн
  9. Что-то оставили на усмотрение разработчика
  10. Не прописали в общих требованиях предоставление всех данных по итогу работы от регистрации доменного имени, хостинга для сайта до предоставления логина и пароля от административной панели

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

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

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

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

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

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

Детальное техническое задание

Универсальные требования ТЗ для разработки сайта

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

1.
Общие требования

Общие требования могут включать:

  • Применить одну из систем управления сайтом, например, NetCat, WordPress, Drupal, 1С:Битрикс
  • Предоставить данные для доступа к системе управления сайтом и его корректировки
2.
Дизайн

Чаще всего требуют:

  • Применить определенную цветовую гамму, язык HTML и CSS
  • Создать сайт по определенной структуре (хедер, блок отображения меню сайта, блок отображения различного рода графической информации, футер сайта)
  • Использовать формат изображений: jpg или png
3.
Функциональность сайта

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

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

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

Написание текста — дополнительная услуга. Разработчики пишут сами или нанимают подрядчика за дополнительную плату.

Пример техзадания для разработки сайта

Пример технического задания на разработку сайта, сделанное в KeyClient: образец технического задания на разработку сайта интернет-магазина.

Цели будущего сайта

Запустить удобную онлайн-платформу электронной коммерции продуктов питания. В частности:

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

Требования к структуре сайта

Сайт должен содержать следующие элементы:

  1. Хедер. Расположить логотип и название магазина
  2. Блок отображения главного меню сайта
  3. Блок отображения последних новостей
  4. Блок отображения новинок
  5. Блок отображения расширенного поиска
  6. Футер сайта. Разместить краткую контактную информацию об интернет-магазине
  7. В блоке меню должны присутствовать категории: «Главная», «Каталог», «Как купить», «Гостевая книга», «Покупателям»

Смотри: пример нашей страницы Блога

Прототип структуры сайта для ТЗ

Требования к навигации (меню) сайта

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

Требования к дизайну сайта

  1. Дизайн должен быть выдержан в строгих и мягких тонах
  2. Использовать бледно-розовый оттенок, код цвета #ffb6c1
  3. Использовать шрифт Open Sans

Требования к юзабилити сайта

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

Требования к функциональным возможностям сайта

Администратор имеет право:

  1. Создавать, удалять, редактировать карточки товара, акций, новостей
  2. Редактировать контакты, добавлять адреса новых магазинов

Пользователь может:

  1. Регистрировать учетную запись, редактировать все личные данные
  2. Заказать обратный звонок
  3. Проверять корзину: добавлять, удалять товарные позиции, оплатить счет

Требования к технологиям сайта (платформа)

  1. Для написания статических страниц и шаблонов должны использоваться языки HTML 4 и CSS
  2. Исходный код должен разрабатываться в соответствии со стандартами W3C (HTML 4. 0)
  3. Для реализации интерактивных элементов клиентской части должны использоваться языки JavaScript и DHTML

Дизайн сайта должен быть выполнен с использованием языка CSS и HTML.

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

Резюме по техническому заданию на разработку сайта

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

Не потеряйте нас, подпишитесь на дайджест
и сразу получите: «10 лайфхаков по привлечению клиентов»

Как составить ТЗ на разработку сайта

Главная

/блог

/Создание web-сайтов

/Как правильно составить ТЗ на разработку сайта?

Разработка сайта начинается не с отрисовки прототипов и не с разработки дизайна.

4 мин.

02 Март 2021

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

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

Зачем нужно ТЗ?

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

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

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

Как правильно составлять ТЗ

Писать точно и однозначно

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

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

Требования в техническом задании должны быть четкими и детальными. Например, вместо требования, чтобы у сайта была быстрая загрузка, можно указать требование, чтобы сайт достигал минимум 70 баллов в Google PageSpeed. А вместо требования, чтобы сайт был готов к большим нагрузкам, можно указать, что сайт должен выдержать единовременный наплыв в 60 тысяч пользователей.

Указать общую информацию

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

Описать инструменты

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

Заказав сайт-визитку, но не указав в пожеланиях, что нужна разработка на Битрикс, можно получить сайт на Tilda.

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

Перечислить пожелания к работе сайта

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

Указать структуру сайта

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

Визуализировать структуру страниц

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

Создание интернет-магазина под ключ Разработка с нуля

Подготовим ТЗ, согласуем с вами и реализуем командой профессионалов

Узнать больше

Важный этап — отрисовка прототипов (скелетов будущих страниц). 

Отрисовкой прототипов занимаются профессиональные UX/UI-дизайнеры.

Если отрисовать прототипы нет возможности, то можно остановиться на перечислении элементов.

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

Расписать сценарии

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

Определиться с контентом

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

Описать дизайн

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

Заключение

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

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

Есть задача? Найдем решение!

Вас зовут *

Ваш телефон *

Ваша эл.почта

Расскажите о вашем проекте

Нажатием кнопки я принимаю условия Оферты и согласен с Политикой конфиденциальности

Условия эталона проекта (TOR) Шаблон

Содержание

  • Определение и цель TOR
  • Содержание TOR
      • 1. Справочная информация
      • 2. Цели
      • 3. Проблемы
      • 4. МЕТОДОЛОГИЯ
        • .
      • 5. Экспертиза
      • 6. Отчетность
      • 7. Рабочий план

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

Шаблон технического задания Скачать бесплатно
(файл DOC, 48Kb)

Определение и цель ТЗ

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

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

ТЗ проекта содержит четкое описание следующей критической информации:

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

Содержание ТЗ

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

  • Предварительное ТЭО и технико-экономический анализ
  • Оценочная деятельность
  • Разработка и мониторинг контрактов на реализацию
  • Оценочные исследования
  • Отчетность и аудит
  • Другая консультационная работа, необходимая на любой стадии проекта

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

Общий формат содержания Технического задания на проект предлагается ниже:

  • Предыстория проекта
  • Цели проекта
  • Вопросы, которые необходимо изучить и проанализировать по определенным критериям
  • Применяемая методология внедрения
  • Требуется экспертиза
  • Требования к отчетности
  • Рабочий план, включая графики работ

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

1. Предыстория

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

Раздел «Предыстория» шаблона ТЗ обычно включает несколько параграфов, в которых рассматриваются следующие вопросы:

  • Опишите проект в контексте соответствующей деловой потребности
  • Укажите общую роль заинтересованных сторон в выполнении проектной деятельности
  • Выделите краткий обзор проекта на сегодняшний день
2.
Цели

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

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

Тип работы/этап проекта

Общий объектив

Завершение проекта Увеличить продажи продукта «А» на 15% за 3 месяца
 
– ТЭО Предоставить лицам, принимающим решения, достаточную информацию, необходимую для принятия или отклонения предлагаемого проекта
— Мониторинг Предоставить лицам, принимающим решения, достаточную информацию, необходимую для принятия обоснованных суждений о выполнении проекта
– Аудит Чтобы проект оставался актуальным и обоснованным с юридической, экономической и технической точек зрения
3.
Вопросы

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

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

  • Эффективность — этот критерий определяет, насколько хорошо данная деятельность преобразует имеющиеся ресурсы в желаемые результаты с точки зрения количества, качества и времени
  • Релевантность — помогает проанализировать, выполняется ли данное действие с желаемой выгодой
  • Эффективность – касается того, насколько широко использованы результаты проекта и реализована ли цель проекта
  • Воздействие — этот показатель помогает выяснить, в какой степени преимущества проекта, полученные целевой аудиторией, оказывают общее влияние на большее количество заинтересованных людей
  • Устойчивость — этот критерий определяет, сохранятся ли положительные результаты проекта после прекращения финансирования.
4. Методология

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

Таким образом, раздел «Методология» шаблона технического задания по проекту должен включать описание следующих элементов:

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

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

В разделе «Экспертиза» шаблона технического задания на проект должно быть указано следующее:

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

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

В разделе «Требования к отчетности» шаблона технического задания должны быть четко указаны требования к процессу отчетности и могут быть указаны следующие сведения:

  • Содержание отчетов по проектам
  • Правила составления приложений
  • Шаблоны отчетов
  • Язык для использования в отчетах
  • Используемые компьютерные программы
  • Даты подачи
  • Люди, ответственные за отчетность и утверждение
  • Другая достаточная информация, такая как количество копий, которые необходимо создать, обязанности по составлению и представлению отчета и т. д.
7. Рабочий план

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

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

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

Как написать мощное техническое задание

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

Это техническая часть тендерной документации.

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

Подробное техническое задание содержит следующую информацию:

  • Объем работ
  • Расписание
  • Требования к координации
  • Законы, правила и стандарты
  • Ресурсы предоставлены

Объем работ

Это получено из описания содержания проекта и содержит два основных компонента:

  1. Результаты
    Слово результаты отсутствует в английском словаре и подчеркнуто в MS Word как орфографическая ошибка, но это одно из самых важных слов в управлении проектами. Результаты — это те предметы, которые проект должен произвести. Это может быть материальный продукт, такой как здание, или электронный элемент, такой как база данных. Это могут быть и услуги, например, обучающий курс. Но каждый проект создавался для того, чтобы что-то производить, и эти продукты должны быть четко определены.

    Результаты должны быть определены с точки зрения класса и качества. Класс — это классификация продукта, основанная на технических характеристиках, а не на качестве, которое представляет собой степень, в которой продукт соответствует требованиям. Низкая оценка — это не плохо, если так и было задумано. Однако низкое качество означает, что продукт не соответствует требованиям, и это всегда плохо. Свод знаний по управлению проектами (PMBOK) определяет создание плана управления качеством, который является частью общего плана управления проектом, где требования определяются до выполнения проекта. Техническое задание обычно представляет собой документ, содержащий только словесную информацию, то есть не включающий чертежи и планы.

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

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

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

Расписание

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

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

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

Требования к координации

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

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

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

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

Законы, постановления и стандарты

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

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

Точно так же почти в каждой отрасли есть стандарты, разработанные для разных видов работ. Международная организация по стандартизации (ISO) разработала стандарты для многих вещей, но в большинстве стран есть свои собственные организации по стандартизации, которые расширили и адаптировали стандарты ISO, например Американский национальный институт стандартов (ANSI). Кроме того, специализированные отраслевые организации по стандартизации, такие как Американское общество по испытаниям и материалам (ASTM), разрабатывают узкоспециализированные стандарты.

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

Предоставленные ресурсы

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

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

Свод знаний по управлению проектами (Руководство PMBOK)

В руководстве PMBOK описание работ по закупкам является результатом процесса планирования управления закупками в области знаний «Управление закупками проекта».

Техническое задание идентично настоящему Техническому заданию о закупках . Руководство PMBOK отдает предпочтение более общему Техническому заданию , потому что Техническое задание используется преимущественно в одних отраслях и очень мало в других.

Он находится в группе процессов «Планирование проекта», поэтому создается до этапа выполнения проекта.

 

 

Техническое задание [Бесплатный шаблон]

Пришло время для нового шаблона!

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

  • Записываю в письменном виде, что на самом деле должна делать моя руководящая группа, чтобы установить «основные правила» для этой группы и их собраний. Это помогает им сосредоточиться на текущей работе, не слишком вдаваться в детали и помогает им и другим серьезно относиться к проекту.
  • Чтобы определить, что должен делать конкретный рабочий поток в проекте. Это полезно, когда есть технический поток работы, которым кто-то руководит, а другие направления подхватываются другими людьми. Это почти урезанная версия Документа об инициировании проекта или Устава проекта, поскольку он относится к определенному набору лиц и задач. Мне это нравится, потому что помогает им и мне увидеть, какова их конкретная роль и обязанности, входящие в их компетенцию.

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

В этой статье:

  • Что входит в техническое задание
    • Общая информация
    • Введение в проект
    • Цели и результаты. шаблон.

      Что входит в техническое задание

      Что входит в техническое задание? Я рад, что вы спросили.

      Читайте дальше, чтобы увидеть, что я включаю.

      Общая информация

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

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

      Я использую параметр «Вставить поле» в Word для ввода имени файла, но если оно выглядит слишком длинным или странным, я сокращаю его до имени, которое мы все поймем.

      Введение в проект

      Начните документ ТЗ по вашему проекту с краткого вводного текста о сути проекта.

      Кратко опишите, что охватывает это техническое задание. Скорее всего, это будет либо компетенция одной группы, т. е. вашей руководящей группы, либо рабочий поток. Объясните, с чем это связано. Например:

      Этот рабочий поток охватывает технические элементы проекта xxx, включая программные и аппаратные элементы, техническое проектирование и тестирование.

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

      Цели и результаты

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

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

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

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

      Ключевые ресурсы/роли и обязанности

      Перечислите ключевые имена и то, за что они отвечают. Это легко сделать в виде таблицы.

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

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

      Встречи команды будут проходить ежемесячно или реже по мере необходимости. Депутаты допускаются только по согласованию с председателем. Постоянная повестка дня будет включать:

      1. Обзор хода выполнения проекта, вех, рисков и проблем
      2. Результаты для утверждения или принятия решений
      3. Особое внимание к особым вопросам для обсуждения или эскалации
      4. AOB

      Структура организации рабочего процесса

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

      Подход

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

      Вехи

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

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

      Бюджет

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

      Включите заявление вроде:

      Ориентировочный бюджет для этого рабочего потока/группы составляет xxx. Это касается ХХХ. Бюджетные предположения включены в PID, а полные цифры подробно описаны в экономическом обосновании проекта.

      Другие примечания

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

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

      Как получить шаблон

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

      Там вы сможете скачать шаблон технического задания. Это документ Microsoft Word, и, как всегда, вам придется отредактировать его, чтобы удалить мои заметки и вставить свой текст (и не забудьте также обновить верхние и нижние колонтитулы).

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

      Пин-код для дальнейшего чтения:

      Проверьте свое техническое задание (ТЗ)

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

      Каковы ваши текущие компетенции по этой теме?

      • Каков ваш уровень понимания этой темы.*
        • Экспертные знания
        • Разумные знания уже
        • Слышал об этом, но не проходил обучение
        • Нет предыдущих знаний

      В качестве примера мы видим ТЗ с многочисленными целями проекта вместо одной, как предлагается в их собственном учебном пособии. Некоторые из этих целей являются либо результатами, либо даже действиями, либо просто глупыми утверждениями, такими как «реализовать проект». Результаты — это в основном действия и предположения, которые должны быть проверены и подтверждены перед запуском, например: «фермеры готовы сотрудничать». Логику вмешательства часто трудно понять или она никогда не задумывалась как логичная…. Элементы дизайна проекта часто перепутаны, а действия расплывчаты, упрощены или завышены, например: «стимулирование предприятий». Более того, исполнительный потенциал агентства-исполнителя редко должным образом оценивается или даже запрашивается оценка …

      Вы можете подумать: «Давайте не будем», потому что после того, как вы выиграете тендер, у вас может появиться шанс каким-то образом существенно изменить и обсудить предложение на начальном этапе, что иногда даже кажется правдой…. Звучит странно, не так ли? Какой смысл в таком тендере?

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

      Может быть, у вас есть идея, как решить эту проблему?

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

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

       

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

       

      Оставьте свое имя и адрес электронной почты и отметьте нужное поле, чтобы ответить на ваш интерес, и мы свяжемся с вами как можно!

       

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

      Мы разделили ТЗ на два основных компонента:

      1. Часть ЧТО должно произойти, относящаяся к проекту в стадии изучения и
      2. КАК это должно произойти, часть, касающаяся организации миссии , которую на самом деле тоже можно рассматривать как проект.

      Затем по содержанию и методике можно ожидать либо инструкций , либо вопросов .
       

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

       

      Формат технического задания

      для (идентификационной) миссии с указанием аспектов (формулирования/мониторинга/оценки) миссии

      МИССИЯ (инструкции)

      Глава А: Обоснование (идентификация) миссии

      • Запрос
      • Актуальность миссии по отношению к донорской политике/отраслям/темам
      • Описание формулировки запроса
      • Описание контекста запроса
      • Обоснование предлагаемого места предполагаемого вмешательства

      Глава B: Цели миссии

      • Выдача качественного надлежащего документа
      • Проверить достоверность предоставленных данных

      Глава C: Объем миссии

      • Настоящие решения по географическим регионам, бенефициарам и секторам.

      Глава D: Роль организаций в миссии

      • Ведущий партнер!
      • Национальные эксперты!
      • Правовая база и полномочия!
      • Офисная и секретарская поддержка миссии.

      Глава E: Применяемый метод

      • Метод(ы) сбора данных (семинары, интервью, АФР и т. д.
      • Контакты / учреждения для консультации
      • Собственные предложения?

      Глава F: Требуется опыт

      • Должности и роли участников миссии
      • Местная экспертиза
      • Опыт работы за границей

      Глава G: Продолжительность миссии

      • Продолжительность
      • Фазы
      • План шагов

      Глава H: Бюджетная миссия

      • По компоненту

      Глава I: Отчетная миссия

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

      Глава J: Продукты

      • Отчет об идентификации по проекту
      • ТЗ миссии по формулированию
      • Меморандум о взаимопонимании с партнерами
      • Отчет о миссии

       

       

      ПРОЕКТ (вопросы, на которые необходимо ответить)

      Глава 1: Справочная информация

      • Проверить место предполагаемого вмешательства?
      • Проверить достоверность данных, указанных в запросе
      • Общая мотивация- почему этот запрос – к нам?, в данный момент ?

      Глава 2: Вмешательство (ЧТО должно произойти, чтобы удовлетворить бенефициаров)

      • Кто такие бенефициары/«конечные пользователи» и почему они были выбраны?
      • Описание?
      • Диагностика с помощью анализа проблем
      • Логическая структура
        – Общие цели?
        — Цель проекта + OVI?
        – Результаты + OVI?
        – ФОРМУЛИРОВКА: Деятельность?
      • Варианты или альтернативы: обоснование выбора
      • ФОРМУЛИРОВКА: показатели результатов, цели проекта и допущения
      • ФОРМУЛЯЦИЯ: модификации логической структуры
      • ФОРМУЛЯЦИЯ: возможность выбора

      Глава 3. Гипотезы и факторы риска для матрицы ЧТО

      • Определение предположений/гипотез
      • Какие могут быть возможные негативные побочные эффекты?
      • Оценка согласованности с другими донорами
      • Какова гибкость дизайна проекта в отношении возникновения возможных факторов риска

      Глава 4: ФОРМУЛИРОВКА: Институциональное укрепление (КАК это должно происходить)

      • Кто является действующими лицами и агентствами-исполнителями и почему они были выбраны?
      • Описание?
      • Диагностика с помощью анализа проблем
      • Матрица управления:
        – Цель управления: Профессиональное функционирование
        – Результаты управления?
        – Управленческая деятельность?
      • Варианты или альтернативы: обоснование выбора
      • Показатели результатов управления, цели управления и допущения

      Глава 5. Гипотезы и факторы риска для матрицы управления (КАК)

      • Определение предположений/гипотез
      • Какие могут быть возможные негативные побочные эффекты?
      • Оценка согласованности с другими донорами
      • Какова гибкость дизайна проекта в отношении возникновения возможных факторов риска

      Глава 6: Устойчивое развитие

      • Дизайн тестового проекта по критериям устойчивого развития
      • Правительственная политика?
      • Правовая база?
      • Собственность?
      • Технологические аспекты/обслуживание?
      • Социальные факторы?
      • Гендерные особенности?
      • Экологические проблемы?
      • Управленческий и организационный потенциал. Ожидаемый организационный потенциал учреждений-исполнителей в будущем
      • Финансовая устойчивость?
      • Экономическое встраивание?

      Глава 7: Условия исполнения/сотрудничества

      • Как будут участвовать бенефициары
      • Каким будет вклад страны/организации/бенефициаров-получателей?
      • Каковы обязательства вовлеченных сторон?
      • Каков вид/модальность помощи?
      • Официальные структуры / Меморандумы о взаимопонимании
      • Каков будет объем технической помощи?
      • Процедуры и организация закупок?
        • ФОРМУЛИРОВКА
      • : Как будет или будет укрепляться потенциал исполнительных агентств ?

      Глава 8: Управление проектом

      • Организационная структура?
      • Межорганизационные отношения?
      • Кадровое обеспечение (экспатрианты или местные жители)?
      • Задачи и должностные инструкции?
      • Внутреннее усиление (Опорная матрица)
      • и оперативный бюджет?
      • Модальности мониторинга и оценки?
      • План передачи?

      Глава 9: ФОРМУЛИРОВКА: План мониторинга и оценки

      • Совместные процессы МиО?
      • Объективно проверяемые показатели результатов, цели проекта, (общие задачи) и допущения?
      • План мониторинга: сбор и анализ данных
      • Обучение: кто что сообщает, когда и кому?

      Глава 10: Продолжительность проекта

      • Какова ожидаемая продолжительность проекта?
      • Какие фазы можно выделить?
      • ФОРМУЛЯЦИЯ: Подробнее о фазах.

      Глава 11: Бюджет

      • Примерный бюджет
      • ФОРМУЛИРОВКА: Проверка бюджета и детали
      • ФОРМУЛИРОВКА: План финансирования

      Глава 12 Ссылки

      • Список проверенных отчетов об оценке
      • публикаций

      Глава 13: ПРИЛОЖЕНИЯ

      • Формулировка ТЗ (и масштаб миссии)
        – Результаты + OVI
        – Мероприятия
        – План финансирования
        – Бюджет миссии по формулировке
        – и т. д.
      • ФОРМУЛИРОВКА: ТЗ Техническая помощь
      • ФОРМУЛИРОВКА: Предложение к соглашению/контракту

      Оценка этого теста ТЗ

      • Как вы восприняли этот тест ТЗ?*
        • Интересно
        • Нейтральный
        • Не интересно
      • Не могли бы вы прокомментировать этот тест?
      • Имя*

        Первый Последний

      • Email*

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

      Оставьте свое имя и адрес электронной почты и отметьте нужное поле, которое вас интересует, и мы свяжемся с вами как можно скорее!

      Отправьте файл

      • Файл
      • Имя*

        Первый Последний

      • Электронная почта*
      • Пожалуйста, укажите, что вы ожидаете от нас. Мы вышлем вам предложение.*

      Целевая группа по оцифровке – Техническое задание

      © Корона авторское право 2022

      Эта публикация распространяется под лицензией Open Government License v3.0, если не указано иное. Чтобы ознакомиться с этой лицензией, посетите сайт nationalarchives.gov.uk/doc/open-government-licence/version/3 или напишите в отдел информационной политики Национального архива, Кью, Лондон TW9 4DU, или по электронной почте: psi@nationalarchives. gov. Великобритания.

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

      Эта публикация доступна по адресу https://www.gov.uk/government/publications/digitisation-taskforce/digitisation-taskforce-terms-of-reference.

      Контекст

      19 июля 2022 года правительство объявило, что будет выполнять рекомендацию Марка Остина по вторичному обзору привлечения капитала (SCRR) о создании рабочей группы, продвигающей полную цифровизацию пакетов акций, во главе с независимым, нейтральным председателем. SCRR определяет оцифровку как устранение бумажных процессов в инфраструктуре расчетов по ценным бумагам на рынках капитала, а также усовершенствование текущей структуры владения акциями в Великобритании.

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

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

      Предыдущая работа включала разработку модели некоторыми заинтересованными сторонами отрасли, чтобы уложиться в крайний срок для ликвидации бумажных сертификатов акций к 2025 году, как того требует Регламент центральных депозитариев ценных бумаг ЕС (CSDR). Эта модель была сосредоточена исключительно на искоренении бумажных сертификатов, но не учитывала, как можно улучшить более широкую структуру опосредованного владения акциями или что можно сделать для повышения эффективности привлечения капитала компаниями. В обзорном документе Юридической комиссии по посредническим ценным бумагам, опубликованном в 2020 году, были рассмотрены вопросы, связанные с посредничеством, например, что можно сделать для расширения прав акционеров и должны ли посредники повсеместно соблюдать минимальные уровни обслуживания, чтобы облегчить реализацию прав акционеров инвесторами.

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

      Принимая во внимание масштабы координации рынка и различный опыт, необходимый для обеспечения того, чтобы цифровизация приносила справедливые результаты, правительство решило назначить сэра Дугласа Флинта руководителем группы отраслевых экспертов, чтобы определить наилучший подход для Великобритании. Кроме того, HMT, BEIS и FCA предложили на рассмотрение этой экспертной группы ряд принципов, чтобы цифровизация приносила максимально возможные преимущества.

      Задачи

      Задачи Целевой группы по оцифровке:

      1) Работать с заинтересованными сторонами в секторе финансовых услуг для достижения консенсуса в отношении изменений, чтобы:

      i. Определить немедленные и долгосрочные средства улучшения существующей системы владения акциями с участием посредников, чтобы:

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

      • эмитенты

        могут легче идентифицировать и общаться с инвесторами в качестве основных бенефициарных владельцев, в том числе по предложениям о вторичном привлечении капитала; и

      • Можно определить

        эффективности для снижения затрат и временных задержек в существующей системе.

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

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

      2) Разработайте график и план внедрения изменений и поддержите прогресс.

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

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

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

      Управление, взаимодействие и расписание

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

      Проект принципов, которыми будет руководствоваться работа Целевой группы по оцифровке

      1) Цифровизация должна приносить пользу

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

      2) Права инвесторов-посредников

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

      3) Права существующих сертифицированных акционеров

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

      4) Права эмитента должны быть улучшены.

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

      5) План перехода

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

      6) Эффективная структура

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

      7) Безопасность

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

      8) Оцифровка

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

      9) Рынок должен рассмотреть все доступные варианты оцифровки при условии, что они соответствуют критериям, представленным выше.

      Шаблон 4: Техническое задание для проверок государственных органов

      © Корона авторское право 2022

      Эта публикация распространяется под лицензией Open Government License v3.0, если не указано иное. Чтобы ознакомиться с этой лицензией, посетите сайт nationalarchives.gov.uk/doc/open-government-licence/version/3 или напишите в отдел информационной политики Национального архива, Кью, Лондон TW9 4DU, или по электронной почте: psi@nationalarchives. gov. Великобритания.

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

      Эта публикация доступна по адресу https://www.gov.uk/government/publications/public-bodies-review-programme/template-4-terms-of-reference-for-public-bodies-reviews.

      Как пользоваться этим документом

      Необходимо следовать этому шаблону. Если министерство желает отступить от его элементов или внести в него дополнения, это следует обсудить с Кабинетом министров.

      Как составить техническое задание

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

      Пожалуйста, обратитесь к параграфам 54-60 руководства для получения рекомендаций по составлению ТЗ, если проверяемым органом является научно-исследовательское учреждение государственного сектора (PSRE) или научный консультативный совет.

      Проверка государственного органа: Шаблон технического задания (ТЗ)

      [Название проверки] государственные органы

      Справочная информация

      В ТЗ должна быть представлена ​​краткая общая информация о проверяемом государственном органе. Это может включать:

      • Миссия и цель органа, включая любой соответствующий устав.

      • Его расходы, количество сотрудников FTE, структура управления и административная классификация.

      • Его механизмы подотчетности, включая:

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

      • Любые ключевые области государственной политики, которые этот орган реализует полностью или частично.

      • Любые ключевые рабочие функции.

      • Любое отношение к децентрализованным администрациям.

      • Дата последнего просмотра тела.

      • Любые результаты предыдущих обзоров, которые будут иметь отношение к этому обзору [сноска 1] .

      Объем и цель проверки

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

      В этом разделе необходимо указать:

      • Какие из квадрантов и тем, изложенных в Требованиях к проверкам государственных органов, будут рассмотрены в обзоре.

      • Должен ли государственный орган выполнять функцию?
        1. Существует ли поставщик услуг или поставщики услуг в частном секторе, которые могли бы выполнять эту функцию? Оказывает ли предоставление этой услуги правительством негативное влияние на рынок / рассматривался ли вопрос о влиянии на рынок?
        2. Какие варианты доступны для приватизации, аутсорсинга и/или развития рынка с течением времени?
        3. Если служба должна по-прежнему предоставляться государственным сектором, может ли министерство забрать политические функции и решения, которые должны принадлежать его министрам?
      • Как департамент обеспечивает, чтобы АО действовал в рамках полномочий министра и имел средства контроля для обеспечения высоких стандартов честности и соотношения цены и качества.
      • Работает ли орган на надлежащей «вытянутой руке» для обеспечения правильного баланса между соответствием приоритетам правительства и любой потребностью в технической экспертизе или беспристрастности.
      • Есть ли у ALB стратегия роста мест и включены ли планы переселения в планы будущего размещения их подразделений.

      • Определите обстоятельства, при которых ALB могут создавать свои собственные правила, и роль министров/парламента в этом процессе.

      • Ведущий рецензент должен определить, где может быть достигнута экономия лимитов расходов отдела ресурсов (RDEL) в размере не менее 5% для среднего обзора, что

        1. Должен быть проведен анализ штатного расписания, корпоративных функций и соответствия стратегии общих услуг, зависимости от ресурсов, не связанных с выплатой заработной платы, использования имущества и закупок, уровня мошенничества и ошибок, соотношения цены и качества грантов и оцифровки услуг.
        2. Действия по достижению цели эффективности должны быть отражены в рекомендациях проверки, а также зарегистрированы и количественно определены в опубликованном отчете проверки.
        3. Цель не менее 5% должна быть достигнута организмом в течение 1-3 лет и продолжаться на регулярной основе.

      • Более подробная информация по темам, изложенным в Требованиях к проверкам государственных органов, будет охватывать проверку, например, «Проверка будет посвящена эффективности и будет сосредоточена, в частности, на функциях и форме».

      • Дополнительные области, которые, как ожидается, охватит проверка, выходящие за рамки Требований.

      • Как было принято решение о том, что пересматривать, что следует учитывать:

        • Результат проведенной самооценки. (Для получения дополнительной информации см. Модель самооценки и руководство.)

        • Факторы, указанные в пункте 118 руководства, если они имели отношение к решению.

        • Любые дополнительные факторы, выявленные отделом в отношении цели и объема проверки.

      • Все, что выходит за рамки обзора.

      • Любые другие органы или функции, рассматриваемые в рамках проверки.
      Механизмы ведомственного и государственного органа для проверки

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

      • Соответствующий ответственный министр и роль министра в обзоре.

      • Ответственный главный бухгалтер и его роль в проверке.

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

      • Роль старшего спонсора и команды спонсоров в отделе спонсоров.

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

      • Территориальная протяженность государственного органа и любое отношение к децентрализованной администрации.

      Ведущий рецензент

      В ТЗ должно быть разъяснено, кто является ведущим рецензентом и какова его роль. Это также может относиться к Условиям участия (Шаблон 2 в руководстве). Дальнейшие указания относительно ожидаемой роли ведущего рецензента можно найти в главе 7 руководства.

      Группа проверки

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

      Сбор доказательств и взаимодействие с заинтересованными сторонами

      В этом разделе должно быть описано, как Группа по анализу и Ведущий рецензент будут собирать доказательства. Руководство по сбору доказательств можно найти в пунктах 143–146 руководства. В нем должно быть указано:

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

      • будут ли консультации, публичные или иные, использоваться для сбора доказательств;

      • какую роль будет играть проверяемый орган в проверке, и каковы ожидания ведущего проверяющего и группы проверки в содействии этой роли;

      • какую роль играют команда спонсора и Старший спонсор в проверке и каковы ожидания ведущего рецензента и группы проверки в содействии этой роли; и

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

      Контрольные комиссии (если это имеет значение для проверки)

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

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

      Дополнительную информацию о создании контрольной комиссии можно найти в пунктах 154–158 руководства.

      Результаты

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

      • Заполненная модель самооценки.

      • Окончательный отчет о внутренней проверке и рекомендации.

      • Предлагаемый отчет для публикации и рекомендации.

      Дополнительными продуктами, которые могут быть согласованы, могут быть:

      • Письменное министерское заявление об объявлении и закрытии обзора.

      • План проекта и реестр рисков.

      • Публичные консультации.

      • Интервью с заинтересованными сторонами.

        No related posts.