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

Содержание

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

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

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

Для чего это?

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

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

Более сложные случаи

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

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

Есть еще масса других ситуаций, которые также нужно учитывать, но выше указаны только самые частые.

Что представляет собой ТЗ?

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

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

Особенности использования

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

Многие специалисты по какой-то причине, разрабатывая техническое задание на проектирование объекта или проведение определенных работ, основываются исключительно на требованиях ГОСТа, но в действительности это в корне неверный подход.

Главная задача

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

Как определиться с требованиями?

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

  • функциональность;
  • безопасность и права доступа;
  • квалификация персонала.

Чему уделить внимание?

Конечно, это далеко не полный перечень. Однако ключевым фактором, которым должен отличаться удачный пример технического задания, является правильно сформулированные требования к функциональности, и именно этим требованиям профессионалы посвящают преимущественное большинство методик и работ. Многие специалисты говорят о том, что требования к функциональности включают в себя примерно 90% от общей сложности работ, связанных с разработкой ТЗ, а все остальное представляет собой своеобразный «камуфляж», который потом будет надеваться на эти требования.

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

Полезные и эффективные разработки

Если виды требований могут быть самыми разными, и здесь все в основном зависит исключительно от целей проекта, то свойств всего три:

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

Дополнительные нюансы

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

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

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

Задание и проект

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

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

Отличия проекта от задания

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

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

Читайте также:  Постоянные и переменные расходы предприятия

Что на практике?

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

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

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

ТЗ – основополагающий документ, которым руководствуются разработчики и проектировщики, приступая к разработке нового изделия. Оно определяет основные направления разработки: конструкции и принципа работы будущего изделия. ТЗ заявляет, с одной стороны, о потребностях общества в новых изделиях, с другой – о технических и технико-экономических характеристиках изделия.

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

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

– основное назначение, технические и тактико-технические характеристики, уровень стандартизации и унификации;

– специальные требования к изделию и др.

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

– характеристика рынка сбыта;

– характеристика производства, на котором изделие будет изготавливаться (технологическая оснащенность, квалификация кадров, технологическая дисциплина, уровень организации труда и др.).

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

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

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

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

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

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

ГОСТ Р 15.201-2000. Система разработки и постановки продукции на производство (СРПП). Продукция производственно-технического назначения. Порядок разработки и постановки продукции на производство (приведены общие требования и краткие рекомендации по разработке).

ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению (кратко изложено содержание ТЗ);

ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы (достаточно подробно изложены состав и содержание ТЗ);

ГОСТ 25123-82. Машины вычислительные и системы обработки данных. Техническое задание. Порядок построения, изложения и оформления (приведен порядок построения ТЗ). Обобщая требования этих стандартов, порядок построения, изложения и оформления ТЗ можно свести к последовательности, представленной в таблице ниже.

Перечень рассматриваемых вопросов

Наименование и область применения (использования)

Наименование и условное обозначение продукции.

Краткая характеристика области техники, в которой предполагается использование продукции.

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

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

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

Цель и назначение разработки

Эксплуатационное и функциональное назначение и перспективность продукции

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

Состав продукции и требования к его устройству. Показатели назначения.

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

Требования к технологичности.

Требования к уровню унификации и стандартизации. Требования безопасности.

Эстетические и эргономические требования.

Требования к патентной чистоте.

Требования к составным частям продукции, сырью, исходным и эксплуатационным материалам. Условия эксплуатации (использования).

Требования к маркировке и упаковке.

Требования к транспортированию и хранению.

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

Ориентировочная экономическая эффективность и срок окупаемости затрат.

Предполагаемая годовая потребность в продукции.

Экономические преимущества разрабатываемой продукции по

сравнению с аналогами

Стадии и этапы разработки

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

Порядок контроля и приемки

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

Приложение к техническому заданию

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

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

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

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

– прогноз развития требований на данную продукцию на предполагаемый период ее выпуска;

– рекомендуемые этапы модернизации продукции с учетом прогноза развития требований;

– соответствие требованиям стран предполагаемого экспорта с учетом прогноза развития этих требований;

– возможность замены запасных частей без применения промышленной технологии;

– доступность и безопасность эффективного использования продукции инвалидами и гражданами пожилого возраста (для соответствующей продукции, предусмотренной законодательством Российской Федерации).

Техническое задание оформляют в соответствии с общими требованиями к текстовым конструкторским документам по ГОСТ 2.105-95 (ЕСКД. Общие требования к текстовым документам) на листах формата А4 , как правило, без рамки и основной надписи. Номера листов (страниц) проставляют в верхней части листа над текстом.

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

