Технические задания

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

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

Многие Разработчики часто недооценивают важность технического задания, однако, ТЗ является важным, можно сказать, краеугольным документом при разработке информационных систем, сайтов, инженерных систем, да и всего чего угодно.
Сегодня, когда в моде Agile, может показаться, что ТЗ документ избыточный, но это до того момента, когда вы не столкнётесь с разработкой действительно серьёзных информационных систем, крупных программных продуктов или порталов. Объяснить на пальцах, чего бы хотелось Заказчику можно, если в системе 3-5 сущности-предмета, а если значительно больше, то обязательно что-нибудь забудется. Потом начнётся рисование на бумажке, записи на салфетках в кафе, сообщения в ватсап: «А вот неплохо было бы сделать, чтобы синие иконочки в правом углу и когда мышкой наводишь, они бы такие выезжали на центр и увеличивались!». Для того чтобы формализовать этот процесс и создаётся техническое задание, то есть документ о том, как всё должно быть.
Техническое задание выполняет ряд важных функций:

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

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

Кто составляет ТЗ?

Техническое задание — это работа не одного человека, а группы лиц:

• Аналитиков со стороны Заказчика — они определяют необходимость системы, выдвигают в письменном виде требования к новой программе.
• Аналитиков со стороны Разработчика — они должны обследовать область, по которой будет разрабатываться программа, или компанию. Учесть все схемы, алгоритмы и нюансы работы, которую будет выполнять система.
• Технический писатель — сотрудник, который соберёт все данные аналитиков и запишет их согласно ГОСТу.

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

По каким ГОСТам пишется ТЗ?

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

В России Техническое задание пишется согласно двум ГОСТам:

• ГОСТ 34.602.89 «Техническое задание на создание автоматизированной системы»;
• ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению».

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

Какой ГОСТ для Технического задания выбрать?

Если вы разрабатываете документацию на программу, которую создали под конкретное предприятие, то ваш ГОСТ 34. Если же пишете документы на массовую программу, то ваш ГОСТ 19.

Можно ли выбрать для тиражируемого программного продукта ГОСТ 34, а для системы под конкретную организацию ГОСТ 19? Да можно, если на этом настаивает по каким-либо причинам Заказчик. Во всех остальных случаях, лучше выбирать нужный ГОСТ, так как Пункты ГОСТов отличаются.

Чем отличаются ГОСТ 34 от ГОСТа 19 при написании ТЗ

Для удобства ниже представлена таблица пунктов ГОСТа 34 и ГОСТа 19 для написания Технического задания.

ГОСТ 19	ГОСТ 34
1. Введение	1. Общие сведения
2. Основания для разработки
3. Назначение разработки	2. Назначение и цели создания системы
	3. Характеристика объекта автоматизации
4. Требования к программе или программному изделию	4. Требования к системе
4.1. Требования к функциональным характеристикам	4.2. Требования к функциям (задачам), выполняемым системой
	4.1. Требования к системе в целом
	4.1.1. Требования к структуре и функционированию системы
	4.1.3. Показатели назначения
4.2. Требования к надёжности	4.1.4. Требования к надёжности
	4. 1.5. Требования к безопасности
	4.1.6. Требования к эргономике и технической эстетике
4.3. Условия эксплуатации	4.1.2. Требования к численности и квалификации персонала системы и режиму его работы
	4. 1.9. Требования к защите информации от несанкционированного доступа
	4.1.10. Требования по сохранности информации при авариях
	4.1.11. Требования к защите от влияния внешних воздействий
	4. 1.12. Требования к патентной чистоте
	4.1.13. Требования по стандартизации и унификации
4.4. Требования к составу и параметрам технических средств	4.1.8. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы
4.5. Требования к информационной и программной совместимости
4.6. Требования к маркировке и упаковке
4.7. Требования к транспортированию и хранению	4.1.7. Требования к транспортабельности для подвижных систем
4.8. Специальные требования	4. 1.14. Дополнительные требования
	4.3. Требования к видам обеспечения
