Словарь заказчика: MVP, ТЗ, деплой и другие слова простым языком
На первом созвоне с разработчиками звучат слова, которые кажутся очевидными всем, кроме вас. Переспрашивать неловко, а от смысла этих слов зависят деньги и сроки. Здесь — 30 слов и понятий, которые вы услышите чаще всего, и что каждое значит для заказчика.
Как пользоваться
- Слова сгруппированы по этапам: идея, работа с командой, техника, запуск, деньги, ИИ.
- У каждого слова — короткое определение и строка «Что важно вам»: на что смотреть как заказчику.
- Если исполнитель говорит словами, которых нет здесь, — просите объяснить. Хороший исполнитель умеет говорить без жаргона.
Содержание
Идея и первая версия · Работа с командой · Техника · Запуск · Деньги · ИИ и no-code
Идея и первая версия
MVP
Минимальная версия продукта, которой уже можно пользоваться и за которую уже можно платить. Не «урезанный продукт», а самый короткий путь проверить главное: решает ли продукт задачу людей. Всё, без чего главный сценарий работает, откладывается.
Что важно вам: чем точнее вы ответите «что не входит в MVP», тем быстрее и дешевле он будет. MVP не обязательно код: иногда это ручной сервис или сборка из готовых инструментов — об этом отдельная статья.
Прототип
Модель продукта, на которой видно, как он будет устроен: экраны, кнопки, переходы. Бывает картинками, бывает кликабельным, бывает работающим кусочком кода. Прототип нужен, чтобы договориться о продукте до того, как его дорого строить.
Что важно вам: спрашивайте, какой прототип вы получите — нарисованный или работающий, и можно ли показать его будущим пользователям.
Главный сценарий
Путь, ради которого продукт существует: например, «клиент выбирает время и записывается на занятие». Его описывают шагами — что делает человек и что показывает продукт.
Что важно вам: если главный сценарий записан шагами, исполнитель гораздо реже делает «не то».
ТЗ (техническое задание)
Документ, где описано, что нужно сделать: для кого продукт, какие сценарии, что входит и что нет, ограничения по срокам, бюджету и платформам. ТЗ не обязано быть толстым — одна понятная страница часто полезнее сорока.
Что важно вам: всё, о чём договорились устно, должно попасть в письменный текст. Как написать задачу без технических знаний — в статье про ТЗ на одной странице.
UX и UI
UX — насколько продуктом удобно пользоваться: понятно ли, куда нажать, сколько шагов до цели. UI — как продукт выглядит: цвета, шрифты, кнопки. Красивый интерфейс с неудобным сценарием всё равно теряет пользователей.
Что важно вам: оценивайте дизайн, проходя сценарий на телефоне, а не разглядывая картинки.
Работа с командой
Бэклог
Общий список задач по продукту, отсортированный по важности. Сверху — то, что делаем в ближайшее время, внизу — идеи «на потом».
Что важно вам: попросите доступ к бэклогу. Так вы видите, что в работе, и сами решаете, что важнее.
Спринт
Короткий отрезок работы, обычно неделя или две, с понятной целью. В начале спринта выбирают задачи, в конце показывают результат.
Что важно вам: у каждого спринта должен быть результат, который можно увидеть, а не только отчёт о проделанной работе.
Демо
Показ того, что сделано: исполнитель открывает продукт и проходит сценарии при вас. Хорошее демо — это то, что можно открыть и потрогать самому, по ссылке.
Что важно вам: регулярные демо — самый простой способ заметить проблему через неделю, а не через полгода. Как принимать работу без знания кода — в отдельной статье.
Оценка (смета)
Прогноз, сколько времени и денег займёт работа. Хорошая оценка показывает, из чего она сложилась: какие части продукта, кто их делает, где запас на риски.
Что важно вам: сравнивайте оценки только на одинаковом описании задачи — иначе вы сравниваете разные продукты. Подробно — в статье о стоимости разработки.
Приёмка и критерии «готово»
Проверка, что работа сделана так, как договаривались. Критерии «готово» — заранее записанные условия: что должно работать, на каких устройствах, с какими данными.
Что важно вам: критерии лучше записать до начала работы — тогда приёмка становится проверкой по списку, а не спором.
Техника
Фронтенд и бэкенд
Фронтенд — то, что видит пользователь: экраны сайта или приложения. Бэкенд — то, что работает «за кулисами»: хранит данные, считает, принимает оплату, отправляет уведомления.
Что важно вам: красивые экраны без бэкенда — ещё не работающий продукт. На демо просите показать сценарий с настоящими данными.
API
Способ, которым программы общаются между собой. Через API ваш продукт принимает оплату, отправляет сообщения в Telegram, берёт данные из CRM или другой системы.
Что важно вам: у многих внешних сервисов есть ограничения и платные тарифы. Спросите заранее, какие сервисы нужны продукту и сколько они стоят в месяц.
База данных
Место, где хранятся данные продукта: пользователи, заказы, записи, платежи. Если там есть личные данные людей, к базе предъявляют требования по безопасности и хранению.
Что важно вам: выясните, кто имеет доступ к базе, где она находится и делаются ли резервные копии.
Репозиторий и Git
Репозиторий — хранилище кода с историей всех изменений: кто, когда и что поменял. Git — программа, которая ведёт эту историю; GitHub и GitLab — самые известные сервисы, где хранят репозитории.
Что важно вам: репозиторий должен принадлежать вам с первого дня. Тогда код ваш, даже если исполнитель сменится. Что ещё должно быть оформлено на вас — в статье о выборе подрядчика.
Хостинг и сервер
Компьютер в дата-центре, на котором работает ваш продукт, и услуга его аренды. Хостинг оплачивается помесячно, как связь.
Что важно вам: аккаунт хостинга лучше оформить на себя, а исполнителю выдать доступ. Тогда сервер не «уйдёт» вместе с исполнителем.
Домен
Адрес сайта, например diaverse.app (а systems.diaverse.app — его поддомен). Домен регистрируют на конкретного владельца на срок, обычно на год, и вовремя продлевают: просроченный домен может занять кто-то другой.
Что важно вам: домен должен быть зарегистрирован на вас. Восстановить домен, оформленный на исполнителя, бывает очень сложно.
Деплой и релиз
Деплой — выкладка новой версии кода на сервер: на тестовый — чтобы проверить, на рабочий — чтобы её увидели пользователи. Релиз — выпуск версии для всех: новая версия приложения в магазине или обновление сайта.
Что важно вам: спросите, можно ли откатиться на прошлую версию, если что-то пошло не так.
Баг и тестирование
Баг — ошибка: продукт делает не то, что должен. Тестирование — проверка, что всё работает, до того как это увидят пользователи. Иногда этим занимается отдельный специалист — тестировщик.
Что важно вам: спросите, кто и как проверяет работу перед показом вам. Если проверяете только вы — это стоит учесть в сроках.
Запуск
Аккаунт разработчика (App Store, Google Play)
Учётная запись в магазине приложений, от имени которой публикуется приложение. У Apple и Google свои правила регистрации и годовая или разовая плата.
Что важно вам: аккаунт должен быть вашим. Приложение, опубликованное с чужого аккаунта, трудно перенести.
Модерация магазина
Проверка приложения командами Apple и Google перед публикацией. Приложение могут вернуть на доработку — например, из-за оплаты внутри приложения, политики конфиденциальности или ошибок.
Что важно вам: закладывайте время на модерацию и спросите исполнителя, кто готовит описание, скриншоты и отвечает на замечания. Решение о публикации принимают Apple и Google.
Аналитика и воронка
Аналитика — сбор данных о том, что делают пользователи. Воронка — путь пользователя по шагам: зашёл, зарегистрировался, сделал главное действие, заплатил. На каждом шаге часть людей отваливается.
Что важно вам: аналитику стоит настроить с первого релиза — иначе вы не узнаете, где теряете людей.
Retention (удержание)
Доля пользователей, которые возвращаются в продукт через день, неделю, месяц. Если продуктом должны пользоваться регулярно, а люди не возвращаются, — скорее всего, он пока не решает их задачу, сколько бы их ни пришло.
Что важно вам: после запуска смотрите не только на число новых пользователей, но и на то, сколько из них вернулось.
Деньги
Фиксированная цена
Оплата за весь проект целиком по заранее согласованному объёму. Подходит, когда объём понятен и не будет меняться.
Что важно вам: при фиксированной цене любое изменение объёма обычно становится отдельной доплатой. Уточните заранее, как оформляются изменения.
Почасовая оплата (T&M)
Оплата за фактически потраченное время по ставке. Гибко, но итоговая сумма заранее неизвестна.
Что важно вам: договоритесь о регулярных отчётах по часам и о сумме, после которой исполнитель обязан предупредить вас заранее.
Команда помесячно
Фиксированная сумма в месяц за работу постоянной команды. Приоритеты можно менять каждую неделю: новая задача заменяет другую, а не добавляется к счёту.
Что важно вам: уточните, можно ли остановиться после любого месяца и что вы получите на руки, если решите уйти. Так работаем мы в Diaverse: без минимального срока, код и доступы — у вас с первого дня.
Расходы после запуска
Деньги, которые продукт тратит каждый месяц после запуска: хостинг, платные сервисы, рассылки, запросы к ИИ, аккаунты разработчика в магазинах.
Что важно вам: попросите исполнителя заранее перечислить эти расходы — они не всегда входят в цену разработки.
NDA
Соглашение о конфиденциальности: стороны обязуются не раскрывать информацию, которую узнали друг о друге. Его подписывают до того, как вы расскажете идею в деталях. Это не юридическая консультация — текст NDA стоит показать юристу.
Что важно вам: если исполнитель не готов подписать NDA до подробного разговора — это повод задать вопросы.
ИИ и no-code
No-code и конструкторы
Сервисы, в которых продукт собирают без программирования, из готовых блоков. Быстро и дёшево для проверки идеи, но со временем можно упереться в ограничения платформы.
Что важно вам: перед заказом разработки проверьте, не хватит ли готового решения. Если хватит — хороший исполнитель скажет об этом прямо.
Вайбкодинг
Создание программ с помощью ИИ: человек описывает задачу словами, ИИ пишет код. Хорошо подходит для прототипов и проверки идей. Без проверки людьми такой код может не выдержать реальных пользователей, нагрузки и требований безопасности.
Что важно вам: если прототип уже собран с ИИ, он может стать основой продукта — как минимум живым ТЗ, а иногда и кодом. Когда этого хватает, а когда нужна разработка, — в статье про прототип с ИИ.
ИИ в разработке
Многие команды используют ИИ-инструменты, чтобы быстрее писать код и тесты. Разница в том, кто проверяет результат: человек, который понимает архитектуру, или никто.
Что важно вам: спросите исполнителя, как у него проверяется код, написанный с помощью ИИ. Мы в Diaverse используем ИИ для скорости, а архитектуру, безопасность и каждый результат проверяют люди.