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

Содержание:

Разработка технического задания: написание и оформление

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

Мы осуществляем разработку следующих видов технического задания:

ТЗ на АСУ и её составные части
ТЗ на программу
ТЗ на сайт (портал)

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

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

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

Подходы к составлению ТЗ

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

Нами выделены следующие принципы:

Совместная работа всей проектной команды
Максимально подробное описание конечного продукта
Сдача-приёмка конечного продукта.

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

ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению
ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

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

Основные принципы написания технического задания (ТЗ) на проектах 1С

1. Зачем пишут ТЗ

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

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

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

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

4) Заказчику заранее важно увидеть, как будут тратиться его деньги.

Основным техническим документом проекта является ТЗ. ТЗ включает в себя:

Описание целей и задач
Спецификацию требований
Технико-экономическое обоснование работ.

В таблице ниже дано описание того, что дает ТЗ заказчику и разработчику:

Что дает ТЗ Заказчику

Что дает ТЗ Разработчику

Осознать, что именно ему нужно

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

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

Показать заказчику «внешний облик» продукта

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

Оценить трудозатраты и потребности в ресурсах.

Определить бюджет проекта

Ход работ проекта

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

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

Передача результата работ

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

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

Управление изменениями в проекте

Управлять изменениями требований, возникающими в процессе работ, разрабатывая дополнительные ТЗ на изменения в Продукте

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

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

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

2. Что пишут в ТЗ

2.1 Стандарты ТЗ

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

Международные стандарты
Государственные стандарты
Корпоративные стандарты

Кратко опишу стандарты, используемых для написания ТЗ:

Международные стандарты.

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

Государственные стандарты.

Основным стандартом для написания ТЗ по информационным системам является ГОСТ 34.602-89. Для крупных проектов, выполняемых в крупных компаниях, данный стандарт подойдет лучше всего. Иногда этот стандарт у ряда заказчиков является обязательным для применения на проектах внедрения автоматизированных систем управления (АСУ). Данный стандарт имеет более жесткую структуру, чем стандарт IEEE Std 830, что одновременно является его преимуществом и недостатком.

В большинстве проектов внедрения 1С:Предприятия данный стандарт является избыточным и сложным для понимания даже для разработчиков АСУ. Однако, когда разработка ТЗ всё-таки ведется по данному ГОСТу предлагается полностью сохранять структуру документа в соответствии с установленным стандартом. При этом по «пустым» разделам просто вносить комментарии типа: «По данному разделу требования отсутствуют».

Корпоративные стандарты.

Корпоративный стандарт существует на отдельном предприятии или в холдинге. Обычно корпоративный стандарт берет за основу любой из двух предыдущих стандартов и дорабатывается с учетом особенностей данного предприятия и его бизнес-процессов. В проектах внедрения 1С чаще всего используется корпоративный стандарт в виде упрощенного варианта ГОСТа34.

2.2 Разделы ТЗ

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

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

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

2.2.1 Описание целей и задач

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

Раздел должен содержать в себе:

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

2.2.2 Описание функциональных требований к ИС

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

Понятие система включает в себя следующие составные элементы:

1) Если это программно-аппаратный комплекс (ПАК), тогда в систему входит:

Платформа программы 1С:Предприятие;
Конфигурация программы;
База данных;
Документация на ПАК;
Рабочие станции;
Серверы с серверным оборудованием;
Внешнее оборудование (считывающие, передающие устройства и т.п.),

2) Если это автоматизированная система, тогда она включает в себя:

ПАК;
Пользователи, работающие с ПАК;
Документация на АСУ;

2.2.3 Описание процесса передачи ИС заказчику

В этом разделе ТЗ описываются:

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

2.2.4 Описание сроков и стоимости работ

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

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

3. Как разрабатывают ТЗ

Процесс написания ТЗ можно разделить на следующие этапы:

Планирование работ;
Сбор информации;
Анализ и синтез информации;
Написание документа;
Согласование документа;

3.1 Планирование работ

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

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

Читайте так же: Отозвана лицензия у аск-мед

3.2 Сбор информации

Существует несколько видов источников информации:

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

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

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

Название проекта;
Стороны проекта;
Участников интервью;
Время и место интервью;
Вопросы для интервью;

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

