Шаблон технического задания – Техническое задание на создание автоматизированной системы ГОСТ 34.602-89. Пример технического задания. Пример техзадание. Проектирование хранилища данных. Проектная документация

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

Введение

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

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или 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).

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

10 правил и немного занудства / RegionSoft Developer Studio corporate blog / Habr

Если пройтись по зарубежным сайтам с запросом «product requirements document», то можно найти креативные и убедительные статьи про то, что техническое задание (ТЗ, PRD) умерло. Отчасти с этим нужно согласиться — при разработке продукта с нуля прототипирование выглядит гораздо интереснее и эффективнее, чем тома записей заказчика, порой ну очень непрофессиональные. Однако, если речь идёт о доработке базовой системы, то дело принимает совершенно другой оборот. Мы сталкиваемся и с доработкой, и с заказной разработкой, поэтому на ТЗ собаку съели, если повар нам не врёт. В общем, сегодня — о тех самых классических технических заданиях, которые пишутся на доработку купленного и установленного программного обеспечения. Короче, о наболевшем.

Грани взаимодействия

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

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

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

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

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

Сбор и анализ требований

Это очень важный внутрикорпоративный процесс, в ходе которого выясняется, чего хотят от программы (здесь и далее возьмём CRM, но методы работают и с другими типами софта) потенциальные пользователи. Если вы обратитесь к крупному вендору типа SAP или системному интегратору, то с высокой долей вероятности вам предложат воспользоваться услугами бизнес-консультанта (он же персональный менеджер, он же аккаунт-менеджер, он же «теперь ваш представитель в нашей компании»). На самом деле, в большинстве случаев это обычный вышколенный продажник, у которого две задачи: накрутить стоимость проекта и не дать вам сорваться с крючка.
Он находится здесь уже целый час и даже не притронулся к белой маркерной доске. Он не настоящий системный аналитик

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

Есть очень простая схема сбора требований.

1. Создайте рабочую группу из руководителей и опытных специалистов подразделений, которые будут пользоваться CRM. Расскажите о решении, которое предполагается выбрать, предоставьте доступ к демо-версии.
2. Члены рабочей группы должны передать информацию сотрудникам и запросить у них пожелания к новой программе в абсолютно свободной форме. Если кто-то из сотрудников никогда не сталкивался с подобным софтом и не готов говорить в аспекте будущего использования, нужно попросить его описать свои периодические задачи, это универсальный подход.
3. Затем каждое подразделение устанавливает, чего нет в CRM или чему она не соответствует, и агрегирует информацию.
4. Рабочая группа анализирует собранные требования, проверяет и исключает пересечения. Например, нередко отдел продаж и отдел маркетинга заказывают один и тот же отчёт, но в требованиях могут по-разному называться поля и сущности, хотя данные за ними стоят одинаковые. Соответственно, нужно придти к единой форме.
5. Рабочая группа формирует список требований и расставляет приоритеты. На этом этапе можно подключить вендора, поскольку он отвечает за ресурсы. Например, можно попросить создать пользовательский отчёт для RegionSoft CRM, а можно заказать интеграцию с сайтом. Это совершенно разные по срокам задачи, здесь очень важен приоритет.
   

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

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

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

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

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

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

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

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

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

Уровень технологии — последний в списке, но по важности и сложности опережающий остальные. Это могут быть требования клиента, связанные с платформой, операционной системой или устройствами. Например, запрос сборки под MacOS. Очень здорово, если такие требования постепенно перерастут в релизы, но иметь их фиксы обязательно. Именно из запросов клиентов на этом уровне мы сделали сборку RegionSoft CRM под MacOS и добавили удалённый доступ по технологии TRM как временное решение редкого, но существующего запроса мобильной версии.

Анатомия технического задания проста, во всяком случае в виде скелета. Обязательные части технического задания помогают заказчику сосредоточиться на проблеме и сформулировать задачу правильно, а исполнителю — понять, что же от него хотят. Кстати, о понимании. Конечно, в начале поста мы немного слукавили, отрицая бизнес-консультантов как класс. Дело вот в чём: каждый вендор работает на рынке по несколько лет (мы сейчас не о CRM-однодневках), а то и десятков лет, а значит имеет набор кейсов практически по каждой отрасли. Соответственно, и инженеры, и программисты, и продажники знакомы со спецификой внедрения в каждом типе компании. Но опять-таки, важно ориентироваться именно на свой бизнес.

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

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

Зачем? Обоснование необходимости доработки и его место в бизнес-процессе. Этот пункт больше нужен самому заказчику, но и вендору нелишне знать, какие ещё процессы будут затронуты. Иногда это помогает найти альтернативное решение.

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

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

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

