Техническое задание 1С

Что такое техническое задание на доработки 1С? С точки зрения ГОСТов*, в которых регламентирована деятельность по разработке программного обеспечения и автоматизированных систем (АС) – это основной документ, определяющий требования и порядок развития или модернизации (далее – создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие.

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

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

Зачем нужно техническое задание

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

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

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

Бесплатная
консультация
эксперта

Наталья Севорина

Консультант-аналитик 1С

Соглашаюсь на обработку персональных данных

Кто разрабатывает техническое задание

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

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

Документ базируется на ГОСТ 34.602-89, дающий формализованную структуру, но не имеющий четких требований к изложению разделов и пунктов. Эта особенность стандарта — его сила и его слабость. Свобода изложения может привести к тому, что требования разделов (особенно функциональные):

• Излагаются не системно, без привязки к какой-либо структуре (модули системы, бизнес-процессы);
• Дублируются;
• Относятся к различным уровням детализации.

Допущение ошибок при составлении технического задания приводит к увеличению стоимости и продолжительности проекта. Основная задача технического задания – оформить требования заказчика в понятном и возможном к реализации формате.

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

• Излишняя детализация;
• Требования, противоречащие друг другу;
• Неточные формулировки.

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

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

Как избежать ошибок при составлении ТЗ

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

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

Руководствоваться нужно следующими правилами:

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

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