3.3 Анализ и синтез информации

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

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

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

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

3.4 Написание документа

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

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

3.5 Согласование документа

Умение согласовывать готовый документа является не менее важным, чем умение разработать и написать этот документ. В соответствии с ГОСТ 34.602-89 предлагается следующий порядок согласования ТЗ:

1. Проект ТЗ на АС разрабатывает организация-разработчик системы с участием заказчика на основании технических требований (заявки; тактико-технического задания и т. п.).

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

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

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

3. Срок согласования проекта ТЗ на АС в каждой организации не должен превышать 15 дней со дня его получения. Рекомендуется рассылать на согласование экземпляры проекта ТЗ на АС (копий) одновременно во все организации (подразделения).

4. Замечания по проекту ТЗ на АС должны быть представлены с техническим обоснованием. Решения по замечаниям должны быть приняты разработчиком проекта ТЗ на АС и заказчиком системы до утверждения ТЗ на АС.

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

6. Согласование проекта ТЗ на АС разрешается оформлять отдельным документом (письмом). В этом случае под грифом “Согласовано” делают ссылку на этот документ.

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

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

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

10. Согласование и утверждение дополнений к ТЗ на АС проводят в порядке, установленном для ТЗ на АС.

11. Изменения к ТЗ на АС не допускается утверждать после представления системы для ее очереди на приемо-сдаточные испытания.

12. Регистрация, учет и хранение ТЗ на АС и дополнений к нему проводят в соответствии, с требованиями ГОСТ 2.501.

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

Для систематизации этого процесса предлагается установить следующие правила согласования ТЗ.

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

ФИО участника;
Должность или роль в проекте;
Пункт ТЗ, по которому есть замечание;
Описание замечания и предложения по его исправлению;

Процесс согласования должен проводиться по следующим правилам:

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

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

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

В чем разница технического задания и описания объекта госзакупки

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

Напомним, что с 11.01.2018 в правилах описания предмета госзаказа произошли изменения:

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

Делать это будет не обязательно:

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

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

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

Правила составления ТЗ по 44 ФЗ

Самый простой и быстрый способ сформировать техническое задание — образец по ФЗ 44 разработать на основе официального издания Единой системы документации национальных стандартов.

Основное назначение технического задания — четко определить и зафиксировать требования к объекту закупки. При этом закон устанавливает, что наименование закупки указывается в соответствии с каталогом товаров, работ, услуг (ч. 4 ст. 23). Каталог утвержден Постановлением Правительства от 08.02.2017 № 145.

При наличии описания закупаемой продукции в КТРУ заказчик обязан:

описывать объект закупки так, как это предусмотрено КТРУ;
включить в описание письменное обоснование (если описание отличается от того, которое предусмотрено в КТРУ).

Утвержденными ПП от 05.06.2015 № 555 Правилами предусмотрена обязанность заказчика указывать наименование предмета закупки в процессе обоснования.

Формулировку требований заказчик составляет на основе правил описания объекта закупки (ст. 33). Выделим некоторые обязательные условия:

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

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

Содержание ТЗ необходимо основывать на положениях 44-ФЗ, также обязательно соблюдать нормы гражданского, бюджетного и антимонопольного законодательств и отраслевых нормативных актов.

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

общая информация;
информация о закупаемом объекте;
требования к поставщикам;
условия исполнения контракта;
приложения (допускается по усмотрению заказчика).

Этапы составления технического задания

1. Составить список терминов, определений и сокращений, которые будут использоваться в документе.

2. Предоставить полную информацию о заказчике:

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

3. Предусмотреть в информации о закупке сведения:

совместная закупка или нет, а если да — права и обязанности каждого заказчика (ПП от 28.11.2013 № 1088);
централизованная закупка, сведения об уполномоченном органе (ч. 1 ст. 26 закона № 44-ФЗ);
привлечение экспертов, порядок их работы.

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

способ определения поставщика (ч. 1 ст. 24);
обоснование выбранного способа определения поставщика (ч. 5 ст. 24).

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

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

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

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

9. Привести желаемые результаты (какую проблему хочет решить заказчик) и цели госзакупки (ст. 13 44-ФЗ).

Читайте так же: Пристав неустойка

10. Указать источник финансирования.

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