5. Требования к программной документации	8. Требования к документированию
6. Технико-экономические показатели
7. Стадии и этапы разработки	5. Состав и содержание работ по созданию системы
8. Порядок контроля и приёмки	6. Порядок контроля и приёмки системы
	7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
	9.Источники разработки

Ниже рассмотрим каждый ГОСТ и пункты ГОСТ по отдельности.

ГОСТ 19 для Технического задания

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

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

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

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

В разделе 2 «Основания для разработки» должны быть указаны:

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

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

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

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

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

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

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

В подразделе 4.4 «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их основных технических характеристик.

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

При необходимости должна обеспечиваться защита информации и программ.

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

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

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

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

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

В разделе 8 «Порядок контроля и приёмки» должны быть указаны виды испытаний и общие требования к приёмке работы.

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

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

ГОСТ 34 для Технического задания

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

1. общие сведения;
2. назначение и цели создания (развития) системы;
3. характеристика объектов автоматизации;
4. требования к системе;
5. состав и содержание работ по созданию системы;
6. порядок контроля и приёмки системы;
7. требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
8. требования к документированию;
9. источники разработки.

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

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

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

В разделе 1 «Общие сведения» указывают:

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

Раздел 2 «Назначение и цели создания (развития) системы» состоит из подразделов:

• назначение системы;
• цели создания системы.

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

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

В подразделе 2.2 «Цели создания системы» приводят наименования и требуемые значения технических, технологических, производственно-экономических или других показателей объекта автоматизации, которые должны быть достигнуты в результате создания автоматизированной системы (АС), и указывают критерии оценки достижения целей создания системы.

В разделе 3 «Характеристики объекта автоматизации» приводят:

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

Раздел 4 «Требования к системе» состоит из следующих подразделов:

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

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

В подразделе 4.1 «Требования к системе в целом» указывают:

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

В требованиях к структуре и функционированию системы приводят (пункт ТЗ 4.1.1):

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

В требованиях к численности и квалификации персонала на АС приводят (пункт ТЗ 4.1.2):

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

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

Для АСУ указывают:

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

В требования к надёжности включают (пункт ТЗ 4.1.4):

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

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

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

Для подвижных АС в требования к транспортабельности (пункт ТЗ 4.1.7) включают конструктивные требования, обеспечивающие транспортабельность технических средств системы, а также требования к транспортным средствам.

В требования к эксплуатации, техническому обслуживанию, ремонту и хранению включают (пункт ТЗ 4.1.8):

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

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

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

В требованиях к средствам защиты от внешних воздействий приводят (пункт ТЗ 4.1.11):

• требования к радиоэлектронной защите средств АС;
• требования по стойкости, устойчивости и прочности к внешним воздействиям (среде применения).

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

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

В дополнительные требования включают (пункт ТЗ 4.1.14):

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

В подразделе 4.2 «Требование к функциям (задачам)», выполняемым системой, приводят:

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

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

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

Для информационного обеспечения системы приводят требования (пункт ТЗ 4.3.2):

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

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

Для программного обеспечения (пункт ТЗ 4.3.4) системы приводят перечень покупных программных средств, а также требования:

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

Для технического обеспечения (пункт ТЗ 4.3.5) системы приводят требования:

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

В требованиях к метрологическому обеспечению (пункт ТЗ 4.3.6) приводят:

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

Для организационного обеспечения приводят требования (пункт ТЗ 4.3.7):

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

Для методического обеспечения САПР (пункт ТЗ 4.3.8) приводят требования к составу нормативно-технической документации системы (перечень применяемых при её функционировании стандартов, нормативов, методик и т. п.).

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

В данном разделе также приводят:

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

В разделе 6 «Порядок контроля и приёмки системы» указывают:

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

В разделе 7 «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие» необходимо привести перечень основных мероприятий и их исполнителей, которые следует выполнить при подготовке объекта автоматизации к вводу АС в действие.

