Требования к исполнителю в техническом задании: Требования к техническому заданию по 44-ФЗ

10 правил и немного занудства / Хабр

Если пройтись по зарубежным сайтам с запросом «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. Если есть лучший перевод — будем рады его внести в пост.

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

Источник: Журнал «Силовые министерства и ведомства: бухгалтерский учет и налогообложение»

Начиная с 01.01.2014 для совершения закупок все учреждения должны применять положения Закона № 44-ФЗ. Отметим, что в данном законе прямо не предусмотрена обязанность заказчика составлять техническое задание. Однако техническое задание является одним из первых документов, который необходимо составить при любом виде закупки, так как в нем прописаны действия или услуги, которые нужно будет выполнить исполнителю.

При составлении технического задания руководствуются ст. 33 «Правила описания объема закупки» Закона № 44-ФЗ.

В частности, необходимо указать в техническом задании:

1. Общую информацию о закупке.
2. Описание объекта закупки.
3. Требования к объекту закупки.
4. Условия закупки.
5.  Особенности отдельных видов закупки.

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

Общая информация о закупке. Этот раздел, как правило, включает в себя:

1. Общие сведения о заказчике (о наименовании, местонахождении, режиме работы).

2. Общие сведения о закупке (о способе определения поставщика в соответствии с ч. 1 ст. 24 Закона № 44-ФЗ, цели закупки согласно ст. 13 Закона № 44-ФЗ, источнике финансирования, нормативно-правовой базе, на основании которой производится закупка).

3. Дополнительные пояснительные сведения.

Описание объекта закупки. Здесь указываются следующие характеристики объекта закупки:

1. Функциональные. Необходимо установить основное назначение объекта закупки и условия его использования по назначению. Функциональное назначение объекта характеризуется, например, такими свойствами, как пищевая ценность (энергетическая, биологическая), эстетические свойства (форма, цвет, запах, совершенство производственного исполнения) и др.
2. Технические. Заказчик может детализировать описание объекта закупки, привести конкретные данные, параметры, исходные и конечные величины, физические величины показателей, описать регламент и порядок действий при поставке товара, выполнении работ, оказании услуг.
3. Качественные. Указывается совокупность свойств, характеристик, признаков товаров, услуг, работ, обусловливающих их способность удовлетворять потребности и запросы заказчика, соответствовать своему назначению и предъявляемым требованиям.
4. Эксплуатационные. Здесь можно прописать характеристики надежности и работоспособности объекта закупки, условия, обеспе­чивающие его эффективную эксплуатацию, к которым относятся в том числе прочность, долговечность, технические параметры, объемно-планировочные, санитарно-гигиенические, экономические и эстетические характеристики. В качестве эксплуатационных характеристик товара можно указать стадию его жизненного цикла использования по назначению.

Отметим, что все вышеперечисленные характеристики объекта закупки являются критерием оценки заявок, окончательных предложений участников закупки (ч. 1 ст. 32 Закона № 44-ФЗ).

При описании объекта закупки необходимо использовать, если это возможно, стандартные показатели, требования, условные обозначения и терминологию, касающуюся технических и качественных характеристик объекта закупки, установленных в соответствии с техническими регламентами, стандартами и иными требованиями, предусмотренными законодательством РФ о техническом регулировании. К ним относятся ГОСТы, СНиПы и другие нормативно-технические документы.

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

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

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

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

2. В случае, если содержится требование о соответствии поставляемого товара изображению товара, на поставку которого заключается контракт, заказчику необходимо привести изображение поставляемого товара, позволяющее его идентифицировать и подготовить заявку, окончательное предложение (пп. 4 п. 1).

3. Поставляемый товар должен быть новым товаром. Это значит, что он не был в употреблении, в ремонте, не был восстановлен, у него не была осуществлена замена составных частей, не были восстановлены потребительские свойства, в случае, если иное не преду­смотрено описанием объекта закупки (пп. 7 п. 1).

Условия закупки. В этом разделе следует указывать:

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

2. Сроки поставки товаров, выполнения работ, оказания услуг. Отметим, что согласно п. 2 ст. 42 Закона № 44-ФЗ обязательно нужно проставить сроки завершения работ. Кроме этого, здесь должны быть указаны промежуточные сроки завершения отдельных этапов работ или приведен график оказания услуг, который поможет распределить объем оказываемых услуг по периодам.

3. Информацию о месте, датах начала и окончания, порядке и графике осмотра участниками закупки образца или макета товара, на поставку которого заключается контракт, если заказчик установил требования о соответствии поставляемого товара образцу или макету товара, на поставку которого заключается контракт (пп. 5 п. 1 ст. 33 Закона № 44-ФЗ).