12. Определить условия нормирования госзакупки (ч. 1 ст. 19).

13. Указать наименование и обоснование объекта госзакупки.

14. Максимально точно и детально описать объект госзакупки (ст. 33).

15. Определить экологические особенности закупаемого объекта.

16. Уточнить объем закупаемых товаров, а также периодичность и срок поставки.

17. Определить гарантийный срок и объем предоставляемых гарантий.

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

19. Обязать предоставлять подтверждение нового товара или потребности в товаре иного состояния.

20. Определить расходы на эксплуатацию.

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

22. Установить порядок поставки и приемки.

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

Образцы техзаданий для товаров, работ, услуг в 2018 году

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

Ниже представлен образец технического задания на поставку товара по 44-ФЗ.

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

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

Примеры для других госзакупок

Также в наших подробных инструкциях вы можете найти образец техзадания и узнать как грамотно провести закупку на:

Составляем техническое задание на проектирование правильно

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

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

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

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

Что такое ТЗ и зачем оно нужно

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

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

эскизное;
архитектурное;
инженерное;
конструктивное на отдельные виды металлоконструкций и т.п.

Как составить ТЗ

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

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

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

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

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

Рекомендуем к прочтению

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

3 шага к идеальному ТЗ

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

Шаг 1. Задайте правильные вопросы

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

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

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

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

Бюджет. Обсудите бюджет проекта: общую стоимость, этапы работы, порядок и сроки оплаты. Постарайтесь договориться об авансе на работу, просите не менее 30% от общей стоимости. Так вы сможете себя обезопасить на случай неплатежеспособности заказчика или разрыва договора. Если заказчик откажется от сотрудничества, согласно ГК РФ, он должен оплатить фактически выполненные работы. На практике получить деньги при расторжении договора сложно, но вы сможете удержать оплату работ из аванса.

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

Шаг 2. Запишите детально

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

ТЗ — юридический документ,

в который записывают весь перечень работ и

оформляют в виде приложения к договору.

Различают ситуации, когда нужны оба документа или можно обойтись одним:

бриф — простая задача, быстрое выполнение.

Пример: дизайн рекламного баннера.

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

Пример: добавить страницу на действующий корпоративный сайт с утвержденным дизайном.

бриф + ТЗ — большой проект с общей стилистикой, дизайном и разработкой.

Пример: создание сайта.

Глоссарий — первый раздел, в который записываются используемые термины и их толкование. Формулировки в техзадании записывайте подробно, точно и формальным языком. Пункты в формате “хороший сайт с веселеньким дизайном” будут трактоваться всеми участниками по-разному и приведут к отсутствию желаемого результата. Хорошее ТЗ может в несколько раз превышать объем договора. Пусть вас это не смущает, все-таки ТЗ и есть главный документ.

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

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

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

Читайте так же: Таможенные пошлина на посылки

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

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

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

Шаг 3. Утвердите сроки

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

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

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

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

Срок согласования этапов. Часто случается, что заказчик тянет с согласованием и замечаниями. Это тормозит работу и откладывает запуск сайта. По итогу заказчик еще и обвиняет исполнителя в срыве сроков проекта. Чтобы этого избежать, пропишите в договоре время на согласование (3-4 дня). Если заказчик в этот срок не пришлет замечаний, этап будет считаться согласованным, и исполнитель примет решение в одностороннем порядке.

Срок подписания актов намного важнее, чем согласования этапов. Без подписанного акта вы не сможете получить оплату за выполненную работу. Если заказчик поступит непорядочно и не переведет оставшуюся сумму, вам придется “бегать” за ним, названивать и заваливать письмами. Формально договор еще не завершен, ведь акт выполненных работ не подписан сторонами.

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

Можно ли работать без ТЗ?

Поклонники гибкой методологии разработки (agile, scrum и др.) вместо четкого и строгого технического задания используют концептуальные документы: скетчи, user stories и пр. По ним задается вектор направления, а детализация появляется во время разработки. Другой альтернативой свободного ТЗ выступают mindmap — диаграммы связи с древовидной структурой.

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

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

Не приступайте к работе без договора.

Спросите обо всем, что может относиться к проекту.

Составьте бриф и ТЗ.

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

Установите и зафиксируйте сроки.

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

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

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

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