Порядок согласования технического задания. Порядок разработки, согласования и утверждения тз на ас

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

Что и как

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

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

Этапы разработки технического задания

1. Предварительное изучение брифа/задачи

Как правило, есть эфемерное представление того, что хочет заказчик - в виде брифа, письма с «хотелками», ТЗ. Изучите предметную область, составьте список вопросов.

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

2. Проведение встречи

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

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

Ответы фиксируйте рядом с вопросами, перечитывайте их.

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

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

3. Разработка концепции

Концепция обычно содержит краткие тезисы будущего ТЗ, а именно:

• Цели и задачи;
• Назначение;
• Роли;
• Структура;
• Содержание;
• Список возможностей (в виде сервисов - кратко).
• Порой концепция содержит подробное описание бизнес-идеи, для понимания, чем выигрышен проект.

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

4. Уточнение требований

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

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

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

5. Утверждение ТЗ

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

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

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

Трудности и как избежать

1. Срыв сроков

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

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

2. Цена-сроки-объем работ

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

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

4. Старайтесь фиксировать все, о чем договариваетесь

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

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

5. Презентуйте результат

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

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

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

Ментальные карты

Техника Mind Maps. Разрабатывайте ТЗ при помощи ментальных карт. Суть процесса состоит в том, что вы изначально рисуете будущий проект в виде схемы. Вы делите продукт на сущности, понятия; при этом в каждом пункте дерева не должно быть больше 3-4 слов. Подобная схема быстро считывается всеми участниками проекта, легко изменять и дополнять дерево. Существует множество программ для разработки таких карт.

Версии и названия файлов

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

По опыту удобно делать названия и версии следующего вида:

NameProject.0.1.doc ,

Где NameProject - название проекта,

0 - версия, отправленная клиенту; если 0 - значит, не отправлялось, пока работаете внутри компании (отдела);

1 - версия, которую вы создаете внутри компании (отдела).

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

Если документов несколько (например, концепция, ТЗ), добавьте тип документа в название документа - NameProject.Concept.0.1.

Структура

Имейте четкую структуру ТЗ. При сборе информации, а также разработке документа, следуйте ей. В зависимости от ожиданий заказчика существует 4 альтернативы для выбора шаблона технического задания. Это может быть ГОСТ, IEEE, Корпоративный шаблон, ваш собственный шаблон (или шаблон компании, в которой вы работаете).

Форматирование

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

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

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

I. Общие положения

1.1. Порядок разработки и утверждения технических заданий по подготовке инвестиционных программ организаций коммунального комплекса, осуществляющих эксплуатацию систем коммунальной инфраструктуры и (или) объектов, используемых для утилизации (захоронения) твердых бытовых отходов, на территории муниципального образования «Город Калуга» (далее – Порядок) устанавливает основы организации разработки и утверждения технических заданий по подготовке инвестиционных программ организациями коммунального комплекса (далее - ОКК).

1.2. Понятия и термины, используемые в настоящем Порядке, применяются в значениях, определенных Федеральным законом от 01.01.01 г. «Об основах регулирования тарифов организаций коммунального комплекса».

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

Организует разработку технических заданий с учетом реального состояния СКИ и определяет перспективу развития СКИ управление городского хозяйства города Калуги (далее – УГХ) совместно с управлением строительства и земельных отношений города Калуги (далее – УСиЗО).

1.4. Техническое задание в части требований к разработке инвестиционной программы организацией коммунального комплекса (далее - ОКК) обуславливает выстраивание системы планов, элементами которой могут быть:

- генеральный план городского округа «Город Калуга»;

Программа комплексного развития СКИ;

Программа выбытия ветхого и аварийного жилищного фонда муниципального образования «Город Калуга»;

Программа модернизации и реформирования жилищно-коммунального хозяйства муниципального образования «Город Калуга».

2. Порядок разработки и содержание технического задания

2.1. Техническое задание разрабатывается индивидуально для каждой ОКК, осуществляющей эксплуатацию СКИ и (или) объектов, используемых для утилизации (захоронения) твердых бытовых отходов (далее - ТБО).

2.2. В техническое задание включаются:

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

2.2.2. Требования к инвестиционной программе.

2.2.3. Сроки разработки инвестиционной программы.

2.2.4. Порядок и форма предоставления, рассмотрения и утверждения инвестиционной программы.

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

2.3.1. В случае отсутствия программы комплексного развития целевые индикаторы разрабатываются на основании:

Прогноза социально-экономического развития муниципального образования «Город Калуга»;

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

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

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

