Что такое техзадание в строительстве

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

О чем эта статья?

Меня часто спрашивают: «Как правильно разработать техническое задание для автоматизированной системы?». Аналогичная тема постоянно обсуждается на различных форумах. Этот вопрос настолько широкий, что ответить в двух словах никак нельзя. Поэтому я решил написать большую статью на данную тему. В процессе работы над статьей я понял, что уложить все в одной статье не выйдет, т.к. получится под 50 страниц и решил разбить ее на 2 части:

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

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

Организация строительства 6: Техническое задание

• Клиент имеет своих специалистов со своими взглядами, и они предъявляют конкретные требования к Техническому заданию;
• Техническое задание разрабатывается для собственных разработчиков (клиенту все равно);
• Техническое задание разрабатывается для передачи подрядчику (т.е. группе программистов, находящихся за штатом компании, или отдельному специалисту);
• Между компаний и клиентом возникает непонимание в вопросе полученного результата, и компания вновь и вновь задается вопросом: «Как надо разрабатывать Техническое задание?». Возможно, последний случай кажется парадоксом, но это правда.
• Возможны и другие, реже встречающиеся варианты;

• А почему нельзя разрабатывать Техническое задание всегда одинаково?
• Существуют ли какие-то стандарты, методики, рекомендации? Где их взять?
• Кто должен разрабатывать Техническое задание? Должен ли этот человек обладать какими-то специальными знаниями?
• Как понять, хорошо составлено Техническое задание или нет?
• За чей счет должно оно разрабатываться, да и нужно ли оно вообще?

Как ни странно, проблемы у всех одинаковые! У всех бывают как успешные документы (и проекты), так и совсем бестолковые (исключение, пожалуй, составляют Технические задания, разработанные еще во времена, когда не было персональных компьютеров, но там были совсем другие условия). Почему так получается?

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

Зачем нужно техническое задание на строительство или ремонт? Будет полезно и строителям и клиентам !

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

Да, действительно существуют ГОСТы и стандарты, в которых предприняты попытки регламентировать эту часть деятельности (разработки программного обеспечения). Когда-то все эти ГОСТы были актуальны и активно применялись. Сейчас существуют разные мнения по поводу актуальности данных документов.

Одни утверждают, что ГОСТы были разработаны очень дальновидными людьми и до сих пор актуальны. Другие говорят, что они безнадежно устарели. Возможно, кто-то сейчас подумал, что правда где-то по серединеJ. Я бы ответил словами Гете: «Говорят, что между двумя противоположными мнениями находится истина. Ни в коем случае!

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