4. Требования к поставщикам (подрядчикам, исполнителям). Здесь можно прописать требования о наличии лицензии, допуска, разрешения и согласования (п. 1 ч. 1 ст. 31 Закона № 44-ФЗ). Кроме того, в силу ч. 2 ст. 31 Закона № 44-ФЗ при закупке отдельных видов товаров (работ, услуг) Правительство РФ устанавливает дополнительные требования к участникам закупок, в том числе к наличию финансовых, материальных и трудовых ресурсов для исполнения контракта, опыта работы, связанного с предметом контракта (ч. 2 ст. 31 Закона № 44-ФЗ).

5. Показатели, которые позволят определить соответствие закупаемых товаров, работ, услуг, установленные заказчиком. При этом указываются максимальные и (или) минимальные значения таких показателей и значения показателей, которые не могут изменяться (п. 2 ст. 33 Закона № 44-ФЗ).

6. Требование к расходам на эксплуатацию товара (ч. 4 ст. 33 Закона № 44-ФЗ). Оно устанавливается для необходимости обосновать документально расходы, которые будут понесены заказчиком при эксплуатации закупленного товара. Величина расходов отражается в численной форме индивидуально для каждого товара с учетом нормальных эксплуатационных и нагрузочных условий работы. Данное требование является критерием оценки заявок, окончательных предложений участников закупки (ч. 1 ст. 32 Закона № 44-ФЗ).

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

Какие требования может не содержать техническое задание?

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

2. Требования к объекту закупки.Согласно п. 3 ст. 33 Закона № 44-ФЗне допускается включение следующих требований:

• о наличии опыта работы к участнику закупки;
• к деловой репутации участника закупки;
• к наличию у участника закупки производственных мощностей, технологического оборудования, трудовых, финансовых и других ресурсов, необходимых для производства товара, поставка которого является предметом контракта, для выполнения работы или оказания услуги, являющихся предметом контракта, за исключением случаев, если возможность установления таких требований к участнику закупки предусмотрена данным законом. Это означает, что не допускается указывать требования, которые могут создать преимущественные условия участия для участников закупки (п. 2 ч. 1 ст. 17 Федерального закона от 26.07.2006 № 135-ФЗ «О защите конкуренции»).

Особенности отдельных видов закупки. Согласно ч. 5 ст. 33 Закона № 44-ФЗ для отдельных видов товаров, работ, услуг Правительством РФ могут быть установлены специальные правила описания закупок, например:

1. Закупка для нужд оборонного заказа. Особенности описания товаров, работ, услуг, входящих в состав государственного оборонного заказа для обеспечения федеральных нужд, могут быть установлены в соответствии с Федеральным законом от 29.12.2012 № 275-ФЗ «О государственном оборонном заказе» (ч. 6 ст. 33 Закона № 44-ФЗ).

2. Закупка лекарственных средств. При закупке лекарственных средств необходимо отражать следующую информацию (пп. 6 ч. 1 ст. 33 Закона № 44-ФЗ):

• международные непатентованные наименования лекарственных средств или (при отсутствии таких наименований) химические, группировочные наименования;
• при закупке лекарственных средств, входящих в перечень лекарственных средств, закупка которых осуществляется в соответствии с их торговыми наименованиями, а также при осуществлении закупки лекарственных препаратов согласно п. 7 ч. 2 ст. 83 Закона № 44-ФЗ разрешается указывать торговые наименования этих лекарственных средств. Данный перечень и порядок его формирования утверждаются Правительством РФ;
• предметом одного контракта (одного лота) не могут быть лекарственные средства с различными международными непатентованными наименованиями или (при отсутствии данных наиме­нований) с химическими, группировочными наименованиями при условии, что начальная (максимальная) цена контракта (цена лота) превышает предельное значение, установленное Правительством РФ, а также лекарственные средства с международными непатентованными наименованиями (при отсутствии этих наименований – с химическими, группировочными наименованиями) и торговыми наименованиями.

3. Закупка машин и оборудования. В силу ч. 4 ст. 33 Закона № 44-ФЗ при закупке машин и оборудования в техническом задании, которое включается в документацию о закупке, необходимо установить следующие требования, если они предусмотрены технической документацией на товар: к гарантийному сроку, к объ­ему предоставления гарантий качества товара, к гарантийному обслуживанию, к расходам на обслуживание товара в течение гарантийного срока, к осуществлению монтажа и наладки товара. При закупке новых машин и оборудования в техническом задании нужно установить требования к предоставлению гарантии производителя и (или) поставщика и сроку ее действия. Следует учитывать, что такая гарантия предоставляется вместе с товаром.