В перечень основных мероприятий включают:

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

Например, для АСУ приводят:

• изменения применяемых методов управления;
• создание условий для работы компонентов АСУ, при которых гарантируется соответствие системы требованиям, содержащимся в ТЗ.

В разделе 8 «Требования к документированию» приводят:

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

В разделе 9 «Источники разработки» должны быть перечислены документы и информационные материалы (технико-экономическое обоснование, отчёты о законченных научно-исследовательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др.), на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы.

В состав ТЗ на АС при наличии утверждённых методик включают приложения, содержащие:

• расчёт ожидаемой эффективности системы;
• оценку научно-технического уровня системы.

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

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

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

Надеюсь, с помощью этой статьи написать Техническое задание вам будет немножко легче!

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

Вы получили тот результат, на который рассчитывали? Если Ваш ответ «да», тогда поздравляю — задачи были поставлены правильно и подрядчик прекрасно Вас понял.

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

Для начала предлагаю разобраться, что такое техническое задание (ТЗ).

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

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

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

Давайте разберёмся, в каких сферах много работников на фрилансе:

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

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

А тут без техзадания не обойтись.

ГЛАВА 1:

ТОП-5 причин отказа от составления ТЗ заказчиком

Вы всё ещё привыкли работать «устно»: не расписывать ТЗ, а всё решать в 5-минутном телефонном разговоре?

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

Эта глава именно для Вас.

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

Давайте разберём ТОП-5 причин отказа от составления ТЗ заказчиком:

1. «Я даже не знаю, что это такое и как составлять это Ваше ТЗ»

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

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

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

1. «Зачем усложнять себе жизнь? Быстренько всё обсудим по телефону и будем дальше работать»

Это путь в никуда. Во-первых, у Вас не будет файла со всеми требованиями, которые Вы предъявляете к исполнителю.

Во-вторых, память — очень коварная штука. Вы (или, что ещё хуже, исполнитель) можете попросту забыть всё то, о чём просили в ходе разговора.

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

Мир постепенно переходит на удалённую работу.

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

В отличие от ТЗ, которое составляется за полчаса и не требует разъяснений.

1. «У меня нет времени на всю эту бюрократию»

По факту техзадание нужно только Вам. Ведь исполнителя не волнует, будет ли продающей его работа, повысит ли она узнаваемость ВАШЕГО бренда.

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

1. «Мы работали раньше без всяких ТЗ и всё было нормально»

Здесь только 2 варианта: или Вам несказанно повезло, или Ваши взгляды на 100% совпадают с видением исполнителя.

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

1. «Сначала надо знать цену работы, а не скидывать ТЗ всем подряд»

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

Например, Вы ищете человека, который напишет текст, и запрашиваете цену.

Тема, объём, требования к уникальности, смысловой нагрузке — всё это влияет на стоимость текста.

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

Надеюсь, я смогла Вас убедить в необходимости составления техзадания.

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

ГЛАВА 2:

Как правильно составить техзадание

От правильности составления ТЗ зависит очень многое.

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

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

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

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

Какое оно, хорошее техзадание?

1. Чётко сформулированное

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

Если Вы хотите заказать логотип, то нужно прописывать всё: форму, цвет, текст и цель (продавать, привлекать внимание и т.д.).

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

2. Детально расписанное

Не бойтесь переборщить с деталями — пишите обо всём, чего Вы хотите. В данном случае лучше «пере», чем «недо».

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

3. Содержащее примеры

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

4. Дающее пространство для творчества

Каждый человек имеет своё уникальное видение и, кто знает, возможно, идеи Вашего подрядчика придутся и Вам по душе?

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

5. Наполненное иллюстрациями, инфографиками и скриншотами

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

В ТЗ это тоже работает. Постарайтесь сократить «воду» и создать максимально наглядное и понятное задание.

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

1. Вступление