Заметим, что в ГОСТе явно не дано даже определения, сказано лишь: «ТЗ на АС является основным документом, определяющим требования и порядок создания (развития или модернизации — далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие».

Если кому-то интересно, о каких ГОСТах я говорю, то вот они:

• ГОСТ 2.114-95 Единая система конструкторской документации. Технические условия;
• ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению;
• ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

Отличное определение, полностью раскрывающее суть. Впрочем, требования ГОСТа направлены как раз на раскрытие этого определения. Я ни в коем случае не критикую требования ГОСТа, я просто утверждаю, что их там явно недостаточно, чтобы разработать эффективное Техническое задание.

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

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

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

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

Среди них есть просто виртуозы своего дела, у которых есть чему поучиться и нужно это делать. Иначе, споры о том, «Как разработать техническое задание» будут продолжаться бесконечно. Однако, я увлекся лирикой…

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

Именно основное, но единственное. Настало время взяться за главное: разложить все «по полочкам», как и обещал.

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

• Требования в функциональности;
• Требования к безопасности и правам доступа;
• Требования к квалификации персонала;
• …. И т.д. Вы можете прочитаете о них в упомянутом ГОСТе (а ниже я их тоже рассмотрю немного подробнее).

Про виды требований я сказал, а что же со свойствами? Если виды требований могут быть различными (зависит от целей проекта), то со свойствами все проще, их 3:

1. Требование должно быть понятным;
2. Требование должно быть конкретным;
3. Требование должно быть тестируемым;

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

• на каком языке (в смысле сложности понимания) должно быть написано техническое задание?
• Должны ли быть описаны в нем спецификации различных функций, алгоритмы, типы данных и прочие технические штуки?
• А что такое техническое проектирование, о котором, кстати, сказано и в ГОСТах, и как оно связано с Техническим заданием?

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

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

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

Технический проект – это документ, который предназначен для технической реализации требований, сформулированных в Техническом задании. Как раз в этом документе описываются структуры данных, триггеры и хранимые процедуры, алгоритмы и прочие штуки, которые потребуютсятехническим специалистам.

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

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

И чем это заканчивается? Как правило, такое ТЗ утверждается, затем реализуется, а в 80% случаев потом совсем не соответствует факту выполненных работ, т.к. много чего решили изменить, переделать, неправильно поняли, не так думали и т.д. и т.п. А потом начинается сериал про сдачу работ. «А вот тут не так как нам надо», а «это у нас работать не будет», «это слишком сложно», «это неудобно» и т.д. Знакомо. Вот и мне знакомо, пришлось набить шишек в свое время.

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

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

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

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

А нужно ли вообще техническое задание? А Технический проект?

Не перегрелся ли я? Разве такое возможно, вообще без Технического задания? Представьте себе возможно (точнее, встречается), и у такого подхода есть много последователей, и их число увеличивается. Как правило, после того, как молодые специалисты начитаются книг про Scrum, Agile и прочие технологии быстрой разработки.

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

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

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

А что же с Техническим проектом? Данный документ весьма полезный и не утратил свою актуальность. Более того, часто без него просто не обойтись. Особенно, если речь идет о передаче работ по разработке на сторону, т.е. по принципу аутсорсинга. Если этого не сделать, есть риск узнать много нового о том, как должна выглядеть система, которую Вы задумалиJ.

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

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

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

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

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

Продолжим исследование вопроса: «Какие требования включать в Техническое задание?»

Формулирование требований к информационной системе. Структура Технического задания

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

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

Как и любую деятельность, формулирование требований можно (и нужно) разделить на этапы. Всему свое время. Это тяжелый интеллектуальный труд. И, если относится к нему с недостаточным вниманием, то результат будет соответствующий. По экспертным оценкам, стоимость затрат на разработку Технического задания может составлять 30-50%. Я придерживаюсь такого же мнения.

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

Например, если речь идет о разработке на классическом языке типа С++, то без детального технического проектирования тут не обойтись. Если речь идет о внедрении системы на платформе 1С, то тут с проектированием ситуация несколько иная, как мы видели выше (хотя, при разработке системы «с нуля», она проектируется по классической схеме).

И так, ГОСТ рекомендует следующие разделы:

Раздел 1. общие сведения.

Что с этим делать на практике

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

Это не актуально, но можно и указать, если требуется

указывают, кто (какие организации) будут работать над проектом. Можно указать и их роли.

Можно вообще удалить этот раздел (достаточно формальный).

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

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

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

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

Что с этим делать на практике

С одной стороны с назначением все просто. Но желательно формулировать конкретно. Если написать что-то вроде «качественно автоматизировать складской учет в компании Х», то потом можно долго обсуждать результат при его завершении, даже независимо от хорошей формулировки требований. Т.к. Заказчик всегда может говорить, что под качеством он имел ввиду нечто иное.

В общем, нервов можно попортить друг другу много, а зачем? Лучше сразу написать примерно так: «Система предназначена для ведения складского учета в компании Х в соответствии с требованиями, зафиксированными в данном Техническом задании».

Цели – это безусловно важный раздел. Если уж его включать, то надо уметь эти цели формулировать. Если у Вас трудности с формулировкой целей, то лучше вообще исключить данный раздел. Пример неудачной цели: «Обеспечить быстрое оформление документов менеджером». Что такое быстрое?

Это можно потом доказывать бесконечно. Если это важно, то лучше переформулировать данную цель так: «Менеджер по продажам должен иметь возможность оформить документ «Реализация товаров» из 100 строк за 10 минут». Подобная цель может появиться, если, например, в настоящее время менеджер тратит на это около часа, что слишком много для этой компании и для них это важно. В такой формулировке цель уже пересекается с требованиями, что вполне естественно, т.к. при разворачивании дерева целей (т.е. дробя их на более мелкие связанные цели), мы и так будем приближаться к требованиям. Поэтому, увлекаться не стоит.

Вообще, умение выделять цели, формулировать их, строить дерево целей это тема совершенно отдельная. Запомните главное: умеете – пишите, не уверены – вообще не пишите. А что будет, если не сформулировать цели? Будете работать по требованиям, такое часто практикуется.

Что с этим делать на практике

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

Не актуально для проектов по автоматизации учета

Что с этим делать на практике

ГОСТ расшифровывает перечень таких требований:

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

Несмотря на то, что основным, безусловно, будет раздел с конкретными требованиями (функциональными), данный раздел тоже может иметь большое значение (и в большинстве случаев имеет). Что может оказаться важным и полезным:

• Требования к квалификации. Возможно, разрабатываемая система потребует переподготовки специалистов. Это могут быть как пользователи будущей системы, так и IT-специалисты, которые будут нужны для ее поддержки. Недостаточное внимание к данному вопросу нередко перерастает в проблемы. Если квалификация имеющегося персонала явно недостаточна, лучше прописать требования к организации обучения, программе обучения, срокам и т.п.
• Требования к защите информации от несанкционированного доступа. Тут комментарии излишни. Это как раз и есть требования к разграничению доступа к данным. Если такие требования планируются, то их нужно расписать отдельно, как можно более детально по тем же правилам, что и функциональные требования (понятность, конкретность, тестируемость). Поэтому, можно эти требования включить и в раздел с функциональными требованиями
• Требования к стандартизации. Если существуют какие-либо стандарты разработки, которые применимы к проекту, они могут быть включены в требования. Как правила, такие требования инициирует IT-служба Заказчика. Например, у компании 1С есть требования к оформлению программного кода, проектированию интерфейса и пр.;
• Требования к структуре и функционированию системы. Тут могут быть описаны требования к интеграции систем между собой, представлено описание общей архитектуры. Чаще требования к интеграции выделяют вообще в отдельный раздел или даже отдельное Техническое задание, т.к. эти требования могут оказаться достаточно сложными.

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

ГОСТ выделяет такие виды:

• Математическое
• Информационное
• Лингвистическое
• Программное
• Техническое
• Метрологическое
• Организационное
• Методическое
• и другие…

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

• Решения о том, на каком языке (или какой платформе) будет вестись разработка не принято;
• К системе предъявляются требования мультиязычного интерфейса (например, русский/английский)
• Для функционирования системы должно быть создано отдельное подразделения или приняты на работу новые сотрудники;
• Для функционирования системы у Заказчика должны произойти изменения в методиках работы и эти изменения должны быть конкретизированы и запланированы;
• Предполагается интеграция с каким-либо оборудованием и к нему предъявляются требования (например, сертификации, совместимости и пр.)
• Возможны другие ситуации, все зависит от конкретных целей проекта.

Что с этим делать на практике

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

Что с этим делать на практике

Общие требования к приемке работ по стадиям (перечень участвующих предприятий и организаций, место и сроки проведения), порядок согласования и утверждения приемочной документации;

Настоятельно рекомендую с ответственностью отнестись к порядку сдачи работ и проверке системы. Именно для этого и нужны тестируемые требования.

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

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

Раздел 7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

Что с этим делать на практике

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

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

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

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

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

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

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

Сроки и порядок комплектования штатов и обучения персонала

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

Что с этим делать на практике

Подумайте, как будут представлены руководства пользователя.

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

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

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

Что с этим делать на практике

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

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

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

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

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

Во второй статье будем говорить только о разделе 4 «Требования к системе», а конкретно мы будет формулировать требования из соображений понятности, конкретности и тестируемости.

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

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

Вид требования

Неправильная формулировка

Комментарий и как можно было сформулировать

«Сумма затрат должна корректно распределяться по соответствующим товарам»

Понятное ли это требование? В общем-то понятное, речь идет о распределении неких затрат по группе товаров.

Конкретное ли это требование? Не сказано, как должна распределяться затрата, по сумме, по количеству, равномерно или как-то иначе?

Тестируемое ли это требование? Вроде бы простая вещь, но как ее проверять, если нет конкретики?

Как можно было бы это переформулировать: «Сумма затрат, указанная в документе, должна распределиться на все товары, указанные в данном документе пропорционально стоимости этих товаров». Получилось и понятно, и конкретно. Как проверить тоже не составит труда.

Программа должна иметь удобный интерфейс

Признаться, под данной формулировкой пришлось однажды подписаться самому – проблем потом было не сосчитать. Конечно же, подобных формулировок быть не должно. Тут нет не конкретики, ни возможность проверить это требование. Хотя, безусловно, понятное (субъективно). Тут переформулировать никак нельзя, надо подробно расписывать каждый элемент «удобности», раз Заказчик на этом настаивает. Например:

• Строки в документ должны добавляться как по нажатию на кнопку «Добавить», так и при нажатии на клавиши «insert», а также вводе пользователем части наименования;
• При просмотре списка товаров должна быть возможность поиска по наименованию, штрихкоду и артикулу;
• И пр.

Доступ к данным по прибыли должен быть доступен только финансовому директору

Понятно? Почти. Правда, прибыль бывает разная, надо уточнить.

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

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

Отчет по продажам должен формироваться за 1 минуту.

Да, понятно. И даже есть конкретное ограничение по времени: 1 минута. Но не известно, какая детализация при этом предполагается: по каждому товару, группам товаров, клиентам или как-то еще?

Можно сформулировать примерно так: «Отчет по продажам в разрезе клиентов с детализацией до каждой товарной позиции (см. образец) должен выводится не более, чем за 1 минуту при условии, что количество товаров в выборке не превышает 5000 строк».

Надеюсь, идея понятна. Если будут конкретные вопросы, пишите, попробую помочь.

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

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

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

Источник www.klerk.ru

Техническое задание на составление сметной документации

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

Скачать образец технического задания на составление сметной документации в 2022 году

Скачать образец технического задания на реконструкцию, разработку ПСД

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

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

3 ч. 1 ст. 33 44-ФЗ).

