Полезная информация:

Что важнее смета или техзадание

Что важнее техзадание или смета

Составлен договор подряда на выполнение отделочных работ в квартире, в техническом задании указаны потолки ГКЛ, а в смете они просчитаны не были, по различным причинам. Теперь заказчик отказывается оплачивать установку данных потолков ГКЛ. и использованные материалы. Кто прав? Кто выиграет в суде данный спор?

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

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

Итак, ТЗ включает в себя следующие сведения:

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

Обязательно отметьте следующие пункты:

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

С какими трудностями можно столкнуться, составляя техзадание?

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

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

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

Фундамент

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

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

2. Стены

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

— сборка сруба, прокладка утеплителя;
— врезка лаг;
— устройство черновых полов.

3. Кровля

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

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

4. Погрузка и доставка материалов.

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

В Аукционной документации: Раздел III. ТЕХНИЧЕСКАЯ ЧАСТЬ на одном листе 11 пунктов. Раздел IV. ПРОЕКТ ДОГОВОРА "1.2. Неотъемлемой частью настоящего договора является утвержденная и согласованная сторонами смета на выполняемые работы." При этом, "Приложение №1 к Договор № ____от_____ 2013г. Смета На выполнение работ по капитальному ремонту отделений 17, 18, столовой ГУЗ «Саратовская областная психиатрическая больница Святой Софии», находящиеся по адресу: г. Саратов, Песчанно-Уметский тракт, б/н, 2км. " — пустая форма. Также есть две папки: Заключение экспертизы и Смета. Заключение экспертизы на три объекта и Смета на 29 пунктов. Заказчик настаивает что смета к договору должна быть на 29 пунктов. Если следовать логике Заказчика, то когда на аукционе на нулевой цикл приложен весь проект и я не задал вопрос что там делают лишние листы, то по окончании аукциона я обязан все здание построить?

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

(17.10.2013, 15:19)———————————————Я понимаю что один пункт дефектовки может превратиться в несколько пунктов сметы. Я же не об этом. Я о том, что если в дефектовке 29 пунктов, а я дал согласие на выполнение только одиннадцати из них, то меня или должны были не допустить, или, если уж допустили, то не имеют права требовать с меня делать все 29 пунктов. К аукционной документации могут прилагать совершенно разную ПСД, и, как я понимаю, обязанность подрядчика выделить, что из приложенной ПСД соответствует Техзаданию Аукциона, а что не соответствует, внести своё понимание в первую часть, отправить и ждать решение Заказчика. Мне при аукционе на установку окон в здании Мирового суда (

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

15 млн), окна, электрика, отопление/утепление и т.п. Мало ли что будет приложено! Да хоть Генплан и выписка из Госреестра. Если у меня есть техзадание к Аукциону, то я и работать обязан по техзаданию, и на основании техзадания должна быть сделана смета Заказчиком.

Что за народ пошел. сначала выигрывают аукцион, и только потом смотрят, что там в этом аукционе было ) По теме. Тут явное несоответствие, обоснование начальной цены контракта (смета) не соответствует предмету аукциона, указанному в технической части. Это может быть поводом для признания этого аукциона недействительным. Заказчик скорее всего ошибся в составлении техзадания — просто "пропустил" последний лист дефектовки. Ред, у вас есть выбор, либо выполнить все работы по смете, либо подать на признание аукциона недействительным. Возможно ещё есть вариант выполнить работы по техзаданию, но получить меньшую сумму, исключив из аукционной сметы (с учетом аукционного снижения цены) работы, которых нет в техзадании. Использовать техническую ошибку заказчика в свою пользу здесь скорее всего не получится.

