Управление разработкой цифрового продукта начинается не с кода, а с требований. Ошибки на этом этапе часто обходятся дороже самой реализации.
Если задача сформулирована недостаточно подробно, заказчик и команда могут по-разному понимать ожидаемый результат. В итоге с технической точки зрения работа оказывается выполнена, а с точки зрения бизнеса — нет.
В статье разбираем, как ставить задачи программистам и что должно входить в ТЗ на реальном примере.
Что такое техническое задание
Техническое задание — это документ, который фиксирует, что нужно сделать, зачем и как проверить результат. Оно помогает избежать разночтений между бизнесом и командой, точнее оценить сроки и бюджет, а также сделать результат разработки более предсказуемым.
Исправить требования на этапе составления ТЗ обычно занимает несколько минут или часов обсуждения.
Но если проблема обнаруживается в процессе разработки, приходится переделывать и тестировать код, заново согласовывать результат. Это влияет на сроки, стоимость и качество проекта, а в отдельных случаях может привести к накоплению технического долга. В крупных проектах стоимость таких изменений может многократно превышать затраты на первоначальную проработку требований.
Поэтому инвестиции в подготовку ТЗ окупаются не только сокращением сроков, но и снижением расходов на доработки.
Из чего состоит правильно поставленная задача
Перед тем как ставить задачи программистам, обычно фиксируют несколько ключевых моментов. Рассмотрим ТЗ разработчикамих реальном на примере.
Текущее состояние системы. Если дорабатывается существующий продукт, важно описать, как процесс работает сейчас и какие ограничения уже есть.
Пример: запись осуществляется через форму обратной связи, после чего менеджер вручную связывается с клиентом и согласовывает время консультации.
На практике такой анализ существующих процессов обычно проводится в рамках предпроектного обследования.
Проблема. Что именно мешает бизнесу сейчас и какую задачу должна решить разработка.
В рассматриваемом сценарии клиенты не могут самостоятельно записаться на консультацию, поэтому менеджеры тратят время на обработку заявок вручную.
Бизнес-цель. Какой результат компания хочет получить после внедрения решения.
В нашем случае — увеличить количество заявок без участия менеджеров.
Задача. Что необходимо реализовать для достижения этой цели.
Например, добавить возможность онлайн-записи на консультацию.
Сценарий использования. Какие шаги проходит пользователь от начала до результата.
Пользователь выбирает свободную дату и время, оставляет контактные данные, подтверждает запись и получает уведомление.
Функциональные требования и интеграции. Что должна делать система и с какими сервисами взаимодействовать.
Например, отображать только доступные слоты, передавать данные в CRM и отправлять пользователю подтверждение записи.
Дальше уже ограничения, критерии приемки и дополнительные материалы.
В ограничениях указываются бюджет, сроки, технические ограничения, требования к архитектуре или безопасности.
Например:
- срок реализации — до 1 месяца;
- интеграция должна работать с действующей CRM;
- доработка выполняется без изменения текущей структуры сайта;
- решение должно соответствовать требованиям по защите персональных данных;
- система должна корректно работать на мобильных устройствах, планшетах и десктопах.
Критерии приемки определяют, когда задача считается выполненной.
Пример: после записи автоматически создается лид в CRM, пользователю приходит подтверждение, а функциональность корректно работает на всех типах устройств.
Дополнительные материалы помогают быстрее разобраться в требованиях. Это могут быть макеты интерфейсов, схемы интеграций, прототипы или примеры аналогичных решений.
Все перечисленные элементы фиксируются в одном месте — техническом задании или карточке задачи в системе управления проектами. Этот документ становится единой точкой правды для команды. По нему разработчики реализуют функциональность, тестировщики проверяют результат, а заказчик принимает работу.
Если требования меняются, они также фиксируются в документе, чтобы у всех участников оставалась актуальная версия задачи.
Чек-лист готовности задачи к разработке
Перед передачей ТЗ полезно пройтись по чек-листу:
- Понятна ли бизнес-проблема, которую решает доработка?
- Определен ли ожидаемый результат для бизнеса?
- Описан ли пользовательский сценарий?
- Зафиксированы ли ограничения по срокам, бюджету и технологиям?
- Есть ли критерии приемки?
- Приложены ли необходимые макеты, схемы или примеры?
- Согласованы ли требования со всеми заинтересованными сторонами?
Если по всем пункты соблюдены, задачу можно отдавать в разработку.
Типичные ошибки при постановке задач
Самая распространенная ошибка — отсутствие бизнес-цели. Команда понимает, что нужно сделать, но не понимает, какой результат ожидает заказчик. Чтобы этого избежать, перед постановкой задачи зафиксируйте проблему, которую должен решить новый функционал, и ожидаемый бизнес-результат.
Не менее часто встречаются слишком общие формулировки. Например, улучшить интерфейс или ускорить систему. Такие требования практически невозможно объективно проверить после завершения работ. Используйте конкретные требования и измеримые критерии, по которым можно оценить результат.
И последнее — не фиксировать изменения в документации. Нередко правки обсуждаются устно или в мессенджерах, поэтому спустя время участникам проекта сложно восстановить историю принятых решений. Все изменения лучше сразу вносить в задачу или проектную документацию, чтобы избежать недопонимания и споров.
Вывод
Хорошо выстроенное управление разработкой начинается с подробно подготовленных требований: что делаем, для кого, как пользователь это использует, какие есть ограничения и как проверяется результат. Без этого разработка не решает бизнес-задачу, непредсказуема по срокам и стоимости.
В Aiston мы помогаем компаниям прорабатывать требования, проектировать решения и запускать цифровые продукты с учетом бизнес-целей. Такой подход позволяет заранее определить объем работ и снизить количество изменений после старта разработки.