Составляя ТЗ, заказчик опирается на действующие нормы, правила и госстандарты (п. 2 ч. 1 ст. 33 44-ФЗ). Для формирования техзадания на проектно-сметную документацию рекомендации разработал и Минстрой: техническое задание составляют в соответствии с приказом № 421/пр от 04.08.2020. В описании обязательно ссылаются на строительные правила и санитарные нормы, сборники федеральных единичных расценок на строительные конструкции и работы, региональные распоряжения и другие нормативы.

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

Чтобы прочитать, понадобится доступ в систему: ПОЛУЧИТЬ БЕСПЛАТНО НА 2 ДНЯ .

Алгоритм составления техзадания

Инструкция, как подготовить техзадание на разработку проектно-сметной документации:

1. Указать название объекта, его адрес, заказчика.
2. Привести документальное основание для проведения работ.
3. Определить вид строительства или иного подряда.
4. Задать сроки проектирования.
5. Привести краткую характеристику основных показателей по объекту.
6. Определить требования к исполнителю, ПСД, результатам проектирования.
7. Сослаться на действующие стандарты, нормы и правила.
8. Прописать особые условия.
9. Установить гарантийные обязательства.

Образцы

Так выглядит техническое задание на разработку ПСД в 2022 году:

Оказание услуг по разработке проектно-сметной документации на капитальный ремонт помещений сантехнического узла

