Кто Должен Писать Техническое Задание

Правила составления технического задания по требованиям 44-ФЗ

Федеральный закон № 44-ФЗ о контрактной системе устанавливает единые требования к описанию объекта закупок, которым заказчик обязан следовать при составлении документации о закупке, независимо от способа их осуществления (ст. 33 44-ФЗ). Рассмотрим, какими правилами должен руководствоваться заказчик при составлении технического задания

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

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

При описании в документации о закупке заказчик должен руководствоваться следующими правилами, установленным 44-ФЗ:

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

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

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

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

Что запрещено включать в объект закупки

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

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

Указание ГОСТов и техрегламентов

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

Заказчик может несколько изменить условия по сравнению с техническим регламентом, ГОСТом или СанПиНом, но только в сторону улучшения характеристик.

Пример
1. В соответствии с СанПин 2.4.1.1249-03 площадь озеленения территории дошкольного образовательного учреждения должна составлять не менее 50%, заказчик может предусмотреть озеленение не менее 60% территории.

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

Положения п. 2 ч. 1 ст. 33 Закона № 44-ФЗ не обязывают заказчика абсолютно во всех случаях закупок руководствоваться ГОСТами, стандартами или техническими регламентами.

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

В случае отсутствия ГОСТов, Технических регламентов товар, для которого существует функционирующий рынок заказчик может сформировать описание на основании данных производителей, качественных показателей, которые необходимы заказчику, данных поставщиков о характеристиках товара по причине отсутствия установленных ГОСТов, стандартов и технических регламентов для данного объекта закупки (Письмо Минэкономразвития России от 03.08.2016 № ОГ-Д28-9745).

В случае если ГОСТы являются устаревшими, то следует применять данный номер ГОСТа, но в действующей редакции (с иным индексом после номера)».

Характеристики ТРУ

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

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

При описании характеристик товара заказчик указывает минимальные и (или максимальные) значения показателей.

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

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

Как через техническое задание заказчик может ограничить конкуренцию?

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

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

Что запрещено включать в один лот?

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

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

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

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

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

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

   Нельзя «подгонять» описание только под один конкретный товар одного производителя. Это является ограничением конкуренции. Единственным исключением тут является ситуация, когда нет другого способа исчерпывающего описания свойств объекта закупки (п.1 ч. 1 ст. 33).

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

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

Источник: https://School.Kontur.ru/publications/420

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

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

Как обычно выглядит старт большинства проектов

• Идея! Точно! Все, делаем!
• Из глубины подсознания тихо доносится: «Так, а как объяснить, разработчикам и дизайнеру, что надо?»

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

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

Кто должен составлять ТЗ

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

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

Зачем заказчику вообще что-то писать

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

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

Почему это выгодно для заказчика

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

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

Один из моментов, это то, как мы воспринимаем информацию, вот эта схема поможет вам лучше выражать свои идеи

Сразу попросить дизайнера сделать дизайн сайта

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

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

Запустить сайт, собранный на коленке и расстроиться, что продажи не подскочили вверх

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

 Мартышка к старости слаба глазами стала;

А у людей она слыхала,

Что это зло еще не так большой руки:

Лишь стоит завести Очки.

Очков с полдюжины себе она достала;

Вертит Очками так и сяк:

То к темю их прижмет, то их на хвост нанижет,

То их понюхает, то их полижет;

Очки не действуют никак.

«Тьфу пропасть! — говорит она, — и тот дурак,

Кто слушает людских всех врак:

Всё про Очки лишь мне налгали;

А проку на-волос нет в них».

Мартышка тут с досады и с печали

О камень так хватила их,

Что только брызги засверкали.

___

К несчастью, то ж бывает у людей:

Как ни полезна вещь, — цены не зная ей,

Невежда про нее свой толк все к худу клонит;

А ежели невежда познатней,

Так он ее еще и гонит.

Техническое задание на разработку пишет ИСПОЛНИТЕЛЬ

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

Техническое задание на разработку пишет ЗАКАЗЧИК

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

Третья сторона или МЕНЕДЖЕРЫ проектов

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

У кого-то такое видение о том, зачем нужно техническое задание

Всем выгодно отсутствие технического задания.

• Отсутствие опыта, слабое представление о сути дела, за которое берётся разработчик
• Отсутствие ТЗ – это отсутствие временных рамок, размытие сумм
• Это способ безнаказанно урезать объёмы работ, ухудшать показатели и функционал

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

Какой процесс создания ТЗ самый эффективный?

Атмосфера доверия и ясные цели – это на самом деле очень важно.

