Вы приходите к разработчику с идеей и спрашиваете: сколько это будет стоить. В ответ получаете пятнадцать уточняющих вопросов.
Это не попытка уйти от ответа. Без этих вводных две одинаково честные оценки могут отличаться в несколько раз — просто потому, что каждый подставил в неизвестные места свои предположения.
«Как создать приложение» начинается не с кода и не с выбора подрядчика, а с описания задачи: от него зависит всё остальное, включая сумму в смете.
Проблема в том, что слово «техническое задание» пугает и звучит как документ на сорок страниц, который должен написать кто-то знающий. На старте это не так. На старте нужна вводная — ответы на полтора десятка вопросов, и почти на все может ответить только заказчик: подрядчик их не выдумает, он может лишь угадать.
Ниже — эти вопросы, ровно в том порядке, в котором я задаю их на первом разборе. Плюс короткое объяснение, зачем каждый нужен и что происходит с оценкой, когда ответа нет.
Каким должно быть техническое задание на приложение на старте
Полное ТЗ с описанием каждого экрана, состояний и правил — это результат этапа проектирования, и делается оно уже за деньги, вместе с подрядчиком. Требовать такой документ от заказчика до первого разговора бессмысленно: чтобы его написать, надо уже знать ответы, которые как раз и вырабатываются в работе.
А вот стартовую вводную заказчик может собрать сам. Без неё подрядчик назовёт только очень предварительную вилку — точность появляется после ответов. Его задача скромнее: описать не как делать, а что и для кого. Из него подрядчик понимает объём — сколько ролей, сколько сценариев, сколько связей с чужими системами, — и только из этого получается оценка, которую можно проверить.
Разница между двумя документами — примерно как между «куда мы едем» и «по какой полосе». Первое обязан знать заказчик. Второе — работа исполнителя.
Задача и результат: вопросы 1–3
1. Какую задачу человека решает продукт?
Не «что он делает», а какую проблему закрывает. «Приложение для доставки» — это описание формата. «Человек хочет заказать обед за две минуты, не звоня и не объясняя адрес заново» — это задача, из которой уже видно, что должно быть в продукте.
2. Кто им будет пользоваться?
Один тип пользователя или несколько. И важно не только кто это, но и в каких условиях он пользуется продуктом: за рулём, на складе в перчатках, за рабочим компьютером. Один и тот же сценарий в этих условиях потребует разных решений.
3. Что вы считаете успехом первой версии?
Какое поведение людей подтвердит, что продукт нужен: повторный заход, оформленный заказ, оставленная заявка, приглашённый коллега. Без этого ответа режется не объём, а качество — по вкусу. И спорить о составе становится нечем: любая функция защищается фразой «а вдруг без неё не пойдёт».
Главный сценарий: вопросы 4–6
4. Что человек делает в продукте по шагам?
От первого экрана до результата, обычными словами: открыл — увидел — выбрал — подтвердил — получил. Этот список и есть основа сметы: каждый шаг — экраны, данные и логика за ними.
5. Что происходит до и после этого сценария?
Откуда человек приходит: реклама, ссылка от знакомого, QR-код на столе. И что происходит после: приходит уведомление, кто-то на вашей стороне видит заявку, что-то попадает в таблицу или CRM. Именно здесь обычно всплывает работа, которой вообще не было в первоначальном списке экранов.
6. Что должно произойти, если что-то пошло не так?
Оплата не прошла, интернета нет, исполнитель не ответил, товар закончился после оформления. Ошибочные ситуации редко обсуждают до старта, а делать их всё равно приходится — и это заметная часть работы, которой не видно в списке функций.
Роли и данные: вопросы 7–9
7. Сколько ролей в продукте?
Клиент, исполнитель, менеджер, администратор. Три роли — это не три дополнительные кнопки: у каждой появляются свои права, экраны и состояния, поэтому сложность растёт заметно быстрее, чем кажется по списку функций. Это один из главных множителей бюджета.
8. Откуда берутся данные?
Пользователь вводит их сам, они приходят из вашей системы, из внешнего сервиса или загружаются файлом. Отдельный вопрос — кто и как их обновляет: каталог, цены, расписание, остатки. Продукт, который живёт на актуальных данных, требует и способа их поддерживать.
9. Насколько данные чувствительные?
Персональные, финансовые, медицинские данные добавляют требований к разграничению доступа, хранению, журналированию и защите. Чем чувствительнее данные, тем больше работы там, где её не видно на экранах.
Связи с внешним миром: вопросы 10–12
10. С какими системами продукт должен обмениваться данными?
CRM, 1С, склад, календарь, телефония, служба доставки. По каждой — что именно должно уходить и приходить. Наличие у системы API — только половина дела: разобраться в её логике и ограничениях занимает больше времени, чем написать код на своей стороне.
11. Нужны ли оплаты внутри продукта?
Если да — какие: разовая оплата, подписка, предоплата с доплатой, возвраты. Кнопка оплаты — не кнопка, а серверная логика со статусами, ошибками и повторными операциями.
12. Как продукт связывается с человеком?
Push-уведомления, сообщения в мессенджер, письма, звонки. И главное — по какому событию и что человек должен сделать после. Отправить сообщение просто; выстроить логику «кому, когда, при каком событии и куда вести дальше» — отдельная работа.
Ограничения: вопросы 13–15
13. Где это должно работать?
iOS, Android, браузер, всё сразу. Ответ зависит от того, как люди пользуются продуктом: если они за компьютером и по работе, создание мобильного приложения может оказаться самым дорогим способом решить задачу, которую закрывает веб-кабинет.
14. Есть ли жёсткие сроки и рамка бюджета?
Не для того, чтобы «подогнать смету». Наоборот: зная рамку, можно честно сказать, что в неё влезает, а что нет — и предложить порядок работ вместо отказа. Разговор без рамки чаще заканчивается оценкой, которая не подходит никому.
15. Кто принимает решения и кто отвечает за содержимое?
Один человек с правом решать или согласование через троих. И отдельно: кто даёт тексты, фотографии, описания, юридические документы. Из-за этого проекты нередко простаивают уже на финише: разработка готова, а текстов, фотографий или юридических документов ещё нет.
Как создать приложение, если ответы уже есть
Из ответов на эти пятнадцать вопросов уже получается рабочее техническое задание на приложение — по крайней мере, та его часть, которую способен собрать заказчик. Не сорок страниц — несколько абзацев, из которых понятно, что строим и для кого.
Дальше с ними можно делать три вещи.
Понять, что вообще строить. Вопрос «как создать приложение» на практике распадается ровно на эти пятнадцать: пока на них нет ответов, любой следующий шаг — выбор платформы, подрядчика или стека — делается наугад.
Сравнивать подрядчиков по существу. Одинаковые вводные дают сопоставимые оценки. Если два предложения отличаются в разы при одном и том же описании — разница в составе работ, и её видно построчно.
Отделять первую версию от второй. Не всё из ответов должно попасть в первый запуск: в него входит только то, без чего нельзя проверить успех из вопроса 3. Как устроен состав первой версии и что в него не входит — в разборе разработки MVP приложения.
Ответы на вопросы дают вводные. Следующий шаг — разложить из них функции на две группы: что действительно нужно для проверки первой версии и что можно отложить. Для этого у меня есть одностраничный рабочий лист: гипотеза, таблица функций с колонкой «что это тянет за собой» и два итоговых списка. Напишите слово «шаблон» в Telegram или Max (контакты в подвале) — пришлю.
Чего в этих вопросах нет намеренно
Здесь нет ни одного технического вопроса: ни про стек, ни про архитектуру, ни про базу данных. Это работа подрядчика, и требовать ответов на них от заказчика — способ переложить свою часть.
Нет и списка функций. Список появляется из ответов, а не наоборот: начав с «нам нужны чат, лента и уведомления», вы описываете чужое приложение, а не свою задачу. Как это заканчивается, я разбирал в шести ошибках первой версии.
Если ответов пока нет
Это нормально, и это не повод откладывать разговор.
Для первого разговора достаточно ответов на вопросы 1–3: они про ваш бизнес, а не про разработку. Пройдёте первые шесть — оценка будет точнее. Остальные проясняются на разборе: часть я задаю сам, часть отпадает, когда становится понятен главный сценарий.
Это, кстати, ответ и тем, кто ищет, как создать своё приложение без подрядчика: пятнадцать вопросов нужны в любом случае. Меняется только то, кто будет отвечать на них дальше — вы сами, ваша команда или исполнитель.
Что действительно стоит принести на первый разговор — не техническое задание на приложение целиком, а задачу и представление о том, как человек ею пользуется. Форматы запуска, их состав и порядок цен — на странице разработки приложений.
И ещё раз, потому что это главный барьер: сорок страниц писать не надо. Пришлите ответы хотя бы на первые три вопроса — покажу, что из них должно попасть в первую версию, а что спокойно ждёт второй.