Разработка проектно-сметной документации на капитальный ремонт помещений сантехнического узла, расположенного на 1 этаже здания Городской клинической больницы № 123 по адресу: г. Москва, ул. Здоровья, д. 1.

Перечень основных данных и требований

Основные данные и требования

Основание для проектирования

Заказчик (полное наименование, адрес, телефон)

Городская клиническая больница № 123, г. Москва, ул. Здоровья, д. 1. Тел. 8(123) 123-12-13.

Разработка проектной документации

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

Основные показатели для проектирования

Городская клиническая больница № 123 по адресу: г. Москва, ул. Здоровья, д. 1.

Общая площадь здания — 5271,9 м².

Общая площадь помещений в границе проектирования — 29,6 м².

Краткая характеристика и основные показатели объекта, обязательные разделы по капитальному ремонту

Краткая характеристика и основные показатели объекта:

Площадь ремонта на первом этаже составляет 29,6 м².

Раздел 1. Пояснительная записка.

Раздел 3. Архитектурные решения.

Подраздел 1. Система электроснабжения.

Подраздел 2. Система водоснабжения.

Подраздел 3. Система водоотведения.

Подраздел 4. Отопление, вентиляция и кондиционирование воздуха, тепловые сети.

Раздел 11. Смета на строительство объектов капитального строительства.

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