Лебедь, Щука и Рак. Давайте сначала освежим в голове басню.

Когда в товарищах согласья нет,На лад их дело не пойдёт,И выйдет из него не дело, только мука.Однажды Лебедь, Рак да ЩукаВезти с поклажей воз взялисьИ вместе трое все в него впряглись;Из кожи лезут вон, а возу всё нет ходу!Поклажа бы для них казалась и легка:Да Лебедь рвётся в облака,Рак пятится назад, а Щука тянет в воду.Кто виноват из них, кто прав — судить не нам;

Да только воз и ныне там.

Источник: https://research-style.ru/journal/zachem-nuzhno-texnicheskoe-zadanie.html

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

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

Стандартная схема при таком подходе выглядит так: 1) заказчик говорит, что хочет сайт, примерно обрисовывает суть, задачи ресурса; 2) исполнитель дает заказчику бриф с большим количеством конкретных вопросов, которые помогают лучше понять суть задачи и составить Техническое задание; 3) исполнитель составляет ТЗ в соответствии с брифом, согласовывает с заказчиком; 4) в соответствии с ТЗ исполнитель разрабатывает сайт.

Логично

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

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

Я начал сомневаться в верности схемы, и вот почему: 1) исполнитель берет деньги за составление ТЗ; 2) исполнитель ставит задачу таким образом, как ему будет проще и выгоднее; 3) исполнитель старается прикрыть каждый кусочек своей попы, исписать десятки листов бумаги, взять за это большую сумму денег и в дальнейшем прикрываться данной бумажкой.

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

Так ли это плохо?

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

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

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

Кто виноват? Я? Нет, потому что я не специалист, я не могу учесть все особенности. Исполнитель? Нет, потому что он разработал проект в точности по ТЗ. Исполнитель — сторона, непосредственно заинтересованная в выполнении задачи с меньшими трудозатратами за большие деньги.

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

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

Я, не думая, читаю, вроде все понятно — и окна прямоугольные, и стены толстые с утеплителем, и полы с гидроизоляцией, и джакузи, и душевая кабина — “Зачем она мне? Ладно, пусть будет, круто же”. В результате, дом выглядит потрясающе, все четко, профессионально, качественно. Я счастлив.

Ровно до тех пор, пока не приходит друг, разбирающийся в строительстве. И тут я понимаю, что оказался полнейшим лохом: “Сколько ты за это отдал? Да ладно!!! У меня на складе аналогичная в пять раз дешевле. А это тебе зачем? Ты же никогда этим не занимался! А это уже давно устарело, есть более лучшие и современные образцы.” Кто виноват в данном случае? Ребята молодцы, все сделали четко, правильно, профессионально, я сам на это подписался, значит я виноват? Но я то откуда знать мог?

Может стоило позвать друга до начала стройки?

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

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

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

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

Возможно ли это?

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

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

Может это и к лучшему. Вопрос довольно неоднозначный.

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

тз, техническое задание, разработка сайта, отношение с клиентами

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

Источник: https://habr.com/ru/sandbox/27254/

Зачем писать техническое задание?

#созданиесайта #разработкасайта #концепциясайта #техзадание #брифнасайт

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

Что такое ТЗ

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

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

Для чего нужно ТЗ на сайт

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

Составление технического задания выполняет важные функции:

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

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

Кто должен составлять ТЗ

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

Техзадание могут составить:

• заказчик;
• исполнитель;
• третья сторона (проект-менеджер, эксперт).

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

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

Что должно быть в ТЗ на разработку сайта

Обычно техническое задание на сайт содержит следующие обязательные пункты:

• Цели и задачи сайта. Это самый важный пункт. В нем ставятся цели, которых планируется достигнуть с помощью сайта, и формулируются задачи, решение которых приблизит к конечному результату;
• Описание проекта. В данном пункте перечисляются характеристики проекта, начиная от целевой аудитории и заканчивая его полезностью для потребителя;
• Техническая сторона сайта. В этом пункте технического задания подробно расписывается карта сайта, функциональность каждого элемента, пользовательский интерфейс, наполнение контентом;
• Рамки проекта. Указываются конкретные сроки на все этапы или на проект в целом, устанавливаются финансовые ограничения;
• Требования к разработке, тестированию и проверке. Оговаривается регламент, по которому будет тестироваться и приниматься готовый сайт;
• Прототип будущего сайта. Это необязательный пункт, но крайне желательный. Если при подготовке технического задания включить в него прототип, то это положительно скажется на дальнейших работах. Прототипы мы уже разбирали в статье «Макет-прототип: бумажный или интерактивный?».

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