* * *

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

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

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

Вы находитесь здесь

Главная » Методологическая книга » 10 требований к ТЗ

Автор(ы): Чарисс Гриффит-Чарльз и Динанд Алкема

: Ключевые слова: Техническое задание (ТЗ)

Ссылки: Руководство Всемирного банка по ТЗ,

Введение.

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

Цель

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

 

Еще одним важным аспектом ТЗ является то, что они необходимы для определения успеха проекта после его завершения. ТЗ должны быть написаны четким и лаконичным языком, чтобы обеспечить эффективную передачу требований (Mahony and Dearden, 2012; Roberts, Khattri, and Wessal, 2011). Спецификации должны, где это возможно, и в зависимости от характера задания, даваться в конкретных числах, с точностью и в областях, чтобы избежать двусмысленности, и должны использоваться в качестве эталона для оценки успеха проекта.

 

В опытно-конструкторских работах ТЗ необходимы для следующих типов проектов:

• Предварительное ТЭО
• ТЭО
• Экспертиза и проектные проекты
• Проекты внедрения, которые уже разработаны
• Обзор, оценка и аудит завершенных проектов
• Отчеты технических рекомендаций

 

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

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

 

Таким образом, проект можно разделить на несколько различных подпроектов для выполнимости, разработки, реализации и оценки, для каждого из которых потребуется собственное ТЗ (Mahony and Dearden, 2012; Roberts, Khattri, and Wessal, 2011). Поэтому важно, чтобы ТЗ были хорошо подготовлены, поскольку любые негативные последствия плохо разработанных ТЗ на начальных этапах могут повлиять на общую программу развития в дальнейшем. Поэтому не менее важно, чтобы ответы на запрос предложений продемонстрировали глубокое понимание ТЗ, чтобы наилучшая организация была выбрана на основе точного соответствия предложения ТЗ.

 

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

 

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

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

 

Ссылки

Махони, Дес и Филип Н. Дирден. 2012. Семиэтапный формат подготовки технических заданий на разработку. Центр международного развития и обучения (CIDT), Университет Вулверхэмптона

Робертс, Дон, Нидхи Хаттри и Арианн Вессал. 2011. Написание технического задания для оценки: практическое руководство. Всемирный банк. Вашингтон, округ Колумбия

Что такое техническое задание? Определение

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

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

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

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

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

При написании ТЗ важно быть ясным и кратким. Документ должен быть адаптирован к конкретному проекту или инициативе и должен пересматриваться и обновляться по мере необходимости.

Различные типы технических заданий

1. Введение
2. Что такое техническое задание?
3. Различные типы технических заданий
3.1 Официальное техническое задание
3.2 Неофициальное техническое задание
4. Заключение

1. Введение. В этой статье блога мы обсудим определение, различные типы и цели терминов ссылка (ТЗ).
2. Что такое техническое задание? Техническое задание относится к документу, в котором излагаются параметры и цели проекта или инициативы. Это включает в себя определение ролей и обязанностей участников, а также сроки и результаты проекта.
3. Различные типы технических заданий: существует два основных типа технических заданий – официальные и неофициальные технические задания.
3.1 Официальное техническое задание: Официальное техническое задание обычно встречается в более сложных проектах или инициативах, требующих более высокого уровня координации между участниками. Эти ТЗ имеют тенденцию быть более подробными и конкретными, чем неофициальные, чтобы обеспечить четкое руководство относительно того, что ожидается от каждой стороны, участвующей в проекте.
3.2 Неофициальное техническое задание: Неофициальные ТЗ, напротив, часто используются в менее сложных проектах, где уже существует высокий уровень понимания между участниками проекта своих ролей и обязанностей. Таким образом, эти ТЗ, как правило, являются более короткими документами, которые содержат общие обзоры, а не конкретные подробности о параметрах проекта.
4. Заключение: В заключение, ТЗ играют

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

Предположим, вам нужен список плюсов и минусов для статьи в блоге «Что такое техническое задание? Определение»:

PRO:
— Предотвращает расширение масштабов
— Дает всем сторонам четкое представление о параметрах проекта
— Облегчает привлечение людей к ответственности
— Способствует лучшему общению между членами команды

CON:
— Разработка может занять много времени
– Требует согласия со стороны всех заинтересованных сторон
– Если плохо написано, может быть больше проблем, чем они того стоят

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

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

Как можно эффективно использовать техническое задание?

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

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