1. Требования к предпроектным работам, разделам проектно-сметной документации

Градостроительные решения, генплан, благоустройство, озеленение, малые архитектурные формы, обеспеченность автостоянками

Требования к разделу «Архитектурно-строительные решения»

Требования к разделу «Архитектурные решения»:

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

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

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

В графической части раздела выполнить:

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

В разделе разработать узлы:

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

Требования к применяемым материалам и техническим решениям:

1. Выполнить демонтаж отделочных слоев стен с последующим оштукатуриванием. Штукатурка стен — улучшенная цементно-песчаная.
2. Стены помещений облицовывать матовой керамической плиткой на всю высоту помещений. Для облицовки применять керамическую плитку матовую белую размером 200×300.
3. Предусмотреть демонтаж и монтаж ПВХ подоконников. Под подоконные ПВХ доски предусмотреть 2 валика из монтажной пены вдоль доски, опорные элементы — деревянные бруски и опорные металлические уголки по стене с шагом не более 600 мм. Опорные уголки заложить под штукатурный слой.
4. Выполнить демонтаж откосов по окнам и дверям.
5. Откосы окон выполнить из гипсоволокнистых листов с последующей облицовкой керамической плиткой. Гипсоволокнистые листы крепить к ПВХ окну через п-профиль. Пространство между откосом и кирпичом заполнить клеем на гипсовой основе двумя непрерывными полосами по длине откоса. Верхний откос выполнить по металлическому оцинкованному каркасу, пространство между стеной и откосом изолировать минеральным утеплителем.
6. Откосы по дверным проемам облицевать керамической плиткой.
7. Ниши под окнами заложить кирпичом или сибитом (в одну плоскость со стеной).
8. Стяжка пола — цементно-песчаная марки не менее В15. Толщину стяжки определить проектом. При необходимости произвести вскрытие пола для определения монтажных и демонтажных объемов работ.
9. Под облицовку пола предусмотреть полимерно-цементную гидроизоляцию.
10. Покрытие пола — керамогранит размером 600×600×10.
11. Потолок во всех помещениях выполнить типа Armstrong открытого типа. В качестве заполнения потолка применить металлокассеты для открытой подвесной системы. Цвет потолка белый.
12. По стоякам отопления, трубам водоснабжения, канализации предусмотреть короба из гипсоволокнистых листов по металлическому оцинкованному каркасу с последующей облицовкой. В коробах предусмотреть установку ревизионных люков.
13. Наличие дверей в помещениях — двери алюминиевые с глухим заполнением из сэндвич-панелей, облицованных металлическими оцинкованными листами толщиной 0,7 мм с полимерным покрытием. Наличие доводчика на полотно. Ручка скоба с двух сторон дверного полотна. В местах крепления, петель, доводчика и т. д. предусмотреть закладные элементы в конструкции двери. Цвет двери белый.
14. Проектом предусмотреть демонтаж и монтаж новых сантехнических кабинок (перегородок). Материал сантехнических кабинок согласовать с заказчиком. Ширина кабинок — не менее 1200 мм. В каждой кабинке предусмотреть установку поручней.
15. Выполнить демонтаж существующих площадок под унитазы.
16. Проектом предусмотреть наклейку матовый пленки на стеклопакеты ПВХ окон.
17. Закладку отверстий, проемов в существующих кирпичных стенах выполнить кирпичом с обеспечением перевязки вновь возводимой кладки с существующей.
18. При нарушении облицовки фасада выполнить восстановление аналогичным материалом.
19. Способ выполнения отверстий в кирпичных стенах, плитах перекрытия — алмазное бурение.

*При составлении ведомостей объемов работ учесть демонтажные и монтажные работы, не входящие в площади ремонта, которые необходимо выполнить как сопутствующие виды работ.

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

• замену систем энергообеспечения и электроснабжения;
• замену или проверку существующей кабельной линии;

В графической части раздела выполнить:

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

