Самый важный этап разработки: опыт создания ТЗ
Если бы 14 лет назад, когда я начал заниматься созданием проектов, мне довелось прочитать то, что написано ниже, то я бы все сделал также. За исключением ТЗ. Они были бы намного лучше!
Успех полностью зависит от проделанной подготовки. Без нее вас неминуемо ждет неудача.
Сейчас я думаю что, что ТЗ — это такое серое пятно для компаний, которые решили разработать мобильное приложение. Поскольку я занимаюсь разработкой мобильных приложений, то и говорить здесь буду только о них. Хотя вся информация легко захватывает любую деятельность по созданию чего угодно.
В основном я пишу для клиентов и тех, кто причастен к созданию цифровых продуктов. Я был и по ту сторону и по другую. Клиенты часто считают что им достаточно заплатить за МП и все будут готово через срок. Но это заблуждение. В действительности от клиента требуется внимание и участие на всех стадиях разработки проекта. Больше всего энергии надо потратить на этапе создания ТЗ. Ведь этот документ — сердце всего проекта. От его проработки будет зависеть жизнеспособность продукта.
Расскажу о первом этапе в работе над мобильным приложением. ТЗ — самый главный документ наравне с договором. ТЗ разрабатывает специальный человек в компании — бизнес-аналитик. Сразу отмечу, первое, что необходимо сделать клиенту на своей стороне — собрать отдельную группу специалистов. В неё точно должны войти: маркетолог, директор, логист, бухгалтер, рядовой сотрудник компании (например продавец-консультант, который работает с покупателями) и IT-директор. Проще говоря, по одному сотруднику из каждого отдела плюс верхушка компании. Эта группа должна быть включена в процесс обсуждения функциональности приложения, чтобы в драфт ТЗ попали все хотелки. Совместно с группой клиента будет сформирован объемный образ будущего мобильного приложения (МП).
Группу собрали — отлично! Аналитик изучит бизнес-процессы компании, посмотрит сайт, проанализирует конкурентов и их цифровые продукты. Потом выявит требования, определит приоритеты, подготовит спецификации, подготовит скелет ТЗ и набросает структуру будущего МП. Затем он разошлет файл участникам группы, и в назначенное время пройдет еще одни митинг. На встрече аналитик подробно расскажет о структуре МП и зафиксирует договоренности.
Процедура может повторяться еще несколько раз. Бизнес-аналитик будет кропотливо вносить коррективы, правки и замечания от клиента и команды разработчиков.
Читаем, разбираемся и описываем все очень подробно. Данные собраны, все высказались. Аналитик собирает единый документ, детально описывает функции мобильного приложения. Работа кропотливая, требует внимательности и воображения.
Порой я встречаю мнение, что ТЗ — просто бумажка. И слышу от клиента следующее:
—Мы же вам всё ясно и понятно объясняем. Зачем так подробно и нудно это обсуждать?
—Там не сложно. Скоро уже закончим? Может вы уже сами допишете и начнем разрабатывать?
—Нам нужно чтобы было, как у них. Просто возьмите и повторите.
И так далее. Но я приведу обычный пример. Возьмём всем понятную и самую популярную функцию приложения push-уведомления. Тут же вроде и говорить не о чем, и так ясно! Пуши должны приходить. Сделайте их и всё. А в реальности Push это отдельный вид искусства, который требует специальной проработки и вот почему.
- Пушей существует много видов. Нужно понять, как клиент хочет отправлять эти пуши. Всем сразу или сегментировать аудиторию и разбить по группам пользователей, или избранным пользователям. В какие моменты пуши должны быть отправлены, по расписанию или по определенным триггерам-событиям и так далее. Это отдельная настройка персонализированной рассылки push-уведомлений.
- Пуши на Android приходят по-разному из-за того, что есть smart-режим в ОС. Это надо предусмотреть и сказать об этом клиенту заранее.
- Есть возможность настраивать пуши, чтобы они приходили с картинками или без.
- Есть возможно чтобы пуши при тапе (при нажатии на него пальцем) на них открывали соответствующую страницу приложения. Это отдельный функционал, который называется deep linking.
- Есть разные возможности для реализации пуша, нативная или через например FCM или скажем через сервисы автоматизации push-рассылки Push Woosh. Одни дают возможность сегментировать аудиторию по разным признакам, другие позволяют собирать уникальные данные для аналитики.
Для примера есть статистика сервиса Kahuna — хорошо разработанные push-уведомления увеличили показатель возвратов пользователей (то, что называется Retention) в приложения более чем в 2 раза.
В общем, такая на первый взгляд простая вещь как Push-уведомление имеет очень много скрытых возможностей в реализации. И бизнес-аналитик должен обо всём сказать клиенту, объяснить, как это будет работать и узнать, как клиенту хочется, чтобы пуши были реализованы на приложении. Так и с регистрацией, и с каталогом, и с карточкой товара и так далее. Все подробности, все нюансы будут влиять на стоимость разработки и на время разработки. Отдельное внимание в ТЗ стоит уделить требованиям к интеграции сервисов и АПИ.
Задача разработчиков мобильного приложения позаботиться, чтобы ТЗ было очень подробное. Ведь исправления и корректировки на этапе программирования драматически увеличивают стоимость проекта. Важно продумать все на этапе проектирования. Тогда участники группы на стороне клиента смогут чётко понять, что будет за продукт и как он будет работать. Информация даст объемное видение мобильного приложения.
Имеем ТЗ — представляем, как будет выглядеть работа с МП. В итоге клиент получает то, что хочет. Великолепно работающий продукт. Потребуется от двух до 4 недель работы над техническим заданием.
Далее ТЗ берут программисты, дизайнеры, тестировщики, менеджер и декомпозируют на простые задачи. Раскладывают, что называется «по ручкам». Оценивают, сколько потребуется времени, чтобы разработать приложение. Потом я собираю коммерческое предложение с оценкой. Презентую клиенту.
Вот что дает ТЗ клиентам:
- Экономия времени — в документе уже есть все ответы, не надо ничего уточнять.
- Экономия денег — предусмотрели и не надо больше тратиться.
- Экономия нервов — я заплатил, я продумал, я договорился и все под контролем, все знают над чем они работают и чего я и все остальные ждут.
- Сформированное видение продукта.
- Сформированные ожидания.
- Возможность посмотреть, как работает команда, которую вы выбрали для написания мобильного приложения, на конкретной одной ясной задаче — разработка ТЗ.
- Возможность потом отправить готовое ТЗ в любую компанию для оценки — потенциально найти лучшие условия.
- Все хотелки проговариваются и фиксируются. Есть возможность их увидеть и осознать. Как следствие, выстроить иначе, чем планировалось. Отказаться от какого-то функционала, что-то изменить или усилить.
ТЗ — это бог разработки.
Мне кажется, что статье не хватает важного примечания - в нашей стране, нужно получать согласование на проведение митинга. А вот на проведение встречи - нет. И если уж вы хотите донести вашу мысль до широкого круга читателей, то стоит избегать привычных вам терминов, имеющих совершенно другое значение в русском языке, при условии, что есть отличные русские слова, абсолютно точно и исчерпывающе описывающие суть термина.
Нет, не стоит.