Если вы планируете разработку качественного digital-инструмента, будь то сайт, приложение, b2b-кабинет и т.д. — вам понадобится грамотное техническое задание (техзадание, ТЗ). О том, что это такое, какие требования к нему предъявляются и какие нюансы стоит учесть — сейчас расскажем.
Суть технического задания
Когда вы начинаете разработку любого IT-продукта, то так или иначе вы описываете свои пожелания: будь то эскиз на салфетке или толстый документ с описаниями, результатами аналитики и ссылками на аналоги. Но это совершенно не значит, что конечный результат вас устроит.
У вас и разработчика разное видение того, как должен работать и функционировать готовый продукт
Избежать этого, а также прийти к единому пониманию, должна помочь разработка проектной документации, самым известным компонентом которой является техническое задание.
Именно на начальном этапе важно правильно спроектировать продукт. Ведь самые дорогие в исправлении ошибки — те, которые были допущены на начальной стадии работ. Они по эффекту домино приводят к многочисленным исправлениям всех уже сделанных на последующих этапах работ.
Что такое техзадание
Техническое задание — это структурированный документ, в котором описываются все требования к продукту понятным для всех сторон языком. Благодаря ему можно:
- четко определить функционал и логику работы предмета разработки,
- выявить все нюансы и риски,
- выстроить коммуникацию с командой разработки,
- контролировать качество на протяжении всех этапов реализации,
- иметь основу для принятия взвешенных решений.
Преимуществами техзадания перед брифом или обычным согласованием являются:
- точный план действий,
- обязательность исполнения,
- структура и поэтапность,
- юридическая значимость.
Кому и для каких задач нужно ТЗ
Описываемый инструмент необходим как для заказчика, так и для IT-специалистов со стороны разработчика или внедренца для решения задач любого типа:
- разработки программного продукта или web-сервиса,
- доработки имеющихся информационных систем,
- интеграции со сторонними ресурсами и сервисами,
- автоматизации бизнес-процессов,
- внедрения новых технологий.
Не всегда этим самым заказчиком выступает бизнес. Часто IT-компании обращаются к своим коллегам за услугой по составлению технических заданий.
Безусловно, можно написать ТЗ своими силами: привлечь к этому сотрудников, отделы, своих разработчиков и руководителей, но такую работу иногда стоит делегировать. И вот почему:
- Экспертиза и наработанный опыт. Гораздо грамотнее, полноценнее, быстрее, а порой даже дешевле обратиться к тем, кто уже имеет более глубокие знания в определенных областях разработки ПО или информационных технологий.
- Ограниченные ресурсы. Нехватка времени и квалифицированных кадров может привести к тому, что итоговый документ будет «сырым» или не учтет важные детали, а сроки будут сорваны, бюджеты превышены.
Поэтому обращение к IT-компании за услугой по разработке техзадания является первым шагом для успешной реализации проекта.
Елена Фрум, ведущий руководитель проектов компании «Пиком»:
Отсутствие технических требований, пространные формулировки — всё это может не только затянуть процесс разработки, но и повести его по ложному пути со срывом сроков и бюджетов.
А вот наличие четко описанного функционала — это одновременно и выстраивание границ проекта, и фиксирование обязательств между клиентом и исполнителем.
Для клиента это основание требовать выполнения тех работ, которые прописаны, а для исполнителя — основание действовать ровно в тех рамках проекта, которые были согласованы обеими сторонами.
Что в себя включает ТЗ
Техническое задание прежде всего описывает постановку задачи. Можно сказать, что любая заявка на разработку цифрового продукта так или иначе задачу описывает. Но есть ряд написанных огромными потерями времени и денег критериев, которым должна удовлетворять эта постановка. Прежде всего, ТЗ должно быть описанным и структурированным. Рассмотрим, из чего оно состоит.
- Введение. Содержит краткое описание проекта и задач перед ним, общую информацию для беглого ознакомления.
- Требования к продукту. Описывают желаемые результаты проекта и перечень входных данных, без которых готовые рабочие процессы невозможны.
- Описание проекта. Здесь важно все разложить по полочкам: что и как будет выглядеть, с чем и каким образом работать. Описываем интерфейсы, архитектуру и бизнес-логику продукта, требования к базам данных, интеграцию с CRM-системами и т.д. Каждый пункт должен быть максимально подробно и доступно расписан.
- График работ. Это этапы разработки и сроки их выполнения, порядок тестирования и обучения сотрудников.
- Бюджет и ресурсы. При необходимости можно прописать, сколько будет стоить каждый этап и какие силы будут задействованы.
- Сдача и приемка. Содержит условия, достижения KPI, при которых проект считается завершенным.
- Приложения. Дополнительные материалы, такие как технические спецификации, стандарты, регламенты, редполитика и т. д.
Требования к техзаданию
Часто возникает проблема — ТЗ может быть и написано. И заказчик даже его согласовал. Но когда видит результат, сделанный точно по ТЗ — выясняется, что он хотел что-то другое. Потому что или прочитал невнимательно толстый документ, или просто не понял что-то в силу разницы языков или из-за сложности изложения.
Еще раз хотим обратить внимание, что техническое задание предназначено для упрощения взаимодействия между заказчиком и исполнителем, чтобы конечный продукт максимально удовлетворял требованиям клиента и мог выполнять те задачи, для которых он разрабатывался. Это не должен быть документ ради документа.
Именно поэтому он должен соответствовать следующим принципам:
- Быть понятным для всех, без двойных смыслов и расплывчатых формулировок.
- Содержать информацию о бизнесе, деятельности, целях и задачах компании заказчика.
- Раскрывать точное назначение разрабатываемого продукта (сайта, приложения и т.п.).
- Описывать процессы простым и понятным языком без специализированных терминов. Либо последнии должны быть раскрыты.
- Указывать точный стек технологий, инструменты и сервисы, с помощью которых будет реализован продукт.
- Подробно рассказывать о том, какой именно нужен функционал, какой будет структура продукта и т.д.
- Объяснять сценарий пользования разработанным продуктом простыми формулировками.
- Распределять обязанности.
Этапы разработки
Процесс составления этого важного документа можно разделить по этапам, которые включают в себя следующие итерации.
- Определение целей и задач проекта
- Аналитика и выявление возможных проблем
- Написание текста ТЗ
- Проверка и корректировка
- Утверждение заказчиком
- Реализация
- Контроль
Подразумевает изучение пожеланий заказчика, анализ существующих аналогов и референсов, определение основных функций и возможностей продукта. На основании собранной информации определяются уже следующие этапы разработки проекта и составляется план работ.
Включает в себя анализ необходимого функционала, особенностей дизайна и интеграций, требуемых нестандартных решений. На данном этапе определяются возможные проблемы и пути их решения. Как показывает практика, чем корректнее будут проведены работы по аналитике, тем более качественный итог получится.
Всё выявленное на предыдущих этапах расписывается подробно, доступным для неспециалистов в бизнесе или производстве языком.
Лучше всего выделить в отдельную итерацию, поскольку она представляет собой согласование между участниками всех результатов работ.
Готовое техническое задание презентуется заказчику. Наглядно демонстрируется предполагаемое готовое решение и функционал, чаще всего на прототипах. Озвучиваются все нюансы. Все согласовывается, при необходимости дорабатывается и подписывается.
Подразумевает поэтапное выполнение каждого фронта работ, по ранее намеченному плану.
Лучше всего это делать по этапам и регулярно, поскольку помогает сохранить качество, вовремя внести корректировки, а также отследить возможные ошибки.
Главный компонент идеального техзадания
Существует ли единый образец хорошего техзадания? Конечно, есть регламенты на создание техзаданий. Например, крупные компании или государственные предприятия обязательно предписывают разработку ТЗ по специализированным ГОСТу:
ГОСТ19.201-78 «Техническое задание. Требование к содержанию и оформлению»
Но формальное следование любому стандарту или регламенту абсолютно не гарантирует хороший результат. Это ровно тот случай, когда форма не определяет содержание. В ТЗ как в документации важна именно проработка содержания, а как в инструменте коммуникации между заказчиком и командой (и внутри команды) — язык и форма изложения.
Описание задачи может быть в любом формате: наборе документов, инфографики, прототипов, примеров кода, либо просто на листе бумаги. Отметим, что в том же ГОСТе техническое задание — это лишь один из документов, который описывает систему. Правда, про остальные почему-то редко вспоминают.
Нет одного варианта, который подходит во всех ситуациях. Но зато существуют признаки, которые сигнализируют, что в документации что-то не так:
- Вместо требований описаны возможные решения или созданы прототипы, демонстрирующие будущий интерфейс.
- Сами требования нечеткие, не допускают однозначную проверку, оставляют недосказанности, имеют оттенок советов, обсуждений или рекомендаций. Например, фразы «Возможно, что имеет смысл реализовать также… ».
- Сложные функции описаны кратким абзацем, с опусканием необходимых деталей. Например, просто прописана фраза «необходима интеграция с 1С», без раскрытия технических подробностей.
- Игнорируется аудитория, для которой предназначено представление требований.
- Пропущены важные детали, связанные с нефункциональными требованиями: сроки готовности сопутствующих систем, информация об окружении системы и т.д. При этом они напрямую будут влиять на текущую разработку.
Как же понять и определить то, что обязательно должно быть прописано в ТЗ? Только за счет опыта. Это работа аналитика, у которого уже были «боевые задачи», кейсы, насмотренность и четкое понимание проблем, возникающих на всех этапах разработки. Очень важно, чтобы это был не просто человек, выполняющий обязанности аналитика, а специалист, имеющий опыт именно с тем видом решения, которое разрабатывается.
Но можно ли возложить всю ответственность на одного аналитика? Любая проектная документация — это всего лишь проекция мыслей аналитика на документы, причем написанные обычным естественным языком со всеми его ограничениями и разночтениями.
Маргарита Чубукова, руководитель проектов компании «Пиком»:
На ум приходит цитата: "То что очевидно для тебя — не очевидно для других" (М. Батырев). Она очень четко подходит в данном случае. Даже если один человек опишет свои мысли в ТЗ, это не значит, что их поймет тот, кто будет это ТЗ реализовывать. Техническое задание должно быть понятным всем. И пишется оно для тех, кто будет с ним работать, а не для потому, что так надо или так положено.
Поэтому обязательная составляющая успеха — сопровождение проекта компетентным и опытным аналитиком. Он начинает проект, остаётся частью команды вплоть до сдачи проекта, а позже — мониторит достижение проектом своих KPI, анализирует результаты, выявляет проблемы или предлагает улучшения. Но важна командная работа.
В целом, чтобы оптимизировать работу над техническим заданием, чтобы получить в итоге максимум, вам потребуются шаги:
- Проведите подготовку с определением того, какие минимальные функции будут при запуске продукта.
- Поменьше теории и концепций — сосредоточьтесь на том, что можно быстро реализовать и протестировать.
- Проверьте все гипотезы о болях и потребностях клиентов на старте. Для этого не понадобится масштабное исследования рынка.
- Минимизируйте затраты каждого шага. Для этого важно понимать — что и для чего делается. Кстати, подойдет метод анализа «Пять почему».
- Откажитесь от сложных и трудозатратных решений — только простые и функциональные.
Выводы
Грамотно составленная документация + сопровождение опытного аналитика — залог создания качественного, продуманного, ориентированного на необходимую целевую аудиторию итогового продукта.
Как показывает практика, такой подход позволяет закрыть все требования и желания заказчика оптимальным образом, а где-то и отговорить от чего-то нефункционального.
Наличие технического задания не дает гарантии, что не будут внесены какие-то корректировки в процессе разработки или внедрения, но вы четко будете понимать, какие шаги будут следовать дальше, какие сроки будут выдержаны и кто за это несет ответственность.
При этом бывают случаи, когда это самое ТЗ не нужно, например, для простых или, наоборот, исследовательских проектов, но это уже совсем другая история…
Со своей стороны мы всегда готовы составить для вас техническое задание, поскольку имеем необходимый опыт, компетенции, специалистов и условия.
Напишите нам info@picom.ru и мы подберем решение для вас.