Вновь проектируемые силовые питающие линии выполнить медным кабелем.

В помещениях предусмотреть применение светильников для потолка Armstrong (совместимых с типом потолка)

Способы прокладки кабельных линий должны соответствовать действующим правилам устройства электроустановок п. 2.1.16, 2.3.15. Рекомендации по монтажу указать в проекте.

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

Типовые привязки розеток по высоте:

Высота электрических выключателей, розеток для бесконтактной сушки рук — 900 мм.

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

Проектом предусмотреть бесконтактные сушки для рук (1 шт.).

Технические характеристики точек подключения и их месторасположение выдаются в процессе проектирования Заказчиком.

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

Проектом предусмотреть демонтаж и монтаж труб водоснабжения. Требуемый материал труб водоснабжения — полипропилен армированный.

В санитарной комнате установить 4 керамических умывальника на пьедестале в комплекте со смесителями и сифонами, 4 настенных дозатора для мыла.

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

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

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

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

Монтаж канализационной сети выполнить из полипропиленовых канализационных труб.

В мужском сантехническом узле предусмотреть установку 4 унитазов, 2 писсуаров.

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

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

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

Замену приборов отопления выполнить по расчету.

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

Температура теплоносителя 70-90 °С.

Система отопления двухтрубная с нижней подачей теплоносителя. Подводка труб отопления к приборам отопления боковая односторонняя.

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

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

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

В спецификациях к воздуховодам указать тип и количество фасонных элементов.

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

Требования к разделу 11. Сметная документация

Сметную стоимость определить в базисном уровне цен с последующим пересчетом в текущий уровень по состоянию на момент подачи проектной документации в Московскую государственную экспертизу с применением индексов изменения сметной стоимости строительства, рекомендуемых к применению письмом Минстроя России. Локальные сметные расчеты на строительно-монтажные работы выполнить в уровне цен на 01.01.2000 по сборникам ФЕР-2001, ФЕРр-2001, ФССЦ-2001 в редакции 2020 г. (по методике 2020), утвержденной Приказом Министерства строительства и жилищно-коммунального хозяйства Российской Федерации от 04.08.2020 № 421/пр.

Сметная документация должна быть предоставлена в программном комплексе «Гранд Смета» в формате XML и MS Excel.

В сметной документации необходимо предусмотреть:

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

Работы на установку лесов и/или применение автовышки при выполнении наружных работ на высоте.

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

Расценки по прайс-листу:

1. Электрическое оборудование (электрические автоматы и рубильники; электрические шкафы, светильники, розетки, выключатели).
2. Радиаторы отопления.
3. Потолочные плиты/кассеты.
4. Сантехнические кабинки, перегородки.
5. Керамогранит для облицовки пола.
6. Керамическую плитку для облицовки стен.
7. Смесители.
8. Бесконтактные сушки для рук.
9. Поручни для кабинок.
10. Сантехнические кабинки.

Требования к согласованию проекта

Оплату за проведение экспертизы в Московской государственной экспертизе производит Заказчик.

3. Дополнительные требования

Указания о разработке дополнительных материалов в связи со спецификой проектирования объекта, в т. ч. дополнительных экземпляров ПСД или ее частей

Состав разделов проектной документации и требования к их содержанию утверждены Постановлением Правительства Российской Федерации № 87 от 16 февраля 2008 г. (с изменениями на 17 сентября 2018 года).

Согласованный комплект проектной и сметной документации выдается заказчику:

1. Проектная документация — 4 экз. на бумаге.
2. Сметная документация — 3 экз. на бумаге.
3. Рабочая документация — 4 экз. на бумаге.

Один экз. сметной и рабочей документации выдается на электронном цифровом носителе (dwg, pdf).

Проектные решения согласовать с Заказчиком.

Разделы проектной документации должны соответствовать требованиям СНиП, СП, СанПиН, Постановлению Правительства Российской Федерации № 87 от 16.02.2008 «О составе разделов проектной документации и требованиях к их содержанию», ГОСТ Р 21.1101-2013 «Система проектной документации для строительства (СПДС). Основные требования к проектной и рабочей документации», Федеральному закону «Технический регламент о требованиях пожарной безопасности» от 22.07.2008 № 123-ФЗ (с изменениями на 27.12.2018).

