Потерял месяц согласований по разработке приложения, психанул. Теперь только платные брифы

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

Тут мы отчасти сами виноваты — не могли остановиться и перелопатили кучу конкурентов, предлагали идеи и записывали их в ТЗ. В итоге потратили чересчур много времени на проект, который не сложился. Теперь делаем отдельный договор под ТЗ, когда видим, что планы меняются и за два созвона тут не порешать.

Почему платный бриф для разработки — это норма?

Представим ситуацию: к вам пришел клиент с запросом сделать сайт как у Apple. Никакого брендбука, только цвета из логотипа. Сначала проводим 1-2 бесплатных созвона. Если после них не появляется представление о том, какой продукт будет на выходе — нужно брифовать. Брифы займут как минимум 1 месяц. Это еженедельные созвоны, а параллельно ТЗ. Зачем? Чтобы клиент знал, что получит в итоге, а команда понимала, с каким объемом задач придется работать.

И почему такая работа должна выполняться бесплатно? (риторически в пустоту)

Как понять, сколько денег брать за техническое задание для приложения?

Я определяю стоимость ТЗ по часовой ставке менеджера, который будет его писать. В эти часы не включаю брифинг, только работу над техническим заданием. Эти работы клиент оплачивает отдельным договором сразу.

Этапы разработки ТЗ

СОБИРАЕМ ОБЩУЮ ИНФОРМАЦИЮ

После первичных созвонов с клиентами заключаем договор на техническое задание на разработку приложения. В течение 1-2 месяцев проводим еженедельные созвоны, менеджер параллельно пишет . Узнаем, что за приложение будет:

— для iOS или Android или и то и то?

— какие языки интерфейса нужны

— на чем будем делать

— какой язык программирования или технологию используем— кто им будет пользоваться: регион публикации, регион использования.

— где оно будет размещаться: площадка публикации, сервер хранения

— как будем зарабатывать с помощью приложения

По поводу языков программирования — мы это определяем от задач, если у заказчика нет пожеланий. Вот такие есть три варианта:

1. No-code и Low-code приложение по технологии drag-and-dropТакой вариант подходит, если: денег мало, сроки горят, нужно сразу и Android и IOS, нужны более ли менее стандартные понятные вещи. Для нас меньше мороки, а для заказчика быстрее и дешевле. Конечно, если приложение нельзя сделать помощью конструктора, мы пишем его кодом.

2. Нативные приложенияОтдельно пишем для IOS на Свифте и отдельно для Android на Котлине. Это самый надежный вариант. Его выбирают, когда планируется много анимаций.

3. Кроссплатформенные приложения Вариант похож на нативные приложения, но его быстрее делать, и стоит он дешевле. Пишется сразу под IOS и Android на Flutter.

Как выбираем сервер хранения?

1. Для международных стартапов — облачные сервера хранения данных. Чаще всего у заказчика нет бюджета на то, чтобы сделать в каждой стране свой сервер. В таком случае мы используем специальные облачные сервисы, которые за нас распределяют данные в юрисдикции нужных стран.

2. Если работаем по России — подбираем по стоимости. Чаще всего пользуемся облаками, либо приобретаем сервер.

ОБСУЖДАЕМ ФУНКИЦОНАЛ

Мы описываем действия, которые клиент будет совершать в приложении. Действия должны быть максимально конкретными и с минимальным количеством технических деталей. Мы отвечаем на вопрос: что должен сделать клиент, чтобы совершить то или иное действие.

Например: Я, как пользователь, хочу иметь возможность добавлять товар в список избранных, для того чтобы в дальнейшем быстро находить его. Здесь понятно, что хочет клиент и для чего.

Антипример: я, как пользователь, хочу, чтобы приложение было удобно для использования. Тут непонятно, что конкретно хочет человек и что для него «удобно». Это общие слова и они не помогают понять, какой функционал ожидает пользователь.

ОПИСЫВАЕМ ИНТЕРФЕЙС

Здесь уже наглядно показываем:

— какие экраны будут в приложении?

— что на каждом экране может сделать пользователь: какие кнопки нажать, куда написать, что перелистнуть?

Такая схема называется User Flow. Она нужна разработчикам и дизайнерам, чтобы видеть, что будет происходить в приложении. Так будет меньше риска, что придется исправлять кучу недочетов и переписывать код.

ЗАБИРАЕМ БРЕНДБУК И ВСЕ, ЧТО С НИМ СВЯЗАНО

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

Как понять, какие вопросы задавать на брифе?

Вопросы во многом зависят от ниши — если приложение для интернет-магазина, то будут одни вопросы, а если для агентства недвижимости, то другие. К нам часто обращаются за приложениями для интернет-магазинов, такси, кафе и ресторанов и агентств недвижимости.

Вот примерные вопросы, которые мы задаем:

И еще вот такие:

А также такие:

Ну и вот:

В заключение

По итогу понятно, что работы тут довольно много. Я пробежался по верхам, но на деле такое ТЗ может быть объемом до 120 страниц. Это супер детальная проработка всего, что будет делаться на сайте: от визуала до внутрянки. И брать за это деньги — логично.

Коллеги, а вы берете отдельные деньги за бриф и ТЗ?

Начал вести тг канал — там раз в неделю выпускаю статьи об IT для предпринимателей. Подписывайтесь, если вам такое интересно.