1. Описание требования каждого механизма и каждой функциональности
   
2. Описание реализации данной функциональности
   
3. Стоимость работ по каждому из этапов в отдельности
   
4. Общая стоимость работ по данному техническому заданию
   
5. Сроки исполнения работ с разбивкой по этапам и указанием очерёдности
   
6. Описание условий установки и тестирования доработки
   
7. Оговорки об исчерпывающем характере технического задания и иные условия
   

10 правил, написанных слезами разработчика

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

Техническое задание не должно быть жадным. Нередко бизнес переоценивает свои возможности или желает получить «всё и сразу». Такой подход не оправдан ни с точки зрения денег, ни с точки зрения бизнеса. Вендор, как правило, существует не пару недель (в случае RegionSoft — 15 лет), и к нему можно обратиться и через некоторое время, когда вы уже реально поймёте, чего в CRM не хватает.

Яркий пример избыточности буквально из вчерашнего дня: клиент купил ERP одной известной российской компании, думая, что раз работает бухгалтерский учёт, то и ERP этого вендора будет хороша. ERP оказалась не то чтобы не очень сама по себе, но очень не подходящей бизнесу. А вот RegionSoft CRM со складским учётом и производством подходит. Есть решение: забыть про ERP, поплакать, интегрировать учёт 1С с новой CRM и радоваться удобной реализации. Но вбуханных денег жалко! И клиент требует интегрировать CRM с ERP. Мы и не такое делали, но зачем такая трата, зачем две относительно схожих системы?

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

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

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

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

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

Да, корпоративный софт выглядит примерно так, и в нём много важных мелочей

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

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

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

1. Клиент пытается продемонстрировать свою техническую грамотность и городит конструкции типа: «имплементировать окно с хинтом в тело календаря с возможностью реакции на колл события…» вместо «в календаре должно всплывать окно, в котором можно отметить задачу как выполненную». Если у вас или вашего внутреннего эксперта нет навыков написания технических текстов, не гуглите — пишите обычными словами, мы их понимаем.
2. ТЗ переполнено грамматическими ошибками. Нужно не только избавиться от расплывчатых описаний и метафор (из реального: «Чтобы компьютер не пищал, будто помирает в судорогах»), лишних слов, слов-паразитов. Проверяйте пунктуацию – зачастую ошибки в ней искажают смысл требования. Задание на проект – это документ и лексика в нём должна быть соответствующая, а грамотность — близкая к 100%.
   

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

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

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

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

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

Заповеди закончились, теперь отповедь

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

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

Наконец он нашёл время закончить ТЗ. Но, увы, вокруг не осталось разработчиков, чтобы его реализовать.

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

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

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

О технических заданиях можно писать бесконечно, это настоящий генератор не только мемов и баек, но и головной боли. Можно рассказать о приоритетах и правилах оформления, о ГОСТе 1989 года, который делает ТЗ бесчеловечным, о стандартах IEEE, которые немного лучше, о прототипах и дополняющих их ТЗ. Но в конце хотелось бы ограничиться одним, самым главным правилом: техническое задание — не норма права, не ГОСТ и не догма, поэтому, если можно улучшить — улучшайте, можно упростить — упрощайте, можно сделать изящно и чтобы всем нравилось — делайте. Уверен, никто после такого не ткнёт носом в ТЗ и не скажет, что там такого не написано. Или почти никто.

---

Весь декабрь мы даём скидки на RegionSoft CRM и весь софт собственной разработки. С 1 по 15 декабря — 15% и крутые условия рассрочки и аренды. У нас не бывает -70% и -90%, потому что мы держим экономически обоснованную цену на лицензии, а не берём её с потолка.

---

Ну а если вам нужна CRM-система (с доработкой или без), то заходите на наш сайт, там много о CRM, её преимуществах и прочем корпоративном софте.

И да, мы всегда ищем партнёров, которые готовы продавать CRM и другие продукты, дорабатывать и продавать CRM, продавать софт и обучать пользователей. Разделение доходов честное и выгодное партнёру. Покажем, расскажем, научим. Пишите на [email protected]

Слайды, слайды. Комиксы взяты с http://www.modernanalyst.com/ и из Pinterest. Если есть лучший перевод — будем рады его внести в пост.

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

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

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

Проблема восприятия информации, вечная. Эффект “сломанного телефона”, частое явление. А что говорить о том, если ты просто не умеешь ставить задачу? Да, такое тоже бывает и с этим нужно как-то работать, но как? Для того чтобы результаты задач, которые вы ставите, соответствовали вашим ожиданиям, пишите техническое задание.

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

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

