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

Как составить техническое задание и получить то, что нужно

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

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

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

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

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

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

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

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

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

Устоявшейся практики нет — как договоритесь с подрядчиком.

Заказчик делает сам

Например, гендиректор студии архитектурной фотографии «АрхФото» Анатолий Шостак называет идеальным заказом ситуацию, когда заказчик сразу присылает подробное ТЗ и просит оценить работы.

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

Анатолий Шостак
Гендиректор «АрхФото»

Совместная работа

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

Техзадание полностью делает исполнитель

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

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

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

Сколько стоит заказать ТЗ

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

Основатель компании по разработке информационных систем Work Solutions Максим Мул при заказе ТЗ рекомендует ориентироваться на 10-20 % от общей стоимости разработки продукта.

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

Максим Мул
Основатель Work Solutions

Если речь про IT-задачи, например, интеграцию между информационными системами, внедрение CRM, разработку дополнительного функционала ПО или приложения по API, то не стоит рассчитывать на ТЗ стоимостью меньше 50 000 руб., считает гендиректор компании «Информатика и Сервис» Владимир Севрук.

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

Владимир Севрук
Гендиректор компании «Информатика и Сервис»

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

У нас есть более сложная форма ТЗ — мы называем ее «сценарий». Для сценария мы проводим предварительные съемки, прописываем и согласовываем все ракурсы с заказчиком, прорабатываем целевую аудиторию и рассчитываем тайминг каждого кадра с учетом движения солнца. И все это ещё до начала чистовой работы.

Анатолий Шостак
Гендиректор «АрхФото»

За составление такого подробного сценария в «АрхФото» берут деньги. В зависимости от сложности проекта и требований заказчика сценарий иногда стоит дороже самой съемки. Зато благодаря ТЗ заказчик еще до начала работ понимает, что получит в итоге, говорит Анатолий Шостак.

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

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

Пишите однозначно

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

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

Бывает, что заказчик не знает, что конкретно хочет получить, причем часто сам того не осознавая. Из-за этого в ТЗ появляются расплывчатые и многословные формулировки. В итоге заказчик с исполнителем потратят значительное время на их уточнение. Эффективнее сделать ТЗ с конкретными и точными требованиями, без многословности.

Алексей Орлов
Руководитель проектов компании «Рексофт»

Стоит попробовать любые пожелания сводить к количественным требованиям.

Дайте подрядчику общую информацию

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

Гендиректор INOSTUDIO Максим Болотов рекомендует как минимум озвучить подрядчику идею проекта, который вы заказываете, уточнить, в чем его конкурентные преимущества и уникальность.

Расскажите подрядчику, какие задачи будет решать IT-решение. Это может быть увеличение прибыли, повышение узнаваемости бренда, лояльности пользователей. Уточните, кто будет пользователями продукта, их социальные и поведенческие характеристики, например, пол, возраст, интересы, семейное положение, потребности — это нужно, чтобы корректно и эффективно сформулировать функциональные требования к продукту.

Максим Болотов
Гендиректор INOSTUDIO

Помогите разобраться в терминах и нюансах

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

Можно ввести отдельный раздел в виде словаря с расшифровкой или пояснять по ходу документа.

Покажите конкурентов

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

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

Максим Болотов
Гендиректор INOSTUDIO

Уточните важные технические требования

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

Например, если вы заказываете интернет-магазин, важно, чтобы его движок мог принимать данные из всех ваших систем — не только обмениваться актуальными ценами с 1С, но и получать информацию из CRM и самописных сервисов.

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

Распишите сценарии использования продукта

Если вы делаете что-то стандартное, то так сильно погружаться в особенности продукта не стоит, это лишь запутает и добавит ТЗ многословности. Но в случае чего-то необычного попробуйте в техзадании отвечать не на вопрос «Что?», а на вопрос «Как будет делать пользователь?».

Если речь про IT-продукты, можно прописывать сценарии по такому шаблону:

Опишите требования к проверке проекта

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

Например, для интернет-магазина это может быть:

Чем подробнее и длиннее чек-лист, тем лучше.

Двигайтесь от общего к частному

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

Шаблоны и примеры ТЗ

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

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

Если планируете заказать IT-продукт, можно использовать за основу госстандарты. Например:

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

Когда ТЗ не нужно

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

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

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

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

Владимир Севрук
Гендиректор компании «Информатика и Сервис»