2.3.2. Информация о планируемых на период реализации разрабатываемой инвестиционной программы объемах ввода объектов жилищного и промышленного строительства, а также характеристики земельных участков, обеспечиваемых инженерной инфраструктурой в целях подключения объектов строительства (реконструкции), представляется УСиЗО по запросу УГХ и должна содержать:

Перечень строительных площадок, а также перечень зданий, строений и сооружений, подключаемых к СКИ, с указанием планируемого адреса;

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

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

Красные линии соответствующих территорий;

Границы зон действия установленных и частных сервитутов;

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

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

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

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

Финансовое состояние ОКК (в том числе кредиторской и дебиторской задолженности , плановой и фактической выручки);

Показатели производственной программы ОКК;

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

2.3.5. Для разработки технического задания, в том числе для определения целевых индикаторов, УГХ запрашивает от ОКК в письменной форме необходимую информацию с указанием перечня, формы и сроков ее предоставления.

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

Целевые индикаторы могут быть сгруппированы, в том числе в следующие группы:

Надежность (бесперебойность) снабжения потребителей товарами (услугами) ОКК;

Доступность товаров и услуг для потребителей (в том числе обеспечение новых потребителей товарами и услугами ОКК);

Эффективность деятельности ОКК;

Обеспечение экологических требований.

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

2.3.8. Основные требования при определении целевых индикаторов:

Однозначность - изменения целевых индикаторов должны однозначно характеризовать положительную или отрицательную динамику происходящих изменений состояния СКИ, а также не иметь различных толкований;

Измеримость - каждый целевой индикатор должен быть количественно измерен;

Доступность - проведение расчета значений индикаторов не должно быть связано с проведением дополнительных исследований и должно минимизировать затраты времени и ресурсов на расчет значений;

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

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

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

2.3.11. В целях обеспечения единых подходов к формированию целевых показателей развития СКИ необходимо в максимальной степени обеспечить синхронизацию разработки целевых индикаторов в технических заданиях, разрабатываемых для различных ОКК.

2.4. Требованиями к инвестиционной программе определяются условия, на соответствие которым УГХ будет проводить проверку инвестиционной программы.

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

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

В техническом задании могут быть сформулированы требования по проведению работ, которые должны были войти в указанную программу. К таким работам можно отнести анализ существующего состояния СКИ и объектов, используемых для утилизации (захоронения) ТБО, с выявлением основных проблем, не позволяющих обеспечить необходимый уровень объемов и качества предоставления товаров и услуг ОКК.

2.5.2. Разработка плана технических мероприятий по строительству и (или) модернизации СКИ и объектов, используемых для утилизации (захоронения) ТБО. При разработке мероприятий учитывать: существующее состояние указанных систем и объектов и обеспечивать доведение их состояния, а также условий их эксплуатации до уровня, задаваемого целевыми индикаторами технического задания; обеспечивать подключение строящихся (реконструируемых) объектов, указанных в техническом задании, к СКИ, а также обеспечивать земельные участки инженерной инфраструктурой. В случае отсутствия программы комплексного развития перечень указанных объектов и земельных участков с их характеристиками и характеристиками планируемых подключаемых объектов (в том числе нагрузок) рекомендуется проводить в приложении к техническому заданию.

2.5.3. В рамках разработки инвестиционной программы в соответствии с частью 3 статьи 11 Федерального закона от 01.01.01 г. должны быть определены финансовые потребности на ее реализацию, которые определяются на основании финансовых потребностей по реализации каждого из мероприятий программы.

2.5.4. Реализация инвестиционной программы, включая отдельные ее мероприятия, в соответствии с частью 1 статьи 10 Федерального закона от 01.01.01 г. обеспечивается соответствующими источниками финансирования, которые гарантируют своевременность инвестиций в необходимом объеме.

2.5.5. Могут быть сформулированы требования по предварительному расчету надбавок к тарифам и тарифов на подключение.

2.5.6. Может быть сформулировано условие о необходимости подготовки ОКК проекта инвестиционного договора в целях развития СКИ. Реализация инвестиционной программы в соответствии с частью 13 статьи 11 Федерального закона от 01.01.01 г. основывается на договоре, заключаемом Городской Управой города Калуги с ОКК, определяющем условия реализации утвержденной инвестиционной программы.

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

2.5.8. Требование к форме инвестиционной программы, отражающей требования к ее разработке.

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

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

2.7. По решению УГХ в техническое задание могут быть включены иные требования.