Конструкторское бюро

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

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

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

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

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

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

Разработка технического задания

Если мы говорим об игре “по-взрослому”, например, техническое задание на разработку мобильного приложения или сайта, то это отдельная работа, за которую платятся немалые деньги. Вы привлекаете человека, как правило, это бывший или действующий технический директор (Chief Technical Officer) и просите его помочь вам.

Наличие бороды необязательно

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

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

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

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

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

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

–

Простите, что прерываю чтение. Присоединяйтесь к моему telegram канал. Свежие анонсы статей, развитие digital продуктов и growth hack, там все. Жду вас! Продолжаем…

–

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

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

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

Далее будут приведены примеры тех.задачний из интернета.

ТЗ на разработку интернет магазина

ТЗ на разработку мобильного приложения

ТЗ на сайт

ТЗ на сервисы/обновления

Если нужно больше образцов, просто погуглите.

Рекомендации и советы

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

Вот так надо

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

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

Например для задачи “Кнопка лайк на сайте”:

1. Описание: необходимо создать кнопку “Лайк” на нашем сайте.
2. Назначение и цели: вовлечение пользователей, выдача/рейтинг материалов по кол-ву лайков.
3. Требования: дизайн такой (пример: ссылка на что-то похожее), функционал (любой пользователь может оценить картинку и поставить лайк, система сайта учитывает кол-во лайков и меняет выдачу материалов), технологии (доступно на desktop и mobile версиях сайта).
4. Описание работ: нарисовать 3 варианта макетов для кнопок (дата готовности: 01.10.17),  разработать систему выдачи материалов по лайкам (дата: 14.10.17), тестирование функции (дата: 16.10.17), релиз (дата: 17.10.17)
5. Приемка работ: пользователь нажимает на кнопку лайк, система засчитывает нажатие, выдача материалов меняется.
6. Приложения: эскизы, наброски, примеры проектов, где работает похожая функция.

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

Ну вот

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

Алексей А.

---

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

---

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

 

Вконтакте

Facebook

Twitter

Google+

Загрузка…

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

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

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

Что было раньше

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

На многих проектах это выливалось в следующие проблемы:

1. Описан внешний вид, но не принцип работы. Простой пример с корзиной интернет-магазина. В ТЗ было написано “Кнопка “Оформить заказ”. Но что должно произойти, когда пользователь нажал на эту кнопку? По каким правилам формируется номер заказа? Какой статус ему присваивается? Куда идет переадресация? А если один из товаров раскупили, пока пользователь оформлял заказ? На эти и многие другие вопросы в ТЗ ответов не было, а ведь это лишь один небольшой элемент. Подобные неописанные моменты приводили к спорам с Заказчиком, сильному выходу из бюджета и прочим неприятным последствиям.
2. Отсутствие переиспользуемых блоков. На многих сайтах есть одинаковые блоки, используемые в разных местах, например, превью товара. Но данный блок в результате описывался в каждой странице. Это очень плохо по нескольким причинам. Во-первых, при необходимости изменения надо вносить сразу в нескольких местах, можно что-то упустить и будет несоответствие. Во-вторых, даже при одинаковых элементах в превью, заказчик может потребовать сделать их по-разному, что влечет за собой дополнительные затраты.
3. ТЗ не коррелирует с задачами для команды. Чем дальше постановка задачи от реальности, тем ниже будет качество на выходе. Это еще одна проблема, которую хотелось решить.
   

Новый подход

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

ТЗ состоит из следующих разделов:

1. Введение
2. Статика
3. Динамика
4. Задачи
5. Административная панель
6. Общие технические требования

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

Введение и подготовка к реализации

• Кратко описываем проект, его цели, ЦА, оставляем ссылки на предпроектную аналитику.
• Описываем процесс инициализации проекта: настройку окружения для разработчиков и подход к разработке концепции дизайна для дизайнеров.
• Принципы адаптивности или разбиения на версии. Последнее время в своей работе мы придерживаемся следующего принципа — “адаптивь все, что адаптивится”. Иначе говоря, в начале работы над ТЗ мы понимаем, какой сложный функционал нам нужен (или может понадобиться в ближайшем будущем) и вместе с дизайнером и front-end разработчиком придумываем способы его заадаптивить. При новом подходе отрицательных результатов еще не было, поэтому отдельные версии описывать не приходилось.

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

Статика

