Как оформить техническое задание на выполнение работ

Содержание
  1. Особенности составления технического задания на выполнение подрядных работ. Образец документа
  2. Правила оформления техзадания к договору подряда
  3. Основание для производственных действий
  4. Цель и исходные данные
  5. Требования подрядчика
  6. Технико-экономическое
  7. Этапы проведения
  8. Приложения
  9. Стандарты и шаблоны для ТЗ на разработку ПО
  10. Гост 34
  11. Гост 19
  12. IEEE STD 830-1998
  13. ISO/IEC/ IEEE 29148-2011
  14. RUP
  15. SWEBOK, BABOK и пр
  16. А как же agile?
  17. Заключение
  18. Как подготовить техническое задание на выполнение работ
  19. Какие цели достигаются
  20. Как составить форму
  21. На выполнение строительно-монтажных работ
  22. На выполнение электромонтажных работ
  23. На выполнение работ по 44-фз
  24. Как составить ТЗ: подробная инструкция по созданию технического задания
  25. Для чего нужно техническое задание?
  26. Как составить техническое задание
  27. ГОСТ
  28. ISO/IEC/IEEE 29148
  29. Порядок документирования требований
  30. Бриф
  31. Технико-коммерческое предложение
  32. Технические требования
  33. Техническое задание
  34. Технический проект
  35. Эксплуатация
  36. Ведите историю правок
  37. Составляйте список терминов и сокращений
  38. Прописывайте каждую деталь
  39. 5 секретов создания технического задания (примеры ТЗ)
  40. 1. Чётко сформулированное
  41. 2. Детально расписанное
  42. 3. Содержащее примеры
  43. 4. Дающее пространство для творчества
  44. 5. Наполненное иллюстрациями, инфографиками и скриншотами
  45. 1. Вступление
  46. 2. Общая цель задания
  47. 3. Требования к выполнению работы
  48. Выводы

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

Как оформить техническое задание на выполнение работ

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

Показать содержание

Правила оформления техзадания к договору подряда

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

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

Основание для производственных действий

Основанием для производства работ являются:

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

Цель и исходные данные

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

Для реализации потребностей по договору подряда обе стороны согласуют исходные данные:

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

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

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

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

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

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

Технико-экономическое

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

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

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

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

Этапы проведения

Сроки начала и завершения этапов оговариваются при составлении техзадания. Их согласуют перед подписанием договора.

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

Приложения

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

В качестве приложений могут быть:

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

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

, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник: https://pravovoi.center/zpp/uslugi/raboty/tehnicheskoe-zadanie.html

Стандарты и шаблоны для ТЗ на разработку ПО

Как оформить техническое задание на выполнение работ

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

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

Придется сделать такую статейку самому… И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification): • Гост 34 • Гост 19 • IEEE STD 830-1998 • ISO/IEC/ IEEE 29148-2011 • RUP • SWEBOK, BABOK и пр.

Гост 34

Гост 34.602-89 Техническое задание на создание автоматизированной системы регламентирует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы.

Согласно Гост 34 техническое задание должно включать следующие разделы: 1. Общие сведения 2. Назначение и цели создания (развития) системы 3. Характеристика объектов автоматизации 4. Требования к системе 5. Состав и содержание работ по созданию системы 6.

Порядок контроля и приемки системы 7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие 8. Требования к документированию 9.

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

Гост 19

“Гост 19.

ххх Единая система программной документации (ЕСПД)” — это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ (или ПО) и программной документации. Т.е. этот стандарт относится к разработке именно ПО.

Согласно Гост 19.201-78 Техническое задание, требования и оформлению техническое задание должно включать следующие разделы:

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

IEEE STD 830-1998

Достаточно хорошее определение стандарта 830-1998 — IEEE Recommended Practice for Software Requirements Specifications дано в самом его описании: Описывается содержание и качественные характеристики правильно составленной спецификации требований к программному обеспечению (SRS) и приводится несколько шаблонов SRS.

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

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

2. Общее описание

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

3.

Детальные требования (могут быть организованы по разному, н-р, так)

  • 1. Требования к внешним интерфейсам
    • 1. Интерфейсы пользователя
    • 2. Интерфейсы аппаратного обеспечения
    • 3. Интерфейсы программного обеспечения
    • 4. Интерфейсы взаимодействия
  • 2. Функциональные требования
  • 3.

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

  • 4. Проектные ограничения (и ссылки на стандарты)
  • 5. Нефункциональные требования (надежность, доступность, безопасность и пр.)
  • 6. Другие требования

4. Приложения 5.

Алфавитный указатель

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

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

ISO/IEC/ IEEE 29148-2011

Стандарт IEEE 29148-2011 обеспечивает единую трактовку процессов и продуктов, используемых при разработке требований на протяжении всего жизненного цикла систем и программного обеспечения. Он приходит на смену стандартов IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998.

Данный стандарт содержит два шаблона спецификации требований: • System requirements specification (SyRS) • Software requirements specification (SRS) System Requirements Specification (SyRS) определяет технические требования для выбранной системы и удобства взаимодействия предполагаемой системы и человека.

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

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

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

2. Ссылки 3. Системные требования

  • 1. Функциональные требования
  • 2. Требования к юзабилити
  • 3. Требования к производительности
  • 4. Интерфейс (взаимодействие) системы
  • 5. Операции системы
  • 6. Состояния системы
  • 7. Физические характеристики
  • 8. Условия окружения
  • 9. Требования к безопасности
  • 10. Управление информацией
  • 11. Политики и правила
  • 12. Требования к обслуживанию системы на протяжении ее жизненного цикла
  • 13. Требования к упаковке, погрузке-разгрузки, доставке и транспортировке

4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3) 5. Приложения

  • 1. Предположения и зависимости
  • 2. Аббревиатуры и сокращений

SRS это спецификация требований для определенного программного изделия, программы или набора программ (продукт), которые выполняют определенные функции в конкретном окружении. Из определения следует, что это аналог ТЗ, описанного в Гост 19, а по структуре очень напоминает SRS из стандарта IEEE 830. SRS может содержать следующие разделы: 1.

Введение

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

2. Ссылки 3. Детальные требования

  • 1. Требования к внешним интерфейсам
  • 2. Функции продукта
  • 3. Требования к юзабилити
  • 4. Требования к производительности
  • 5. Требования к логической структуре БД
  • 6. Ограничения проектирования
  • 7. Системные свойства ПО
  • 8. Дополнительные требования

4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3) 5. Приложения

  • 1. Предположения и зависимости
  • 2. Аббревиатуры и сокращений

Данный стандарт достаточно сложно найти в открытом виде в Интернете, но постараться можно, и опять же только на англ.

RUP

Структура SRS в RUP(Rational Unified Process) представляет собой документ, в котором необходимо описать артефакты, полученные в процессе специфицирования требований.

Шаблон SRS в RUP адаптирован из стандарта IEEE STD 830 и содержит два варианта:

• Традиционный шаблон SRS со структурированными функциональными требованиями по функциям Системы, максимально похож на 830 стандарт. • Упрощенный шаблон SRS со структурированными функциональными требованиями в виде вариантов использования (use cases): 1. Введение.

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

2. Обзор системы

  • 1. Обзор вариантов использований.
  • 2. Предположения и зависимости.

3. Детальные требований

  • 1. Описание вариантов использования.
  • 2. Дополнительные требования.
  • 3. Другие функциональные требования.
  • 4. Нефункциональные требования.

4. Вспомогательная информация.

Естественно, что в Интернете можно найти шаблон и примеры SRS от RUP.

SWEBOK, BABOK и пр

SWEBOK, BABOK, а также множество других методологий разработки ПО и сводов знаний при упоминании SRS ссылаются на вышеупомянутые зарубежные стандарты.

Также стоит сказать, что для описания требований к АС и ПО используются и другие виды документов, кот каждый называет по разному: FRD (Functional Requirements Document), RD (Requirements Document), ПЗ (Постановка задачи или Пояснительная записка) и пр.

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

А как же agile?

Я скажу одной фразой из Манифеста Agile: “Working software over comprehensive documentation”. Поэтому в Agile документации отводится совсем мало места. Мое же убеждение, что разработать АС без ТЗ можно (используя техники/рекомендации Agile), но вот в дальнейшем сопровождать — невозможно. Поэтому сразу задумайтесь, как вы будете писать ТЗ и другую документацию, при разработке ПО по Agile.

Заключение

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

Но главное, чтобы ТЗ не превращалось в ХЗ, а, именно, содержание (наполнение) в ТЗ — самое главное! Но это уже совсем другая история… Если есть интерес, то можно пройти он-лайн курс Разработка и управление требованиями к ПО.

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

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

  • Анализ и проектирование систем

Источник: https://habr.com/ru/post/328822/

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

Как оформить техническое задание на выполнение работ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник: http://MirBlankov.ru/tz-na-vypolnenie-rabot/

Как составить ТЗ: подробная инструкция по созданию технического задания