Ничего подобного. Просто таким образом Заказчики "заряжают" аукционы. Выиграл свой — делаем по техзаданию, выиграл чужак — будем прессовать по смете. Это обычная коррупция. Я выиграл за реальную себестоимость этих 11 пунктов и не имею возможности делать работы сверх техзадания. У госзаказчиков десятки дармоедов сидят и за госсчёт документацию проверяют/экспертизируют, в комиссиях по пять-десять человек. И кто поверит в эти "случайности"? Допустили к аукциону при моём согласии на работы по 11 пунктам, не отклонили — будьте добры и смету мне только на эти работы. Когда я влетаю на аукционах никакое государство мне навстречу не пойдёт, будет драть как липку, или делай — или РНП, так что каков привет, таков ответ. Вот меня и интересует: — "Что говорит Закон?"

Ред, закон говорит., что этот аукцион недействителен, не пожалуетесь Вы в ФАС, пожалуются те, кто проиграл.

сметная документация является неотъемлемой частью технического задания:'( , так что читать нужно было аукционную документациюB) . и заказчики ничего "не заряжают для своих" , я бы сказала, смета — основной документ техзадания. И выполнять-принимать работы на основании именно тендерной сметы. кстати и заказчика потом проверять будут в первую очередь сравнивая тендерную смету с представленными КСками

А смета составляется на основании дефектной ведомости. Четко написано в аукционной документации п. 1.12.2 , 1.13 Техническое задание является главным основанием для выполнения работ. Заказчик будет выкручиваться. Кто кого.

смета же была представлена в аукционной документации^_^ какие вопросы к заказчику?Добавлено (13.11.2013, 14:41)——————————————— и кто сказал, что техническая часть и дефектная ведомость это одно тоже?Добавлено (13.11.2013, 14:42)———————————————не посмотрели, не просчитали, теперь заказчики виноваты

Migulka посмотрите внимательно на первом листе сметы ОСНОВАНИЕ- дефектная ведомость. А дальше в смете преднамеренное завышение объема работ и стоимости.

Alexx9, основание дефектная ведомость, кто спорит)) но аукционную документацию смотреть нужно внимательно. Смета так же ней прилагалась., так как является ее неотъемлемой частью^_^ и подобные вопросы задавать на этапе размещения заявки, после проведения торгов))Добавлено (13.11.2013, 15:14)———————————————могут не подписывать контракт, и вперед реестр недобросовестных поставщиков)) следующий за ними в торгах, заключит контракт, может он аукционную документацию оконца прочел

Alexx9, распечатала и смету и дефектовку: итак, объемы совпадают, виды работ тоже (единственное в дефектовке демонтаж окон идет как "разборка деревянных заполнений проемов оконных с подоконными досками, а в смета он разбит на демонтаж оконных коробок+ снятие оконных переплетов+ снятие подоконных досок). остальные страшные "добавленные пункты", чтоб разорить несчастного "чужого" подрядчика это материалыДобавлено (13.11.2013, 15:31)———————————————Alexx9, кстати демонтаж окон в соответствии с расценкой дефектовки был бы чуть дешевле, чем разборки коробок-переплетов-досок

Migulka в дефектой ведомости 11 пунктов в смете №20,21,17,16,15 откуда взялись позиции.Все БАСТА.

Alexx9, хотя а аукционной документации ведомость объемов загружена только первая страница. но сметы и дефектный акт приложены. вопрос — почему смету не изучили, хотя бы из праздного интереса — какими расценками работы берутся да и по ведомости видно, что работы обрываются, так сказать, на полпутиДобавлено (13.11.2013, 15:46)———————————————Alexx9, вы сейчас говорите про ведомость объемов работ посмотрите дефектную ведомость — она в одном архиве со сметойДобавлено (13.11.2013, 15:53)———————————————Alexx9, итак что имеем на выходе- опечатку в вордовском файле аукционной документации + абсолютно дефектную ведомость и смету, которые так же были представлены для всеобщего обозрения. вывод- внимательно изучать ВСЮ аукционную документацию:ok:

Да я согласен с Вами надо быть внимательным.

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

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

Благодаря консультациям с другого форума мы нашли правильное решение. Работы = техзадание=забота подрядчика. Смета = ОНМЦ=забота заказчика.

Alexx9, сообщение 12 , сам себя цитировать это сильно . а нельзя ли номера статей ГК, ФЗ . как то получается правильное решение=выгодное ред решение .

В том,что техзадание и смета различаются по пунктам, нет ничего страшного (при определенном раскладе). Например, в смете отдельно может быть прописан используемый материал или конкретные работы. Но, если имеются серьезные несоответствия, то в таком случае следует подавать запрос на разъяснения положений аукционной документации и требовать, чтоб Заказчик привел документацию в соответствии с законом. ДействияУРЗ, если сметы и ТЗ существенно различаются — подробнее по ссылке:

AndrewTTT, Ну еще 12 дней надо было подождать.. Техзадание -это протокол намерений. Проект (ВОР)-воплощение в более приближенные к строительным нормам техзадание . Смета- финансы-за которые вы получаете деньги . Несоответствие -это нормально. Но только после всех согласований.

Aleksej, разговаривать с ботами — все-равно что заниматься самоудовлетворением.

iunicreditbank.ru

Так что же такое «Техническое Задание»? / Habr

Данный текст был создан сугубо ради существования постоянной ссылки, которую бы сам автор, да и все вы — могли бы смело отправлять своим будущим заказчикам, коллегам, родственникам и знакомым в виде стандартизированного ответа на вопрос: «А надо ли мне ваше ТЗ и вообще что это?»

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

Проблема

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

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

Переводим на понятный язык

1) ТехЗадание — оно ставит задачу. А значит оно должно идти перед прототипом, скетчем, тестом, дизайн-проектом, потому что любой майндмеп, диаграмма потоков данных, архитектура — это уже выполнение некой задачи, это ответ на вопрос. А до того, как сам вопрос еще не задан, не сформулирован и не подписан всеми сторонами — любой ответ будет априори неправильным, не так ли? Итак, начало любой работы над любым проектом — это постановка задачи, а не судорожный поиск набросков десятка вариантов ее решения.

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