Как мы все знаем, страницы могут содержать либо статическую информацию, либо динамическую, присылаемую с сервера. Подразделы статики — страницы проекта. Каждую страницу мы разбиваем на блоки. Если блок статический, то мы описываем его суть и вид контента. Например, описание одного из блоков страницы “О компании” может выглядеть так. “Основные преимущества компании. 5-6 иконок с описаниями.” Это очень краткое, но достаточное для точной оценки описание блока. При описании статики главная цель — задать четкие рамки. Сделать адаптив иконок не составит труда, а с графиком или таблицей все не так просто и однозначно. Но при этом нам не важно какие именно будут иконки и подписи к ним.

Если же страница содержит блок, который можно “вынести за скобки”, то в месте его интеграции мы пишем “Интегрируется функционал “NAME”, а сам функционал описываем в разделе “Динамика”.

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

Динамика

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

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

Задачи

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

Административная панель

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

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

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

1. SEO-требования к тегам и микроразметке
2. Правила транслитерации
3. Ручное и автоматическое тестирование
4. Поддерживаемые браузеры
5. …

Новые версии

При описании новых версий необходимо вносить изменения в существующие элементы. Мы рассматривали следующие способы описания доработок: в начале каждого из разделов (Статика, Динамика, АП) писать “Доработка функционала “NAME”, либо сделать отдельный раздел “Доработки”, в котором в кучу будут свалены сразу все изменяющиеся задачи. Пока остановились на втором варианте, но это связано скорее удобством на конкретных проектах. В других условиях лучше подойдет первый способ.

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

Пример

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

Статика

Страница “Раздел каталога”

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

Интегрируется следующий функционал:

1. “Хлебные крошки”
2. “Дерево каталога”
3. “Фильтрация. Общие положения”
4. “Фильтрация. Текст”
5. “Фильтрация. Текст и изображение”
6. “Фильтрация. Диапазон”
7. “Сортировка. По умолчанию”
8. “Сортировка. По возрастанию цены“
9. “Сортировка. По убыванию цены”
10. “Превью товара. Плитка”
11. “Пагинация. Постраничная”
12. “Текстовый блок”. Интегрируется в виде блока для SEO-текста перед подвалом сайта

URL: /c/1745-name, где 1745- id текущей категории каталога, а name — транслитерированное название этой категории.

Динамика

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

Функционал “Фильтрация. Общие положения”

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

• выпадающий список закрывается, а фильтр применяется. В текущем разделе остаются только товары, соответствующие текущим активным фильтрам
• название кнопки фильтра приобретает вид: “Название фильтра: K”, где K — количество выбранных значений фильтра, если их 2 или больше, или “Название фильтра: значение”, если было выбрано одно значение.
• цвет кнопки фильтра меняется на вид используемого фильтра
• в значениях других фильтров остаются только варианты, удовлетворяющие текущим активным фильтрам. Если в одном из неактивных фильтров остается одно значение, его кнопка приобретает вид неактивной, а название выводится в формате “Название фильтра: значение”
• у всех активных фильтров после названия добавляется крестик, при клике на который сбрасывается только этот фильтр
• пагинация сбрасывается

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

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

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

Выбранные фильтры добавляются в URL посредством query-параметров.

Функционал “Превью товара. Плитка”

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

1. Цена (целое число в рублях РФ)
2. Название товара
3. Метка “В магазине” или “С витрины”
4. Изображение
5. Размер
6. Кнопка “В корзину” (Интеграция функционала “Добавить в корзину”)
7. Кнопка “В избранное” (Интеграция функционала “Добавить в избранное”)

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

На одной строке должно помещаться 3-4 плитки с превью товара.

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

Административная панель

Одна страница требует большого количества разделов АП, опишу один из них.

Товар

Список всех товаров с фильтрацией. При редактировании/добавлении товара доступны следующие поля:

1. Название (текст)
2. Бренд (радио)
3. Изображения
4. Цена (целое число)
5. Описание (текстовый блок)
6. Тип (магазин/витрина, радио)
7. Состояние. Значение включает в себя Название (текст) и Пояснение (текст).
8. Статус. Возможны варианты:
   
   1. на продаже
   2. на модерации
   3. на доработке
   4. отклонен
   5. продан
   6. не прошел проверку
   7. отменен Продавцом
9. Размер с бирки (необязательное). Текстовое поле без валидации
10. …

Полей более 30 и, дабы не раздувать статью, опустим их.

Выводы

Плюсы нового подхода:

1. Полнота. Данное ТЗ позволяет однозначно описывать требования, что является основным и необходимым параметром любого ТЗ.
2. Понятность. Около половины наших клиентов не имеют на своей стороне технического специалиста и сталкиваются с разработкой впервые. Поэтому очень важно было сделать ТЗ максимально понятным и читаемым. И у нас получилось! Даже технически не подкованные клиенты понимают, как оно устроено, могут спокойно его читать и давать отличную обратную связь.
3. Молекулярность. ТЗ полностью соответствует нашим требованиям к разбиению на отдельные элементы, что значительно упрощает и решает проблемы, описанные выше. Блоки ТЗ напрямую соответствуют задачам, которые выполняются разработчиками, что было встречено на ура. Также ТЗ отлично ложится на дизайн-систему (про нее статья выйдет уже на следующей неделе).
4. Простота оценки и конфигурации сметы. Хорошо описанные и разбитые задачи стало просто и приятно оценивать. Если во время оценки мы понимаем, что требования неполные, то дописываем их. Под каждый проект (этап) делаем гугл таблицу, в которой заказчик может попробовать разные конфигурации проекта и определить наиболее подходящий для себя вариант по цене/функционалу.
5. Взаимодействие с заказчиками поднялось на новый уровень. Внесенные изменения позволяют четко определить границы проекта. Если необходимо внести изменения относительно ТЗ, это оценивается как новая задача, хотя при старом подходе это вызывало много споров.
6. Рентабельность. Т.к. это в первую очередь бизнес, данный показатель наравне с предыдущим является одним из самых важных. Детальная проработка позволила свести количество плохо оцененных задач к минимуму. Ни по одному из проектов, реализуемых по новому подходу, не было превышения бюджета.

Минусы:

1. Внесение доработок. На одном из проектов было необходимо ввести статусы товаров. В итоге получилось огромное количество доработок по 2-3 строчки. Нельзя это назвать явным минусом, т.к. полното требований в приоритете, но и идеальным данных подход назвать нельзя.
2. Сложность восприятия при автоматизации бизнес-процессов. Если взять бизнес-процессы некоторых компаний от момента продажи до получения товара покупателем, не всегда есть возможность (или необходимость на первых этапах) покрыть весь процесс за счет Статики, Динамики и АП, т.к. многие задачи выполняются вручную, обсуждаются с клиентами по телефону и т.д. Это немного усложняет восприятие ТЗ в чистом виде, и требует дополнительного описания процессов.
3. Стоимость и время разработки. Продавать ТЗ, конечно, стало сложнее, ведь далеко не все при первом контакте с разработкой готовы платить за него 10-20% от проекта при том что многие наши конкуренты берут за него 10-20 тыс. Но подобная работа сполна окупается при реализации, снижая риски проекта и улучшая качество.

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

Мы настолько довольны результатом, что решили отказаться от стандартных тасктрекеров в пользу доработки Google Docs для полноценной работы с задачами на основе ТЗ. Если опыт будет удачным, напишем об этом отдельную статью. А пока ждем от вас объективную критику и советы, с надеждой, что кому-то эта статья помогла).

Шаблон технического задания на АС по ГОСТ 34 [technicaldocs.ru]

Требования к структуре технического задания на АС по ГОСТ 34 устанавливаются ГОСТ 34.602-89. В общем случае техническое задание должно состоять из следующих разделов:

1 Общие сведения
1.1 Полное наименование системы и ее условное обозначение
1.2 Шифр темы или шифр (номер) договора
1.3 Наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты
1.4 Перечень документов, на основании которых создается система, кем и когда утверждены эти документы
1.5 Плановые сроки начала и окончания работы по созданию системы
1.6 Сведения об источниках и порядке финансирования работ
1.7 Порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы
2 Назначение и цели создания системы
2.1 Назначение системы
2.2 Цели создания системы
3 Характеристика объектов автоматизации
3.1 Краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию
3.2 Сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды
4 Требования к системе
4.1 Требования к системе в целом
4.1.1 Требования к структуре и функционированию системы
4.1.1.1 Перечень подсистем, их назначение, основные характеристики, требования к числу уровней иерархии и степени централизации системы
4.1.1.2 Требования к способам и средствам связи для информационного обмена между компонентами системы
4.1.1.3 Требования к характеристикам взаимосвязей создаваемой системы со смежными системами, требования к ее совместимости
4.1.1.4 Требования к режимам функционирования системы
4.1.1.5 Требования по диагностированию системы
4.1.1.6 Перспективы развития, модернизации системы
4.1.2 Требования к численности и квалификации персонала системы и режиму его работы
4.1.2.1 Требования к численности персонала (пользователей) АС
4.1.2.2 Требования к квалификации персонала, порядку его подготовки и контроля знаний и навыков
4.1.2.3 Требуемый режим работы персонала АС
4.1.3 Показатели назначения
4.1.3.1 Степень приспособляемости системы к изменению процессов и методов управления к отклонению параметров объекта управления
4.1.3.2 Допустимые пределы модернизации и развития системы
4.1.3.3 Вероятностно-временные характеристики, при которых сохраняется целевое назначение системы
4.1.4 Требования к надежности
4.1.4.1 Состав и количественные значения показателей надежности для системы в целом или ее подсистем
4.1.4.2 Перечень аварийных ситуаций, по которым должно быть регламентированы требования к надежности, и значения соответствующих показателей
4.1.4.3 Требования к надежности технических средств и программного обеспечения
4.1.4.4 Требования к методам оценки и контроля показателей надежности на разных стадиях создания системы в соответствии с действующими нормативно-техническими документами
4.1.5 Требования к безопасности
4.1.6 Требования к эргономике и технической эстетике
4.1.7 Требования к транспортабельности для подвижных АС
4.1.8 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы
4.1.8.1 Условия и регламент (режим) эксплуатации, которые должны обеспечивать использование технических средств (ТС) системы с заданными техническими показателями, в том числе виды и периодичности обслуживания ТС системы или допустимость работы без обслуживания
4.1.8.2 Предварительные требования к допустимым площадям для размещения персонала и ТС системы, к параметрам сетей энергоснабжения
4.1.8.3 Требования по количеству, квалификации обслуживающего персонала и режимам его работы
4.1.8.4 Требования к составу, размещению и условиям хранения комплекта запасных изделий и приборов
4.1.8.5 Требования к регламенту обслуживания
4.1.9 Требования к защите информации от несанкционированного доступа
4.1.10 Требования по сохранности информации при авариях
4.1.11 Требования к средствам защиты от влияния внешних воздействий
4.1.11.1 Требования к радиоэлектронной защите средств АС
4.1.11.2 Требования по стойкости, устойчивости и прочности к внешним воздействия (среде применения)
4.1.12 Требования к патентной чистоте
4.1.13 Требования по стандартизации и унификации
4.1.14 Дополнительные требования
4.1.14.1 Требования к оснащению системы устройствами для обучения персонала (тренажерами, другими устройствами аналогичного назначения) и документацией на них
4.1.14.2 Требования к сервисной аппаратуре, стендам для проверки элементов системы
4.1.14.3 Требования к системе, связанные с особыми условиями эксплуатации
4.1.14.4 Специальные требования по усмотрению разработчика или заказчика системы
4.2 Требования к функциям (задачам), выполняемым системой
4.2.1 Требования к подсистеме. Перечень функций, задач или их комплексов (в том числе обеспечивающих взаимодействие частей системы), подлежащих автоматизации
4.2.2 Временной регламент реализации каждой функции, задачи (или комплекса задач)
4.2.3 Требования к качеству реализации каждой функции (задачи или комплекса задач), к форме представления выходной информации, характеристики необходимой точности и времени выполнения, требования одновременности выполнения группы функций, достоверности выдачи результатов
4.2.4 Перечень и критерии отказов для каждой функции, по которой задаются требования по надежности
4.3 Требования к видам обеспечения
4.3.1 Требования к математическому обеспечению
4.3.2 Требования к информационному обеспечению
4.3.2.1 Требования к составу, структуре и способам организации данных в системе
4.3.2.2 Требования к информационному обмену между компонентами системы
4.3.2.3 Требования к информационной совместимости со смежными системами
4.3.2.4 Требования по использованию общесоюзных и зарегистрированных республиканских, отраслевых классификаторов, унифицированных документов и классификаторов, действующих на данном предприятии
4.3.2.5 Требования по применению систем управления базами данных
4.3.2.6 Требования к структуре процесса сбора, обработки, передачи данных в системе и представлению данных
4.3.2.7 Требования к защите данных от разрушений при авариях и сбоях в электропитании системы
4.3.2.8 Требования к контролю, хранению, обновлению и восстановлению данных
4.3.2.9 Требования к процедуре придания юридической силы документам, продуцируемым техническими средствами АС (в соответствии с ГОСТ 6.10.4)
4.3.3 Требования к лингвистическому обеспечению
4.3.4 Требования к программному обеспечению
4.3.4.1 Требования к независимости программных средств от используемых СВТ и операционной среды
4.3.4.2 Требования к качеству программных средств, а также к способам его обеспечения и контроля
4.3.4.3 Требования по необходимости согласования вновь разрабатываемых программных средств с фондом алгоритмов и программ
4.3.5 Требования к техническому обеспечению
4.3.5.1 Требования к видам технических средств, в том числе к видам комплексов технических средств, программно-технических комплексов и других комплектующих изделий, допустимых к использованию в системе
4.3.5.2 Требования к функциональным, конструктивным и эксплуатационным характеристикам средств технического обеспечения системы
4.3.6 Требования к метрологическому обеспечению
4.3.6.1 Предварительный перечень измерительных каналов
4.3.6.2 Требования к точности измерений параметров и (или) к метрологическим характеристикам измерительных каналов
4.3.6.3 Требования к метрологической совместимости технических средств системы
4.3.6.4 Перечень управляющих и вычислительных каналов системы, для которых необходимо оценивать точностные характеристики
4.3.6.5 Требования к метрологическому обеспечению технических и программных средств, входящих в состав измерительных каналов системы, средств встроенного контроля, метрологической пригодности измерительных каналов и средств измерений, используемых при наладке и испытаниях системы
4.3.6.6 Вид метрологической аттестации (государственная или ведомственная) с указанием порядка ее выполнения и организаций, проводящих аттестацию
4.3.7 Требования к организационному обеспечению
4.3.7.1 Требования к структуре и функциям подразделений, участвующих в функционировании системы или обеспечивающих эксплуатацию
4.3.7.2 Требования к организации функционирования системы и порядку взаимодействия персонала АС и персонала объекта автоматизации
4.3.7.3 Требования к защите от ошибочных действий персонала системы
4.3.8 Требования к методическому обеспечению
4.3.9 Требования к другим видам обеспечения системы
5 Состав и содержание работ по созданию системы
5.1 Перечень документов по ГОСТ 34.201, предъявляемых по окончании соответствующих стадий и этапов работ
5.2 Вид и порядок проведения экспертизы технической документации (стадия, этап, объем проверяемой документации, организация-эксперт)
5.3 Программа работ, направленных на обеспечение требуемого уровня надежности разрабатываемой системы
5.4 Перечень работ по метрологическому обеспечению на всех стадиях создания системы с указанием их сроков выполнения и организации-исполнителей
6 Порядок контроля и приемки системы
6.1 Виды, состав, объем и методы испытаний системы и ее составных частей
6.2 Общие требования к приемке работ по стадиям
6.3 Статус приемочной комиссии
7 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
7.1 Приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ
7.2 Изменения, которые необходимо осуществить в объекте автоматизации
7.3 Создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ
7.4 Создание необходимых для функционирования системы подразделений и служб
7.5 Сроки и порядок комплектования штатов и обучения персонала
8 Требования к документированию
8.1 Согласованный разработчиком и заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201 и НТД отрасли заказчика; перечень документов, выпускаемых на машинных носителях; требования к микрофильмированию документации
8.2 Требования по документированию комплектующих элементов межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД
8.3 При отсутствии государственных стандартов, определяющих требования к документированию элементов системы, дополнительно включают требования к составу и содержанию таких документов
9 Источники разработки

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

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