Кратко — универсальные советы по составлению ТЗ

Составляя ТЗ самостоятельно или с подрядчиком, придерживайтесь следующих правил:

Не пропустите новые публикации

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

Источник

Всегда ли нужен ГОСТ при разработке крупных проектов?

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

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

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

Кому будет полезна статья:

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

тендерным специалистам со стороны как заказчика (специалистам по закупкам), так и исполнителя;

заинтересованным лицам команды разработки (аккаунтам, ПМ, аналитикам).

Если у вас есть опыт в этом вопросе, мы рекомендуем перейти к части второй, где мы расскажем, “откуда растут ноги” у ГОСТа и так ли он неизбежен при работе с госзакупками.

Часть 1. Общие понятия

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

Представим себе абстрактную ситуацию: заказчику нужно произвести некий продукт. Для того, чтобы донести свою потребность исполнителю, заказчик фиксирует требования в следующем виде: “Система должна автоматизировать процесс получения услуги Х”. Заказчик считает необходимым указать лишь эти детали, возможно, считая всё остальное очевидным — но здесь есть риск ошибиться.

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

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

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

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

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

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

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

Тем не менее документация НУЖНА, даже если это просто описание user stories. Иногда команде достаточно иметь определенные паттерны, чтобы понимать, что определенная user story предполагает наличие функции, которая должна быть реализована тем или иным способом.

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

Часть 2. ГОСТ: необходимость или неизбежность?

История вопроса

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

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

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

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

Так как же получилось, что ГОСТ 34.602-89 стал практически обязательным для государственного заказчика?

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

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

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

Существуют мнения, что работа над ГОСТ 34 не была доведена до своего логического завершения, тем не менее эта серия приобрела широкую популярность и до сих пор широко используется в России.

Недостатки ГОСТ

Наряду с бесспорными плюсами, ГОСТы серии 34 имеют ряд недостатков:

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

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

В ГОСТ отсутствуют отдельные понятия IT-отрасли, связанные с управлением проектами и рисками.

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

Так нужно ли писать ТЗ именно по ГОСТ 34.602-89?

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

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

Что же с госсектором?

ТЗ по ГОСТ 34 для госзаказчиков — это преимущественно юридический документ. Однако, в составе конкурсной документации нет понятия «Техническое задание» — этот документ правильнее называть “техническими требованиями”.

Посмотрим внимательно на состав ТЗ по ГОСТ 34, а именно:

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

В ином случае будет сложно и бесполезно писать ТЗ к тому, что еще пока неизвестно. В составе конкурсной документации, как правило, такой документ будет содержать очень много “воды” и подобных формулировок: «Требования будут уточнены на стадии проектирования и зафиксированы в частном техническом задании (ЧТЗ)».

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

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

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

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

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

Что же делать?

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

В частности, разработчики могут сформировать для заказчика отдельный документ (например, на один из модулей системы) по ГОСТ 34, как ЧТЗ. В некоторых случаях подобный документ называют “описанием постановки задачи” (ОПЗ), и он содержит в своем составе описание бизнесовой части, схемы бизнес-логики на основании требований законодательства (НПА). В таком виде документация презентуется заказчику.

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

Этот документ может быть оформлен не по ГОСТ 34 (так называемая «дельта» для разработки), в нем нет общих формулировок и «воды». Естественно основной документ в базе знаний постоянно актуализируется, после мержа туда таких вот «дельт».

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

Другие стандарты

Помимо ГОСТ, существуют международные стандарты по проектированию требований, зачастую более современные:

Также есть стандарты и нотации практически для любой области разработки, например, по управлению услугами в сфере IT (SERVICE DESK) — ITIL Foundation.

На такие стандарты опираются международные сертификационные организации, например, IREB (International Requirements Engineering Board). В нашей команде аналитики по желанию проходят сертификацию IREB, и по нашим наблюдениям, многие заказчики обращают на это внимание (хотя если у специалиста нет сертификации, он все равно может иметь глубокие знания).

Выводы

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

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

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

атомарность (независимость от других требований);

абстрактность (независимость от способов реализации);

Независимо от того, в какой форме нужна документация, будет уместен принцип «чем проще, тем лучше». Даже если ТЗ составлено по весьма избыточному ГОСТу, «текст ради текста» недопустим – нужно стремиться к полноте и простоте.

Спасибо за внимание! Будем рады услышать ваши мнения в комментариях.

Источник