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

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

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

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

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

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

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

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

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

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

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

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

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

1. Пушей существует много видов. Нужно понять, как клиент хочет отправлять эти пуши. Всем сразу или сегментировать аудиторию и разбить по группам пользователей, или избранным пользователям. В какие моменты пуши должны быть отправлены, по расписанию или по определенным триггерам-событиям и так далее. Это отдельная настройка персонализированной рассылки push-уведомлений.
2. Пуши на Android приходят по-разному из-за того, что есть smart-режим в ОС. Это надо предусмотреть и сказать об этом клиенту заранее.
   
3. Есть возможность настраивать пуши, чтобы они приходили с картинками или без.
   
4. Есть возможно чтобы пуши при тапе (при нажатии на него пальцем) на них открывали соответствующую страницу приложения. Это отдельный функционал, который называется deep linking.
   
5. Есть разные возможности для реализации пуша, нативная или через например FCM или скажем через сервисы автоматизации push-рассылки Push Woosh. Одни дают возможность сегментировать аудиторию по разным признакам, другие позволяют собирать уникальные данные для аналитики.

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

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

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

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

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

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

1. Экономия времени — в документе уже есть все ответы, не надо ничего уточнять.
2. Экономия денег — предусмотрели и не надо больше тратиться.
   
3. Экономия нервов — я заплатил, я продумал, я договорился и все под контролем, все знают над чем они работают и чего я и все остальные ждут.
   
4. Сформированное видение продукта.
   
5. Сформированные ожидания.
   
6. Возможность посмотреть, как работает команда, которую вы выбрали для написания мобильного приложения, на конкретной одной ясной задаче — разработка ТЗ.
   
7. Возможность потом отправить готовое ТЗ в любую компанию для оценки — потенциально найти лучшие условия.
   
8. Все хотелки проговариваются и фиксируются. Есть возможность их увидеть и осознать. Как следствие, выстроить иначе, чем планировалось. Отказаться от какого-то функционала, что-то изменить или усилить.
   

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