Примечание

Эти и другие требования к структуре и содержанию технического задания на АС по ГОСТ 34 подробнее см. ГОСТ 34.602-89

Разделы и подразделы ТЗ на АС должны быть размещены в порядке, установленном в разд. 2 ГОСТ 34.602-89.

ТЗ на АС оформляют в соответствии с требованиями ГОСТ 2.105-95 на листах формата А4 по ГОСТ 2.301 без рамки, основной надписи и дополнительных граф к ней.

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

Примечание

Эти и другие требования к оформлению технического задания на АС по ГОСТ 34 подробнее см. ГОСТ 2.105-95

Образец технического задания к тендеру 2020

Автор: Черданцева Татьяна 12 июня 2017

Составление технического задания (ТЗ) — важный этап подготовки к закупке. Разберемся в требованиях 44-ФЗ и приведем пример технического задания для тендера.

Понятие технического задания

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

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

ТЗ — внутренний документ, но оно публикуется вместе со всей документицией о проведении тендера.

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

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

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

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

1. Указать полное наименование объекта с установлением объема закупаемых предметов, услуг.
2. Конкретизировать описание товаров, указав детально и четко функциональные, качественные и эксплуатационные характеристики.
3. Обозначить конечную дату или период времени, к которому ожидается достигнуть поставленный результат закупки или установить график оказания услуг.
4. Установить требования к гарантии, гарантийному обслуживанию и объему предоставления гарантий качества.
5. Зафиксировать иные существенные условия заказа: место доставки, условия поставки, монтажа, наладки, обучения.

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

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

Скачать

Пример технического предложения для тендера

Скачать