Дайте общую информацию о своём проекте и предстоящей работе.

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

2. Общая цель задания

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

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

3. Требования к выполнению работы

Детально опишите, как Вы хотите, чтобы задача была выполнена.

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

Например, в ТЗ для дизайнера:

• Размер логотипа 3,5 см х 3,5 см.
• Цвета красный и жёлтый.
• Текст на логотипе «BeautyDom», шрифт Arial размер 16.

Это основные пункты, которые сделают Ваше ТЗ намного более понятным для исполнителя.

Также не стоит забывать об обратной связи. Старайтесь отвечать на все вопросы о выполнении работы.

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

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

ГЛАВА 3:

Разбираем техзадания для специалистов разных профилей

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

Предлагаю наглядно рассмотреть хорошие и плохие техзадания.

1. Техническое задание для копирайтера

Неправильное ТЗ	Правильное ТЗ
Написать текст про оформление Инстаграма. Чтоб было интересно и легко читалось.	Написать текст о разных возможностях вести визуально красивый Инстаграм. В качестве примера контента берём статью: https://seoquick.ru/oformlenie-instagram/. Длина текста не менее 5 тысяч символов. Уникальность 100%. Ссылки на 10 инстаграм-профилей с разным стилем оформления страниц. Текст должен содержать 3 главы и выводы. Минимум по 2 иллюстрации к каждой главе.

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

В таком формате, как хочешь, нет никаких требований к структуре текста.

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

1. Техническое задание для дизайнера

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

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

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

Неправильное ТЗ

Правильное ТЗ

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

Создать сайт для мастера наращивания ногтей Ольги Ноготок. Разработка с нуля, предоставляем логотип (в прикреплённом файле). На сайте должны быть страницы «О мастере», «Где мы находимся», «Примеры работ» и «Цены». Также всплывающее окно с номером телефона и активная кнопка «Задать вопрос». Создать 2 версии сайта: на русском и английском языках. Дизайн сайта простой и понятный: без активных цветов, отдать предпочтение бежевому и красному. Основная цель — создание интерактивной визитки, где можно посмотреть цены, примеры работ и узнать, куда звонить и где работает мастер. Сайт, который нравится и который можно использовать в качестве примера: https://beautynails.kiev.ua/. По программной части: дополнительных встроенных программ не требуется.

Этот пример самый объёмный, потому что создание сайта с нуля — задача нелёгкая.

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

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

Пример плохого дизайна сайта демонстрирует «Худший сайт в мире”:

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

А вы все еще думаете, что сайт можно создать без четко прописанного ТЗ?

ГЛАВА 4:

Чем грозит неправильно составленное ТЗ

О преимуществах технических заданий для исполнителей мы уже поговорили.

Выяснили, почему отказ от составления ТЗ — это отговорка.

Чем же грозит неправильно составленное ТЗ, читайте далее.

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

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

1. Финансовые убытки

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

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

1. Репутационные риски

Этот пункт наглядно демонстрирует такая ситуация: Вы заказываете сайт для своей адвокатской фирмы и прописываете «сырое» ТЗ.

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

Когда потенциальные клиенты видят Ваш сайт, то о компании складывается не самое лучшее мнение — «тыканье» в текстах нравится далеко не всем.

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

Но получилось то, что получилось, а клиентов Вы в итоге потеряли.

1. Временные потери

Внесение правок занимает время, а время — это репутация и деньги.

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

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

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

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

Выводы

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

Если Вы сотрудничаете со специалистами на аутсорсе, то рано или поздно перед Вами встанет задача прописать техзадание.

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

Основными преимуществами ТЗ являются:

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

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

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

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

Какие цели достигаются

На основании сведений, которые содержаться в данном документе, становится возможным:

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

Как составить форму

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

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

• Основную информацию о планируемой закупке;
• Общие сведения об объекте закупки;
• Требования к исполнителям;
• Какие условия должны соблюдаться при исполнении договора;
• Сведения об имеющихся приложениях.

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

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