3) Как же вам понять, решает ли предложенная дизайн-концепция или интерактивный прототип, а то и готовый к употреблению сайт — вышеизложенную задачу бизнеса? Ничего не поделаешь, придется опять вернуться к определению: «определяет… ожидаемые результаты и сроки выполнения. То есть должны быть объективные критерии, по которым можно определить, сделан ли тот или иной пункт работ или нет». То есть ТЗ без четких измеримых показателей в рублях, секундах, тонно-километрах или градусах Цельсия — быть не может. Бриф может, или прототип, или еще любая абсурдная бумажка, но только не ТехЗадание.

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

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

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

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

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

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

Итак: Что делаем? Для чего? Как поймем, что сделали? Сколько стоит каждый пивот? — написанные на листочке ответы на все эти вопросы и являются «серебряной пулей», способной вытащить даже самый провальный проект.

Контрольные вопросы

А здесь перечислю ответы на самые часто встречающие вопросы от заказчиков:

1) Так что, на написание ТехЗадания может еще и официальный ГОСТ есть? — Да, даже несколько.

2) А что, в ТехЗадание не входит описание нужных страниц, количества кнопок, используемых библиотек, гайдлайнов и т.д.? — В само ТЗ нет, но в Приложения вы можете все это поместить, разумеется скорректировав все это с вышеописанными целями, ограничениями и способами дальнейшей оценки достигнутого результата. Размещайте хоть весь будущий контент, хоть описание типовых персонажей — но не вместо четкой постановки задачи, а уже после нее.

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

4) Вот вы и Википедия пишете, что ТЗ создается заказчиком. Но я не умею\мне некогда\просто не хочу его делать сам. Как же быть? — Отдать разработку ТЗ третьей стороне, вполне знакомой с вашим бизнесом, его задачами, целевой аудиторией и потребностями, и в то же время досконально осведомленной о всех этапах веб-разработки. Эта третья сторона станет неким «веб-нотариусом», то есть гарантом того, что исполнитель не занизит нужные вам показатели или не затянет сроки, и что заказчик установит достижимые метрики и на итоговой приемке не будет субъективно оценивать созданный продукт, на ходу изменяя зафиксированные ранее требования.

