Техническое задание (сокращенно – ТЗ или техзадание) представляет собой документ, детально описывающий цели и задачи, которые поставлены заказчиком перед исполнителем. Его оформление позволяет упростить как производство работ, так и контроль над их выполнением. Грамотно составленное ТЗ – это первый и очень важный шаг на пути к взаимовыгодному сотрудничеству между заказчиком и подрядчиком, позволяющий исключить или минимизировать спорные ситуации в ходе дальнейшей работы. Учитывая актуальность технического задания для успешной деятельности обеих заинтересованных сторон, имеет смысл рассмотреть основные вопросы, связанные с оформлением и исполнением документа более внимательно.
Кто должен составлять ТЗ?
Порядок документирования требований
В каком случае ТЗ не нужно?
Шаблоны для скачивания и примеры
Что такое ТЗ?
Под техническим заданием понимается четко сформулированный и детальный перечень требований к конечному продукту, заявленный заказчиком и направляемый исполнителю. Несмотря на краткость приведенной формулировки, объем ТЗ может быть очень значительным и достигать нескольких десятков страниц. Например, если речь идет о реализации масштабного проекта или разработке и изготовлении сложного технологического оборудования.
Характерной особенностью технических заданий выступает сильная зависимость – как содержимого, так и оформления документа – от специфики конечного продукта. Отдельного упоминания заслуживают ТЗ на различное программное обеспечение, включая веб-сайты, онлайн-сервисы, интернет-магазины и различные приложения. Их актуальность особенно велика, что легко и вполне логично объясняется важностью и стремительным развитием IT-индустрии.
Для чего требуется ТЗ?
Необходимость составления технического задания не вызывает сомнений. Наличие документа позволяет решить сразу несколько принципиально важных задач:
- озвучить основные причины реализации объекта;
- сформулировать четкие требования к итоговому продукту;
- проверить, насколько компетентен исполнитель;
- перечислить его необходимые характеристики, свойства, составные элементы и т.д. (перечень качеств зависит от специфики товара или услуги);
- детально описать обязанности каждой из заинтересованных сторон – исполнителя и заказчика;
- установить основные этапы и сроки выполнения поставленных задач – как по отдельности, так и для проекта в целом;
- определить критерии оценки характеристик конечного продукта и установления соответствия заданным параметрам.
Не менее важной задачей технического задания становится исключение или минимизация возможных разногласий между заказчиком и исполнителем. Они могут касаться как отдельных свойств или качеств товара/услуги, так и путей достижения поставленных целей. В результате наличие ТЗ становится ключевым фактором успешного сотрудничества заинтересованных сторон – без конфликтов и спорных ситуаций.
Кто должен составлять ТЗ?
Несмотря на кажущуюся простоту вынесенного в подзаголовок вопроса, ответ на него не так очевиден, каким видится на первый взгляд. Рассмотрим три возможных варианта.
Заказчик
Данный ответ кажется наиболее логичным. Но он является таковым только в том случае, если предметом задания выступает проект, непосредственно связанный с основным видом деятельности заказчика. Например, если IT-компании требуется программа для обслуживания локальной сети. В этом случае квалификации штатных сотрудников фирмы вполне достаточно, чтобы составить грамотное ТЗ.
На практике такая ситуация складывается далеко не всегда. Например, крупному предприятию требуется построить новый производственный цех. Но в его штате попросту может не оказаться специалистов в проектировании и строительстве нужной квалификации. В этом случае имеет смысл привлечь к составлению ТЗ сторонних профессионалов, включая сотрудников потенциального исполнителя.
Исполнитель
Выше приводится пример, когда имеет смысл доверить разработку и оформление технического задания работникам компании-исполнителя. Схема работы в этом случае обычно выглядит так:
- сначала заказчик ставит общую задачу;
- затем исполнитель направляет в его адрес бриф с уточняющими вопросами;
- на основании полученных ответов происходит разработка ТЗ;
- после этого документ отправляется заказчику на утверждение.
Обязательным условием эффективного применения описанной схемы выступает доверие исполнителю со стороны заказчика. В противном случае намного правильнее последнему привлечь к работе сторонних специалистов.
Совместно
Самый оптимальный вариант взаимодействия. Напоминает описанную выше схему разработки ТЗ исполнителем, но предусматривает намного более многоступенчатую процедуру с активным участием сотрудников заказчика. При грамотной реализации позволяет добиться лучших результатов как в части точности, так и полноты технического задания.
Стоимость ТЗ
Невозможно дать однозначного ответа на вопрос о том, сколько стоит техническое задание. В этом нет ничего удивительного, если учесть разнообразие вариаций этого документа, отличающихся как объемом, так и содержанием. Важно понимать, что рассчитывать на бесплатное составление ТЗ не стоит. Тем более – в случае приглашения сторонних специалистов.
Единственным вариантом реально сэкономить становится ситуация, когда исполнитель заинтересован в получении заказа. В этом случае вполне реально добиться от него оформления технического задания на бесплатной основе при гарантиях со стороны заказчика заключить договор на выполнение работ в будущем.
Как составить ТЗ?
Разработка и оформление технического задания – сложная задача. Ее успешное решение предусматривает комплексный подход и доскональное изучение вопроса.
Что потребуется?
Грамотно составленное ТЗ предусматривает наличие нескольких обязательных составных частей, включая:
- Подробное описание целей реализации проекта.
- Основные требования и ожидания от конечного продукта.
- Ключевые этапы выполнения работ.
- Календарный график или сроки исполнения.
- Процедура контроля в процессе реализации проекта и итоговой приемки конечного продукта.
- Приложения к ТЗ. Их перечень зависит от специфики проекта и обычно включает расчет стоимости, ссылки на нормативно-правовые документы и технические регламенты, другую справочную информацию, которая может оказаться полезной исполнителю.
Пошаговый план
Фактически, процедура составления технического задания представляет собой наполнение каждого из перечисленных выше разделов итогового документа. Последовательность предпринимаемых при этом действий зависит от специфики проекта и характеристик конечного продукта. Главное – четко выполнить требования к содержимому и оформлению ТЗ, что позволит успешно решить стоящие перед документом задачи.
Рекомендации по составлению
Не менее важно не допустить типичных ошибок, характерных для недостаточно квалифицированных разработчиков и составителей ТЗ. Чтобы добиться этого, имеет смысл следовать нескольких достаточно простым рекомендациям, включая:
- Однозначные формулировки. Содержание ТЗ не должно включать описаний или характеристик, допускающих неоднозначные трактовки. В тексте документа не допускается присутствие качественных прилагательных и крайне приветствуются конкретные цифры.
- Определение используемых терминов. Заказчик и исполнитель должны разговаривать на одном языке. Поэтому ключевые понятия нуждаются в расшифровке.
- Соблюдение установленных стандартов. Перечень нормативных документов, которые можно использовать при составлении технического задания, приводится ниже. Здесь же необходимо отметить, что ссылки на ГОСТы или ISO всегда полезны, так как сводят к минимуму возможные разночтения.
- Предоставление исполнителю максимально возможной информации о заказчике. Такие сведения помогают сориентироваться в том, что является важным для заказчика, его целевой аудитории и других важных параметрах.
- Перечисление конкурентов. Достаточно часто существенную помощь в реализации проекта оказывает изучение и анализ аналогов, уже представленных на рынке или запланированных к запуску конкурирующими компаниями. Такой подход к решению задачи заслуживает внимания, так как позволяет минимизировать сопутствующие расходы и не заниматься «изобретением велосипеда», а сосредоточиться на улучшении уже имеющихся разработок.
- Внесение корректировок при необходимости. Если речь идет о сотрудничестве двух коммерческих структур, целесообразно наладить постоянное общение. В том числе –с целью уточнения ТЗ, если это потребуется. Хотя намного правильнее заранее прописать все возможные нюансы и сценарии развития событий, так как любые корректировки технического задания можно и нужно считать форс-мажором.
Скачать шаблон и пример ТЗ на оказание услуг – источник s-vfu.ru.
О стандартах
Порядок разработки технических заданий регламентируется множеством стандартов – как международных, так и отечественных. Причем в отношении разных проектов и продуктов действуют различные нормы. Наиболее часто упоминается международный стандарт ISO/IEC/IEEE 29148-2018. Он устанавливает требования к ТЗ на разработку информационных систем и программного обеспечения.
Если говорить об отечественных стандартах, необходимо обязательно отметить два из них. Первый – это ГОСТ 34.602-89, который устанавливает основные технические и другие требования к ТЗ на автоматизированные системы. Второй – это ГОСТ 19.201-78, определяющий порядок разработки ТЗ в рамках единой системы программной документации.
Оба стандарта впервые появились еще в Советском Союзе, а потому их актуальность остается под вопросом. Отсутствие более новых документов показывает слабое законодательное и нормативное сопровождение вопроса составления и разработки технических заданий в России.
Существуют и другие стандарты, в большинстве своем международные – IEEE STD 830-1998, RUP, BABOK, SWEBOK и т.д. Их использования в отечественных условиях сильно ограничено из-за отсутствия учета местной специфики и широкого распространения.
Порядок документирования требований
Грамотное составление ТЗ предусматривает обмен документами между заказчиком и исполнителем. Первым из них выступает бриф. Он представляет собой перечень вопросов, которые исполнитель адресует заказчику с целью уточнения поставленных задач.
Далее формируется коммерческое и техническое предложение. Такой документ обычно составляется при реализации масштабных проектов. Он содержит детальное описание финансовых показателей и технических требований к результатам.
На основании обоих документов (второй может быть заменен на перечень требуемых технических характеристик) составляется ТЗ. Его в обязательном порядке утверждает заказчик и согласовывает исполнитель. В подавляющем большинстве случаев техническое задание является обязательным приложением к договору.
В каком случае ТЗ не нужно?
Техническое задание требуется далеко не всегда. Например, если уже разработана детальная проектная документация, или проведены детальные предпроектные исследования/инженерные изыскания. Также не имеет особого смысла составлять ТЗ для небольших проектов, требования и характеристики которых можно перечислить непосредственно в договоре.
Шаблоны для скачивания и примеры
Найти образец технического задания на выполнение работ несложно. В сети размещено множество подобных шаблонов и реальных примеров из практики. Важно понимать, что ТЗ для разных проектов и продуктов очень сильно отличаются друг от друга. Поэтому следует крайне внимательно относиться к имеющимся образцам и подбирать подходящий.
FAQ
Что такое ТЗ?
Под техническим заданием понимается перечень требований к разрабатываемому продукту или реализуемому проекту. Он включает технические характеристики, сроки выполнения, нередко – стоимость производимых работ и другие подобные параметры.
Для чего необходимо техническое задание?
Составление ТЗ позволяет четко сформулировать поставленные перед исполнителем задачи и исключить возможность возникновения спорных ситуаций в процессе их решения.
Что следует включить в ТЗ?
Содержание ТЗ определяется с учетом специфики конкретного продукта и может включать обширный набор сведений – от перечня требуемых характеристик до описания процедуры контроля качества.
Кто занимается составлением ТЗ?
На практике встречаются три варианта ответа на этот вопрос: заказчик, исполнитель, одновременно оба. Эффективность применения каждого зависит от статуса заинтересованных сторон и характера их взаимоотношений.
Какие типичные ошибки допускаются при разработке технического задания?
Самыми частыми ошибками при составлении ТЗ выступают: неоднозначные формулировки, отсутствие четких требований, недостаток информации о заказчике, продукте и конкурентах.
Подведем итоги
- Техническое задание – это перечень требований к конечному продукту или результатам реализации проекта.
- Разработка ТЗ – важный подготовительный этап, от успешного выполнения которого зависит эффективность дальнейшего сотрудничества между заказчиком и исполнителем, а также качество полученного на выходе продукта.
- Составлением ТЗ занимается заказчик, исполнитель или одновременно оба. Последний вариант нередко оказывается самым плодотворным при условии взаимного доверия между сторонами.
- Стоимость технического задания определяется индивидуально и зависит от специфики конечного продукта, его сложности и предъявляемых заказчиком требований.
Руководство по эксплуатации (РЭ) относится к стандартизированной документации, являющейся неотъемлемой частью проектирования и производства продукции промышленного назначения. Документ содержит информацию о товаре, необходимую для оценки его эксплуатационных качеств и корректного использования. Наличие руководства обеспечивает безопасное использование изделия и является необходимым условием для получения сертификата.
Компания Серконс оказывает услуги в сфере разработки руководства по эксплуатации
Зачем и для кого создается документ?
Руководство по эксплуатации устанавливает правила использования, хранения, перемещения, техобслуживания, выполнения ремонтных работ, методы утилизации и технические параметры конкретного продукта.
Документ создается для пользователей изделия и специалистов по его сервисному обслуживанию. Он сопровождает продукт после его реализации и в отличие от техпаспорта, крайне важен для рядового потребителя. От полноты и доступности информации о товаре, представленной в РЭ, напрямую зависит его эффективность, термин действия и коммерческий успех.
Любой продукт, независимо от своего предназначения и выполняемых функций, нуждается в оформлении эксплуатационной инструкции. Наличие документа, обеспечивающего корректную и безопасную эксплуатацию, заметно увеличивает конкурентоспособность, как простой расчески, так и технологически сложного прибора перед их аналогами.
Особенности создания и оформления
Составление руководства по эксплуатации является обязательным условием для получения ряда разрешительных документов и беспрепятственного выпуска продукции в обращение. Потребность в документе также возникает у компаний, не изготавливающих товар, а специализирующихся на его транспортировке, распространении или импортно-экспортных процессах.
Руководство может создаваться на подготовительном этапе, как на отдельный продукт, так и на группу однотипных моделей с едиными данными и правилами. Процесс его оформления не отличается от конструкторско-технической документации и регулируется положениями национальных стандартов ГOCТ 2.601-2013 и ГOCТ 2.105-95.
В документе излагается только достоверная и понятная информация, позволяющая в полной мере разобраться в принципах и механизмах функционирования изделия. Применение схем, чертежей и графиков увеличивает наглядность Руководство по эксплуатации для целевой аудитории.
Являясь структурным документом, эксплуатационное руководство предусматривает наличие следующих разделов:
- наименование продукта;
- предназначение и сферы применения;
- описание продукта и принципов его функционирования;
- правила оценки состояния продукта, его упаковки, хранения и транспортировки;
- регламент ремонтных работ;
- описание возможных неисправностей и способов их устранения;
- условия переработки и утилизации.
В зависимости от индивидуальных особенностей и сложности изделия некоторые разделы, подразделы или отдельные части РЭ могут объединяться в процессе разработки. При наличии особых требований к какому-либо подразделу он документируется как отдельная инструкция и прилагается в качестве дополнения к основному экземпляру эксплуатационного руководства.
Требования к созданию руководства по эксплуатации
Основным документом, регламентирующим создание эксплуатационной инструкции, является стандарт ЕСКД, точнее требования, входящих в него:
- ГОСТ 2.610-2013;
- ГОСТ 2.601-2013;
- ТР ТС 010/2011;
- ТР ТС 016/2011.
При производстве устройств узконаправленного стандарта (насосов, арматуры) РЭ составляется с учетом Правил безопасности для промышленного оборудования.
Например, техрегламенты ТС РЭ требуют наличия в эксплуатационном руководстве данных о назначенных показателях: ресурсах, терминах действия и хранения, а также перечень критических сбоев в работе устройства и величины его предельно-допустимых состояний. Это новые, никогда ранее не предъявлявшиеся требования и условия, появление которых демонстрирует тенденцию количественного роста.
Кто разработчик?
Создание руководство по эксплуатации – обязанность производителя (импортера), который может самостоятельно составить документ. Но практика свидетельствует о том, что экономически выгоднее поручить выполнение этой задачи профессионалам. Они сформируют эксплуатационную инструкцию на основании сведений представленных заказчиком и при необходимости запросят дополнительную информацию.
Форма приема готового РЭ может быть любой, поэтому она оговаривается на этапе переговоров. Документ не требует внесения в специальный реестр, за исключением изделий медицинской направленности и предназначенных для узкого применения.
Отправить заявку на разработку руководства по эксплуатации
Вас может заинтересовать
Техническая документация
Другие услуги
Отзывы
ООО «ИЛОТ»
Уважаемый Андрей Алексеевич
Компания ООО «ИЛОТ» выражает Вам благодарность за профессиональное многолетнее партнерство и помощь в получении для нашей компании разрешительной документации на технические устройства для разных отраслей промышленности.
Благодаря высококвалифицированной работе команды специалистов «Серконс», ряд сложнейших заказов был выполнен в кратчайшие сроки. Особенно хотелось бы отметить менеджеров Мельникова Георгия и Телицыну Евгению за отзывчивость и оперативность.
Все работы были выполнены качественно и в ожидаемые сроки.
Мы получили большое удовольствие от совместной работы и можем рекомендовать вас как надежного профессионального партнера. Надеемся на долгосрочное взаимовыгодное сотрудничество.
Руководитель отдела логистики ВЭД ООО «ИЛОТ», Эстеркин К.В.
ООО «ПСК-Реконструкция»
Благодарственное письмо
ООО «ПСК-Реконструкция» выражает благодарность ООО «Серконс» за плодотворное сотрудничество в рамках проведения негосударственной экспертизы проектной документации на проекты, разработанные нашей организацией.
Работа выполнялась грамотно и профессионально. Благодарим за рекомендации по устранению замечаний в ходе экспертизы.
Мы уверены, что в дальнейшем сумеем сохранить и продолжить наши партнерские отношения. Особенно хочется поблагодарить Родригес Изабель Владиславовну за эффективное ежедневное взаимодействие с нашими сотрудниками.
Генеральный директор
М.А. Ахиллес
ООО «Галактика»
Настоящим выражаем свою благодарность ГК «Серконс», который является нашим основным партнером в сфере сертификации продукции с 2018 года.
В перечень услуг, оказываемых нам ГК «Серконс», входит оформление Сертификатов Соответствия Таможенного Союза и Деклараций Соответствия Таможенного Союза.
Отдельно хочется отметить профессионализм работы менеджеров по сертификации продукции Мельникова Георгия Викторовича и Телицыну Евгению Николаевну – их ответственное отношение к каждому запросу, высокую скорость обработки запросов и оперативное разрешение возникающих вопросов.
Благодарим за сотрудничество и надеемся на эффективное взаимодействие в будущем!
Генеральный директор
И.В. Липский
ООО «МорНефтеГазСтрой»
Уважаемая Яна Александровна!
Компания ООО «МорНефтеГазСтрой» выражает глубокую и искреннею благодарность ООО «СЗРЦ ПБ» за профессиональный подход к своей работе. Квалификация и опыт специалистов, которые всегда на связи, позволили оперативно решить возникшие вопросы в кратчайшие сроки и выполнить работу в соответствии со всеми нормами и правилами.
Желаем процветания и финансового благополучия вашей компании. Будем рассчитывать на дальнейшее плодотворное сотрудничество в сфере проведения испытаний по определению пожаробезопасности продукции и сертификации.
Генеральный директор
Тижук М.М.
ООО «ВолгоградНИПИморнефть»
Уважаемый Алексей Петрович,
Благодарим за качественно выполненную услугу по разработке СТУ на проектирование и строительство объекта в части обеспечения ПБ блока хранения и налива СУГ по объекту:
«Освоение месторождения D33 с объектами инфраструктуры. Первый этап освоения. Реконструкция трубопровода товарной нефти НСП «Романово» — ООО «ЛУКОЙЛ-КНТ». Особенно хотелось бы отметить менеджера Д. О. Мастерских и экспертов А. А. Митичкина и Е. М. Черникова за их профессионализм и оперативность.
Рекомендуем ГК «Серконс» как надежного и профессионального партнёра, надеемся на дальнейшее взаимовыгодное сотрудничество.
Первый зам. генерального директора – Директор по развитию бизнеса – Главный инженер
А. В. Скурлатов
ООО «Мастер РУФ»
Благодарственное письмо.
От лица компании ООО «Мастер Руф» выражаем вам благодарность за качественно выполненную услугу по проведению негосударственной экспертизы проектной документации на проекты, разработанные нашей организацией.
Все работы выполнены качественно и в ожидаемые сроки. В особенности хотелось бы отметить менеджера Родригес Изабель Владиславовну – за профессионализм и оперативную работу.
Мы можем рекомендовать ООО «Серконс» как надежного и профессионального партнера, и надеемся на дальнейшее взаимовыгодное сотрудничество.
С уважением,
Генеральный директор
И.Н. Малахов
«Золотой медвежонок – 2020»
Благодарность
Оргкомитет XI Национальной премии в сфере товаров и услуг для детей «Золотой медвежонок – 2020» выражает глубокую признательность за экспертную поддержку и профессиональный подход к работе в Экспертном совете Техническому директору испытательного центра ГК «Серконс» Прокопьевой Ирине Александровне.
Ваш экспертный опыт – ценный вклад в развитие премии.
С нетерпением ждём Вашего участия в XII национальной премии «Золотой Медвежонок – 2021».
Председатель оргкомитета
А.В. Цицулина
ООО «Газэнергосеть розница»
Благодарственное письмо
Уважаемый Алексей Петрович!
ООО «ГЭС розница» выражает благодарность ГК «Серконс» за выполненную работу по проведению специальной оценки условий труда (СОУТ) в нашей компании в 2020 году.
Благодаря компетентности и высокому уровню профессионализма специалистов ГК «Серконс» услуги по проведению СОУТ были выполнены качественно и своевременно.
Коллектив ООО «ГЭС розница» желает Вашей команде успехов во всех начинаниях и достижения всех поставленных целей. Надеемся в будущем на взаимовыгодное сотрудничество с Вашей организацией!
С уважением,
Заместитель генерального директора –
Главный инженер ООО «ГЭС розница»
С.А. Карабашев
ФКП «Анозис»
Уважаемый Алексей Петрович!
ФКП «Анозит» выражает благодарность экспертной организации ГК «Серконс» за качественно проведенное техническое диагностирование и экспертизу промышленной безопасности на производственных площадках нашего предприятия.
Хотим выразить благодарность за высокую организованность сотрудников и способность быстро и качественно решать поставленные задачи.
Особенно хотим поблагодарить специалиста по промышленной безопасности Баздрова Олега Андреевича, инженеров Фёдорова Алексея Владимировича и Безуглова Антона Юрьевича, а также руководителя отдела лицензирования и регистрации ОПО – Юзвенко Романа Евгеньевича, за корректно выполненную работу и ответственный подход к выполнению поставленных задач.
Главный инженер
О.Г. Бенцлер
АО «Раменский приборостроительный завод»
Уважаемый Алексей Петрович!
АО «Раменский приборостроительный завод» выражает благодарность и признательность лично Вам и всему коллективу ГК «Серконс» за оперативное и качественное проведение СОУТ. На всех этапах сотрудники демонстрировали профессиональный подход к делу и высокую квалификацию в области.
Особую признательность хочется выразить эксперту по СОУТ Ли Татьяне Владимировне за качественное и оперативное выполнение работ по СОУТ, широкий спектр профессиональных знаний и непосредственную вовлеченность в рабочий процесс.
Отдельно благодарим менеджера Михайлова Станислава Александровича, который был с нами от этапа заключения договора и на протяжении всего рабочего процесса.
Рекомендуем ГК «Серконс» как надежного партнера, работающего на высоком профессиональном уровне.
Главный инженер
С.И. Пономарев
ГБК РО «СШОР №8 им. В.В. Понедельника»
Уважаемый Андрей Алексеевич!
ГБУ РО «СШОР № 8» пользуется услугами ООО «Серконс» по сертификации спортивных объектов, находящихся в оперативном управлении нашего учреждения с 2016 года.
За это время с помощью команды ООО «Серконс» г. Ростова-на-Дону произведена сертификация, а также продление сроков действия сертификатов на спортивные объекты: Дворец спорта, открытый футбольный стадион на 1500 зрительских мест, водно-спортивная база «Зелёный остров».
Благодарим команду менеджеров, особо отмечаем работу менеджера Н. Г. Сундуковой, которая за все эти годы персональной работы с нашим учреждением проявила себя как высокопрофессиональный, грамотный специалист‚ ответственный и внимательный к проблемам клиента.
Надеемся на дальнейшее сотрудничество с ООО «Серконс» и рекомендуем всем Вашу компанию как прекрасно организованную и авторитетную организацию.
С уважением,
И.о. директора А.А. Пивоваров
ООО «Хабаровскремпроект»
Уважаемая Яна Александровна!
ООО «ХАБАРОВСКРЕМПРОЕКТ» выражает благодарность компании ООО «СЗРЦ ПБ» за качественно выполненную услугу по разработке и согласованию специальных технических условий в МЧС России ив Министерстве строительства и жилищного-коммунального хозяйства Российской Федерации.
Так же хотим особо отметить менеджера Синявского Дмитрия Юрьевича и руководителя Отдела независимой оценки риска и экспертизы пожарной безопасности Рементова Андрея Николаевича за профессионализм и качественное исполнение работы.
Мы можем рекомендовать компанию ООО «СЗРЦ ПБ», как хорошо организованную, профессиональную команду, и рады, что приняли решение о сотрудничестве с Вами.
Также на сегодняшний день прорабатываем возможность сотрудничества с Вашей компанией на разработку и прохождение СТУ по планируемому проекту Гостиничный комплекс по пер. Некрасовский 30 в г. Владивостоке.
Генеральный директор
ООО «Хабаровскремпроект» А.А. Радыгин
АО «Евраз НТМК»
Уважаемая Яна Александровна!
АО «Евраз НТМК» выражает благодарность компании ООО «СЗРЦ ПБ» за качественно выполняемые услуги по разработке специальных технических условий.
Мы можем рекомендовать компанию ООО «СЗРЦ ПБ», как хорошо организованную профессиональную команду, выражаем уверенность в сохранении сложившихся отношений и надеемся на дальнейшее плодотворное сотрудничество.
Начальник УКС И.Е. Хаятов
ООО «АББ»
Уважаемый Андрей Алексеевич!
Благодарим ООО «Серконс» в лице Увайской Людмилы Леонидовны и ее команды специалистов за организацию и проведение работ по сертификации, а также декларированию соответствия большого перечня продукции ООО «АББ», подпадающей под действие Технических регламентов Таможенного союза ТР ТС 004/2011 «О безопасности низковольтного оборудования» и ТР ТС 020 «Электромагнитная совместимость технических средств», а также за содействие по другим направлениям нашего сотрудничества с ООО «Серконс», которое длится с 2011 года.
Работа Ваших Специалистов важна и способствует процессу своевременного выпуска продукции ООО «АББ» в обращение на территории Таможенного союза.
Рассчитываем на продолжение стабильного, долгосрочного сотрудничества с ООО «Серконс».
Старший инженер по технической поддержке и сертификации продукции Е.Н. Герасимович
ООО «Магистраль»
Уважаемый Алексей Петрович!
ООО «Магистраль» выражает благодарность ГК «Серконс» за профессиональное оказание услуги по негосударственной экспертизе проектной документации и результатов инженерных изысканий.
За время нашего сотрудничества хотелось бы отметить компетентность менеджера Шуракова Сергея Сергеевича и его способность качественно и быстро решать вопросы.
Нам доставило большое удовольствие сотрудничество с ГК «Серконс».
Мы рекомендуем данную компанию в качестве профессионального партнера и надеемся на дальнейшее сотрудничество.
Генеральный директор ООО «Магистраль» Г.М. Макаршин.
ООО «Старт-Строй»
Генеральному директору ООО «Серконс» Григорьеву А.А.
ООО «Старт-Строй» выражает слова искренней благодарности руководству и сотрудникам ООО «Серконс» за проведение экспертизы проектной документации строительства объекта: «Многоквартирный жилой дом №4 по адресу: г. Н. Новгород, Советский район, у дер. Кузнечиха».
Отмечаем высокий профессионализм сотрудников Вашей организации, высокое качество работы. Благодаря слаженным действиям команды экспертов и менеджеров сопровождения, экспертиза была проведена в кратчайшие сроки и на высоком профессиональном уровне.
Желаем Вам профессионального роста и успехов в бизнесе.
Генеральный директор Поваляев А.В.
ГРУППА КОМПАНИЙ «ИСТА»
Благодарственное письмо
Компания ООО «ИСТА-Техника» характеризует филиал органа по сертификации «СЕРКОНС» в г. Санкт-Петербург как профессионального и надежного партнера в области обязательного подтверждения соответствия продукции требованиям ТР ЕАЭС 043/217.
Квалифицированные менеджеры и их ассистенты — Лукконен Александра Владимировна, Васильевская Дарья Алексеевна, Савченко Анастасия Николаевна, а также экспертный состав испытательных лабораторий «СЗРЦ ПБ» и «НОРМАТЕСТ», продемонстрировали глубокое знание специфики продукции в области пожарной безопасности.
Компания ООО «ИСТА-Техника» характеризует филиал органа по сертификации «СЕРКОНС» в г. Санкт-Петербург как профессионального и надежного партнера в области обязательного подтверждения соответствия продукции требованиям технического регламента Евразийского экономического союза «О требованиях к cредствам обеспечения пожарной безопасности и пожаротушения» ТР ЕАЭС 043/2017.
С уважением,
Директор центра пожарной безопасности,
Павлов А.П.
Смотреть все
Среди наших клиентов
В данной статье я попытался подробно рассмотреть проблему разработки Технических заданий. Тема стара, как и проблема. Но она до сих пор часто решается «как получится». Как сказал Генри Шоу «Мелочи тревожат нас больше всего: легче увернуться от слона, чем от мухи».
О чем эта статья?
Меня часто спрашивают: «Как правильно разработать техническое задание для автоматизированной системы?». Аналогичная тема постоянно обсуждается на различных форумах. Этот вопрос настолько широкий, что ответить в двух словах никак нельзя. Поэтому я решил написать большую статью на данную тему. В процессе работы над статьей я понял, что уложить все в одной статье не выйдет, т.к. получится под 50 страниц и решил разбить ее на 2 части:
-
В первой части «Разработка Технического задания. Что это такое, зачем оно нужно, с чего начать и как должно выглядеть?» я подробно попытаюсь ответить на вопросы темы, рассмотрю структуру и назначение Технического задания, дам некоторые рекомендации по формулировке требований.
-
Вторая часть «Разработка Технического задания. Как формулировать требования?» будет полностью посвящена выявлению и формулировке требований к информационной системе.
Для начала надо разобраться, какой в действительности вопрос интересует тех, кто спрашивает «Как разработать техническое задание?» Дело в том, что от того, для каких целей это делается, а также кем будет использоваться, будет сильно зависеть и подход к разработке технического задания. О каких вариантах я говорю:
-
Коммерческая организация решила внедрить у себя автоматизированную систему. Она не имеет собственной IT-службы и решили поступить так: Заинтересованное лицо должно разработать Техническое задание и отдать его на разработку сторонней организации;
-
Коммерческая организация решила внедрить у себя автоматизированную систему. Она имеет собственную IT-службу. Решили поступить так: разработать Техническое задание, затем согласовать его между IT-службой и заинтересованными лицами, и реализовать собственными силами;
-
Госструктура решила затеять IT-проект. Тут все настолько мутно, куча формальностей, откатов, распилов и пр. Я не буду рассматривать такой вариант в данной статье.
-
IT-компания занимается услугами по разработке и/или внедрению автоматизированных систем. Это наиболее сложный случай, ведь приходится работать в самых различных условиях:
-
Клиент имеет своих специалистов со своими взглядами, и они предъявляют конкретные требования к Техническому заданию;
-
Техническое задание разрабатывается для собственных разработчиков (клиенту все равно);
-
Техническое задание разрабатывается для передачи подрядчику (т.е. группе программистов, находящихся за штатом компании, или отдельному специалисту);
-
Между компаний и клиентом возникает непонимание в вопросе полученного результата, и компания вновь и вновь задается вопросом: «Как надо разрабатывать Техническое задание?». Возможно, последний случай кажется парадоксом, но это правда.
-
Возможны и другие, реже встречающиеся варианты;
-
Думаю, сейчас у читателя должны возникнуть вопросы:
-
А почему нельзя разрабатывать Техническое задание всегда одинаково?
-
Существуют ли какие-то стандарты, методики, рекомендации? Где их взять?
-
Кто должен разрабатывать Техническое задание? Должен ли этот человек обладать какими-то специальными знаниями?
-
Как понять, хорошо составлено Техническое задание или нет?
-
За чей счет должно оно разрабатываться, да и нужно ли оно вообще?
Этот список может быть бесконечным. Говорю так уверенно от того, что уже 15 лет в профессиональной разработке программного обеспечения, а вопрос о Технических заданиях всплывает в любом коллективе разработчиков, с кем приходиться работать. Причины тому разные. Поднимая тему разработки Технического задания, я прекрасно отдаю себе отчет в том, что не смогу изложить ее на 100% для всех интересующихся темой. Но, попробую, как говорится «разложить все по полочкам». Те, кто уже знаком с моими статьями знают, что я не пользуюсь «копи-пастом» труда других людей, не перепечатываю чужие книги, не цитирую многостраничные стандарты и прочие документы, которые Вы и сами сможете найти в интернете, выдавая их за свои гениальные мысли. Достаточно набрать в поисковике «Как разработать Техническое задание» и Вы сможете прочитать много интересного, но, к сожалению, многократно повторяющегося. Как правило, те, кто любит умничать на форумах (попробуйте все-таки поискать!), сами никогда не делали толкового Технического задания, и непрерывно цитируют рекомендации ГОСТов по данному вопросу. А тем, кто действительно серьезно занимается вопросом, обычно некогда сидеть на форумах. Про ГОСТЫ, кстати, мы тоже поговорим. В разные годы своей работы мне приходилось видеть множество вариантов технической документации, составленной как отдельными специалистами, так и именитыми командами и консалтинговыми компаниями. Иногда еще я занимаюсь такой деятельностью: выделяю себе время и занимаюсь поиском информации на интересующую тему по необычным источникам (такой небольшой разведкой). В результате приходилось видеть документацию и по таким монстрам, как ГазПром, РЖД и много других интересных компаний. Конечно же, я соблюдаю политику конфиденциальности, несмотря на то, что эти документы попадают ко мне из общедоступных источников или безответственности консультантов (разбрасывают информацию по интернету). Поэтому сразу говорю: конфиденциальной информацией, которая принадлежит другим компаниям не делюсь, независимо от источников возникновения (профессиональная этика).
Как ни странно, проблемы у всех одинаковые! У всех бывают как успешные документы (и проекты), так и совсем бестолковые (исключение, пожалуй, составляют Технические задания, разработанные еще во времена, когда не было персональных компьютеров, но там были совсем другие условия). Почему так получается? Именно потому, что цели у проектов бывают разные, как и пользователи этих документов. И, конечно, компетенции непосредственных специалистов не на последнем месте. В этих двух статьях я попытаюсь поделиться своим личным опытом, накопленном за многие годы. Конечно, получится в сжатом виде, т.к. вопрос достоин целой книги (кстати, идея, а может написать?)…
Что такое техническое задание?
Первое, что мы сейчас сделаем, так это разберемся с тем, что за зверь такой, «Техническое задание».
Да, действительно существуют ГОСТы и стандарты, в которых предприняты попытки регламентировать эту часть деятельности (разработки программного обеспечения). Когда-то все эти ГОСТы были актуальны и активно применялись. Сейчас существуют разные мнения по поводу актуальности данных документов. Одни утверждают, что ГОСТы были разработаны очень дальновидными людьми и до сих пор актуальны. Другие говорят, что они безнадежно устарели. Возможно, кто-то сейчас подумал, что правда где-то по серединеJ. Я бы ответил словами Гете: «Говорят, что между двумя противоположными мнениями находится истина. Ни в коем случае! Между ними лежит проблема». Так вот, между этими мнениями истины нет. Потому как ГОСТы не раскрывают практических проблем современной разработки, а те, кто их критикует, альтернативы (конкретной и системной) не предлагают.
Заметим, что в ГОСТе явно не дано даже определения, сказано лишь: «ТЗ на АС является основным документом, определяющим требования и порядок создания (развития или модернизации — далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие».
Если кому-то интересно, о каких ГОСТах я говорю, то вот они:
-
ГОСТ 2.114-95 Единая система конструкторской документации. Технические условия;
-
ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению;
-
ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.
Куда более удачное определение представлено в википедии (правда про ТЗ в целом, а не только для программного обеспечения ): «Техническое задание – это исходный документ на проектирование технического объекта. Техническое задание устанавливает основное назначение разрабатываемого объекта, его технические и тактико-технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования. Задание как исходный документ на создание чего-то нового существует во всех областях деятельности, различаясь по названию, содержанию, порядку оформления и т. п. (например, проектное задание в строительстве, боевое задание, домашнее задание, договор на литературное произведение и т. д.)»
Отличное определение, полностью раскрывающее суть. Впрочем, требования ГОСТа направлены как раз на раскрытие этого определения. Я ни в коем случае не критикую требования ГОСТа, я просто утверждаю, что их там явно недостаточно, чтобы разработать эффективное Техническое задание. И это нормально, ведь есть ГОСТ, например, на изготовление хлеба, и это вовсе не значит, что любой человек может выпечь хлеб по ГОСТу. Кроме ГОСТа требуется знание методик и практик, как в любом деле. Именно этот факт лежит в корне проблемы, которая лежит посерединеJ. А многие специалисты почему-то при необходимости разработать Техническое задание, обращаются только к требованиям ГОСТа. Ну, давайте начнем жить по ГОСТу, посмотрим, что получится! Но ведь не может такого быть, что в столь распространенном занятии, как разработка и внедрение автоматизированных систем не проводилось исследований, не изучались практики, не писалось книг об этих самых практиках! И это так. Конечно, есть много отличных (!) трудов, посвященных тематике формулирования требований и в конце статьи я приведу такие примеры. Многое в своей практике я использовал именно оттуда, а когда работал над этой статьей, то тоже нашел много интересных мыслей, которыми рад буду поделиться. Так что, велосипеда изобретать не нужно, но есть потребность систематизировать эти знания. Кстати, любопытный факт, ни одного отечественного автора в этих трудах нет. Вся литература в переводе с западных авторов, но зато каких! Среди них есть просто виртуозы своего дела, у которых есть чему поучиться и нужно это делать. Иначе, споры о том, «Как разработать техническое задание» будут продолжаться бесконечно. Однако, я увлекся лирикой…
И так, как следует из определения, основное назначение Технического задания — сформулировать требования к разрабатываемому объекту, в нашем случае к автоматизированной системе.
Именно основное, но единственное. Настало время взяться за главное: разложить все «по полочкам», как и обещал.
Что необходимо знать о требованиях? Необходимо четко понимать, что все требования нужно разделять по видам и по свойствам. Сейчас мы научимся это делать. Для разделения требований по видам нам как раз поможет ГОСТ. Тот перечень видов требований, который там представлен, является хорошим образцом того, требования каких видов следует рассматривать. Например:
-
Требования в функциональности;
-
Требования к безопасности и правам доступа;
-
Требования к квалификации персонала;
-
…. И т.д. Вы можете прочитаете о них в упомянутом ГОСТе (а ниже я их тоже рассмотрю немного подробнее).
Думаю, для Вас очевидно, что ключевым фактором успешного Технического задания являются именно хорошо сформулированные требования к функциональности. Именно этим требованиям посвящено большинство работ и методик, о которых я говорил. Требования к функциональности – это 90% сложности работ по разработке Технического задания. Все остальное зачастую является «камуфляжем», который надет на эти требования. Если требования сформулированы плохо, то какой красивый камуфляж на них не натягивай, успешного проекта не выйдет. Да, формально все требования будут соблюдены (по ГОСТу J), ТЗ разработано, утверждено и подписано, деньги за него получены. И что? А дальше начнется самое интересное: что делать-то? Если это проект на ГосЗаказе, то проблем нет – там бюджет такой, что ни в какой карман не влезет, в процессе реализации (если она будет) все и будет выясняться. Именно таким образом и пилится большинство бюджетов проектов на ГосЗаказах (накалякали «ТЗ», слили десяток миллионов, а проект делать не стали. Все формальности соблюдены, виновных нет, новое авто возле дома. Красота!). Но ведь мы говорим о коммерческих организациях, где деньги считают, да и результат нужен другой. Поэтому давайте разбираться с главным, как разрабатывать полезные и работающие Технические задания.
Про виды требований я сказал, а что же со свойствами? Если виды требований могут быть различными (зависит от целей проекта), то со свойствами все проще, их 3:
-
Требование должно быть понятным;
-
Требование должно быть конкретным;
-
Требование должно быть тестируемым;
Причем последнее свойство невозможно без двух предыдущих, т.е. является этакой «лакмусовой бумажкой». Если результат выполнения требования невозможно протестировать, значит, оно либо не понятное, либо не конкретное. Подумайте об этом. Именно во владении этими тремя свойствами требований и заключается мастерство и профессионализм. На само деле все очень просто. Когда разберешься.
На этом повествование о том, что такое Техническое задание можно было бы завершить и перейти к главному: как формулировать требования. Но не так все быстро. Есть еще один крайне важный момент:
-
на каком языке (в смысле сложности понимания) должно быть написано техническое задание?
-
Должны ли быть описаны в нем спецификации различных функций, алгоритмы, типы данных и прочие технические штуки?
-
А что такое техническое проектирование, о котором, кстати, сказано и в ГОСТах, и как оно связано с Техническим заданием?
В ответах на эти вопросы кроется очень коварная вещь. Именно поэтому часто возникают споры о достаточности или отсутствии необходимой детализации требований, о понятности документа Заказчиком и Исполнителями, об избыточности, формате представления и т.д. А где вообще граница между Техническим заданием и Техническим проектом?
Так вот:
Техническое задание – это документ, в основе которого лежат требования, сформулированные на понятном (обычном, привычном) для Заказчика языке. При этом может и должна использоваться отраслевая терминология, понятная Заказчику. Никаких привязок к особенностям технической реализации быть не должно. Т.е. на этапе ТЗ в принципе не важно, на какой платформе будут реализовываться эти требования. Хотя есть исключения. Если речь идет о внедрении системы на основе уже существующего программного продукта, то такая привязка может иметь место, но только на уровне экранных форм, форм отчетов и пр. Выяснением и формулированием требований, а также разработкой Технического задания должен заниматься бизнес-аналитик. И уж никак не программист (если только он не совмещает в себе эти роли, такое случается). Т.е. этот человек должен говорить с Заказчиком на языке его бизнеса.
Технический проект – это документ, который предназначен для технической реализации требований, сформулированных в Техническом задании. Как раз в этом документе описываются структуры данных, триггеры и хранимые процедуры, алгоритмы и прочие штуки, которые потребуютсятехническим специалистам. Заказчику в это вникать вовсе не обязательно (ему и термины такие могут быть непонятны). Технический проект делает Архитектор системы (вот совмещение этой роли с программистом вполне нормально). А точнее группа специалистов во главе с архитектором. Чем больше проект, тем и больше людей работает над Техническим заданием.
Что мы имеем на практике? Забавно наблюдать, когда директору приносят на согласование Техническое задание, которое изобилует технической терминологией, описанием типов данных и их значений, структуры базы данных и пр. Он, конечно, пытается вникнуть, раз надо утверждать, пытаясь найти между строк знакомые слова и не потерять цепочку бизнес-требований. Что, знакомая ситуация? И чем это заканчивается? Как правило, такое ТЗ утверждается, затем реализуется, а в 80% случаев потом совсем не соответствует факту выполненных работ, т.к. много чего решили изменить, переделать, неправильно поняли, не так думали и т.д. и т.п. А потом начинается сериал про сдачу работ. «А вот тут не так как нам надо», а «это у нас работать не будет», «это слишком сложно», «это неудобно» и т.д. Знакомо?!! Вот и мне знакомо, пришлось набить шишек в свое время.
Так что мы имеем на практике-то? А на практике мы имеем размытую границу между Техническим заданием и Техническим проектом. Она плавает между ТЗ и ТП в самых разных проявлениях. И это плохо. А получается так потому, что культура разработки стала слабой. Частично это связано с компетенциями специалистов, частично со стремлением сократить бюджеты и сроки (ведь документация занимает много времени — это факт). Есть и еще один важный фактор, влияющий на использование Технического проекта как отдельного документа: стремительное развитие средств быстрой разработки, а также методологий разработки. Но это отдельная история, чуть ниже несколько слов об этом скажу.
Еще небольшой, но важный момент. Иногда Техническим заданием называют небольшой кусочек требований, простой и понятный. Например, доработать поиск объекта по каким-либо условиям, добавить колонку в отчет и пр. Такой подход вполне себе оправдан, зачем усложнять жизнь. Но применяется не на больших проектах, а на мелких доработках. Я бы сказал это ближе к сопровождению программного продукта. В этом случае в Техническом задании может быть описано и конкретное техническое решение реализации требования. Например, «В алгоритм такой-то внести такое-то изменение», с указанием конкретной процедуры и конкретного изменения для программиста. Это тот случай, когда граница между Техническим заданием и Техническим проектам полностью стирается, т.к. нет никакой экономической целесообразности раздувать бумаготворчество там, где это не нужно, а полезный документ создается. И это правильно.
Управленческий учет: с нуля до настройки в 1С, Excel и Google-таблицах
Уметь настраивать и вести управленку — значит быть полезным для руководителей. Научитесь понимать, откуда приходят и куда уходят деньги компании на курсе повышения квалификации от «Клерка».
А нужно ли вообще техническое задание? А Технический проект?
Не перегрелся ли я? Разве такое возможно, вообще без Технического задания? Представьте себе возможно (точнее, встречается), и у такого подхода есть много последователей, и их число увеличивается. Как правило, после того, как молодые специалисты начитаются книг про Scrum, Agile и прочие технологии быстрой разработки. На самом деле это замечательные технологии, и они работают, только в них не говорится дословно «не надо делать технических заданий». В них говорится «минимум бумаг», особенно ненужных, ближе к Заказчику, больше конкретики и быстрее к результату. Но фиксирование требований никто не отменял, и там это явно сказано. Как раз там требования и фиксируются исходя из трех замечательных свойств, о которых я говорил выше. Просто у некоторых людей так устроено сознание, что если можно что-то упростить, так давайте это упростим до полного отсутствия. Как сказал Эйнштейн «Сделай так просто, как возможно, но не проще этого». Золотые ведь слова, ко всему подходят. Так что Техническое задание нужно, иначе успешного проекта Вам не видать. Другой вопрос, как составлять и что туда включать. В свете методологий быстрой разработки надо сосредоточиться только на требованиях, а весь «камуфляж» можно отбросить. В принципе, я с этим согласен.
А что же с Техническим проектом? Данный документ весьма полезный и не утратил свою актуальность. Более того, часто без него просто не обойтись. Особенно, если речь идет о передаче работ по разработке на сторону, т.е. по принципу аутсорсинга. Если этого не сделать, есть риск узнать много нового о том, как должна выглядеть система, которую Вы задумалиJ. Должен ли с ним знакомиться Заказчик? Если хочет, почему нет, но настаивать и утверждать данный документ нет никакой необходимости, он будет только сдерживать и мешать работать. Спроектировать систему до мелочей практически невозможно. В этом случае придется непрерывно вносить изменения в Технический проект, что занимает немало времени. А если организация сильно забюрократизирована, то вообще все нервы там оставите. Как раз о сокращении такого рода проектирования и идет речь в современных методологиях быстрой разработки, о которых я упоминал выше. Кстати, все они базируются на классическом XP (экстремальном программировании)- подходе, которому уже порядка 20 лет. Так что сделайте качественное Техническое задание, понятно Заказчику, а Технический проект используйте как внутренний документ, для взаимоотношений между архитектором системы и программистами.
Интересная деталь по поводу технического проектирования: некоторые средства разработки, устроенные по принципу предметной ориентированности (типа 1С и аналогичных) предполагают, что проектирование (имеется ввиду процесс документирования) требуется только на действительно сложных участках, где требуется взаимодействие между собой целых подсистем. В простейшем случае, например создать справочник, документ, достаточно лишь правильно сформулированных бизнес-требований. Об этом говорит и стратегия бизнеса этой платформы в части подготовки специалистов. Если посмотреть на экзаменационный билет специалиста (именно так он называется, а не «программиста»), то Вы увидите, что там присутствуют лишь бизнес-требования, а как их реализовать на программном языке это и есть задача специалиста. Т.е. ту часть задачи, которую призван решать Технический проект, специалист должен решить «в голове» (речь идет о задачах средней сложности), причем здесь и сейчас, следуя определенным стандартам разработки и проектирования, которые формирует опять же компания 1С для своей платформы. Таким образом, из двух специалистов, результат работы которых внешне выглядит одинаково, один может экзамен сдать, а второй нет, т.к. грубо нарушил стандарты разработки. Т.е заведомо предполагается, что специалисты должны обладать такой квалификацией, чтобы типичные задачи проектировать самостоятельно, без привлечения архитекторов системы. И такой подход работает.
Продолжим исследование вопроса: «Какие требования включать в Техническое задание?»
Формулирование требований к информационной системе. Структура Технического задания
Сразу определимся: мы будет говорить именно о формулировании требований к информационной системе, т.е. предполагая, что работа по выработке бизнес-требований, формализации бизнес-процессов и вся предшествующая консалтинговая работа уже выполнена. Конечно, некоторые уточнения могут выполняться и на этом этапе, но именно уточнения. Сам проект автоматизации не решает проблем бизнеса – помните об этом. Это аксиома. Почему-то некоторые руководители пытаются ее опровергнуть, считая, что если купят программу, то наступит порядок в хаотичном бизнесе. Но ведь аксиома на то и аксиома, что доказательств не требует.
Как и любую деятельность, формулирование требований можно (и нужно) разделить на этапы. Всему свое время. Это тяжелый интеллектуальный труд. И, если относится к нему с недостаточным вниманием, то результат будет соответствующий. По экспертным оценкам, стоимость затрат на разработку Технического задания может составлять 30-50%. Я придерживаюсь такого же мнения. Хотя 50 – пожалуй, перебор. Ведь Техническое задание – это еще не последний документ, который должен быть разработан. Ведь еще должно быть и техническое проектирование. Такой разброс обусловлен различными платформами автоматизации, подходами и технологиями, применяемыми проектными командами при разработке. Например, если речь идет о разработке на классическом языке типа С++, то без детального технического проектирования тут не обойтись. Если речь идет о внедрении системы на платформе 1С, то тут с проектированием ситуация несколько иная, как мы видели выше (хотя, при разработке системы «с нуля», она проектируется по классической схеме).
Несмотря на то, что формулировка требований является основной частью Технического задания, а некоторых случая она становиться единственным разделом ТЗ, следует обратить внимание на то, что это важный документ, и оформлять его следует соответственно. С чего начать? В первую очередь начать надо с содержания. Составьте содержание, а затем начните его разворачивать. Лично я делаю так: сначала набрасываю содержание, описываю цели, всю вводную информацию, а затем принимаюсь за основную часть – формулировку требований. Почему не наоборот? Не знаю, мне так удобнее. Во-первых, это гораздо меньшая часть времени (по сравнению с требованиями), во-вторых, пока описываешь всю вводную информацию, настраиваешься на главное. Ну это кому как нравится. Со временем у Вас выработается свой шаблон Технического задания. Для начала рекомендую в качестве содержания взять именно тот, что описан в ГОСТ. Для содержания он подходит отлично! Затем берем и начинаем описывать каждый раздел, не забывая про рекомендации следования трем свойствам: понятности, конкретности и тестируемости. Почему я на этом так настаиваю? Об этом в следующем разделе. А сейчас предлагаю все-такт пройтись по тем пунктам ТЗ, которые рекомендуются в ГОСТе.
И так, ГОСТ рекомендует следующие разделы:
-
общие сведения;
-
назначение и цели создания (развития) системы;
-
характеристика объектов автоматизации;
-
требования к системе;
-
состав и содержание работ по созданию системы;
-
порядок контроля и приемки системы;
-
требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
-
требования к документированию;
-
источники разработки.
Итого, 9 разделов, каждый из которых тоже делится на подразделы. Разберем их по-порядку. Для удобства представлю все в виде таблицы по каждому пункту.
Раздел 1. общие сведения.
|
Рекомендации по ГОСТ |
Что с этим делать на практике |
|
полное наименование системы и ее условное обозначение; |
Тут все понятно: пишем, как будет называться система, ее краткое наименование |
|
шифр темы или шифр (номер) договора; |
Это не актуально, но можно и указать, если требуется |
|
наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты; |
указывают, кто (какие организации) будут работать над проектом. Можно указать и их роли. Можно вообще удалить этот раздел (достаточно формальный). |
|
перечень документов, на основании которых создается система, кем и когда утверждены эти документы; |
Полезная информация. Тут стоит указать ту нормативно-справочную документацию, которую Вам предоставили для ознакомления с определенной частью требований |
|
плановые сроки начала и окончания работы по созданию системы; |
Пожелания по срокам. Иногда в ТЗ об этом пишут, но чаще такие вещи описываются в договорах на работы |
|
сведения об источниках и порядке финансирования работ; |
Аналогично, как и в предыдущем пункте про сроки. Более актуально для государственных заказов (для бюджетников) |
|
порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы. |
Не вижу необходимости в этом пункте, т.к. требования к документированию вынесены отдельно, а кроме этого есть целый отдельный раздел «Порядок контроля и приемки» системы. |
Раздел 2. назначение и цели создания (развития) системы.
|
Рекомендации по ГОСТ |
Что с этим делать на практике |
|
Назначение системы |
С одной стороны с назначением все просто. Но желательно формулировать конкретно. Если написать что-то вроде «качественно автоматизировать складской учет в компании Х», то потом можно долго обсуждать результат при его завершении, даже независимо от хорошей формулировки требований. Т.к. Заказчик всегда может говорить, что под качеством он имел ввиду нечто иное. В общем, нервов можно попортить друг другу много, а зачем? Лучше сразу написать примерно так: «Система предназначена для ведения складского учета в компании Х в соответствии с требованиями, зафиксированными в данном Техническом задании». |
|
Цели создания системы |
Цели – это безусловно важный раздел. Если уж его включать, то надо уметь эти цели формулировать. Если у Вас трудности с формулировкой целей, то лучше вообще исключить данный раздел. Пример неудачной цели: «Обеспечить быстрое оформление документов менеджером». Что такое быстрое? Это можно потом доказывать бесконечно. Если это важно, то лучше переформулировать данную цель так: «Менеджер по продажам должен иметь возможность оформить документ «Реализация товаров» из 100 строк за 10 минут». Подобная цель может появиться, если, например, в настоящее время менеджер тратит на это около часа, что слишком много для этой компании и для них это важно. В такой формулировке цель уже пересекается с требованиями, что вполне естественно, т.к. при разворачивании дерева целей (т.е. дробя их на более мелкие связанные цели), мы и так будем приближаться к требованиям. Поэтому, увлекаться не стоит. Вообще, умение выделять цели, формулировать их, строить дерево целей это тема совершенно отдельная. Запомните главное: умеете – пишите, не уверены – вообще не пишите. А что будет, если не сформулировать цели? Будете работать по требованиям, такое часто практикуется. |
Раздел 3. Характеристика объектов автоматизации.
|
Рекомендации по ГОСТ |
Что с этим делать на практике |
|
краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию |
На практике обычно это не включают. Но можно привести ссылки на документы, которые полезно изучить составу проектной команды для погружения в вопрос (отраслевые особенности, например) |
|
сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды |
Не актуально для проектов по автоматизации учета |
Раздел 4. Требования к системе
|
Рекомендации по ГОСТ |
Что с этим делать на практике |
|
Требования к системе в целом. ГОСТ расшифровывает перечень таких требований:
|
Несмотря на то, что основным, безусловно, будет раздел с конкретными требованиями (функциональными), данный раздел тоже может иметь большое значение (и в большинстве случаев имеет). Что может оказаться важным и полезным:
Все остальные требования менее важны и можно их не описывать. На мой взгляд, они только утяжеляют документацию, и практической пользы несут немного. А Требования к эргономике описывать в виде общих требований очень сложно, лучше их перенести к функциональным. Например, может быть сформулировано требование «Получить информацию о цене товара нажав только одну кнопку». На мой взгляд, это все-таки ближе к конкретным функциональным требованиям, хоть и относится к эргономике. |
|
Требования к функциям (задачам), выполняемым системой |
Вот он, тот самый главный и ключевой пункт, который будет определять успех. Даже если все остальной сделать на отлично, а этот раздел на «3», то и результат по проекту будет в лучшем случае на «3», а то и вообще проект провалится. Именно эти мы и займемся более детально во второй статье. Именно к этому пункту относится «правило трех свойств требований», о которых я говорил. |
|
Требования к видам обеспечения ГОСТ выделяет такие виды:
|
На первый взгляд может показаться, что эти требования не важны. В большинстве проектов это действительно так. Но не всегда. Когда стоит описывать данные требования:
|
Раздел 5. Состав и содержание работ по созданию системы
|
Рекомендации по ГОСТ |
Что с этим делать на практике |
|
Перечень стадий и этапов работ по созданию системы в соответствии с ГОСТ 24.601, сроки их выполнения, перечень организаций — исполнителей работ, ссылки на документы, подтверждающие согласие этих организаций на участие в создании системы, или запись, определяющую ответственного (заказчик или разработчик) за проведение этих работ |
Другими словами, это план разработки системы, ее этапность, возможность привлечения подрядчиков и т.п. |
Раздел 6. Порядок контроля и приемки системы
|
Рекомендации по ГОСТ |
Что с этим делать на практике |
|
Виды, состав, объем и методы испытаний системы и ее составных частей (виды испытаний в соответствии с действующими нормами, распространяющимися на разрабатываемую систему); Общие требования к приемке работ по стадиям (перечень участвующих предприятий и организаций, место и сроки проведения), порядок согласования и утверждения приемочной документации; |
Настоятельно рекомендую с ответственностью отнестись к порядку сдачи работ и проверке системы. Именно для этого и нужны тестируемые требования. Но даже наличие тестируемых требований может оказаться недостаточно при сдаче системы, если четко не прописан порядок приемки-передачи работ. Например, распространенная ловушка: система сделана, вполне работоспособна, но Заказчик по каким-либо причинам не готов в ней работать. Причины эти могут быть любые: некогда, поменялись цели, кто-то уволился и т.п. И говорит: «Поскольку мы еще не работаем в новой системой, значит и не можем быть уверены, что она работает». Так что учитесь правильно выделять этапы работ, способы проверки результатов по этим этапам. Причем Заказчику такие способы должны быть понятны изначально. Если они зафиксированы на уровне Технического задания, то всегда можно при необходимости к ним обратится и подвести работы с передаче. |
Раздел 7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
|
Рекомендации по ГОСТ |
Что с этим делать на практике |
|
Приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ; |
Весьма важный момент. К примеру, для функционирования системы так, как задумано, может потребоваться использование каких-либо отраслевых или общероссийских справочников и классификаторов. Эти справочники должны каким-то образом появляться в системе, обновляться и правильно использоваться. Могут быть и любые другие правила ввода информации, принятые в компании (или планируемые). Например, информация о договоре раньше заносили текстовой строкой в произвольном виде, а теперь требуется номер отдельно, дату отдельно и т.д. Таких условий может быть очень много. Часть из них может быть воспринята с сопротивлением персонала, поэтому лучше все такие случаи прописать на уровне требований к порядку ввода данных |
|
Изменения, которые необходимо осуществить в объекте автоматизации Создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ |
Любые изменения, которые могут потребоваться. Например, в компании отсутствует локальная сеть, устаревший парк компьютеров, на которых система не заработает. Возможно, какая-то необходимая информация обрабатывалась на бумаге, а теперь ее необходимо вводить в систему. Если этого не делать, то какой-либо модуль не заработает и т.п. Возможно, что-то упрощалось, а теперь требуется учитывать более детально, соответственно кто-то должен собирать информацию по определенным правилам. Этот перечень может быть длинным, смотрите на конкретный случай своего проекта. |
|
Создание необходимых для функционирования системы подразделений и служб; Сроки и порядок комплектования штатов и обучения персонала |
Про это мы уже говорили ранее. Возможно, система разрабатывается под новую структуру или вид деятельности, которого раньше не было. Если не будет соответствующего персонала, да еще и обученного, то система не заработает, как грамотно ее не строй. |
Раздел 8. Требования к документированию
|
Рекомендации по ГОСТ |
Что с этим делать на практике |
|
Согласованный разработчиком и Заказчиком системы перечень подлежащих разработке комплектов и видов документов |
Наличие полноценной документации – важная часть результата. Все мы знаем, что документирование чего-либо трудоемкий труд. Поэтому, необходимо заранее оговорить с Заказчиком, какие виды документации будут разрабатываться, как они будут выглядеть (содержание и желательно примеры). Подумайте, как будут представлены руководства пользователя. Возможно, у Заказчика есть принятые корпоративные стандарты, значит надо к ним обращаться. Игнорирование требований к документации очень часто приводит к самым неожиданным последствиям на проектах. Например, все сделано и все работает. Пользователи тоже умеют работать. Про документацию вообще не договаривались и не разговаривали. И вдруг при сдаче работ кто-то из топ-менеджеров Заказчика, который даже не участвовал в проекте, но участвует в приемке работ, Вас спрашивает: «А где руководства пользователя?» И начинает Вас убеждать, что о наличии руководств пользователя договариваться было и не нужно, это «само собой» якобы подразумевается. И все, не хочет принимать у Вас работу. За чей счет будете разрабатывать руководства? На этот крючок попадали уже многие команды. |
Раздел 9. Источники разработки
|
Рекомендации по ГОСТ |
Что с этим делать на практике |
|
Должны быть перечислены документы и информационные материалы (технико-экономическое обоснование, отчеты о законченных научно-исследовательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др.), на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы. |
Если честно, это ближе к лирике. Особенно, когда говорят об экономическом эффекте и пр. вещах, которые объективно посчитать практически невозможно. Т.е. можно конечною, то это будет скорее на бумаге, чисто теоретически. Поэтому, лучше сослаться просто на отчет об обследовании, требования ключевых лиц. |
И так, мы рассмотрели все разделы, которые могут быть включены в Техническое задание. «Могут», а не «Обязаны» именно потому, что любой документ должен разрабатываться для достижения результата. Поэтому, если для Вас очевидно, что какой-то отдельный раздел к результату не приблизит, значит он Вам не нужен и не надо тратить на него время.
Но вот без главного: функциональных требований ни одно грамотно Техническое задание не обходится. Хочу заметить, что в практике такие Технические задания встречаются, и еще как! Есть деятели, которые сумеют развести воды по всем разделам, опишут общие требования общими словами, и документ получается весьма увесистый, и слов в нем умных много, и даже Заказчику может понравится (т.е. он его утвердит). Но вот работать по нему может не получиться, т.е. практической пользы от него мало. В большинстве случаев такие документы рождаются, когда надо получить много денег именно под Техническое задание, а сделать его надо быстро и не погружаясь в детали. А особенно, если известно, что дальше дело не пойдет, или его будут делать совсем другие люди. В общем, просто для освоения бюджета, особенно государственного.
Во второй статье будем говорить только о разделе 4 «Требования к системе», а конкретно мы будет формулировать требования из соображений понятности, конкретности и тестируемости.
Почему требования должны быть понятными, конкретными и тестируемыми.
Потому, что практика показывает: по началу большинство ТЗ, которые разрабатывают специалисты либо оказываются не востребованы (не соответствуют действительности), либо становятся проблемой для того, кто из должен реализовать, т.к. Заказчик начинает манипулировать неконкретными терминами и требованиями. Приведу несколько примеров того, какие фразы встречались, к чему это приводило, а затем попробую дать рекомендации, как избежать подобных проблем.
|
Вид требования |
Неправильная формулировка |
Комментарий и как можно было сформулировать |
|
Функциональность |
«Сумма затрат должна корректно распределяться по соответствующим товарам» |
Понятное ли это требование? В общем-то понятное, речь идет о распределении неких затрат по группе товаров. Конкретное ли это требование? Не сказано, как должна распределяться затрата, по сумме, по количеству, равномерно или как-то иначе? Тестируемое ли это требование? Вроде бы простая вещь, но как ее проверять, если нет конкретики? Как можно было бы это переформулировать: «Сумма затрат, указанная в документе, должна распределиться на все товары, указанные в данном документе пропорционально стоимости этих товаров». Получилось и понятно, и конкретно. Как проверить тоже не составит труда. |
|
Эргономичность |
Программа должна иметь удобный интерфейс |
Признаться, под данной формулировкой пришлось однажды подписаться самому – проблем потом было не сосчитать. Конечно же, подобных формулировок быть не должно. Тут нет не конкретики, ни возможность проверить это требование. Хотя, безусловно, понятное (субъективно). Тут переформулировать никак нельзя, надо подробно расписывать каждый элемент «удобности», раз Заказчик на этом настаивает. Например:
|
|
Разграничение прав доступа |
Доступ к данным по прибыли должен быть доступен только финансовому директору |
Понятно? Почти. Правда, прибыль бывает разная, надо уточнить. Конкретно? Конечно нет. Как это видится в реализации? Если речь идет о валовой прибыли, то значит необходимо ограничивать доступ к данным о стоимости закупки, т.к. в противном случае валовую прибыль вычислить не составит труда, поскольку данные о стоимости реализации известны широкому кругу лиц. К тому, что относится к правам доступа, надо относиться очень аккуратно. А если у менеджеров по продажам мотивация построена на валовой прибыли, так эти требования еще и противоречат друг другу, т.к. менеджеры никогда не смогут это проверить. Если уж включать такое требование, то нужно указывать конкретные отчеты и объекты системы, в которых указывать, какая часть данных должны быть доступна отдельным категориям лиц. И рассматривать каждый такой случай индивидуально. |
|
Производительность |
Отчет по продажам должен формироваться за 1 минуту. |
Да, понятно. И даже есть конкретное ограничение по времени: 1 минута. Но не известно, какая детализация при этом предполагается: по каждому товару, группам товаров, клиентам или как-то еще? Можно сформулировать примерно так: «Отчет по продажам в разрезе клиентов с детализацией до каждой товарной позиции (см. образец) должен выводится не более, чем за 1 минуту при условии, что количество товаров в выборке не превышает 5000 строк». |
Надеюсь, идея понятна. Если будут конкретные вопросы, пишите, попробую помочь.
Чтобы в Техническом задании было больше конкретики, существует немало рекомендаций. Даже есть перечень слов, которые употреблять в Техническом задании не рекомендуется. Интересно об этом пишет К.Вигерс, в своей книге «Разработка требований к программному обеспечению». Приведу самые интересные и простые, на мой взгляд, рекомендации:
-
Не следует использовать слов, имеющих множество синонимов. Если это необходимо, то лучше дать четкое определение термину в разделе «Термины и определения» к Техническому заданию.
-
Следует стараться не использовать длинных предложений;
-
Если какое-то требование Вам кажется слишком общим, его необходимо детализировать до более мелких, но конкретных требований;
-
Используйте больше схем, графиков, таблиц, рисунков – так информацию воспринимается гораздо легче;
-
Следует избегать таких слов: «эффективный», «адекватный», «простой», «понятный», «быстрый», «гибкий», «улучшенный», «оптимальный», «прозрачный», «устойчивый», «достаточный», «дружественный», «легкий» и др. Перечень можно продолжать, но, мне кажется идея понятна (попробуйте его продолжить самостоятельно).
Все, что написано выше, это информация важная, но не самая. Как Вы помните, в начале статьи я это назвал термином «камуфляж», т.к. самое главное, что составит как минимум 90% времени и сложности работы над документом – это выявление и формулировка требований. А информацию о требованиях надо еще суметь собрать, структурировать и сформулировать. В этом, кстати, много общего между обследованием деятельности предприятий с последующим описанием бизнес-процессов. Но есть и важные различия. Одно из таких ключевых отличий – это наличия этапа построения прототипа будущей системы, или как его еще называют «модели информационной системы».
В следующей статье мы будем говорить только о методиках выявления требований, а также рассмотрим, что общего между работой по сбору требований к информационной системе и сбору информации для описания бизнес-процессов.