На любом этапе разработки продукции при согласии заказчика и разработчика в ТЗ или документ, его заменяющий, могут быть внесены изменения и дополнения, не нарушающие условия выполнения обязательных требований. Согласование и утверждение дополнений к ТЗ проводят в порядке, установленном для самого ТЗ. Изменения к ТЗ не допускается утверждать после представления изделия на приемо-сдаточные испытания. Регистрация, учет и хранение ТЗ и дополнений к нему проводят в соответствии с требованиями ГОСТ 2.501-88 (ЕСКД. Правила учета и хранения).

В качестве ТЗ может быть использован иной документ, содержащий необходимые и достаточные требования для разработки продукции и взаимопризнаваемый заказчиком и разработчиком. В случае инициативной разработки продукции ТЗ (или заменяющий его документ), базируется на результатах исследования рынка продукции, а также патентных исследований по ГОСТ Р 15.011- 96 (СРПП. Патентные исследования. Содержание и порядок проведения)

Не допускается включать в ТЗ требования, которые противоречат законам Российской Федерации и обязательным требованиям.

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

Как составить ТЗ: подробная инструкция по созданию технического задания

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

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

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

Для чего нужно техническое задание?

Техническое задание не менее значимо, чем юридический акт, в деле закрепления прав и обязанностей сторон — заказчика и исполнителя.

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

Когда каждая мелочь регламентирована, всё на своих местах, все при своих полномочиях и обязанностях, остаётся мало пространства для нечестного манёвра и недопонимания. Идеально, когда его вообще не остаётся.

Читайте также:  Штатная единица - это что такое в штатном расписании?

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

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

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

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

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

Во многих вакансиях на позицию системного аналитика или технического писателя можно встретить требование: знание ГОСТ 19 и ГОСТ 34. Что это такое?

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

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

Не пугайтесь, но ГОСТ 19 введён в 1980 году. Учитывая, что основа и парадигма программного обеспечения на протяжении долгого времени примерно та же, он пока не утратил своей актуальности. Это можно сравнить со строительством зданий. Конечно, меняются материалы и конструкции, но общие понятия — фундамент, стены, перекрытия — сохраняются.

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

Само техническое задание должно содержать следующие пункты:

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

Более новый стандарт — ГОСТ 34, но и здесь присутствует нюанс. Новее он только на 10 лет. То есть, введён с 1 января 1990 года.

Формулировка назначения выглядит так: «Распространяется на автоматизированные системы (АС) для автоматизации различных видов деятельности (управление, проектирование, исследование и т. п.), включая их сочетания…».

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

  • Общие сведения;
  • Назначение и цели создания (развития) системы;
  • Характеристика объектов автоматизации;
  • Требования к системе;
  • Состав и содержание работ по созданию системы;
  • Порядок контроля и приемки системы;
  • Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
  • Требования к документированию;
  • Источники разработки.

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

ISO/IEC/IEEE 29148

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

Последняя редакция — ISO/IEC/IEEE 29148:2018, но, к сожалению, она отсутствует в открытом доступе, поэтому возьмём за основу предыдущую, от 2011 года.

По аналогии с ГОСТами, стандарт содержит два раздела. Один из них, SyRS — System Requirements Specification — определяет общие требования к построению систем, их принципам и характеру взаимодействия пользователя с ними. По похожей схеме составлен ГОСТ 34.

SRS — Software Requirements Specifitaion — по аналогии с ГОСТ 19, содержит требования к конечному программному продукту.

Общая схема строится следующим образом:

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

Порядок документирования требований

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

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

В основном, уместен в контексте продуктов низкой и средней сложности. Например, небольшой сайт, воронка продаж или даже копирайтинг.

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

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

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

Виджет обратного звонка для сайта

  • Повысьте конверсию сайта на 30%.
  • Экономьте на тарифах: от 5 рублей в минуту.
  • Настраивайте под ваш сайт. Адаптируйте под все устройства. Тестируйте разные виджеты.
  • Используйте гибкие настройки показа.
  • Стройте отчеты по звонкам: от показа виджета до ключевого слова.

Технико-коммерческое предложение

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

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

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

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

Технические требования

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

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

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

Технический проект

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

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

Эксплуатация

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

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

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

Рекомендации по составлению ТЗ

Ведите историю правок

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

Составляйте список терминов и сокращений

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

Прописывайте каждую деталь

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

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

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

Не оставляйте белых пятен. При наведении на рисунок, он скрывается? Хорошо, но уточните — он уезжает влево? Становится прозрачным? С какой скоростью? Как он появляется опять? Малейшая деталь без чёткой логики ставит разработчиков и весь процесс в тупик.

Техническое задание для программиста 1С

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

Кто должен писать ТЗ?

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

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

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

Получите 267 видеоуроков по 1С бесплатно:

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

Тех. задание обязательно должно содержать в себе:

  • цель — задача, которую мы решим, реализуя данное ТЗ;
  • описание — краткое изложение предстоящих доработок;
  • способ реализации — подробное описание методов решения цели. В этом пункте необходимо описать все нюансы задачи на языке программиста: какие регистры, справочники создаем/редактируем, как должен выглядеть интерфейс и т.д. Если Вы не владеете «языком программиста», но «что-то слышали», лучше не пытаться писать на техническом языке — получается достаточно весело. Описание должно быть однозначным и не вызывать вопросов. Также может содержать в себе пример реализации подобного решения в другой сфере;
  • оценка работы — очень важный пункт, описание трудозатрат.
Читайте также:  Лучшие бизнес идеи из Америки

Примеры и образцы ТЗ для 1С

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

К сожалению, мы физически не можем проконсультировать бесплатно всех желающих, но наша команда будет рада оказать услуги по внедрению и обслуживанию 1С. Более подробно о наших услугах можно узнать на странице Услуги 1С или просто позвоните по телефону +7 (499) 350 29 00. Мы работаем в Москве и области.

Как грамотно составить техническое задание программисту

Что такое техническое задание (ТЗ)?

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

Почему важно зафиксировать весь процесс работы в виде технической документации?

  1. В ТЗ прописаны договоренности между исполнителем и заказчиком, которые сложно выразить в договоре из-за использования специфической IT-терминологии.
  2. Это сэкономит время на коммуникациях: зафиксированные технические решения избавят от многочисленных пересказов, подтверждений, путаницы в показаниях.
  3. Документ позволит четко разделить зоны ответственности между сторонами проекта.
  4. ТЗ дает возможность проанализировать будущий проект и выявить проблемы на стадии планирования.
  5. Правильно составленное задание сделает поведение всех участников работы предсказуемым и избавит от возникновения многочисленных недоразумений.
  6. С юридической точки зрения, наличие этого документа облегчит сторонам разрешение спорных моментов.
  7. Техзадание делает возможным финансовое планирование, что является залогом успешного бизнеса. Заказчику будет заранее видно, на что расходуются его средства.

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

Если одна из сторон хочет сотрудничать без техзадания

Это может означать следующее:

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

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

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

Участники проекта

ЗаказчикМенеджер проектаРазработчики
Ставит задачуСтавит задачу разработчикамВыполняют задание в соответствии с ТЗ
Согласовывает ТЗКонтролирует ход работы и расставляет приоритеты
Принимает работуОсуществляет взаимодействие с заказчиком и разработчиком
Тестирует выполненную работу (если нет тестировщиков)

Если проект большой, дополнительно могут добавиться участники:

  • Product Manager
  • Руководитель проекта
  • Спонсор проекта
  • Тестировщики
  • Технические писатели
  • Кураторы
  • Пользователи/потребители (например, для финального тестирования)
  • И др.

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

Что дает сторонам каждый раздел ТЗ:

Раздел ТЗ

+ Для Заказчика

+ Для Разработчика

Осознание задач, которые решает проект или его доработка

Понимание сути задачи

Представление о том, каким будет готовый продукт

Уверенность в правильном понимании конечного результата

Ориентирование в сроках работ и получения планируемых результатов

Оценка трудозатрат и потребности в ресурсах

Определение более-менее точной суммы затрат и планирование бюджета

Согласованный учет всех работ проекта

Подробное описание работ и каждого этапа реализации проекта

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

Оценка результата работ

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

Возможность удостовериться в бесперебойной работе проекта и в его соответствии требованиям ТЗ

Планирование затрат на обслуживание и представление о дальнейшей поддержке проекта

Выполнение работ с учетом обслуживания проекта в перспективе

Планируемые доработки проекта

Доработка в соответствии с новыми потребностями

Последствия составления некачественного задания

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

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

Обычно разработке качественного ТЗ мешают следующие моменты:

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

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

Исполнитель не готов без должной оплаты тратить больше ресурсов на разработку ТЗ.

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

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

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

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

Техзадание должно отвечать на вопросы:

  1. Что? (какие работы, содержание элементов)
  2. Где? (расположение элементов)
  3. Когда? (последовательность выполнения и установленные сроки работ)
  4. Как? (технология реализации, оформление, принцип работы.) Как правило, у любого объекта должны быть функции: добавления, отображения, редактирования, удаления. А также описаны зависимости и взаимодействия с другими объектами. Иногда добавляются функции модерации, валидации, автообновления, архивации и т.п.
  5. Откуда? / Куда? (при переносе и т. п.)
  6. Зачем? (обоснование работ, если задание будет согласовываться с 3-м лицом)
  7. Особенности.