Как оформить техническое задание на выполнение работ

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

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

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

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

Наши продукты помогают вашему бизнесу оптимизировать расходы на маркетинг

Узнать подробнее

Для чего нужно техническое задание?

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

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

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

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

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

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

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

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

Во многих вакансиях на позицию системного аналитика или технического писателя можно встретить требование: знание ГОСТ 19 и ГОСТ 34. Что это такое?

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

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

ГОСТ

Не пугайтесь, но ГОСТ 19 введён в 1980 году. Учитывая, что основа и парадигма программного обеспечения на протяжении долгого времени примерно та же, он пока не утратил своей актуальности. Это можно сравнить со строительством зданий. Конечно, меняются материалы и конструкции, но общие понятия — фундамент, стены, перекрытия — сохраняются.

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

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

  • Введение;
  • Основания для разработки;
  • Назначение разработки;
  • Требования к программе или программному изделию;
  • Требования к программной документации;
  • Технико-экономические показатели;
  • Стадии и этапы разработки;
  • Порядок контроля и приемки;
  • Приложения.

Более новый стандарт — ГОСТ 34, но и здесь присутствует нюанс. Новее он только на 10 лет. То есть, введён с 1 января 1990 года.

Формулировка назначения выглядит так: «Распространяется на автоматизированные системы (АС) для автоматизации различных видов деятельности (управление, проектирование, исследование и т. п.), включая их сочетания…».

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

  • Общие сведения;
  • Назначение и цели создания (развития) системы;
  • Характеристика объектов автоматизации;
  • Требования к системе;
  • Состав и содержание работ по созданию системы;
  • Порядок контроля и приемки системы;
  • Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
  • Требования к документированию;
  • Источники разработки.

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

ISO/IEC/IEEE 29148

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

Последняя редакция — ISO/IEC/IEEE 29148:2018, но, к сожалению, она отсутствует в открытом доступе, поэтому возьмём за основу предыдущую, от 2011 года.

По аналогии с ГОСТами, стандарт содержит два раздела. Один из них, SyRS — System Requirements Specification — определяет общие требования к построению систем, их принципам и характеру взаимодействия пользователя с ними. По похожей схеме составлен ГОСТ 34.

SRS — Software Requirements Specifitaion — по аналогии с ГОСТ 19, содержит требования к конечному программному продукту.

Общая схема строится следующим образом:

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

Порядок документирования требований

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

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

Бриф

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

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

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

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

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

50 минут в подарок новым клиентам

  • Повысьте конверсию сайта на 30%.
  • Экономьте на тарифах: от 5 рублей в минуту.
  • Настраивайте под ваш сайт. Адаптируйте под все устройства. Тестируйте разные виджеты.
  • Используйте гибкие настройки показа.
  • Стройте отчеты по звонкам: от показа виджета до ключевого слова.

Узнать подробнее

Технико-коммерческое предложение

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

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

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

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

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

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

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

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

Технический проект

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

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

Эксплуатация

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

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

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

Ведите историю правок

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

Составляйте список терминов и сокращений

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

Прописывайте каждую деталь

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

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

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

Не оставляйте белых пятен. При наведении на рисунок, он скрывается? Хорошо, но уточните — он уезжает влево? Становится прозрачным? С какой скоростью? Как он появляется опять? Малейшая деталь без чёткой логики ставит разработчиков и весь процесс в тупик.

Узнать подробнее

Источник: https://blog.calltouch.ru/kak-sostavit-tz-podrobnaya-instruktsiya-po-sozdaniyu-tehnicheskogo-zadaniya/

5 секретов создания технического задания (примеры ТЗ)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. Техническое задание для дизайнера
Неправильное ТЗПравильное ТЗ
Создать перекидной календарь для компании «Агро-Мир» на 2021 год.Создать перекидной календарь формата А2 (предпочтительно горизонтальный) для компании «Агро-Мир» на 2021 год. Календарь выполнить в корпоративных цветах: салатовый, голубой и белый (в палитре CMYK — С(50%); М(0%); Y (100%); K (0%), C (70%); M ( 0%); Y (25%); и С(0%); М(0%); Y (0%); K (0%) соответственно). На изображениях месяца должны быть представлены трактора из каталога компании (agromir.com/katalog-traktora-2020). Дедлайн — 25 июня 2020. Форма презентации — полноформатная печать.

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

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

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

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

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

Сайт, который нравится и который можно использовать в качестве примера: https://beautynails.kiev.ua/.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

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

Источник: https://seoquick.ru/preparing-a-technical-task/

Финансист тут
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: