Помните закон Мерфи? Если вас могут понять неправильно, вас обязательно поймут неправильно. Это справедливо не только в общении между людьми, но и в создании сайтов. Клиент хотел второй «Фейсбук», а получил форум юных собаководов. Разработчик не угадал хотелку заказчика - потратил время впустую.

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

Статья будет полезна:

• Всем, кто имеет отношение к созданию сайтов: разработчикам, дизайнерам, верстальщикам.
• Менеджерам проектов.
• Руководителям диджитал-студий.
• Предпринимателям, которые планируют заказать разработку сайта.

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

Что такое техзадание и зачем оно нужно

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

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

Пользы от технического задания много. Для каждой стороны она своя.

Польза для клиента:

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

Польза для исполнителя:

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

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

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

Техзадание составляет исполнитель

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

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

Это не значит, что клиент исчезает и появляется в самом конце, чтобы написать: «Збс, одобряю». Он тоже должен участвовать в процессе:

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

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

Этот совет вытекает из главной цели техзадания - «Убедиться, что клиент и исполнитель правильно поняли друг друга».

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

Посмотрите. Кто-то ведь посчитал этот дизайн красивым и разрешил использовать на своем сайте:

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

• Сайт должен понравиться заказчику. А если у него будет плохое настроение?
• Сайт должен быть удобным. Что это значит? Удобным для чего?
• Сайт должен выдерживать большие нагрузки. 10 тысяч посетителей? Или 10 миллионов?
• Качественный экспертный контент. Ну, вы поняли.

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

• Сайт должен загружаться быстро → Любая страница сайта должна иметь больше 80 баллов в Google PageSpeed Insights.
• Большие нагрузки → 50 тысяч посетителей одновременно.
• На главной странице выводится список статей → На главной странице выводится список последних 6 опубликованных статей.
• Минималистичный удобный интерфейс подписки → Поле «Оставьте e-mail» и кнопка «Подписаться» → *нарисованный эскиз*.

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

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

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

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

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

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

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

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

Чтобы таких проблем не было, опишите используемые инструменты, движки и библиотеки. Заодно укажите требования к хостингу. Мало ли, вы сделаете на PHP - а у клиента сервер на.NET.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Действие пользователя.
• Ответное действие сайта.
• Результат.

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

Подробнее о сценариях использования читайте в «Википедии ».

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

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

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

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

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

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

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

Вместо вывода: структура техзадания

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

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

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

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

Комментарии разработчиков

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

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

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

Крупные заказчики часто просят очень подробные ТЗ, в которых описана каждая кнопка. Небольшие компании наоборот не любят дотошные документы на 100 страниц. Долго читать и легко упустить что-то важное. Чаще мы делаем лаконичные ТЗ на 10–15 страниц.

Мы указываем:

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

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

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

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

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

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

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

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

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

Что было плохо:

1. Мы писали список требований к иллюстрациям для анимации, не сопроводив эти требования примерами с картинками и видео. Это был просто текст вроде: “старайтесь рисовать гнущиеся элементы таким образом, чтобы энкор поинты суставов совпадали друг с другом”. Из-за того что мы поленились это проиллюстрировать, наш иллюстратор сделал то что нужно только с третьего раза.
2. Мы насыщали ТЗ слишком большим количеством примеров. Иллюстратор буквально тонул в изобилии работ, которые нам нравятся. Не было четкого стилистического ориентира.
3. Много текста. Мы писали лишнюю информацию о проекте. Эта информация никак не могла помочь иллюстратору сделать его работу.
4. Раскадровка с недостаточными пояснениями о том что будет происходить в слайде.
5. Доступность ТЗ только онлайн, на Гугл Диске.
6. Мы не имели четкого представления для кого пишем это ТЗ. Мы не вошли в роль этого человека для нашего проекта.

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

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

Суть нашего нового подхода к написанию ТЗ свелась к следующему:

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

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

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

4. Любые технические требования теперь мы иллюстрируем и записываем видео . Тут важно побольше задавать вопросов себе: что в нашем пайплайне может быть непонятно? Что может породить дополнительные вопросы?

5. Теперь мы скидываем не только текст в формате Гугл Докс, но еще ссылку на скачивание PDF версии ТЗ, чтобы в случае неполадок с интернетом, ТЗ было под рукой.

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

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):

ГОСТ 34
ГОСТ 19
IEEE STD 830-1998
ISO/IEC/ IEEE 29148-2011
RUP
SWEBOK, BABOK и пр.