Основные рекомендации и пояснения по написанию ТЗ

  1. Чем больше масштаб проекта, тем более объемным должно быть техническое задание.
  2. Необходимо указывать реально осуществимые сроки выполнения работ с учетом времени на согласование проектной документации и приемо-сдаточных мероприятий. Стоит обратить внимание на ответственность заказчика за бездействие с его стороны или на форс-мажоры, тормозящие выполнение работ.
  3. Программисту нужны четкие условия. Формулировки “как вариант”, “примерно”, “около”, “где-то рядом”, “там, где лучше по вашему мнению”, – неприемлемы. Требования и характеристики, которые носят субъективный характер, бессмысленны с практической и ошибочны с юридической точек зрения.
  4. Чтобы сделать задачу по созданию какого-либо функционального модуля понятной для программиста, в техзадании размещают гиперссылки на те страницы, где есть нужные элементы интерфейса и функции, и дают к ним подробные пояснения. Также прилагают скриншоты с выделением интересующего фрагмента.
  5. Если дизайна для страниц нет или он не так важен для заказчика, программист может использовать прототипы, о чем после согласования указывается в задании.
  6. ТЗ должно быть удобным и понятным для всех сторон проекта, подробно описывать все этапы и подпункты даже по самым незначительным работам. Программист и менеджер не всегда имеют представление о том, что необходимо заказчику, поэтому важно своевременно обнаружить и согласовать все несогласованные детали.

7 типовых ошибок

  1. Нечеткие цели и задачи.
  2. Мало деталей в технической информации.
  3. Размытые или неустановленные сроки.
  4. Нет согласованности по всем вопросам между сторонами.
  5. Нет регламента взаимодействия.
  6. Нет ответственных лиц.
  7. Нет критериев оценки результата.

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

Задача:
Разместить на сайт www.site.name.ru новую страницу, где будут размещены контакты и фотографии продавцов-консультантов, а также онлайн чат.

Описание:

  1. ГДЕ? Добавить в главное верхнее меню сайта новый раздел «Ваш консультант» между разделами «Блог» и «Наши клиенты».
  2. КУДА? URL новой страницы сделать: /vash_konsultant.htm
  3. КАК? Макет новой страницы взять со страницы “Наши врачи”. Только вместо врачей будут консультанты.
  4. ЧТО? Структура страницы следующая:
    • заголовок: Ваш консультант – по центру (в стиле других заголовков страниц сайта);
    • 3 блока в ряд, имеющие поля:
      • с фотографиями продавцов размером 400*600 (выравнивание по центру);
      • Ф.И.О. продавцов под фотографиями (текстовый формат с возможностью правки);
      • телефон общий у всех: 555-555-55 под Ф.И.О. (текстовый формат с возможностью правки);
      • электронный адрес под телефоном (e-mail: site2@mail.ru);
      • кнопка «Получить консультацию» ниже всех полей, размер кнопки, цвет и форма в стиле кнопок на сайте (см. кнопка «Сделать заказ» на url: /katalog.ru).
  5. ОТКУДА? Данные консультантов должны правиться в редакторе сайта. Также должны редактироваться теги TITLE, DESCRIPTION, H1.

Если работы выполняются для целей SEO – не забывайте закладывать все необходимые элементы на странице.

Также внизу разместить форму заказа.

  1. ГДЕ? Под списком консультантов, над футером.
  2. ЧТО? Три поля:
    • Имя
    • Номер телефона
    • Содержание заявки
  3. КАК? Обязательные для заполнения поля: Имя и Номер телефона. Оформление сделать по образцу формы обратной связи. Если обязательное поле не заполнено, то должно выводиться сообщение, как в форме обратной связи.
  4. КУДА? Заявку отправлять на email заказчика: info@common.com
  5. КАК? Оформление письма в свободной форме.
  6. ОСОБЕННОСТИ Защиту от ботов поставить, как на форме обратной связи.
    При отправке заявки, если все заполнено правильно, в Яндекс-метрику должно отсылаться событие “Отправка заявки”.
  7. НЕ ЗАБЫТЬ О ПРАВИЛАХ ПРИЁМКИ
    Проверить:
    • На странице не должно быть незакрытых HTML-тегов.
    • Проверить адаптив на мобильных устройствах Android с разрешением ***x**** и ****x****, и планшетах с разрешением 1280 x 1024.
    • Проверить работу в браузерах Safari, Chrome, Mozilla.

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

Читать дальше подобные статьи

Онлайн SEO-сервис Labrika

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

Оцените статью
Добавить комментарий