Многие компании считают, что привлекать посторонних специалистов к процессу написания технического задания, неразумно. Аргументируют они это тем, что этим могут воспользоваться компании-конкуренты, которые создадут ТЗ, понятное исключительно их сотрудникам, что, соответственно, будет их преимуществом. Частично с этими опасениями можно согласиться. Однако причина вовсе не в меркантильных помыслах подрядчиков, а в том, что у каждой компании специфичные подходы к выполнению этого документа.
Давайте для начала разберемся, что такое техническое задание. Википедия дает следующее определение: «документ, содержащий требования заказчика к объекту закупки, определяющие условия и порядок ее проведения для обеспечения государственных или муниципальных нужд, в соответствии с которым осуществляется поставка товара, выполнение работ, оказание услуг и их приемка».
В ГОСТах тоже есть такое понятие, как техническое задание, к примеру, ГОСТ 19.201-78 дает четкие предписания, что должно содержаться в этом документе.
Однако, как мы уже не раз могли убедиться на практике, у каждого клиента совершенно разные взгляды на то, что должно содержаться и как должен быть оформлен такой документ, как техническое задание. К примеру, некоторые клиенты уверены, что оформив на несколько страниц требования к будущей работе, они получат на 90% достоверную оценку предстоящих работ и срок их выполнения. Зачастую, увидев на электронной почте письмо с прикрепленным документом «Техническое задание, завтра вышлете по нему КП», программисты понимают, что содержание документа будет примерно такое «мы хотим, чтобы система могла осуществлять обмен необходимой информацией с сайтом».
В одной из компаний было условное разделение на техническое задание и технической проект. Под техническим заданием понимался документ, в котором на понятном бизнес-пользователям языке были написаны требования, предъявляемые к системе. Техническим проектом называли подробный основательный документ, который составили на основании технического задания, он содержит максимальное количество деталей будущего проекта, написан преимущественно языком, понятным разработчикам.
Составлять техническое задание самостоятельно решаются в первую очередь небольшие компании, у которых нет возможности обратиться к специалисту для составления технического задания, но есть срочная задача, требующая срочного решения. Они составляют его самостоятельно и отсылают в несколько фирм-франчайзи. Естественно, не будут, да и не смогут они профессионально составлять документ, содержащий большое количество технической информации и терминов.
Как же написать его так, чтобы в итоге получить то, что было задумано авторами, а не то, что может любая типовая конфигурация.
В первую очередь следует напомнить о таких основных правилах написания технического задания, как определение целей, задач, функциональных требований, наличие оглавления и списка сокращений. Заметим, что текст желательно писать короткими и понятными фразами.
А сейчас расскажем вам о некоторых особенностях составления технического задания, которые помогут получить в результат, максимально приближенный к требованиям.
Техническое задание можно составить в виде инструкции для пользователя. В этом документе действия пользователя расписаны пошагово. То есть с помощью этого документа, пользователь сможет ознакомиться с процессами и без затруднений пользоваться необходимыми функциями. Спецификой такого вида технического задания является его деление на отдельные процессы и описание их специфики.
Чтобы информация правильно воспринималась пользователем, необходимо ее визуализировать. Удачным решением будет иллюстрирование текста скриншотами, блок-схемами, макетами. Это поможет избежать неправильного понимания или интерпретации системы.
Удобство использования. Две предыдущие рекомендации – визуализация процессов и понятная рядовому пользователю логика работы – помогут реализовать в техническом задании необходимое количество пунктов, что обеспечит комфортное использование системы. К примеру, если с системой будут работать начинающие пользователи и техническое задание будет написано понятным для них языком, можно не сомневаться в успешности проекта. Кстати, такое техническое задание будет полезно и топ-менеджерам, которые не всегда дружны с «бухгалтерскими программами». Разберем на примере, в техническом задании системы, функционирующей в сфере розничной торговли, не было указано, что поиск товара по артикулу не должен занимать больше трех секунд, поэтому осуществлялся бы типовой поиск, время ожидания которого полминуты. В реальности это могло бы привести к серьезным последствиям, при работе с розничными покупателями дорога каждая секунда, поэтому длительное ожидание недопустимо.
Отсылка на популярные решения. Для того чтобы заказчику стали более понятны предлагаемые вами решения, можно воспользоваться аналогичными примерами из известных систем, к примеру, Битрикс24 или различные продукты 1С.
Обратная связь. Еще раз повторим: успешное техническое задание необязательно должно быть напичкано сложными терминами и написано по ГОСТу, в первую очередь оно должно быть понятно коллегам составителя и тем, кто непосредственно заниматься его реализацией. Поэтому прежде чем отправлять документ специалистам-разработчикам, предложите ознакомиться с ним своим коллегам или партнерам. Заручившись их положительными отзывами, можно смело отправлять техническое задание на разработку. И помните, даже если вам кажется, что документ написан ясным и понятным языком, не всегда он будет таковым для остальных, поэтому не пренебрегайте возможностью получить одобрение как минимум одного-двух пользователей.
И напоследок. Конечно, у каждого свое представление о том, как должно выглядеть техническое задание и в идеале его составлением должен заниматься специалист. Однако в экстренных ситуациях (нехватка времени, средств) при самостоятельном написании технического задания, используя приведенные выше советы, процент успешности его реализации вырастает в разы.