Самый важный этап разработки: опыт создания ТЗ

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

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

В основном я пишу для клиентов и тех, кто причастен к созданию цифровых продуктов. Я был и по ту сторону и по другую. Клиенты часто считают что им достаточно заплатить за МП и все будут готово через срок. Но это заблуждение. В действительности от клиента требуется внимание и участие на всех стадиях разработки проекта. Больше всего энергии надо потратить на этапе создания ТЗ. Ведь этот документ — сердце всего проекта. От его проработки будет зависеть жизнеспособность продукта.

Расскажу о первом этапе в работе над мобильным приложением. ТЗ — самый главный документ наравне с договором. ТЗ разрабатывает специальный человек в компании — бизнес-аналитик. Сразу отмечу, первое, что необходимо сделать клиенту на своей стороне — собрать отдельную группу специалистов. В неё точно должны войти: маркетолог, директор, логист, бухгалтер, рядовой сотрудник компании (например продавец-консультант, который работает с покупателями) и IT-директор. Проще говоря, по одному сотруднику из каждого отдела плюс верхушка компании. Эта группа должна быть включена в процесс обсуждения функциональности приложения, чтобы в драфт ТЗ попали все хотелки. Совместно с группой клиента будет сформирован объемный образ будущего мобильного приложения (МП).

Группу собрали — отлично! Аналитик изучит бизнес-процессы компании, посмотрит сайт, проанализирует конкурентов и их цифровые продукты. Потом выявит требования, определит приоритеты, подготовит спецификации, подготовит скелет ТЗ и набросает структуру будущего МП. Затем он разошлет файл участникам группы, и в назначенное время пройдет еще одни митинг. На встрече аналитик подробно расскажет о структуре МП и зафиксирует договоренности.

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

Читаем, разбираемся и описываем все очень подробно. Данные собраны, все высказались. Аналитик собирает единый документ, детально описывает функции мобильного приложения. Работа кропотливая, требует внимательности и воображения.

Порой я встречаю мнение, что ТЗ — просто бумажка. И слышу от клиента следующее:

—Мы же вам всё ясно и понятно объясняем. Зачем так подробно и нудно это обсуждать?

—Там не сложно. Скоро уже закончим? Может вы уже сами допишете и начнем разрабатывать?

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

И так далее. Но я приведу обычный пример. Возьмём всем понятную и самую популярную функцию приложения push-уведомления. Тут же вроде и говорить не о чем, и так ясно! Пуши должны приходить. Сделайте их и всё. А в реальности Push это отдельный вид искусства, который требует специальной проработки и вот почему.

Для примера есть статистика сервиса Kahuna — хорошо разработанные push-уведомления увеличили показатель возвратов пользователей (то, что называется Retention) в приложения более чем в 2 раза.

В общем, такая на первый взгляд простая вещь как Push-уведомление имеет очень много скрытых возможностей в реализации. И бизнес-аналитик должен обо всём сказать клиенту, объяснить, как это будет работать и узнать, как клиенту хочется, чтобы пуши были реализованы на приложении. Так и с регистрацией, и с каталогом, и с карточкой товара и так далее. Все подробности, все нюансы будут влиять на стоимость разработки и на время разработки. Отдельное внимание в ТЗ стоит уделить требованиям к интеграции сервисов и АПИ.

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

Имеем ТЗ — представляем, как будет выглядеть работа с МП. В итоге клиент получает то, что хочет. Великолепно работающий продукт. Потребуется от двух до 4 недель работы над техническим заданием.

Далее ТЗ берут программисты, дизайнеры, тестировщики, менеджер и декомпозируют на простые задачи. Раскладывают, что называется «по ручкам». Оценивают, сколько потребуется времени, чтобы разработать приложение. Потом я собираю коммерческое предложение с оценкой. Презентую клиенту.

Вот что дает ТЗ клиентам:

ТЗ — это бог разработки.