5) И что, если ТЗ является юридическим документом, то я потом могу засудить аутсорсера, не заплатить ему, заставить переделать все в десятый раз? — Если документ составлен правильно, указаны цели и методология оценки их достижения; если документ подписан сторонами и упомянут в Договоре (само ТехЗадание договором не является) — то конечно же сможете. А вот с обычным брифом, прототипами, арт-креатив-макетом, Безопасной сделкой на FL — уже нет.

6) Мне говорят, что работа будет вестись по какому то то ли скраму, то ли аджайлу; а значит архаичное ТЗ мне больше уже не нужно. Это так? — Посудите сами: вам называют непонятное слово, явно что-то маскирующее и вот уже на основании незнакомого вам термина предлагают отказаться от юридически грамотного и наполненного целями и метриками документа. Сам же agile никаких целей вроде «достичь не менее 10 000 посещений к концу года», или «достичь цифры более 25 заказов с сайта через месяц» — установить не может, это просто способ проведения совещаний и новой организации нерадивых сотрудников. Задумайтесь несколько раз: «А не пускают ли вам пыль в глаза?». На самом деле никакому новомодному скраму профессиональное ТЗ повредить не может, а вот помочь — обязательно.

habr.com

эпический опыт конкурсов и пара баек / КРОК corporate blog / Habr

Широко известный пример неточно поставленного ТЗ

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

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

Было сложно — не то слово. В длинном перелёте я читал ТЗ на 20 страниц. В нём была такая особенность: если читать его бегло, то может показаться, что оно написано правильно и точно. Но если начать копать в детали инженерной реализации, то всплывало сразу много нежданчиков. Некоторые требования подпунктов, вроде 3.2.5 и 4.8.2.9, могли противоречить друг другу или быть просто взаимно невыполнимыми в реальном мире.

Почему нельзя согласовать ТЗ сразу?

Не секрет, что на конкурсах и тендерах крайне редко встречается достаточно полное техническое задание (или хотя бы детальные критерии приёмки, или просто внятные техтребования). Любой размытый пункт документации может обеспечить вам невероятное количество сюрпризов и увеличение работ на порядок. Вот буквально пара примеров из реальных документов, по которым надо было как-то оценивать объём работ и подписываться:

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

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

Экологическое равновесие

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

Что же происходит дальше? Дальше наступает интересное экологическое равновесие.

В плохом случае:

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

В обычном случае, когда «точно по ТЗ» проект явно не заработает:

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

В итоге все всё прекрасно понимают и договариваются. Конечно, бывают отдельные проекты, где крупный заказчик своим ТЗ может буквально свести с ума интегратора. Только он прекрасно понимает, что если так сделает, больше этот интегратор к нему в конкурсы не придёт. А по многим работам в стране всего 2-3 компании, которые вообще могут потянуть такое, чисто по сложности и объёму проекта. Оставаться в конце один на один с последней страшно, уже исполнитель будет условия диктовать.

Например, вот проект. Была в ТЗ строчка: «Систему надо поставить на мониторинг». Это вылилось в отдельный проект: невозможно было ни оценить трудозатраты, ни спланировать. А заказчик всё видел иначе. У него есть внутренний регламент, исторически сложившийся. Дальше начинаются так называемые «тёрки». С одной стороны: «Мы вам сделаем по ТЗ», с другой — «Мы так не примем». Понятно, что обе стороны в той или иной степени правы, и дело доводить до конфликта не хотят: с одной стороны, повторюсь, суд и «получите, что хотели», с другой — потраченные впустую деньги и время. Никому это просто не надо.

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

Что делать, если совсем плохо

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

Сначала я разбил ТЗ на несколько документов. Дело в том, что они согласовывали его всем коллективом руководителей, поскольку опасались ответственности. И каждый раз находили что-то новое. Разбитый на части документ согласовывался по подразделениям, и дело наконец-то пошло. Начали разбираться не «что вы написали», а «что вы хотите». И дальше: «что вы хотите — невозможно и не нужно, давайте лучше вот так» — потихоньку удалось прийти сначала к реализуемым требованиям, а потом и к компромиссу.

