Согласно техническому заданию / Хабр
Добрый вечер, созидающая часть Хабра!Будучи разработчиком, я постоянно работаю с техническими спецификациями клиентов и мой первый пост — это небольшой очерк, анализ такой вещи, как «техническое задание».
Итак, когда компания-заказчик приходит к исполнителю и заказывает «неосязаемое нечто», последний делает постный вид и просит предоставить техническое задание (бриф, описание, спецификация). Заказчик, полный энтузиазма, начинает выплескивать его на бумагу и это правильное начало, ведь техническое задание – замечательная штука!
Оно позволяет выразить свои идеи, сделать их понятными для окружающих и получить в итоге именно то, что нужно! С помощью тех. задания мы можем упорядочить мысли, правильно поставить задачу и увидеть противоречия на самых ранних этапах. Несмотря на то, что сам термин чаще применяется в бизнесе, суть его распространяется почти на все аспекты нашей жизни. Сформулированное в том или ином приближении, тех.
В быту мы постоянно ощущаем его полезность: заказывая шоколадный торт, описывая идеальную прическу парикмахеру или выбирая жену, которая должна быть милой, остроумной и уметь готовить. Повсеместное использование породило бесчисленное множество уже готовых, типичных технических заданий. К примеру, в кофейне нам достаточно сказать «Капучино!» и не рассказывать официанту про «кофейный напиток на основе эспрессо с добавлением молока и пены»
Жаль только, что, полное неоспоримых преимуществ, Тех. Задание, содержит пару больших и жирных «но».
Давая представление о том, что будет делать продукт, техническое задание совершенно не способно описать, насколько хорошо он будет это делать. Даже самое подробное ТЗ содержит массу мест для вольной интерпретации – мест, которые исполнитель часто трактует в сторону уменьшения усилий.
Возьмем, для примера, рулон туалетной бумаги.
Простейший предмет с элементарным техническим заданием и понятным каждому функционалом. Тем не менее, на полке супермаркета можно обнаружить совершенно разную бумагу.
Одна будет грязно-серой, другая – белоснежной; одна — стоить доллар, другая в три раза дороже! Выбрав одну – вы заработаете геморрой, выбрав другую – достигнете небывалых высот мысли.
Переходя от бытовых примеров к бизнесу, можно посмотреть на тендерные закупки. Система, основанная на тех. спецификациях и естественном стремлении бизнеса сэкономить средства, буквально выдавливает хороших поставщиков, сводя торги исключительно к ценовой конкуренции.
В итоге, несостоятельность тех. задания, как регулятора качества работы вкупе с самым дешевым исполнителем приводят заказчика к парадоксальному результату: продукт, полностью отвечающий ТЗ, работает настолько плохо, что пользоваться им попросту невозможно.
Ситуацию хорошо иллюстрирует известная притча про скупого человека, который принес портному кусок материала и попросил сшить ему шапку.
При заказе скупец поинтересовался, не хватит материала на два головных убора? Получив утвердительный ответ, он спросил про три, четыре… и сторговался, в итоге, на десяти. Через неделю он получил свой заказ. Шапок было действительно десять, но все они едва налазили на мизинец.
Пожалуй, шапка, которую нельзя одеть на голову – это прекрасная зарисовка главной беды плохого продукта: номинальное присутствие плохо отлаженного функционала в большинстве случаев равно его отсутствию.
И, если притча кажется немного абсурдной и оторванной от нынешних реалий, читатель легко найдет массу современных примеров (допустим, среди многофункциональной электроники).
Разумное применение
ТЗ, со всеми плюсами и минусами – это, прежде всего инструмент, который требует правильного применения. Оно уместно в чистом виде, когда речь идет о сильно стандартизированном решении – например, поставках цемента известного состава и марки в четко оговоренные сроки.Возведение технического задания в принцип – разрушительно для продукта.
Однажды автор встречался с Заказчиком, который утверждал, будто описание его задачи не допускает никаких разночтений и от исполнителя не зависит ничего. На его столе лежали предложения от разных подрядчиков и он выбирал самого бюджетного. При этом одет он был, отчего-то, не в самую дешевую одежду и, сидя в удобном кресле, пил ароматный пуэр.
Я призываю Заказчика помнить, что ТЗ — это полезная штука, но она описывает низший уровень качества решения
Изображения взяты с сайтов: pt.wikinoticia.com cultofmac.cultofmaccom.netdna-cdn.com, www.popwuping.com, www.thinkgeek.com
P.S. Я не уверен в правильности выбранного блога, но не нашел более подходящего.
Поставка товара не соответствующего техническому заданию \ Акты, образцы, формы, договоры \ КонсультантПлюс
- Главная
- Правовые ресурсы
- Подборки материалов
- Поставка товара не соответствующего техническому заданию
Подборка наиболее важных документов по запросу Поставка товара не соответствующего техническому заданию (нормативно–правовые акты, формы, статьи, консультации экспертов и многое другое).
- Поставка:
- 60 счет
- Акт возврата некачественного товара
- Акт недопоставки
- Акт о выявленных недостатках товара
- Акт о скрытых недостатках
- Показать все
- Поставка:
- 60 счет
- Акт возврата некачественного товара
- Акт недопоставки
- Акт о выявленных недостатках товара
- Акт о скрытых недостатках
- Показать все
Зарегистрируйтесь и получите пробный доступ к системе КонсультантПлюс бесплатно на 2 дня
Позиции судов по спорным вопросам. Бюджетные организации: Закупка в целях франкирования по Закону N 44-ФЗ
(КонсультантПлюс, 2023)Суд отмечает, что согласно законодательству о контрактной системе экспертиза может проводиться заказчиком не только привлеченными специалистами, но и своими силами, что исключает доводы о том, что оценка товара комиссией заказчика не является экспертной и не подтверждает несоответствие поставленного товара требованиям технического задания.
..»
Зарегистрируйтесь и получите пробный доступ к системе КонсультантПлюс бесплатно на 2 дня
Определение Верховного Суда РФ от 29.03.2021 N 305-ЭС21-2324 по делу N А40-325353/2019
Требование: О пересмотре в кассационном порядке судебных актов по делу о признании недействительным одностороннего отказа от государственного контракта, обязании принять товар и встречного иска об обязании освободить помещение от поставленного товара.
Решение: В передаче дела в Судебную коллегию по экономическим спорам Верховного Суда РФ отказано, так как суд округа, проверив правильность применения норм материального и процессуального права, отменил решение суда первой инстанции и постановление суда апелляционной инстанции, направил дело на новое рассмотрение, признав, что содержащиеся в обжалуемых актах выводы сделаны без установления и соответствующей правовой оценки обстоятельств, имеющих существенное значение для правильного рассмотрения спора.Суд округа признал, что суды нижестоящих инстанций не дали оценки доводам департамента о том, что от заказчика не требуется проведение внешней экспертизы при приемке товара.
Из положений статьи 41 Закона N 44-ФЗ не следует, что заказчик обязан привлекать сторонних экспертов во всех случаях приемки товара; о том, что подписанная сторонами Спецификация является ничтожной сделкой, поскольку ее содержание не соответствует условиям контракта и технического задания, согласно которым поставляемый товар должен быть оригинальным. Товар должен быть произведен производителем техники. Между тем в Спецификации написано, что спорный товар поставляется под товарным знаком «ОРИГИНАЛЬНЫЙ» и не был изготовлен производителем техники.
Зарегистрируйтесь и получите пробный доступ к системе КонсультантПлюс бесплатно на 2 дня
Решение Московского УФАС России от 04.10.2022 по делу N 077/07/00-14218/2022
Обстоятельства: Поступила жалоба Заявителя, согласно которой Заказчиком при проведении Закупки не соблюдена минимальная доля закупок товаров российского происхождения, установленная Постановлением Правительства РФ N 2013.
Решение: Признать жалобу необоснованной.Учитывая, что Заявителем не представлены документы, подтверждающие несоответствие товара, предлагаемого к поставке победителем Закупки, техническим характеристикам, указанным в техническом задании, Комиссия приходит к выводу о необоснованности указанного довода жалобы.
Техническое задание: уроки по их структуре и интерпретации результатов
Lire en francais | Leer en español
Автор: Dr. Issa Sombié/Из Буркина-Фасо. Он научный сотрудник Национального центра научных и технологических исследований и профессор университета. Доктор социологии и обладатель степени магистра в области оценки
Техническое задание (TdR) представляет собой структуру, которая позволяет описать цель, объем и процесс, включая управленческие и технические аспекты, оценки в соответствии с потребностями. тех, кто запрашивает оценку программы или проекта.
Это руководство имеет первостепенное значение в процессах оценки, так как именно на него возлагаются ожидания тех, кто запрашивает оценку.
Кроме того, они служат ориентиром для оценщика, поэтому их ясность и точность очень важны.
Часто на отношения между оценщиками и лицом, запрашивающим оценку, влияют отсутствующие, вводящие в заблуждение или двусмысленные элементы технического задания. Обычно в ходе этой разработки реальные потребности программы не находят адекватного отражения.
Далее мы рассмотрим наиболее приемлемые базовые элементы в качестве структуры для использования Технического задания (ToR) и применимой к процессу оценки, согласно Детскому фонду Организации Объединенных Наций (ЮНИСЕФ).
Таблица 1 : Основные элементы структуры Технического задания (ТЗ) ЮНИСЕФ
| Содержание основы анализа | 900 05 Описание |
| Фон | Презентация программы, ее характеристики, ее эволюция с течением времени, участвующие игроки, национальный и международный фон, а также составляющие ссылки на оценку. |
| Цели оценки | Причины оценки, ее дополнительная ценность, а также процесс использования результатов. |
| Вопросы и критерии оценивания | Список вопросов, на которые необходимо ответить при оценивании, различные критерии оценивания, которые необходимо учитывать. |
| Существующие источники данных | Источники информации имеются и доступны. |
| Методология | Различные шаги, подходы и методы сбора данных процесса, чтобы ответить на вопросы. |
| Участие игроков, участвующих | Процессы участия всех игроков, участвующих в оценке. |
| Ответственность и обязательства вовлеченных игроков | Определение обязательств и ответственности игроков. |
| Состав группы по оценке | Описание профилей и навыков оценщиков. |
| Бюджет | Общий бюджет и его основные разделы. |
В одном упражнении мы оценим три процесса оценки, в которых использование Технического задания (ТЗ) в различных программах, осуществляемых в Буркина-Фасо в Африке, привело к неоднозначным результатам.
Первый касается оценки программы борьбы с лимфатическим филяриатозом.
| СОДЕРЖАНИЕ АНАЛИЗА | ЧТО БЫЛО ПОСТАВЛЕНО |
| Исходная информация | 90 025 Включено|
| Цели оценки | Включено |
| Вопросы и критерии оценки | Не включены |
| Существующие источники данных | Не включено |
| Методология | Не включено |
| Участие вовлеченных игроков | Не включено |
| Re обязанности и обязательства вовлеченных игроков | Не включено |
| Состав группы оценки | Включено |
| Процедуры и логистика | Не включено |
| Бюджет | Не включено |
Второй — это оценка программы по ВИЧ/СПИДу, реализуемой местной организацией.
| СОДЕРЖАНИЕ АНАЛИЗА | ЧТО БЫЛО ПОСТАВЛЕНО |
| Исходная информация | 90 025 Включено|
| Цели оценки | Включено |
| Вопросы и критерии оценки | Не включены |
| Существующие источники данных | Не включено |
| Методология | Не включено |
| Участие вовлеченных игроков | Не включено |
| Re обязанности и обязательства вовлеченных игроков | Не включено |
| Состав группы оценки | Включено |
| Процедуры и логистика | Не включено |
Наконец, показан процесс оценки программы борьбы с малярией международной НПО.
| СОДЕРЖАНИЕ АНАЛИЗА | ЧТО БЫЛО ПОСТАВЛЕНО |
| Исходная информация | 900 25 Включено|
| Цели оценки | Включено |
| Вопросы и критерии оценки | Включены |
| Существующие источники данных | Не включено |
| Методология | Включено |
| Участие вовлеченных игроков | Не включено |
| Ответственность и обязательства вовлеченных игроков | Включено |
| Состав группы оценки | Включено |
| Процедуры и логистика | Не включены |
Из таблиц видно, что различные элементы, предлагаемые аналитической структурой , не всегда учитываются при составлении технического задания. Мы обнаруживаем, что «исходная информация» не была представлена в трех примерах ТЗ, как это было предложено в рамках анализа ЮНИСЕФ.
«Цели оценки», а также «состав команды» также учитывались в трех примерах, хотя и не совсем так, как предполагает аналитическая схема. Что касается элементов: «существующие источники данных», «вовлечение вовлеченных игроков», «процедуры и логистика» и «бюджет», то они не были разработаны ни в одном из трех примеров.
Наконец, «методология», «оценочные вопросы», «ответственность и обязательства вовлеченных игроков» рассматривались только в одном из трех примеров. Мы отмечаем, что некоторые важные элементы не всегда учитывались.
Благодаря этому краткому анализу технического задания на процесс оценки мы узнали несколько вещей:
Первый урок:
Необходимо уточнить цель и задачи оценки. Точное и подробное описание целей оценки позволит группе по оценке предложить соответствующие методы для удовлетворения заявленных потребностей. Для этого любой, кто запрашивает оценку программы или проекта, должен стремиться установить свои приоритеты с точки зрения ожидаемой информации, а не в соответствии с критериями оценки.
Прежде всего, руководители программ должны избегать стандартных формул технического задания, в которых просто меняется название проекта.
Второй урок:
Очень важно составить вопросы для оценки, которые, хотя и не являются исчерпывающими или правильно сформулированными, всегда позволяют команде по оценке лучше понять ожидания и информационные потребности тех, кто запрашивает оценку. С точки зрения оценщика мы склонны говорить, что не бывает неправильных вопросов и что важнее всего знать, что вы хотите найти. Во многих случаях отсутствие навыков оценки скрывает реальную проблему в установлении потребностей, даже выбор вопросов для оценки остается в руках оценщика.
Третий урок:
Хотя сложно требовать стандартной структуры Технического задания, его формулировка должна включать ряд существенных элементов. Мы считаем, что элементы, относящиеся к контексту, цели и задачам оценки, вопросам, критериям и методологии, имеют основополагающее значение для оценщиков при подготовке их технического предложения.
Руководителям программ рекомендуется изучить различные руководства в этой области. Перед установлением цели и задач оценки необходимо предусмотреть возможное использование результатов оценки.
Заключение:
Качество оценок во многом зависит от проработанной структуры технического задания. На самом деле сложно дать адекватный ответ на плохо сформулированный вопрос или плохо поставленную проблему.
Этот анализ позволил нам выявить определенные недостатки, которые могут повлиять на техническое задание. Таким образом, мы обнаружили, что цели и вопросы оценки часто мало или плохо определены, что приводит к отсутствию навыков при подготовке ТЗ. Наиболее серьезным является то, что, основываясь на результатах, недостаточное внимание уделяется важности, придаваемой процессу оценки.
Зачем мы проводим оценку? Следует напомнить, что первая цель оценки заключается в поддержке принятия решений. Это означает, что перед ее разработкой игроки уже провели инвентаризацию ожидаемой информации и знают, для чего она будет использоваться.
Однако в контексте управления программами и проектами в Африке мы часто наблюдаем, что оно просто стремится удовлетворить положения, изложенные в документе по разработке программы или проекта. Оценка заказана, потому что она уже была запланирована во время разработки проекта, поэтому она должна быть сделана. Это также объясняет редкое использование результатов оценки.
В этих условиях проблема формулирования потребностей в оценке, а также качества ее результатов, вероятно, сохранится.
Управление проектами. Техническое задание
© Copyright 2020, все права защищены March Limited
Определение
Существует множество точек зрения на точное определение документа технического задания. Некоторые из них приведены ниже:
«Документ, определяющий объем и детали деятельности, к которой он относится, и любые условия, связанные с назначением лица (лиц) для осуществления деятельности (обычно используется в отношении предоставления профессиональных услуг).
)’
Или
«Руководящее положение, определяющее объем и пределы расследования».
Есть много других, которые могут немного зависеть от использования в отрасли.
Примером, приведенным здесь, может быть Техническое задание между Советом проекта и Менеджером проекта в отношении того, что ожидается от проекта.
В основном это документ, описывающий цель и структуру проекта.
Он также известен как «ТЗ» или иногда Устав проекта.
Создается в начальной части проекта на этапе инициации.
Он имеет решающее значение для проекта, поскольку определяет все его ключевые аспекты.
Содержание
Сюда могут входить:
- Видение, цели, объем и результаты (это то, что на самом деле будет произведено проектом).
- Заинтересованные стороны, полномочия, роли и обязанности (т.е. кто будет принимать в этом участие)
- Ресурсные, финансовые (затраты и бюджеты) и планы качества (т.е. как это будет достигнуто)
- Структура и график разбивки работ (т.
е. когда он будет достигнут) - Идентификация заказчика
- Основные допущения и ограничения
- Ключевые области риска
- Используемый проектный подход или стратегия
е. когда он будет достигнут) По сути, это основа дорожная карта проекта.
Это дает команде управления проектом четкое представление о том, что должен произвести проект.
Затем проект должен произвести результаты в соответствии с ограничениями технического задания.
После утверждения технического задания оно должно быть подписано всеми заинтересованными сторонами.
Вполне вероятно, что техническое задание будет содержать много информации, которая существует отдельно в блокноте проекта.
Точный характер документа технического задания будет согласован между менеджером проекта и советом проекта.
В соответствии с PRINCE2® техническое задание создается сразу после утверждения бизнес-обоснования проекта.
Он будет представлен Совету проекта на утверждение Руководителем проекта.