Обязательно соответствие объемов и материалов в проектной и сметной документации.

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

Сметная документация должна отвечать требованиям заказчика и должна быть составлена в программном комплексе «Гранд Смета» в 2 уровнях цен:

1. В базисных ценах 2001 года (применяя единичные расценки из сборников в редакции 2020 года), по сборникам ФЕР-2001, ФЕРм-2001, ФЕРр-2001, ФЕРп-2001, ФССЦ-2001, ФССЦпг-2001.
2. В текущим уровне цен с учетом индексов цен, сложившихся ко времени выдачи сметной документации по сборникам ФЕР-2001, ФЕРм-2001, ФЕРр-2001, ФЕРп-2001 ФССЦ-2001, ФССЦпг-2001 и составлена базисно-индексным методом.

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

Величину накладных расходов и сметной прибыли принять в соответствии с приказами Минстроя России № 812/пр и № 774/пр. Накладные расходы и сметную прибыль показать по каждой сметной позиции с учетом понижающих коэффициентов (коэффициенты должны быть видны).

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

При отсутствии какого-либо материала в сборниках ФССЦ допускается указывать цену материала по прайс-листам. Прайс-лист предоставляется по выбранному поставщику с указанием на прайс-листе даты и реквизитов поставщика. Прайс-листы необходимо пронумеровать. В локальном сметном расчете в графе «обоснование» указывать шифр, по которому принята стоимость данного материала. Стоимость материалов, отсутствующих в сборниках ФССЦ, принять в текущем уровне цен с пересчетом в базисный уровень цен 2001 г. методом «обратного счета».

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

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

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

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

Качество выполняемых работ должно удовлетворять требованиям, установленным действующими СНиП, СП и СанПиН.

Оплата за выполненные проектные работы производится после предоставления положительного заключения Московской государственной экспертизы.

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

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

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

А это еще один образец техзадания на составление проектно-сметной документации для заказчика.

В 2009 году закончила бакалавриат экономического факультета ЮФУ по специальности экономическая теория. В 2011 — магистратуру по направлению «Экономическая теория», защитила магистерскую диссертацию.

Источник goscontract.info

Как составить техническое задание и получить то, что нужно

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

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

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

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

• Купи его до 19:00 сегодня.
• Мне нужен хлеб из пекарни около дома.
• Хлеб должен быть весом от 200 до 300 г.
• Он должен быть либо из ржаной, либо из гречневой муки.

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

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

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

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

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

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

Устоявшейся практики нет — как договоритесь с подрядчиком.

Заказчик делает сам

Например, гендиректор студии архитектурной фотографии «АрхФото» Анатолий Шостак называет идеальным заказом ситуацию, когда заказчик сразу присылает подробное ТЗ и просит оценить работы.

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

Анатолий Шостак
Гендиректор «АрхФото»

Совместная работа

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

Техзадание полностью делает исполнитель

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

Совместная работа по составлению ТЗ и заказ задания исполнителю отличается в первую очередь подходом. Например, вы хотите заказать интернет-магазин:

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

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

Сколько стоит заказать ТЗ

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

Основатель компании по разработке информационных систем Work Solutions Максим Мул при заказе ТЗ рекомендует ориентироваться на 10-20 % от общей стоимости разработки продукта.

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

Максим Мул
Основатель Work Solutions

Если речь про IT-задачи, например, интеграцию между информационными системами, внедрение CRM, разработку дополнительного функционала ПО или приложения по API, то не стоит рассчитывать на ТЗ стоимостью меньше 50 000 руб., считает гендиректор компании «Информатика и Сервис» Владимир Севрук.

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

Владимир Севрук
Гендиректор компании «Информатика и Сервис»

Платные подробные ТЗ применяют и в других сферах. Например, в архитектурной фотографии.

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

Анатолий Шостак
Гендиректор «АрхФото»

За составление такого подробного сценария в «АрхФото» берут деньги. В зависимости от сложности проекта и требований заказчика сценарий иногда стоит дороже самой съемки. Зато благодаря ТЗ заказчик еще до начала работ понимает, что получит в итоге, говорит Анатолий Шостак.

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

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

Пишите однозначно

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