ГОСТ 34

Согласно ГОСТ 34 техническое задание должно включать следующие разделы:

1. Общие сведения
2. Назначение и цели создания (развития) системы
3. Характеристика объектов автоматизации
4. Требования к системе
5. Состав и содержание работ по созданию системы
6. Порядок контроля и приемки системы
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
8. Требования к документированию
9. Источники разработки

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

ГОСТ 19

1. Введение;
2. Основания для разработки;
3. Назначение разработки;
4. Требования к программе или программному изделию;
5. Требования к программной документации;
6. Технико-экономические показатели;
7. Стадии и этапы разработки;
8. Порядок контроля и приемки;
9. Приложения.

Естественно ГОСТ 34 (и 19) уже устарели, и я не люблю их использовать, но при правильном интерпретации стандартов, можно получить хорошее ТЗ, см. Заключение.

IEEE STD 830-1998

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

Согласно стандарту техническое задание должно включать следующие разделы:

1. Введение

• 1. Назначение
• 2. Область действия
• 3. Определения, акронимы и сокращения
• 4. Ссылки
• 5. Краткий обзор

• 1. Взаимодействие продукта (с другими продуктами и компонентами)
• 2. Функции продукта (краткое описание)
• 3. Характеристики пользователя
• 4. Ограничения
• 5. Допущения и зависимости

• 1. Требования к внешним интерфейсам
  • 1. Интерфейсы пользователя
  • 2. Интерфейсы аппаратного обеспечения
  • 3. Интерфейсы программного обеспечения
  • 4. Интерфейсы взаимодействия
• 2. Функциональные требования
• 3. Требования к производительности
• 4. Проектные ограничения (и ссылки на стандарты)
• 5. Нефункциональные требования (надежность, доступность, безопасность и пр.)
• 6. Другие требования

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

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

• Презентацией Юрия Булуя Классификация требований к программному обеспечению и ее представление в стандартах и методологиях .
• Анализ требований к автоматизированным информационным системам. Лекция 11: Документирование требований .
• (читать вместе с комментариями)
• Примеры ТЗ и другой документации по разработке АС для МЭР
• ГОСТ-овский стиль управления . Статья Gaperton по правильной работе с ТЗ по ГОСТ
• Шаблоны документов для бизнес-аналитиков из

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

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

Правила, применяемые к таким заданиям

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

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

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

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

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

Иные формы использования такого документа

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

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

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

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

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

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

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

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

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

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

Кто должен составлять техзадание

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

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

Структура технического задания

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

Структура документа ТЗ:

1. Оглавление
2. История изменений
3. Терминология
4. Общие сведения о проекте (назначение, цели и задачи проекта)
5. Требования к проекту (функциональные, пользовательские, общие и другие требования)
6. Требования к видам обеспечения
7. Требования к документированию
8. Стадии и этапы разработки
9. Порядок контроля и приемки проекта
10. Дополнительные материалы

Рассмотрим подробнее каждый пункт структуры.

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

2. История изменений

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

3. Терминология

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

4. Общие сведения о проекте

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

5. Требования к проекту

Один из самых объемных и также основной пункт в техзадании. В нем описываются абсолютно все требования к проекту, такие как:

• требования к функционированию проекта;
• требования к надежности;
• требования к исполнительному персоналу;
• требования к патентной чистоте;
• требования к стандартизации;
• требования к конфиденциальности;
• требование к безопасности;
• и другие …

6. Требования к видам обеспечения

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

7. Требования к документированию

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

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

8. Стадии и этапы разработки

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

9. Порядок контроля и приемки проекта

В этом разделе описывается порядок приема проекта, система тестов.

10. Дополнительные материалы

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

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

1. Желательно по максимуму использовать графические материалы. Часто бывает так, что одна схема или диаграмма может заменить несколько страниц текста.
2. Не использовать расплывчатых, двусмысленных описаний. Все должно быть описано четко и понятно.
3. Описание проекта должно быть логически связным и не иметь противоречий.
4. Необходимо указывать абсолютно все данные и требования, даже те, которые на первый взгляд могут показаться абсурдными. Такими данными могут быть поля в форме регистрации, формат даты в статье и прочее.
5. При указании сроков, необходимо учитывать, что неотъемлемой частью разработки является тестирование и исправление ошибок, поэтому в очень короткие сроки можно не вложится.
6. После выбора исполнителя необходимо совместно просмотреть ТЗ, возможно появятся новые вопросы или дополнения.