Правила технического задания / Хабр

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

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

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

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

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

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

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

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

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

8. Если ваши подчиненные также будут пользоваться созданным приложением, постарайтесь им самостоятельно объяснить особенности работы с приложением – это избавит IT-специалиста от необходимости сто раз объяснять одно и то же.

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

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

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

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

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

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

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

При описании в документации о закупке заказчик должен руководствоваться следующими правилами, установленным 44-ФЗ:

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

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

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

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

Что запрещено включать в объект закупки

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

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

Указание ГОСТов и техрегламентов

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

Заказчик может несколько изменить условия по сравнению с техническим регламентом, ГОСТом или СанПиНом, но только в сторону улучшения характеристик.

Пример
1. В соответствии с СанПин 2.4.1.1249-03 площадь озеленения территории дошкольного образовательного учреждения должна составлять не менее 50%, заказчик может предусмотреть озеленение не менее 60% территории.

2. В восстановительные соки допускается добавление лимонной кислоты в дозировке не более 3 г/л (в соотв. с тех. регламентом). Заказчик может уточнить этот показатель, уменьшив ее содержание, например, до 2 г/л. Если заказчик ссылается на ГОСТ, который содержит в себе диапазонные значения, то лучше эти значения отдельно расписать, чтобы уже участник в своей заявке нам показал конкретное значение из этого диапазона ГОСТа.

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

В случае отсутствия ГОСТов, Технических регламентов товар, для которого существует функционирующий рынок заказчик может сформировать описание на основании данных производителей, качественных показателей, которые необходимы заказчику, данных поставщиков о характеристиках товара по причине отсутствия установленных ГОСТов, стандартов и технических регламентов для данного объекта закупки (Письмо Минэкономразвития России от 03.08.2016 № ОГ-Д28-9745).

В случае если ГОСТы являются устаревшими, то следует применять данный номер ГОСТа, но в действующей редакции (с иным индексом после номера)».

Характеристики ТРУ

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

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

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

Как через техническое задание заказчик может ограничить конкуренцию?

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

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

Что запрещено включать в один лот?

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

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

Рекомендации к составлению ТЗ

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

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

Понимание определения и цели?

Джули Уоррен

5 февраля 2022 г.

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

Что означает слово «техническое задание»?

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

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

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

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

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

Создайте его заранее.

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

Убедитесь, что вы знаете, что получите.

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

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

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

Сосредоточьтесь на критических вопросах:

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

Что должно включать техническое задание?

Справочная информация: 

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

Оценка: 

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

Оценочные вопросы:

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

Обзор:

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

Методология:

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

Заинтересованные стороны:

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

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

Допущения:

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

Сбор данных:

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

Документы: 

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

Результаты: 

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

Формат

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

Окончательный вердикт:

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

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

Поделиться этим постом

[rank_math_breadcrumb]

5 февраля 2022 г.

Среднесрочный обзор – Техническое задание

09.11.2022

Независимый среднесрочный обзор (MTR) предназначен для информирования Секретариата о выполнении оставшейся части текущего контракта KPSRL (2021-2024) и процессе разработки стратегия после 2024 года для KPSRL. Процесс разработки стратегии на период после 2024 года состоится в третьем-четвертом квартале 2023 года и выходит за рамки этого задания, но должен основываться на его выводах.

ССО будет разделен на два этапа. На этапе 1 будет оцениваться прогресс в достижении цели и результатов проекта, как указано в проектных документах KPSRL (с акцентом на теорию изменений [ToC] и структуру, основанную на результатах [RBF]), и способствовать обсуждению последствий для будущих планов и действий. Он должен выделять ранние признаки успеха и/или неудачи проекта, а также неожиданные результаты. Он также будет посвящен процессу, которому следовала Платформа, с целью установить, как и почему были достигнуты (или нет) определенные результаты, а также выявить конкретные сведения о том, что сработало, а что нет. Этот этап ССО также будет включать в себя совместный процесс осмысления для проверки результатов с ключевыми заинтересованными сторонами. На этапе 2 оценщики будут сопровождать Секретариат KPSRL и его партнеров по консорциуму в процессе пересмотра ToC и RBF.

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

Основными критериями, которые будут использоваться для оценки опыта консультанта(ов), являются:
1. Опыт оценки сетей, альянсов или сообществ практиков.
2. Опыт оценки проектов и программ, основной целью которых является обучение.
3. Опыт проведения оценок в секторе СРО.
4. Опыт фасилитации процессов теории дизайна изменений.
5. Привлечение перспектив из стран FCAS. Предпочтение отдается разнообразным командам.

Основными критериями оценки предлагаемого подхода и методов являются:
1. Соответствие целям и объему оценки.
2. Инновационный характер.
3. Достоверность выводов, основанная на силе доказательств.
4. Способность делать полезные выводы для будущего посредством совместного осмысления.