На выполнение строительно-монтажных работ

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

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

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

На выполнение электромонтажных работ

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

• Место выполнения работ;
• Сроки выполнения;
• Дается краткое описание требуемых работ;
• Требования к исполнителю.

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

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

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

На выполнение работ по 44-фз

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

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

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

Пример технического задания на осуществление работ по 44-ФЗскачать

Этим вопросом часто задаются представители заказчика, когда возникает необходимость автоматизировать какой-либо бизнес-процесс. Почему-то сегодня со стороны большинства заказчиков нет полного понимания того, насколько это важный этап, а не простая бюрократическая волокита. И насколько скрупулезно обе стороны подойдут к этому этапу работ, настолько будет более точным, правильным, ожидаемым и быстрым результат проекта.
Что ж попробуем разобраться. Давайте для начала все-таки определимся, что же такое техническое задание?
Техническое задание (ТЗ) — исходный документ на проектирование технического объекта (изделия). ТЗ устанавливает основное назначение разрабатываемого объекта, его технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования.
Можно сказать, что ТЗ — документ, в котором описывается, ЧТО нужно заказчику, в отличие от последующей проектной документации, в которой акцент переносится на ответ на вопрос, КАК этого достичь.
(Материал из Википедии).
Данное определение, на мой взгляд, полностью раскрывает суть термина. Итак, основное назначение ТЗ полностью раскрыть и описать все требования, предъявляемые к желаемому результату заказчиком. От того, как сформулированы эти требования, зависит успех или неуспех проекта. И на данном этапе заинтересованность в успехе должны проявлять максимально обе стороны. Заказчик – чтобы потратить меньше средств на переделку неудачного проекта, исполнитель – чтобы меньшими усилиями успешно завершить проект и получить прибыль. И как раз на этом этапе возникает резонный вопрос: кто должен писать данный документ?
С одной стороны, казалось бы, это должен делать заказчик, т.к. он и только он полностью знает, что же он хочет видеть в результате. Но сможет ли данная сторона, не обладая техническими знаниями в области разработки программного обеспечения, корректно изложить все свои требования? Провести их анализ на предмет того, что каждое требование должно быть понятным, конкретным, тестируемым, как того требуют правила составления ТЗ. «Хочу кнопку красного цвета, дающую точные данные по продажам за месяц!». Наверное, ничего вразумительного на основе данного ТЗ исполнитель не реализует.
Тогда ТЗ должен писать сам исполнитель? Тоже не идеальный вариант. Исполнитель, получив от заказчика изложение задачи, может интерпретировать её немного в ином русле, как понимает задачу сам. И сухой технический язык, на котором будут изложены все понятые исполнителем требования, не даст ответа заказчику – то ли он имел в виду, описывая желаемый результат. Особенно комично выглядит ситуация, когда на стол руководителя заказчика попадает документ, изобилующий технической терминологией, специфическими словами, зачастую на английском языке, который он должен подписать и, соответственно, подтвердить, что всё написанное это то, что они и просили!
Поэтому наиболее оптимальный вариант – это работа в тандеме. Именно при полном погружении исполнителя в предметную область заказчика, разговор на одном языке при построении списка требований, когда сходятся воедино язык потребителя-неспециалиста и язык разработчика, рождается документ, на основании которого будет создан продукт, максимально приближенный к исходной поставленной цели. Такой синтез даст обеим сторонам полное понимание описываемого процесса. Не будет сомнений в том, что какая-то часть технического документа осталась «белым пятном» и во что эта часть превратится в результате.
Да, написание ТЗ сложная задача, но лучше временные инвестиции вложить в данный этап, нежели найти брешь и выяснить, что нужно переделывать фундамент, когда пришло время положить крышу.
И главное, перед тем, как создавать документ, заказчику нужно понять, что именно он хочет видеть в результате, а исполнителю – отказаться от реализации невыполнимых требований.
Успешных вам проектов!