Техническое задание это необходимый элемент коммуникации заказчика или представителя заказчика (маркетолога) с разработчиком. В случае если вы не уделите достаточного времени для проработки ТЗ, то скорее всего получите совсем не тот результат на который рассчитываете.
Человек, которому кажется, будто он очень ясно излагает мысли, не всегда бывает понятен другим, потому что он идет от мыслей к словам, а слушатель — от слов к мыслям.
© Себастьен-Рош Николя де Шамфор
- Кому важно составление технического задания
- Составляющие технического задания
- Введение в предмет технического задания
- Основания для разработки. Почему мы делаем этот продукт
- Целевая аудитория продукта
- Требования к продукту. Что хотим в итоге?
- Функциональные требования
- Стадии и этапы разработки
- Порядок контроля и приемки
- Перечень принятых сокращений
- Основные ошибки при составлении технического задания
- Нюансы работы при создании технического задания
- Основная суть технического задания
- Окончательные выводы по созданию технического задания для проекта
Кому важно составление технического задания
Составление данного документа важно для заказчика, так как ему необходимо проследить за выполнением задачи разработчиком (исполнителем). Это напрямую влияет на конечный результат, которого он хочет добиться.
Безусловно, иногда сложно полностью описать задачу, которая стоит перед руководителем бизнеса, однако это не означает, что в данном вопросе можно своевольничать и делать все что вздумается. Во всем должна быть система. А тем более в подаче проблемы и способа ее решения.
В первую очередь, составление техзадания важно работнику, который данную задачу обязуется выполнить. Если работник сталкивается с проблемами при изучении технического задания, он обязан внести соответствующие коррективы, выделить замечания, после чего показать их заказчику для согласования.
Здесь очень важно, чтобы и заказчик, и исполнитель достигли определенного консенсуса в выполнении задачи, проекта. Посредником в выполнении такой задачи служит техническое задание.
Составляющие технического задания
Введение в предмет технического задания
В данном разделе нужно описать в общих чертах, что подразумевает данный проект. В целом можно описать направление деятельности, с которой проект связан напрямую, и что происходит на рынке в этой сфере на данный момент. Это вступительная часть нашего задания, которая должна быть описана в одном либо двух абзацах. На данном этапе нужно быть лаконичным. В целом объем данного раздела должен быть от 5 до 10 предложений.
Основания для разработки. Почему мы делаем этот продукт
Здесь нужно указать ряд причин, которые подвигли вас создать данную программу или продукт. Стоит также отметить ряд проблем, которые есть в бизнесе, и как данные доработки помогут их решить. В целом должно быть 2–3 основных и 2–3 дополнительных пункта, помогающих лучше понять вашу проблематику.
Если вы руководитель (заказчик), то вам необходимо посмотреть на техническое задание с позиции специалиста и понять, в чем он разбирается и какой язык для описания проблем и решения задач он использует. Если у вас другие понятия и вы не обладаете техническим языком специалиста, то лучше добавить схематическое описание ваших предложений. Это значительно расширит данный документ и прояснит последовательность действий для разработчика.
Именно по этой причине на текущий момент самыми востребованными специалистами являются разработчики с междисциплинарными (смежными) знаниями и навыками. Которые могут общаться со всеми звеньями разработки на уместном языке.
Целевая аудитория продукта
Этот этап подразумевает определение целевой аудитории (ЦА) для кого планируется разработка. Стоит задуматься также над каждой категорией ЦА и определить основные проблемы каждого звена, их приоритетные задачи. В виде схематичного графика можно представить круги, внутри которых описать, что делает тот или иной участник данного продукта и что для него важно.
Речь идет не только о клиентах бизнеса, но и о ваших сотрудниках, которые, возможно будут использовать ваш продукт для выполнения своих задач.
Требования к продукту. Что хотим в итоге?
В этом разделе мы указываем все, что должен сделать исполнитель, чтобы был произведен качественный результат. Само «ядро нашего продукта» находится именно в данном месте. Описываются все наиболее важные и значимые детали, влияющие на целевую аудиторию, для которой, собственно, и делается продукт.
Функциональные требования
Эта стадия создания итоговой работы является наиболее значимой при разработке. В данном пункте активно обсуждаются все детали проекта, рассматриваются точки соприкосновения с будущим готовым проектом.
Этот раздел — своего рода спицы в построении качественного результата, который будет принят заказчиком. Важно заметить, что чем лучше будут описаны эти требования, чем лучше они будут проиллюстрированы и поняты разработчиком, тем качественнее будет разработанный продукт.
Неплохо будет дать ссылки на различные примеры сайтов найденные в Интернет. Это создаст конструктивное понимание между заказчиком и работником. Здесь указываем только то, что хотим видеть, и не вдаемся в мелкие детали. Грубо говоря, не требуем невозможного.
Стадии и этапы разработки
Указываем информацию по стадиям. Допустим, вначале идут подготовительные работы, далее — поиск имеющихся публичных разработок в сети интернет, фреймворков, построение кода или оформление дизайна, затем проходит тестирование и в конце — передача продукта. В целом описанные стадии не являются аксиомой для каждого проекта и могут редактироваться в зависимости от типа исполняемой задачи.
Порядок контроля и приемки
Специалист должен понимать, в какой последовательности показывать результаты своей работы заказчику и, соответственно, по каким этапам ему необходимо двигаться, чтобы выполнить полученную задачу максимально эффективно. Немаловажным здесь будет указать временные промежутки, чтобы в моменты «дедлайнов» не показать заказчику плохо разработанный продукт. Каждый этап должен контролировать заказчик, и это будет кардинально менять работу специалиста.
Конечно, речь не может идти о том, что данная работа способна сформироваться на фрилансе, но такой вариант возможен в том случае, если заказчик и специалист – это ответственные и профессиональные люди, работающие в своих сферах не один год.
Перечень принятых сокращений
Например, при написании этого материала я часто использую слово «продукт». Что оно означает?
«Продукт» — это произведенный товар (сайт или программа), либо систематизированная услуга (организация системы сквозной аналитики или установка и настройка CRM-системы), выполненная работником (специалистом) для упрощения деятельности заказчика, с целью получения последним материальной выгоды за определенную плату.
Описано в наиболее общих чертах, но в данном разделе немаловажной составляющей является конкретика продукта и всего, что с ним связано. Опять же, здесь можно использовать схемы, графики, текст, звук, видео, диаграммы и т. д.
Основные ошибки при составлении технического задания
Зачастую к составлению самого технического задания относятся с большой долей безалаберности, и как результат, заказчик может быть недоволен продуктом, если разработчик просто не учел какую-либо деталь и теперь все предприятие вынуждено нести на себе груз ошибки в коммуникации между заказчиком и исполнителем. Чтобы такого не допустить, опишите до мельчайших подробностей тот процесс, который должен произвести разработчик.
Если не учесть каждый пункт, описанный выше, то возможно, и вам придется присоединиться к числу непрофессиональных работников либо «убыточных заказчиков».
Нюансы работы при создании технического задания
Упускают некоторые важные детали в работе продукта, которые приводят разработчика к потраченному впустую времени без продвижения к получению результата. Иногда разработчику вообще бывает катастрофически недостаточно информации по проекту. Заказчик и разработчик должны понимать, что они идут в одной «упряжке» и отсутствие информации или ее неверная трактовка приведут руководителя и разработчика в тупик, из которого не будет иного выхода, кроме как начать все заново. Получается некий замкнутый лабиринт, где заказчик и исполнитель ищут решение поставленной задачи (выход из лабиринта). Только объединив усилия, возможно достичь результата. Поодиночке движение невозможно.
Основная суть технического задания
Суть технического задания – это возведение фундамента между заказчиком и разработчиком. Этот документ – контрольное звено в суде и доказательство правоты одной из сторон. Кроме того, документ помогает дать четкое понимание как заказчику, так и исполнителю суть разработки и ее структурные составляющие от начала поиска необходимой информации до финальной версии продукта.
Окончательные выводы по созданию технического задания для проекта
- Техническое задание – незаменимый для руководителя инструмент ведения бизнеса в XXI веке и правильный способ оценки работы исполнителя.
- Составление технической документации важно не только руководителю (заказчику), но и исполнителю (разработчику), так как позволяет предотвратить конфликты между сторонами и показывает, кто из них прав.
- Техническое задание имеет ряд составляющих, каждая из которых должна быть описана и учтена.
- Часть заказчиков и разработчиков относятся к техническому заданию как к «небольшой писульке», заполнение которой возможно в общих чертах. Это приводит к проблемам в бизнесе для руководителя и сложностью понимания задачи сотрудником (разработчиком).
- Исходя из вышесказанного необходимо правильно составлять техническое задание. Нужно понимать, что вы решаете общую задачу, и попытаться найти совместное решение в техническом задании.
- Суть технического задания – нахождение точек связи между заказчиком и разработчиком.