Где-то решали быстро, где-то предлагали сдавать по их ТЗ и смотреть, что получится. Заказчик увидел, что работы реально идут, согласился, что так правильно, и не давил, пока всё шевелилось. В общем, вырулили.

Личные встречи и выезды

Ещё одно весёлое попадалово — это если заказчик хочет встречаться по каждому чиху. Особенно приятно, когда это нефтянка с Дальнего Востока. В одном проекте была традиция — любую мелочь обсуждали раз в неделю на совещании. Собиралось 12 человек от компании, 5 человек от производителя железа и нас трое. И безопасник. В конце концов, смогли тоже побить на части и перевести на телефонную конференцию. По телефону мужики друг друга не видели, пятнице не радовались, и потому совещания шли в 3 раза быстрее.

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

Опять же, личные встречи нужны, чтобы решать сложные вопросы. Любое серьезное решение или этап — встречаться. По телефону не работает.

Железо

Один раз участвовали в конкурсе на работы и поставку оборудования, не выиграли. Но компания-победитель всё равно наняла нас на работы на субподряд: в стране просто больше не было спецов, тема очень специфическая. Ну хорошо, мы не гордые, сделаем только работы. За две недели до сдачи выясняется, что генподрядчик заказал не то железо. Точнее, то, но не в той конфигурации. Мы-то знали, какие комментарии писать к заказу и какие конкретно волшебные слова говорить поставщику. А здесь, грубо говоря, одну букву в модели перепутали. В России такого железа просто физически нет. До сдачи — 2 недели.

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

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

Работа с иностранцами

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

Мы отвечаем за железо, коллеги иностранные — за ПО. Предлагаем им: давайте пропишем чётко, что входит в состав работы, где зона ответственности, сделаем нормальное ТЗ: что делаем, какой результат, чтобы потом протестировать и штатно сдать. Они: «Да зачем это надо? Там же вот описание работ!» — а там документ на две страницы в духе: «Наш профессиональный инженер приедет и всё сделает, не волнуйтесь». И ещё добавили: «У нас на сайте есть описание системы — вот». Подписались они в итоге без детального ТЗ. Внедряли как есть. Систему они реально подписали и закончили только через 2 года (два поколения системы сменилось), специально под этого заказчика дорабатывали часть функционала.

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

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

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

Альтруизм и отвага

Ещё одна черта, наверное, чисто российских проектов — это «Чип и Дейл спешат на помощь». Редко, но бывают эпохальные вещи, например, прямо к сдаче железо выходит из строя. Но альтруизм и отвага делают нас непобедимыми. Там, где иностранный подрядчик рукой бы махнул и начал бы стандартную замену через вендора, мы можем и на уши всех поднять, и на пороге у их гендира объявиться где-нибудь в Швеции, или ещё хуже — с паяльником залезть в железку и починить. Конечно, бывает, не помогает, но в целом срабатывает. Правда, винтик лишний всегда остаётся.

Регламент заказчика

Самые сюрпризы начинаются после фразы: «Работы должны быть выполнены или согласованы в соответствии с регламентом заказчика»:

Регламент могут не приложить к документации конкурса. Ищите сами.
Регламент может меняться: например, если это требования к инженерке стадионов по европейскому стандарту, может оказаться, что к концу работ европейцы приняли новые требования.
Была в одном финансовом учреждении служба безопасности, которая даже регламент не показывала. Просто приходил безопасник и говорил: «Так нельзя. Почему — не скажу». И уходил.
Бывают внутренние требования вроде: «Жить в Москве не менее 10 лет» или «Не привлекать к работам иностранных граждан».
В банках часто есть целый регламент на основании документов Банка России, их могут и не указать как требования в конкурсе — для них это само собой разумеющееся. Доходит до договора и реализации — появляется вот эта штука со словами: «А вот еще требования к системе». А там разделение прав, администрирование, требования к персоналу по сертификатам.
Иногда бывают «забытые» требования по бекапам, обучению не менее 10 специалистов и так далее, всё это надо каждый раз выспрашивать.

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