Советы по написанию ТЗ

Следующие советы помогут Вам при составлении технического задания:

1. Охарактеризуйте свой продукт:

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

2. Опишите бизнес-модель проекта:

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

3. Обозначьте миссию компании:

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

4. Проанализируйте конкурентов:

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

5. Составьте портрет клиента:

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

6. Поставьте SMART-цели, то есть:

• конкретные;
• измеримые;
• достижимые;
• сопоставимые (с общей стратегией);
• определенные (во временных рамках).

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

Если Вам понравилась статья — ставим лайк и делимся ей в социальных сетях. Хотите получать больше полезных статей? Подпишитесь на рассылку. Раз в неделю пишем коротко про интернет-маркетинг.

Источник статьи: https://bvorona.su/blog/sajtyi/ux/zachem-pisat-texnicheskoe-zadanie.html

Источник: https://zen.yandex.ru/media/id/5c18cca82fb96d00aa8d2bb3/zachem-pisat-tehnicheskoe-zadanie-5c19f2def07b4100accbb632

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

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

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

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

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

Наши продукты помогают вашему бизнесу оптимизировать расходы на маркетинг

Узнать подробнее

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

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

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

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

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

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

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

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

Во многих вакансиях на позицию системного аналитика или технического писателя можно встретить требование: знание ГОСТ 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 формы. Либо просто разместите кнопку обратного звонка, чтобы задать вопросы и проконсультировать клиента прямо в режиме реального времени по телефону.

50 минут в подарок новым клиентам

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

Узнать подробнее

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Узнать подробнее

Источник: https://blog.calltouch.ru/kak-sostavit-tz-podrobnaya-instruktsiya-po-sozdaniyu-tehnicheskogo-zadaniya/

10 заповедей технического задания (с толкованием)

И взошел директор по проектированию qb.digital Виталий Мазуревич на гору, и были даны ему Скрижали Завета, как делать правильное ТЗ.

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

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

Форматы ТЗ перерабатывались, перерабатываются и будут перерабатываться. Формулировки переписываются, какие-то разделы вымарываются, новые добавляются. Толщина документа непостоянна, как ветер мая.

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

Cossa рекомендует: онлайн-курс “Руководитель Digital-проектов”.

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

• 12 месяцев
• Онлайн в удобное время
• Помощь в трудоустройстве
• Доступ к курсам навсегда
• Диплом

Записывайтесь прямо сейчас!>>>

Реклама

Из этих вопросов и родились «10 заповедей о техническом задании». Я посмотрел на ТЗ не как на документ (артефакт), а как на часть процесса производства, и все стало ясно.

1. ТЗ — обязательный документ при создании любого продукта

Миф о том, что для простых проектов ТЗ не нужно, не выдерживает критики. Нужно! И для простого, и для сложного. Просто для простых проектов пишите простое ТЗ, а для сложных — сложное, если вы верите, что для ТЗ такая градация существует в принципе.

2. ТЗ описывает продукт, но не проект

ТЗ должно отвечать на вопрос «Что делаем?», но не «Как делаем?».

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

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

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

3. ТЗ не является договором

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

4. ТЗ описывает не только функциональные требования, но и интерфейс

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

5. ТЗ составляет только обладающий соответствующей компетенцией специалист

Звучит просто, а реализуется сложно.

Я не верю в клиентские ТЗ. Я не верю в ТЗ, которые пишут менеджеры. Кто же его пишет?

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

6. ТЗ разрабатывается после этапа дизайна, но до начала верстки

Подробно я об этом уже писал на Cossa. Коротко. Если делать ТЗ до дизайна, то устанете вносить изменения в этот документ, и потратите кучу сил/денег/времени/сотрудников/заказчиков. Поэтому мы в qb.

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

Тут же возникает резонный вопрос: «А по чему рисуется дизайн?». Отвечаем: по концептуальному описанию, функциональному описанию и прототипам.

7. ТЗ не терпит правок после его утверждения

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

8. ТЗ может править только его автор или обладающий компетенцией специалист

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

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

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

9. ТЗ должно описывать, как минимум, текущую версию продукта

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

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

И когда возникнет вопрос «А как это работает?» (а он, поверьте, возникнет), то ответить на него не сможет никто.

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

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

Я видел много проектов, которые превращались в ад только потому, что кто-то или не читал ТЗ, или читал его невнимательно, или читал, но не понял.Добивайтесь чёткого понимания ТЗ у себя любыми силами.

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

Источник: https://www.cossa.ru/234/125799/