Хороший подрядчик будет конкретизировать и уточнять неоднозначные строчки в ТЗ, но это потребует дополнительного времени на переделку. Поэтому лучше стараться минимизировать недопонимание. И постараться определить для себя конкретные требования к продукту еще до разговора с исполнителем.

Бывает, что заказчик не знает, что конкретно хочет получить, причем часто сам того не осознавая. Из-за этого в ТЗ появляются расплывчатые и многословные формулировки. В итоге заказчик с исполнителем потратят значительное время на их уточнение. Эффективнее сделать ТЗ с конкретными и точными требованиями, без многословности.

Алексей Орлов
Руководитель проектов компании «Рексофт»

Стоит попробовать любые пожелания сводить к количественным требованиям.

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

Дайте подрядчику общую информацию

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

Гендиректор INOSTUDIO Максим Болотов рекомендует как минимум озвучить подрядчику идею проекта, который вы заказываете, уточнить, в чем его конкурентные преимущества и уникальность.

Расскажите подрядчику, какие задачи будет решать IT-решение. Это может быть увеличение прибыли, повышение узнаваемости бренда, лояльности пользователей. Уточните, кто будет пользователями продукта, их социальные и поведенческие характеристики, например, пол, возраст, интересы, семейное положение, потребности — это нужно, чтобы корректно и эффективно сформулировать функциональные требования к продукту.

Максим Болотов
Гендиректор INOSTUDIO

Помогите разобраться в терминах и нюансах

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

Можно ввести отдельный раздел в виде словаря с расшифровкой или пояснять по ходу документа.

Покажите конкурентов

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

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

Максим Болотов
Гендиректор INOSTUDIO

Уточните важные технические требования

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

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

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

Распишите сценарии использования продукта

Если вы делаете что-то стандартное, то так сильно погружаться в особенности продукта не стоит, это лишь запутает и добавит ТЗ многословности. Но в случае чего-то необычного попробуйте в техзадании отвечать не на вопрос «Что?», а на вопрос «Как будет делать пользователь?».

• Плохо — «Требование 1. На сайте есть корзина, пользователь по дополнительному запросу может получить список дополнительных товаров». В этом случае непонятно, что и как должно работать.
• Хорошо — «Когда пользователь заходит в корзину, сайт показывает ему всплывающий баннер. На этом баннере должны быть товары, которые могут пригодиться покупателю. Он может одним кликом добавить любой товар к заказу. Или закрыть окно». В этом случае понятно, как работает сценарий использования корзины и блока с кросс-товарами.

Если речь про IT-продукты, можно прописывать сценарии по такому шаблону:

• действие пользователя;
• ответ сайта;
• если пользователь делает так, то сайт делает так;
• если пользователь делает по-другому, то сайт отвечает так.

Опишите требования к проверке проекта

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

Например, для интернет-магазина это может быть:

• Буду проверять корректное отображение в браузерах Chrome, Firefox, Mozilla трех последних версий.
• Отображение на экранах мобильника с разрешением 320 px на 480 px, монитора с разрешением 1024 px на 802 px, большого монитора с разрешением…
• Скорость разгрузки по сервису такому-то не больше 1 секунды.

Чем подробнее и длиннее чек-лист, тем лучше.

Двигайтесь от общего к частному

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

Шаблоны и примеры ТЗ

Универсального шаблона технического задания нет — требования будут отличаться в зависимости от отрасли и типа проекта.

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

Если планируете заказать IT-продукт, можно использовать за основу госстандарты. Например:

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

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

Когда ТЗ не нужно

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

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

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

Вместо ТЗ выгоднее сначала сделать предпроектное обследование, изучить реальные потребности клиентов, вместе с аналитиком подрядчика. А затем решать, нужно ли ТЗ вообще.
Может быть, выгоднее и эффективнее выполнять бизнес-задачу, например, с помощью SCRUM. Действуя небольшими итерациями в 1-2 недели, анализируя результат и постепенно дополняя требования.

Владимир Севрук
Гендиректор компании «Информатика и Сервис»

Кратко — универсальные советы по составлению ТЗ

Составляя ТЗ самостоятельно или с подрядчиком, придерживайтесь следующих правил:

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

Не пропустите новые публикации

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

Источник kontur.ru