Однажды ко мне пришел крупный застройщик, хотел обновить дизайн приложения. Провели два созвона, определились, что будет в дизайне. Делаю простенькое ТЗ на доп. разработку. Все круто, казалось бы. Потом выяснилось, что нужно интегрироваться с 1С. Это сложная доработка, поэтому с командой делаем полноценное техническое задание. Присылаем им готовое ТЗ, договор и счет — ждем ответа. Проходит день, два… неделя. Мы забили, а потом увидели кейс у коллег по нашему ТЗ.
Тут мы отчасти сами виноваты — не могли остановиться и перелопатили кучу конкурентов, предлагали идеи и записывали их в ТЗ. В итоге потратили чересчур много времени на проект, который не сложился. Теперь делаем отдельный договор под ТЗ, когда видим, что планы меняются и за два созвона тут не порешать.
![](https://habrastorage.org/getpro/habr/upload_files/612/b9b/a3f/612b9ba3fe6f8076cc3774a0cc6efdc8.png)
Почему платный бриф для разработки — это норма?
Представим ситуацию: к вам пришел клиент с запросом сделать сайт как у Apple. Никакого брендбука, только цвета из логотипа. Сначала проводим 1-2 бесплатных созвона. Если после них не появляется представление о том, какой продукт будет на выходе — нужно брифовать. Брифы займут как минимум 1 месяц. Это еженедельные созвоны, а параллельно ТЗ. Зачем? Чтобы клиент знал, что получит в итоге, а команда понимала, с каким объемом задач придется работать.
И почему такая работа должна выполняться бесплатно? (риторически в пустоту)
Как понять, сколько денег брать за ТЗ?
Я определяю стоимость ТЗ по часовой ставке менеджера, который будет его писать. В эти часы не включаю брифинг, только работу над техническим заданием.
![Количество часов, которое мы тратим на разработку ТЗ разной сложности. Количество часов, которое мы тратим на разработку ТЗ разной сложности.](https://habrastorage.org/getpro/habr/upload_files/67a/2b2/087/67a2b20874177aa09ca6d6d3220a7b87.png)
Эти работы клиент оплачивает отдельным договором сразу.
Что делаем на брифе?
Собираем общую информацию
После первичных созвонов с клиентами заключаем договор на ТЗ. В течение 1-2 месяцев проводим еженедельные созвоны, менеджер параллельно пишет . Узнаем, что за приложение будет:
для iOS или Android или и то и то?
какие языки интерфейса нужны
на чем будем делать
какой язык программирования или технологию используем
кто им будет пользоваться: регион публикации, регион использования
где оно будет размещаться: площадка публикации, сервер хранения
как будем зарабатывать с помощью приложения
По поводу языков программирования — мы это определяем от задач, если у заказчика нет пожеланий. Вот такие есть три варианта:
No-code и Low-code приложение по технологии drag-and-drop
Такой вариант подходит, если: денег мало, сроки горят, нужно сразу и Android и IOS, нужны более ли менее стандартные понятные вещи. Для нас меньше мороки, а для заказчика быстрее и дешевле. Конечно, если приложение нельзя сделать помощью конструктора, мы пишем его кодом.Нативные приложения
Отдельно пишем для IOS на Свифте и отдельно для Android на Котлине. Это самый надежный вариант. Его выбирают, когда планируется много анимаций.Кроссплатформенные приложения
Вариант похож на нативные приложения, но его быстрее делать, и стоит он дешевле. Пишется сразу под IOS и Android на Flutter.
![](https://habrastorage.org/getpro/habr/upload_files/23a/c08/0e9/23ac080e96af88ded41a6cf94489fd10.png)
Как выбираем сервер хранения?
1. Для международных стартапов — облачные сервера хранения данных. Чаще всего у заказчика нет бюджета на то, чтобы сделать в каждой стране свой сервер. В таком случае мы используем специальные облачные сервисы, которые за нас распределяют данные в юрисдикции нужных стран.
2. Если работаем по России — подбираем по стоимости. Чаще всего пользуемся облаками, либо приобретаем сервер.
![ТЗ для мобильного приложения из сферы недвижимости ТЗ для мобильного приложения из сферы недвижимости](https://habrastorage.org/getpro/habr/upload_files/ecc/50e/9c7/ecc50e9c7fed48fa58848f2524a420e2.png)
Обсуждаем функционал
Мы описываем действия, которые клиент будет совершать в приложении. Действия должны быть максимально конкретными и с минимальным количеством технических деталей. Мы отвечаем на вопрос: что должен сделать клиент, чтобы совершить то или иное действие.
Например: Я, как пользователь, хочу иметь возможность добавлять товар в список избранных, для того чтобы в дальнейшем быстро находить его. Здесь понятно, что хочет клиент и для чего.
Антипример: я, как пользователь, хочу, чтобы приложение было удобно для использования. Тут непонятно, что конкретно хочет человек и что для него «удобно». Это общие слова и они не помогают понять, какой функционал ожидает пользователь.
Результат обсуждения с заказчиком идет в ТЗ по функционалу:
![Функционал для приложения доставки продуктов Функционал для приложения доставки продуктов](https://habrastorage.org/getpro/habr/upload_files/d57/020/780/d5702078031a27ef549e4d0720dd6ff8.png)
Описываем интерфейс
Здесь уже наглядно показываем:
какие экраны будут в приложении?
что на каждом экране может сделать пользователь: какие кнопки нажать, куда написать, что перелистнуть?
Такая схема называется User Flow. Она нужна разработчикам и дизайнерам, чтобы видеть, что будет происходить в приложении. Так будет меньше риска, что придется исправлять кучу недочетов и переписывать код.
![Главный экран приложения сна Главный экран приложения сна](https://habrastorage.org/getpro/habr/upload_files/528/257/cbd/528257cbded8edb60e5a4ca2a3bb5f5b.png)
Забираем брендбук и все, что с ним связано
Тут мы дорабатываем все требования к интерфейсу: прикрепляем брендбуки, референсы и макеты. По сути — это финальные согласования дизайна всего приложения. Здесь принимаем все оставшиеся правки.
Как понять, какие вопросы задавать на брифе?
Вопросы во многом зависят от ниши — если приложение для интернет-магазина, то будут одни вопросы, а если для агентства недвижимости, то другие. К нам часто обращаются за приложениями для интернет-магазинов, такси, кафе и ресторанов и агентств недвижимости.
Вот примерные вопросы, которые мы задаем:
![](https://habrastorage.org/getpro/habr/upload_files/569/c35/3da/569c353da7a655ff53e74f8b59fb2e6c.png)
![](https://habrastorage.org/getpro/habr/upload_files/b60/130/58e/b6013058e42ea67028e8f5765e09ebd0.png)
![](https://habrastorage.org/getpro/habr/upload_files/a6a/792/d57/a6a792d57f78d8b3d90f809a3ada88bf.png)
![](https://habrastorage.org/getpro/habr/upload_files/dbb/c06/663/dbbc066637bd111537055093fd38c2b3.png)
Что по итогу?
По итогу понятно, что работы тут довольно много. Я пробежался по верхам, но на деле такое ТЗ может быть объемом до 120 страниц. Это супер детальная проработка всего, что будет делаться на сайте: от визуала до внутрянки. И брать за это деньги — логично.
Коллеги, а вы берете отдельные деньги за бриф и ТЗ?
Начал вести тг канал — там раз в неделю выпускаю статьи об IT для предпринимателей. Подписывайтесь, если вам такое интересно.