Образец формы технического задания по 44-ФЗ в 2020 году

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

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

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

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

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

Чем отличается техзадание от описания объекта заказа

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

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

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

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

Скачать

Требования к техзданию

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

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

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

• ГОСТ Р 7.0.97-2016, включающий требования к оформлению различной документации;
• реестр госзакупок в Единой информационной системе;
• иные источники общедоступных данных.

В техническом задании должны быть прописаны наименование объекта госзаказа, а также основные требования и условия к нему. По ч. 4 ст. 23 44-ФЗ, название предмета заказа приводится на основании действующего каталога товаров, работ, услуг (КТРУ) (утв. ПП РФ № 145 от 06.02.2017).

Изучив искомую позицию в КТРУ, специалист заказчика описывает объект госзаказа в строгом соответствии с конкретной строкой каталога. В случае несовпадения прописанных в КТРУ характеристик и описания заказчика ответственный специалист приводит письменное обоснование, указывая при этом требуемое наименование закупаемого объекта (Правила, закрепленные Постановлением Правительства № 555 от 05.06.2015).

В техническом задании описывается конечный результат закупки в части товаров, работ и услуг, учитывающий все потребности заказчика. Формирование описательной части нормируется статьей 33 44-ФЗ. Эти правила нужно также учесть и при разработке всего техзадания:

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

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

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

1. В первую очередь нужно детерминировать параметры закупки — установить и расшифровать терминологию, которая будет применяться в техническом задании.
2. Составить информационную карту. В этом разделе приводятся общие сведения о заказе — полное или краткое название организации-заказчика, его регистрационные и контактные сведения, организационно-правовая форма, местонахождение, ответственное лицо и его контакты.
3. Внести информацию о самой госзакупке — объект торгов и его обоснование (ст. 33), объем и срок поставки, способ определения поставщика, подрядчика или исполнителя (ч. 1 ст. 24 44-ФЗ), обоснование данного способа. Также нужно указать, является ли данная закупка совместной или нет (ПП РФ № 1088 от 28.11.2013), централизованной, ведет ли заказ уполномоченный орган (ч. 1 ст. 26 44-ФЗ), привлекаются ли экспертные организации или иные специалисты.
4. Прописать все требования к потенциальным поставщикам, участвующим в торгах.
5. Указать особые характеристики, которыми должен обладать исполнитель, — определенные производственные мощности или опыт в исполнении аналогичных контрактов.
6. Отразить специфические условия по заказу, непосредственно связанные с его исполнением, возможные экологические условия (режим работы, производственные требования, особенности, которые могут возникнуть при транспортировке, установке или вводе в эксплуатацию приобретаемой продукции).
7. Отразить основные цели и задачи объявляемой закупки (ст. 13 44-ФЗ).
8. Прописать в задании источник финансирования госзаказа.
9. Определить обязанность поставщика следовать действующему законодательству и нормативно-правовым актам в ходе исполнения госзакупки, отразить нормирование заказа в соответствии с ч. 1 ст. 19 44-ФЗ.
10. Описать порядок поставки (как будет производиться транспортировка, какая будет упаковка и т. д.), сдачи, приемки, установки, необходимость монтажа или демонтажа, ввод в эксплуатацию. Внести требования о гарантии и гарантийном сроке.
11. Подтвердить обязательство о поставке новой продукции (не употреблявшейся ранее) или указать необходимость приобретения иных товаров для нужд заказчика.

Готовый документ может выглядеть так:

Разъяснения по теме

Основные тезисы	Реквизиты документа	Документ
Требование указать в заявке параметры не только самого товара, но и компонентов, которые применяются при его изготовлении (например, химические показатели составных частей, результаты испытаний), считается избыточным.	Письмо от 31.05.2016 № РП/36546/16	Скачать
Отдельные вопросы подготовки технического задания для закупки лекарств по Постановлению Правительства № 1380 от 15.11.2017.	Письмо Минздрава № 418/25-5 от 14.02.2018	Скачать
	Письмо ФАС № АК/12985/18 27.02.2018	Скачать
Объединение в техническом задании лицензируемых и нелицензируемых видов работ может ограничивать число участников закупки.	Письмо ФАС № АЦ/5147/15 от 09.02.2015	Скачать
Требовать указать остаточный срок годности лекарств и медизделий в процентах неправомерно, если это приводит к ограничению конкуренции.	Письмо от № ИА/71717/17 от 18.10.2017	Скачать
Закупать запчасти без работ, для выполнения которых они нужны, нельзя.	Письмо Минфина № 24-02-07/73170 от 07.11.2017	Скачать