3. Порядок согласования, утверждения

и изменения технического задания

3.1. Техническое задание разрабатывается и утверждается в сроки, учитывающие период подготовки ОКК инвестиционной программы и сроки утверждения данной программы.

3.2. Проект технического задания предварительно согласовывается УГХ с ОКК, разрабатывающей инвестиционную программу.

3.3. Разработанный проект технического задания в случае необходимости рассматривается на рабочей группе, в состав которой входят представители УГХ, УСиЗО, управления архитектуры и градостроительства города Калуги, управления экономики города Калуги, Городской Думы города Калуги, ОКК, а также по согласованию могут входить и заинтересованные организации, планирующие осуществить строительство (реконструкцию) объектов капитального строительства с подключением новой (дополнительной) нагрузки к СКИ.

3.4. Рассмотренный рабочей группой проект технического задания утверждается правовым актом Городской Управы города Калуги.

3.5. Подготовку проекта правового акта Городской Управы города Калуги об утверждении технического задания осуществляет УГХ.

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

3.7. В качестве оснований для пересмотра (внесения изменений) в утвержденное техническое задание рекомендуется определять:

Принятие или внесение изменений в программу комплексного развития муниципального образования «Город Калуга»;

Принятие или внесение изменений в программы социально-экономического развития муниципального образования «Город Калуга» и иные программы, влияющие на изменение условий технического задания;

Вынесение органом регулирования муниципального образования «Город Калуга» решения о недоступности для потребителей товаров и услуг ОКК с учетом надбавки к ценам (тарифам), предлагаемой ОКК для обеспечения реализации инвестиционной программы;

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

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

3.8. Пересмотр (внесение изменений) технических заданий может производиться не чаще одного раза в год.

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

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

3.11. Пересмотр или внесение изменений в техническое задание осуществляется в порядке, соответствующем порядку его разработки.

3.12. Решение об утверждении или пересмотре технического задания, внесение изменений в техническое задание доводятся до ОКК, осуществляющей разработку инвестиционной программы, УГХ в письменном виде в недельный срок со дня его принятия.

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

Документ ГОСТ 34.602-89 «ТЗ на создание АС» содержит в первых же строках явное указание:

1.1. ТЗ на АС является основным документом, определяющим требования и порядок создания (развития или модернизации — далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие.

Приступая к написанию ТЗ (ЧТЗ) необходимо собрать первичные сведения, которые будут отображаться на титульном листе.

Следует начинать написание ТЗ (ЧТЗ) с титульного листа. Титульный лист содержит:

1. Наименование заказчика
2. Наименование системы / подсистемы
3. Наименование типа документа (ТЗ / ЧТЗ и т.д.)
4. Наименование очереди создания АС
5. Шифр темы
6. Согласующие надписи

Наименование заказчика

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

1. Единственный заказчик (наиболее частая ситуация)
2. Группа заказчиков, в которой кто-то один является основным. Например, один заказчик является функциональным, т.е. АС создаётся непосредственно для него. Другой же заказчик оплачивает разработку. На титульном листе следует отображать лишь одного заказчика. Этот вопрос следует предварительно согласовать с руководством заказчиков. Обычно этот вопрос относится к компетенции менеджера проекта.
3. В отдельных случаях заказчик может потребовать указать наименование исполнителя, без указания собственного наименования. Этот вопрос также следует предварительно согласовать с заказчиком.

Как правило у заказчика два наименования — полное и краткое. Специалисты со стороны заказчика отрицательно относятся к ошибкам в обоих наименованиях. Обычно языковая форма наименования на титульном листе следующая: <Полное наименование заказчика> (<Краткое наименование заказчика>). Если заказчик подчиняется какой-либо вышестоящей организации, возможно следует включить её наименование в наименование заказчика.

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

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

Наименование системы / подсистемы

АС может состоять из подсистем. Подсистемы — из модулей. АС состоит из множества элементов, которые могут образовывать иерархию. Языковое обозначение этих элементов может быть различным; главное — согласовать термины с заказчиком, чтобы общаться с ним на одном языке. В явном виде ГОСТ 34.602-89 содержит лишь 2 термина — Система (АС) и Подсистема. Остальные термины д.б. определены заказчиком и исполнителем.

Наименование типа документа

В данном случае м.б. следующие типы документа:

1. Техническое задание (ТЗ) на разработку АС
2. Техническое задание на модификацию АС
3. Частное техническое задание на разработку какой-либо части АС, например Подсистемы, входящей в АС
4. Частное техническое задание на модификацию АС / Подсистемы.

ТЗ и ЧТЗ

Следует определиться с типом документа — ТЗ или ЧТЗ?

ТЗ пишется на всю Систему (АС). ЧТЗ на какую-либо часть АС — на Подсистему.

При наличии общего ТЗ на АС имеет смысл писать ЧТЗ на отдельные подсистемы. ЧТЗ предполагает наличие ТЗ.

Если речь идёт о написании ЧТЗ, тогда на титульном листе следует указывать 2 наименования: наименование АС и наименование Подсистемы.

Документы ГОСТ серии 34 не содержат термина «Частное техническое задание». Вместе с тем в документе ГОСТ 34.003-90 «АС. Термины и определения» читаем:

1.2. ТЗ на АС разрабатывают на систему в целом, предназначенную для работы самостоятельно или в составе другой системы.

Дополнительно могут быть разработаны ТЗ на части АС: на подсистемы АС, комплексы задач АС и т.п. в соответствии с требованиями настоящего стандарта; на комплектующие средства технического обеспечения и программно-технические комплексы в соответствии со стандартами ЕСКД и СРПП; на программные средства в соответствии со стандартами ЕСПД; на информационные изделия в соответствии с ГОСТ 19.201 и НТД, действующей в ведомстве заказчика АС.

Разработка и модификация

В требованиях к содержанию документа ТЗ (см. ГОСТ 34.602-89) используются следующие термины:

1. Разработка АС
2. Модификация АС
3. Развитие АС
4. Модернизация АС

Трудно провести чёткую границу между этими понятиями (кроме п.п. 1-2). Поэтому мы предлагаем рабочую версию определений, не претендующую на полноту.

Разработка АС — написание кода, документации, проведение пусконаладочных работ, внедрение и т.д. с нуля.

Модификация АС — внесение согласованных изменений в уже существующую АС.

Развитие АС — дополнение АС какими-либо новыми элементами (например, новой подсистемой)

Модернизация АС — перевод АС на новую платформу (например на новую ОС).

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

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

Наименование очереди создания АС

Следует различать два понятия:

1. стадии и этапы создания АС (см. ГОСТ 34.601-90 «АС. Стадии создания»)
2. очередь создания АС

ГОСТ 34.003-90 ИТ. «Комплекс стандартов на АС. АС. Термины и определения» так определяет термины:

очередь создания АС — часть АС, для которой в техническом задании на создание АС в целом установлены отдельные сроки ввода и набор реализуемых функций

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

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

ГОСТ 34 в явном виде не объясняет различие между стадиями/этапами создания АС и очередями создания АС.

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

Шифр темы

Следует различать понятия:

1. Шифр темы
2. Краткое наименование АС
3. Децимальный номер

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

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

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

Согласующие надписи

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

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

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

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

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

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

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

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

Заказчику:

• Что именно он хотел бы получить на выходе, опираясь на свои текущие ресурсы и возможности;
• Провести внутреннее согласование запросов между структурными подразделениями;
• Контролировать соответствие выполненных подрядчиком работ.

Подрядчику:

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

Всем сторонам:

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

Разработка и утверждение технического задания на создание АС - этап 3.1 стадии технического задания. Редакция от 20.06.2018.

Разработка и утверждение технического задания на создание АС

Создан 18.05.2018 11:24:34

Из толкового словаря

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

Термины и определения

Утверждение - Официальное удостоверение уполномоченного на это должностного лица или в том, что разработанный вводится в действие. Удостоверение может быть зафиксировано на утверждаемом документе непосредственной или ссылкой на другой документ, содержащий решение об утверждении (акт, протокол, письмо и т.д.) [из п. 1.4.74 Р 50-605-80-93].

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

На титульном листе помещают заказчика, разработчика и согласующих организаций, которые скрепляют гербовой печатью. При необходимости титульный лист оформляют на нескольких страницах. Подписи разработчиков ТЗ на АС и должностных лиц, участвующих в согласовании и рассмотрении проекта ТЗ на АС, помещают на последнем листе. Форма титульного листа ТЗ на АС приведена в. Форма последнего листа ТЗ на АС приведена в [из п. 3.4 ГОСТ 34.602-89].

На 3.1 «Разработка и утверждение технического задания на создание АС» проводят разработку, и и, при необходимости, технических заданий на части АС [из п. 7 прил. 1 ГОСТ 34.601-90].

Связанные документы

• ГОСТ 34.602-89 ИТ. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы