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

17 ответов на вопрос “Согласно техническому заданию или технического задания как правильно?”

  1. alexanderm1971 Ответить

    Добрый вечер, созидающая часть Хабра!
    Будучи разработчиком, я постоянно работаю с техническими спецификациями клиентов и мой первый пост — это небольшой очерк, анализ такой вещи, как «техническое задание».
    Итак, когда компания-заказчик приходит к исполнителю и заказывает «неосязаемое нечто», последний делает постный вид и просит предоставить техническое задание (бриф, описание, спецификация). Заказчик, полный энтузиазма, начинает выплескивать его на бумагу и это правильное начало, ведь техническое задание – замечательная штука!

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

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

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

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

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

    Разумное применение

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

    Я призываю Заказчика помнить, что ТЗ — это полезная штука, но она описывает низший уровень качества решения. Хороший, по-настоящему хороший продукт требует к себе человеческого отношения на всех этапах создания. Любите его, не торопитесь с релизом, и он непременно получится восхитительным!
    Изображения взяты с сайтов: pt.wikinoticia.com cultofmac.cultofmaccom.netdna-cdn.com, http://www.popwuping.com, http://www.thinkgeek.com
    P.S. Я не уверен в правильности выбранного блога, но не нашел более подходящего.

  2. twiksoed Ответить

    При составлении технического задания на ремонт прежде всего нужно учитывать предписания контролирующих органов. Представители санитарно-эпидемиологического надзора, пожарной и трудовой инспекции, Ростехнадзора и ряда других инстанций после своих визитов оставляют почти готовые «технические задания». Задача руководителя учреждения — лишь немного видоизменить предписания, сделав их понятными для специалистов-сметчиков. Они впоследствии будут трансформировать теоретические выкладки, касающиеся видов работ и площадей помещений, в проектно-сметную документацию, на основании которой строительная организация приступит к выполнению своей части работ.
    Казалось бы, все просто. Однако на практике возникает много нюансов, и на них следует обращать пристальное внимание. Рассмотрим на примере, как именно результаты проверок трансформируются в техническое задание. Предположим, что после визита представителя противопожарной службы руководитель АУ получил следующие предписания:
    Заменить аварийную электропроводку в помещении N 312.
    Дооборудовать средствами пожаротушения (дополнительным огнетушителем) пост N 2 на втором этаже.
    Заменить глухие металлические решетки на окнах в кабинетах N N 101 — 120 на открывающиеся. Оборудовать специализированный пост для хранения ключей от них.
    Расширить дверной проем аварийного выхода на втором и третьем этажах до 1200 мм.
    Согласовать в противопожарной службе план эвакуации с третьего этажа.
    Заменить электрические выключатели в кабинетах N N 118, 119, 207, 314.
    Очистить от посторонних предметов лестничный пролет между вторым и третьим этажами для доступа к запасному выходу.
    На третьем этаже заменить электрические автоматы (электрические предохранители), установить устройство защитного отключения.
    После изучения данных предписаний руководитель автономного учреждения (или другое ответственное лицо) должен выбрать те замечания, которые лягут в основу технического задания. Разумеется, остальные претензии также необходимо снять, только к ремонту они не относятся.
    Так, замена электрической проводки подразумевает целый комплекс подготовительных и вспомогательных работ — штробление, оштукатуривание штроб, шпаклевку и чистовую отделку поверхностей (альтернативой этому может стать укладка кабеля в специализированный пластиковый короб). Особое внимание стоит уделить марке электрического кабеля (чтобы ее определить, можно привлечь сотрудников-электриков). Сечение и количество жил кабеля выбираются в зависимости от мощности осветительных приборов и количества потребителей электроэнергии, к которым относятся компьютеры, разное оборудование, вентиляторы, чайники, электроплиты, СВЧ-печи и т.д.
    Кроме того, техническое задание по данному пункту можно составить следующим образом (этот способ не предусматривает наличия специальных знаний в области электрики).
    Замена электропроводки — 100 м кабеля на освещение, 50 м на подключение розеток и выключателей. Общая максимальная мощность осветительных приборов составляет 760 Вт, общая максимальная мощность источников — потребителей электроэнергии равна 5 кВт.
    Штробление стен — 15 пог. м.
    Укладка кабеля в штробы с дальнейшей заделкой их материалом на основе гипсовых смесей — 15 пог. м.
    Шпаклевка, ошкуривание, грунтовка, финишная отделка — 15 пог. м.
    Замена розеток, выключателей (в случае необходимости) — 10 шт.
    На основании этих исходных данных сметчик сможет подобрать электрический кабель необходимого сечения, а специалисты АУ, ответственные за ремонтные работы, совместно со строителями впоследствии решат, какими материалами проводить финишную отделку. Если же, например, будет указана только необходимость заменить 250 м электрического кабеля, техническое задание останется непонятным для сметчика. Он не сможет перевести эту информацию в проектно-сметную документацию.
    Дооборудование дополнительным огнетушителем не входит в перечень строительных работ, поэтому в техническом задании мы его опускаем. По тем же причинам не рассматриваются согласование плана эвакуации и расчистка лестничного пролета. Заменить выключатели без проведения «крупномасштабных» электрических работ способен штатный электрик или специалист обслуживающей организации, поэтому включать данный пункт в техзадание также нецелесообразно.
    Что касается замены металлических решеток, возможно, она приведет к разрушению наружных откосов, поэтому в техническом задании этому пункту обязательно нужно уделить внимание. Разобьются откосы при демонтаже или нет — заранее сказать сложно, но лучше перестраховаться и заложить эти работы в смету. Если впоследствии решетки удастся снять аккуратно, то при взаиморасчетах с подрядчиком данные работы просто не будут оплачены, а акты выполненных работ будут составлены на меньшую сумму. Однако, чтобы не возникло двойственной ситуации, в договоре строительного подряда необходимо оговорить этот момент.
    Техническое задание по данному пункту будет выглядеть следующим образом:
    Демонтаж решеток глухих 80 кв. м — 20 шт.
    Монтаж решеток открывающихся (составных из двух элементов) 80 кв. м — 20 шт.
    Демонтаж, монтаж наружных отливов (сандриков) — 40 пог. м.
    Штукатурка наружных откосов — 80 пог. м.
    Шпаклевка, грунтовка, окраска наружных откосов — 80 пог. м.
    Пункт технического задания, касающийся расширения дверного проема, рекомендуется составлять следующим образом:
    Демонтаж дверей второго и третьего этажей — 3,2 кв. м.
    Расширение дверных проемов аварийного выхода на втором и третьем этажах с 800 до 1200 мм.
    Вывоз строительного мусора.
    Монтаж распашных дверей — 4,8 кв. м.
    Монтаж дверной окладки — 10,4 пог. м.
    Установка дверной фурнитуры (замков, петель, ручек, защелок) — 2 комплекта.
    Ремонт наружных откосов (шпаклевка, грунтовка, окраска) — 10,4 пог. м.
    При замене электрических автоматов следует соблюдать предельную осторожность. Если поставить слабые предохранители, они будут постоянно отключаться, не выдерживая нагрузки. Если автоматы рассчитаны на большую мощность, они могут не сработать при небольших утечках тока, что, в свою очередь, способно привести к короткому замыканию. Правильно подобрать марку и мощность автоматов (особенно устройства защитного отключения) для целого этажа может только профессиональный электрик. Автор рекомендует дополнительно проконсультироваться со специалистами по этому вопросу — даже в случае, если суммарная мощность ранее используемых автоматических выключателей известна.

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

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

  3. alena575 Ответить

    Когда компания-заказчик приходит к исполнителю и заказывает «неосязаемое нечто», последний делает постный вид и просит предоставить техническое задание (бриф, описание, спецификация). Заказчик, полный энтузиазма, начинает выплескивать его на бумагу и это правильное начало, ведь техническое задание – замечательная штука!

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

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

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

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

    И, если притча кажется немного абсурдной и оторванной от нынешних реалий, читатель легко найдет массу современных примеров (допустим, среди многофункциональной электроники).
    Разумное применение
    ТЗ, со всеми плюсами и минусами – это, прежде всего инструмент, который требует правильного применения. Оно уместно в чистом виде, когда речь идет о сильно стандартизированном решении – например, поставках цемента известного состава и марки в четко оговоренные сроки.
    Возведение технического задания в принцип – разрушительно для продукта.
    Однажды автор встречался с Заказчиком, который утверждал, будто описание его задачи не допускает никаких разночтений и от исполнителя не зависит ничего. На его столе лежали предложения от разных подрядчиков и он выбирал самого бюджетного. При этом одет он был, отчего-то, не в самую дешевую одежду и, сидя в удобном кресле, пил ароматный пуэр.
    Мы призываем Заказчика помнить, что ТЗ – это полезная штука, но она описывает низший уровень качества решения. Хороший, по-настоящему хороший продукт требует к себе человеческого отношения на всех этапах создания. Любите его, не торопитесь с релизом, и он непременно получится восхитительным!
    Изображения взяты с сайтов: http://pt.wikinoticia.com http://cultofmac.cultofmaccom.netdna-cdn.com, http://www.popwuping.com
    Оригинальная статья.

  4. Kenas Ответить

    2Ртуть:
    Чето мне кажется что не надо так уж шибко относиться к неправильным на ваш взгляд словам в разговоре, как вам например фраза:
    “..торчки в обратной(летящей/свободной) заднице лезут, транзюк выходит, иглорез не помогает уже, нагрузка то дерганная, надо видимо по первичке трансил воткнуть или какую рекуперацию завести.. ”
    Да, если произнести ее например по телефону находясь в троллейбусе – явно чето нехорошее подумают, а так это немного извращенное но понятное для спецов (возможно не для всех) выражение:
    “Выбросы самоиндукции (торчки/пички) в обратноходовом преобразователе (летящей и тп заднице (подразумевается задний фронт импульса)) слишком большие, транзистор сгорает (“выходит” – имеется ввиду – выходит из строя), RC цепочка для гашения этих импульсов не помогает видимо придется защитный диод ставить (одна из первых их начала выпускать фирма Transil) или добавить обмотку для рекуперации (возвращению обратно в питание тех самых импульсов самоиндукции)”
    Насколько я знаю – жаргон (или арго, непомню что именно, поправте если ошибаюсь) использовалось раньше купцами при общении чтобы покупатель не понимал того что с точки зрения купца ему знать не положенно..
    И все эти выражения типа “привед я медвед” обозначают принадлежность человека к какой либо группе и в тоже время в какойто степени ограждают информацию от непосвещенных..
    О! Кстати, почему пишется запаснЫй а не запаснОй выход?

  5. Phantom1978 Ответить

    В определенных случаях 44-ФЗ допускает указание в конкурсной документации товарных знаков — в случае если при выполнении работ, оказании услуг предполагается использовать товары, поставки которых не являются предметом контракта. При этом обязательным условием является включение в описание объекта закупки слов «или эквивалент». Допустим, предметом контракта является строительство. Разумеется, в рамках строительства используются строительные материалы — например, цемент, клей, кирпич определенных марок. Но поскольку цемент, клей, кирпич не являются предметом контракта, то заказчик, закупая, по сути, работу с использование материалов, может предъявить требования к материалам, то есть указать, что ему нужен цемент, клей, кирпич определенной торговой марки. Но со словами «или эквивалент».
    Есть ряд исключений, когда слова «или эквивалент» не пишутся:
    В случае несовместимости товаров, на которых размещаются другие товарные знаки, и необходимости обеспечения взаимодействия таких товаров с товарами, используемыми заказчиком. Например, у заказчика есть сеть, которая работает только с конкретным оборудованием, и другое оборудование нельзя интегрировать в эту сеть, так как оно просто не будет работать.
    В случае закупок запасных частей и расходных материалов к машинам и оборудованию, используемому заказчиком, в соответствии с технической документацией на указанные машины и оборудование. Важно обратить внимание на то, что в документации к этому товару и оборудованию должно быть четко написано, что используются запасные части только этого производителя.
    В описании объекта закупки должны использоваться, если это возможно, стандартные показатели, требования, условные обозначения, терминология, касающаяся технических и качественных характеристик объекта закупки, которые установлены в соответствии с техническими регламентами, стандартами и иными требованиями.
    Ст. 33 44-ФЗ разрешает в описание объекта закупки включать спецификации, планы, чертежи, эскизы, фотографии, результаты работ, тестирования, требования в отношении проведения испытаний, методов испытаний, упаковки в соответствии с требованиями гражданского кодекса РФ, маркировки, этикеток, подтверждения соответствия (стандарту, ТУ или др.), процессов и методов производства и др.
    Документация должна содержать изображение поставляемого товара (если есть требование о соответствии поставляемого товара изображению).
    Документация должна содержать информацию о месте, датах начала и окончания, порядке и графике осмотра участниками закупки образца или макета товара, на поставку которого заключается контракт (при наличии требования о соответствии поставляемого товара образцу или макету товара). Например, если госзаказчик пишет в документации, что поставляемый товар должен соответствовать определенному макету, то он должен указать, по какому адресу расположен макет, чтобы все потенциальные участники закупки могли в определенное время ознакомиться с ним.
    Поставляемый товар должен быть новым. То есть речь идет о товаре, который не был в употреблении, в ремонте, не был восстановлен, у которого не была осуществлена замена составных частей и не были восстановлены потребительские свойства. Однако законодатель делает важную оговорку: «в случае если иное не предусмотрено описанием объекта закупки». То есть если заказчик указывает в техническом задании, что ему нужен товар не новый, то он может его получить.
    Документация о закупке должна содержать показатели, позволяющие определить соответствие закупаемых товара, работы, услуги потребностям заказчика (указываются максимальные (или) минимальные значения таких показателей, а также значения показателей, которые не могут изменяться. Но если будет указан конкретный показатель, под который попадает только одна марка, значит, будет нарушена конкуренция.
    При необходимости в техническом задании устанавливаются требования к гарантийному сроку товара, работы или услуги и объему предоставления гарантий их качества; к гарантийному обслуживанию товара; к расходам на эксплуатацию товара; к обязательности осуществления монтажа и наладки товара; к обучению лиц, осуществляющих использование и обслуживание товара.
    В случае определения поставщика новых машин и оборудования заказчик устанавливает в документации о закупке требования к предоставлению гарантии производителя и (или) поставщика данного товара и к сроку действия такой гарантии. Предоставление такой гарантии осуществляется вместе с данным товаром.
    В документацию о закупке нельзя включать следующие требования:
    к производителю товара (нельзя написать, например, что завод, производящий товар, должен работать на рынке 20 лет и располагать определенными мощностями);
    к участнику закупки (в том числе требования к квалификации, наличию опыта работы);
    к деловой репутации;
    к наличию производственных мощностей, технологического оборудования, трудовых и финансовых ресурсов.
    Исключения составляют случаи, когда возможность установления таких требований к участнику закупки предусмотрена настоящим законом.
    Закон ввел новые инструменты регламентации качества: техническое регулирование, технический регламент, международный стандарт, национальный стандарт, оценка соответствия, декларирование соответствия, знак обращения на рынке и др. Их заказчик тоже может использовать при формировании описания объекта закупки.
    Специфические вопросы регулируют другие законы. Так, например, при закупке пищевых продуктов госзаказчик должен ориентироваться на Федеральный закон от 02.01.2000 №29-ФЗ. Особенности описания объектов закупок по государственному оборонному заказу могут устанавливаться Федеральным законом от 29.12.2012 № 275-ФЗ.

    Антимонопольное законодательство

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

  6. belizar Ответить

    Рекомендации по ГОСТ
    Что с этим делать на практике
    Требования к системе в целом.
    ГОСТ расшифровывает перечень таких требований:
    требования к структуре и функционированию системы;
    требования к численности и квалификации персонала системы и режиму его работы;
    показатели назначения;
    требования к надежности;
    требования безопасности;
    требования к эргономике и технической эстетике;
    требования к транспортабельности для подвижных АС;
    требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы;
    требования к защите информации от несанкционированного доступа;
    требования по сохранности информации при авариях;
    требования к защите от влияния внешних воздействий;
    требования к патентной чистоте;
    требования по стандартизации и унификации;
    Несмотря на то, что основным, безусловно, будет раздел с конкретными требованиями (функциональными), данный раздел тоже может иметь большое значение (и в большинстве случаев имеет). Что может оказаться важным и полезным:
    Требования к квалификации. Возможно, разрабатываемая система потребует переподготовки специалистов. Это могут быть как пользователи будущей системы, так и IT-специалисты, которые будут нужны для ее поддержки. Недостаточное внимание к данному вопросу нередко перерастает в проблемы. Если квалификация имеющегося персонала явно недостаточна, лучше прописать требования к организации обучения, программе обучения, срокам и т.п.
    Требования к защите информации от несанкционированного доступа. Тут комментарии излишни. Это как раз и есть требования к разграничению доступа к данным. Если такие требования планируются, то их нужно расписать отдельно, как можно более детально по тем же правилам, что и функциональные требования (понятность, конкретность, тестируемость). Поэтому, можно эти требования включить и в раздел с функциональными требованиями
    Требования к стандартизации. Если существуют какие-либо стандарты разработки, которые применимы к проекту, они могут быть включены в требования. Как правила, такие требования инициирует IT-служба Заказчика. Например, у компании 1С есть требования к оформлению программного кода, проектированию интерфейса и пр.;
    Требования к структуре и функционированию системы. Тут могут быть описаны требования к интеграции систем между собой, представлено описание общей архитектуры. Чаще требования к интеграции выделяют вообще в отдельный раздел или даже отдельное Техническое задание, т.к. эти требования могут оказаться достаточно сложными.
    Все остальные требования менее важны и можно их не описывать. На мой взгляд, они только утяжеляют документацию, и практической пользы несут немного. А Требования к эргономике описывать в виде общих требований очень сложно, лучше их перенести к функциональным. Например, может быть сформулировано требование «Получить информацию о цене товара нажав только одну кнопку». На мой взгляд, это все-таки ближе к конкретным функциональным требованиям, хоть и относится к эргономике.
    Требования к функциям (задачам), выполняемым системой
    Вот он, тот самый главный и ключевой пункт, который будет определять успех. Даже если все остальной сделать на отлично, а этот раздел на «3», то и результат по проекту будет в лучшем случае на «3», а то и вообще проект провалится. Именно эти мы и займемся более детально во второй статье. Именно к этому пункту относится «правило трех свойств требований», о которых я говорил.
    Требования к видам обеспечения
    ГОСТ выделяет такие виды:
    Математическое
    Информационное
    Лингвистическое
    Программное
    Техническое
    Метрологическое
    Организационное
    Методическое
    и другие…
    На первый взгляд может показаться, что эти требования не важны. В большинстве проектов это действительно так. Но не всегда. Когда стоит описывать данные требования:
    Решения о том, на каком языке (или какой платформе) будет вестись разработка не принято;
    К системе предъявляются требования мультиязычного интерфейса (например, русский/английский)
    Для функционирования системы должно быть создано отдельное подразделения или приняты на работу новые сотрудники;
    Для функционирования системы у Заказчика должны произойти изменения в методиках работы и эти изменения должны быть конкретизированы и запланированы;
    Предполагается интеграция с каким-либо оборудованием и к нему предъявляются требования (например, сертификации, совместимости и пр.)
    Возможны другие ситуации, все зависит от конкретных целей проекта.

  7. Saawa Ответить

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

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

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

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

    В первом приближении главные требования к техническому заданию — это продуманность и полнота. Но, так как не во всех случаях составители способны соблюсти данные условия, были разработаны общепринятые стандарты разработки ТЗ.
    Во многих вакансиях на позицию системного аналитика или технического писателя можно встретить требование: знание ГОСТ 19 и ГОСТ 34. Что это такое?
    Из названия легко понять, что данные стандарты приняты на общегосударственном уровне и являются рекомендуемым образцом разработки технических заданий на территории России.
    Вместе с тем, надо помнить, что эти два ГОСТа имеют отношение именно к программным комплексам. То есть, в современном понимании — к сайтам, приложениям, системам автоматизации. ТЗ на размещение предприятия общественного питания в бюджетном учреждении придётся писать по другим правилам.

    ГОСТ


    Не пугайтесь, но ГОСТ 19 введён в 1980 году. Учитывая, что основа и парадигма программного обеспечения на протяжении долгого времени примерно та же, он пока не утратил своей актуальности. Это можно сравнить со строительством зданий. Конечно, меняются материалы и конструкции, но общие понятия — фундамент, стены, перекрытия — сохраняются.
    Согласно тексту Постановления, согласно которому принят данный стандарт, назначение его следующее: «Устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения».
    Само техническое задание должно содержать следующие пункты:
    Введение;
    Основания для разработки;
    Назначение разработки;
    Требования к программе или программному изделию;
    Требования к программной документации;
    Технико-экономические показатели;
    Стадии и этапы разработки;
    Порядок контроля и приемки;
    Приложения.
    Более новый стандарт — ГОСТ 34, но и здесь присутствует нюанс. Новее он только на 10 лет. То есть, введён с 1 января 1990 года.
    Формулировка назначения выглядит так: «Распространяется на автоматизированные системы (АС) для автоматизации различных видов деятельности (управление, проектирование, исследование и т. п.), включая их сочетания…».
    Текст технического задания строится по структуре:
    Общие сведения;
    Назначение и цели создания (развития) системы;
    Характеристика объектов автоматизации;
    Требования к системе;
    Состав и содержание работ по созданию системы;
    Порядок контроля и приемки системы;
    Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
    Требования к документированию;
    Источники разработки.
    Разумеется, за прошедшее время подходы были пересмотрены. Введены новые правила и рекомендации. Сами ГОСТы перешли в разряд базовой опорной точки, а конечный результат остаётся на усмотрение составителей. Тем не менее, при работе с госзаказчиками необходимо брать за основу именно ГОСТ.

    ISO/IEC/IEEE 29148

    Разработанный Международной организацией по стандартизации ISO, данный современный стандарт пригоден для использования помимо всего прочего в международных проектах.
    Последняя редакция — ISO/IEC/IEEE 29148:2018, но, к сожалению, она отсутствует в открытом доступе, поэтому возьмём за основу предыдущую, от 2011 года.

    По аналогии с ГОСТами, стандарт содержит два раздела. Один из них, SyRS — System Requirements Specification — определяет общие требования к построению систем, их принципам и характеру взаимодействия пользователя с ними. По похожей схеме составлен ГОСТ 34.
    SRS — Software Requirements Specifitaion — по аналогии с ГОСТ 19, содержит требования к конечному программному продукту.
    Общая схема строится следующим образом:
    Введение. Назначение продукта или системы, содержание, обзор функций и пользователей.
    Ссылки.
    Системные требования. Требования к юзабилити и производительности системы, состоянию, физическим характеристикам, окружению и безопасности, правилам. Для приложений — требования к внешним интерфейсам, к производительности, структуре БД, функциям и юзабилити.
    Тестирование и проверка. Процедуры тестирование по каждому из пунктов предыдущего раздела.
    Приложения. Термины, схемы, история правок.

    Порядок документирования требований

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

    Бриф

    В основном, уместен в контексте продуктов низкой и средней сложности. Например, небольшой сайт, воронка продаж или даже копирайтинг.
    Бриф обращён к заказчику и не предполагает жёстких финальных требований или детального описания результата. Выверенной должна быть только структура опросника. В него могут входить такие пункты, как:
    Цель и назначение продукта;
    Предполагаемый бюджет;
    Целевая аудитория.
    Вопросов на которые отвечает заказчик, может быть до 20-30, но не более, иначе это становится большой нагрузкой. Задача брифа в том, чтобы получить общее направление для обсуждения.
    Такой опрос удобно разместить на сайте, если он не сложный. Его можно запрограммировать или дать ссылку на Google формы. Либо просто разместите кнопку обратного звонка, чтобы задать вопросы и проконсультировать клиента прямо в режиме реального времени по телефону.

  8. LIMONik Ответить

    И многочисленными ТЗ от всяких девочек.
    Вы замечали, что перед словом “задание” есть слово ТЕХНИЧЕСКОЕ? И, скорее всего, оно как-то превращает то, что стоит за словом “задание”, в нечто чёткое, техническое.
    У меня уже пригорает от девочек-гуманитарок-руководительнец, которые “Так, я составила и отправила вам техническое задание, посмотрите, всё ли вам там понятно”.
    Это юридический документ, полностью покрывающий все требования заказчика.
    Рассмотрите его определение и описание (источник)
    Техническое задание — исходный документ на проектирование технического объекта (изделия). ТЗ устанавливает основное назначение разрабатываемого объекта, его технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования. Техническое задание является юридическим документом — как приложение включается в договор между заказчиком и исполнителем на проведение проектных работ и является его основой: определяет порядок и условия работ, в том числе цель, задачи, принципы, ожидаемые результаты и сроки выполнения. То есть должны быть объективные критерии, по которым можно определить, сделан ли тот или иной пункт работ или нет. Все изменения, дополнения и уточнения формулировок ТЗ обязательно согласуются с заказчиком и им утверждаются. Это необходимо и потому, что в случае обнаружения в процессе решения проектной задачи неточностей или ошибочности исходных данных возникает необходимость определения степени вины каждой из сторон-участниц разработки, распределения понесенных в связи с этим убытков. Техническое задание, как термин в области информационных технологий – это юридически значимый документ, содержащий исчерпывающую информацию, необходимую для постановки задач исполнителям на разработку, внедрение или интеграцию программного продукта, информационной системы, сайта, портала либо прочего ИТ сервиса.
    … и сравните его с той писюлькой, которую вам прислал ваш заказчик. Не выглядит ли это смешно?
    Для его составления выработано множество стандартов ГОСТ, ISO и т.д.
    ТЗ содержит:
    * раздел с терминами и определениями,
    * раздел с исходными данными,
    * постановку целей,
    * постановку задач,
    * результаты и т.д.
    Может отличаться точностью, но прежде всего – это юридический документ, утверждённый сторонами, и с которым можно, если что, пойти в суд.
    Если заказчик прислал ТЗ, то это в первую очередь означает, что он не понимает, что такое “ТЗ”, а прислал он “З”, или просто список пожелалок.
    Короче,
    Я ещё смирился с тем, что все технологию SWYPE называют словом Т9, хотя водят пальцем по клавиатуре, в которой клавиш уже давно не 9, и алгоритмы SWYPE и T9 отличаются как бокс от балета.
    Но игнорировать значение слова “ТЕХНИЧЕСКОЕ” и использовать его просто потому что оно прикольно звучит – я призываю прекратить.
    И да, крайне рекомендую к обзорному осмотру статью на хабре, описывающую ТЗ без эмоций:
    https://habr.com/ru/post/300420/

  9. Sedoy792 Ответить

    Будучи разработчиком, я постоянно работаю с техническими спецификациями клиентов и мой первый пост — это небольшой очерк, анализ такой вещи, как «техническое задание».
    Итак, когда компания-заказчик приходит к исполнителю и заказывает «неосязаемое нечто», последний делает постный вид и просит предоставить техническое задание (бриф, описание, спецификация). Заказчик, полный энтузиазма, начинает выплескивать его на бумагу и это правильное начало, ведь техническое задание – замечательная штука!

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

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

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

  10. FRG888 Ответить

    В большинстве крупных организаций внутрифирменные отношения «пользователь-отдел IT» неизбежны, особенно при создании рабочих приложений, необходимых пользователю на постоянной основе. Сложность этих отношений может быть обусловлена многими факторами, но чаще всего это непонимание, возникающее из-за того, что стороны говорят на разных «языках» с различной терминологией. Пользователь понимает, что он хочет, но не может это сформулировать, IT-специалист понимает пользователя, но опасается, что результат выйдет иным, чем видит это первый. Чаще всего проблема начинается с того, что именно пользователь не готов к диалогу: он требует «чтобы работало», «отчет одной кнопкой», «чтобы за минуту выводилось», «чтобы даты в Excel не вылезали» и прочее. При этом его совершенно не интересует, каким образом это делается и какие механизмы работают. На заявления о нагрузке на сервер, просьбы нарисовать схему желаемого результата, обсудить пути решения пользователь не реагирует, полагая, что настоящий профессионал со всем справится. Результаты такого непонимания вредят всему производственному процессу: затягиваются сроки решения задач, возникают ошибки и пробелы в системах, которые нужны пользователю, страдает перегруженный неверными действиями сервер, скорость работы снижается.
    Одним из способов разрешения такого конфликта является написание задания на проект – технического задания, которое предполагает полное и точно изложение требований внутрифирменного заказчика и является своеобразной инструкцией для IT -специалиста. Однако не каждый пользователь способен изложить свои мысли грамотно и доходчиво.
    Приведу несколько советов для написания корректного задания пользователем, по которому можно работать и которое ложится в основу отношения между заказчиком решения и специалистом.
    1. Прежде, чем составлять техническое задание, пользователь должен понять, что именно он хочет получить. Следует определить цель задания, ключевые особенности желаемого результата, нарисовать (написать, создать таблицу) для себя желаемый выход работы.
    2. Собрать документацию, согласно которой вы выполняете работу, для которой необходимо приложение (программа). Прочитать ее внимательно, с карандашом, отмечая особенности и тонкости.
    3. Следует понять, какие параметры следует задавать на входе, какова периодичность работы с желаемой программой (отчетом, приложением, утилитой), сколько данных примерно будет получаться на выходе и все ли они нужны (к примеру, если вам нужна сумма выручки от продаж пяти категорий изделий по категориям без наименований, не стоит требовать создания отчета в миллион строк с указанием каждой продажи с детальными характеристиками). Далеко не каждому специалисту необходима максимально детализированная информация, обработка которой создает значительную нагрузку для вычислительных систем.
    4. Подробно описать необходимую информацию, указать ее особенности, исключения, необходимый уровень детализации. Следует продумать все мелочи: формат чисел, округление, доли, ставки и проч.
    5. Избавиться в техническом задании от расплывчатых описаний, лишних слов, слов-паразитов. Проверить пунктуацию – зачастую ошибки в ней искажают смысл задания. Задание на проект – это документ и лексика в нем должна быть соответствующая. Однако не следует стараться написать все на техническом языке, если вы не владеете терминологией на должном уровне.
    6. Обсудить написанное задание с непосредственным исполнителем, попытаться разрешить все вопросы, внимательно прислушиваясь к мнению собеседника. Не стоит забывать, что вы свою сферу деятельности знаете лучше и только вы можете точно объяснить, какой инструмент вам необходим для эффективно работы. IT-специалист знает свое дело и не обязан знать нюансы работы каждого отдела в организации.
    7. Передать задание в работу за разумный срок до окончательной реализации, чтобы была возможность протестировать результат и исправить возможные ошибки.
    8. Если ваши подчиненные также будут пользоваться созданным приложением, постарайтесь им самостоятельно объяснить особенности работы с приложением – это избавит IT-специалиста от необходимости сто раз объяснять одно и то же.
    9. Помните, что ваше задание будет служить справочником для вас — в нем всегда можно посмотреть описание информации, вспомнить забытое требование.
    Конечно, только лишь умение писать техническое задание не избавит от всех проблем, но оно позволит отношениям с IT-отделом перейти в серьезную плоскость сотрудничества, позволит пользователю повысить свою техническую грамотность и получить требуемое, а специалиста по IT избавит от ряда проблем и ненужных вопросов.

Добавить ответ

Ваш e-mail не будет опубликован. Обязательные поля помечены *