Но часто ситуация хуже: состав документации не обозначен, заказчик ссылается на ГОСТ. А там, например, три периода тестирования — предприёмка, опытная эксплуатация, финальная сдача в промэксплуатацию. У некоторых же заказчиков финальная сдача бывает почему-то до опытной эксплуатации, например.

Иногда случается, что заказчик просто ошибается в ТЗ. Привозим оборудование, а его ставить некуда, места просто нет. Что делать? Опять искать компромисс.

План приёмки

Самое главное — не поленитесь и составьте хотя бы простой план приёмки. Методика испытаний — это не лишняя вещь. Написать стоит. На приёмке заказчик часто понимает, что что-то ещё не протестировал и предлагает поменять программу тестирования. Лучше всё сразу предусмотреть. Снимает массу конфликтов и очень помогает в банках.

Лет десять назад было, например, так. Наши инженеры сдавали систему, документации — мизер, требований нет. Дальний Восток, наши: «Акты подпишите, и мы поедем». Заказчик попался дотошный, но адекватный. Говорит: «Вы сейчас в вертолёт сядете, а я тут один останусь с этой. Давайте по-настоящему проверим». Ну, на ходу придумывали методику тестирования, показывали, что и как работает. Подписали. Чуть не остались гостить на лишнюю неделю.

Или вот был случай, сдавали систему. Всё подписали, все счастливы. И тут выясняется, что безопасники не хотят пользоваться так, как айтишники требования написали. Где они были, когда проект писался, непонятно. Мы пошли навстречу, помогли поверх требований, нашли вариант, который всех устраивает. Нам в тот же день пошли на компромисс на другом сложном участке. Так и работает.

В целом

Вообще, ситуация меняется: за последние 8 лет заказчики очень повзрослели, стали серьёзнее относиться к делу. Раньше было вообще без бумаги, даже схему расстановки часто могли не передать. Теперь всё пишется. Мы тоже нахватались грабель, стали сами настаивать, чтобы в проекте была необходимая документация, это ведь и наша защита тоже. Цель — чтобы все всех понимали.

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

Но надо сказать, если бы мы предлагали лет 10 назад так, как сегодня работать, нас бы ни один заказчик не стал слушать. Культуры не было, бесполезно. Помню, было даже так в те дремучие годы: программу приёмки подписали. Дошло до дела, заказчик говорит: «Надо иначе». Мы: «Вот документ подписан вами». Он: «Да выкиньте его, нам надо иначе!»

habr.com

Техническое задание — Википедия

Материал из Википедии — свободной энциклопедии

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

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

Техни́ческое зада́ние (ТЗ, техзада́ние) — документ, содержащий требования заказчика к объекту закупки, определяющие условия и порядок ее проведения для обеспечения государственных или муниципальных нужд, в соответствии с которым осуществляются поставка товара, выполнение работ, оказание услуг и их приемка. Используется в качестве исходного документа, в котором учитывается основное назначение закупки товаров, работ, услуг, их характеристики, задание заказчика, описание первичных данных, целей и задач закупки, сроков поставки, выполнения работ, оказания услуг, требований к товару, работам, услугам, их результатам, к гарантиям, описание объекта закупки, объем закупаемых товаров, работ, услуг, формы отчетности, обоснование требований к товару, работам, услугам, эквивалентные показатели, экономические требования, а также специальные требования^[1]^[2]^[3].

Техническое задание используется в машиностроении, производстве и бизнесе для того, чтобы поставщики, покупатели и пользователи материалов, продуктов или услуг понимали и согласовывали все требования^[4].

Техническое задание в разных странах[править | править код]

Египет[править | править код]

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

Хорошев А.Н. Введение в управление проектированием механических систем: Учебное пособие. — Белгород, 1999. — 372 с. — ISBN 5-217-00016-3.

ru.wikipedia.org