Короткий ответ: для предварительной оценки разработки нужно подготовить не длинное ТЗ, а согласованный контур: бизнес-цель, пользователей, один-два сквозных сценария, список интеграций, ограничения и критерии готовности. Чем яснее границы первой версии, тем честнее можно сравнить состав работ, риски и допущения подрядчиков.
Оценка «сделать приложение» почти ничего не говорит о проекте. Под одним названием могут скрываться личный кабинет, роли, платежи, импорт данных, модерация, уведомления и несколько внешних систем. Если эти различия не вынести на поверхность, подрядчик либо заложит слишком широкий запас, либо назовёт привлекательную цифру, которую позже придётся пересматривать. NIST в SSDF предлагает встраивать практики безопасности в жизненный цикл разработки; для заказчика это хороший повод проверять безопасность и эксплуатацию уже на этапе входных данных, а не после согласования макетов.
1. Начните с решения, которое должен получить бизнес
Первая страница подготовки должна отвечать на вопрос: какое решение станет возможным после запуска? «Нужна цифровизация» — направление, но не критерий. Полезнее описать исходную ситуацию, действие пользователя и ожидаемый управленческий результат без неподтверждённых обещаний эффективности.
| Поле | Что зафиксировать | Пример формулировки |
|---|---|---|
| Проблема | Где возникает ручная работа или потеря данных | Заявки приходят по разным каналам и теряют статус |
| Пользователь | Кто выполняет действие и с какими правами | Клиент создаёт заявку, менеджер меняет статус |
| Сценарий | Что происходит от входа до результата | Создать заявку → проверить → назначить → закрыть |
| Результат | Что можно проверить после внедрения | Есть история статусов и ответственный |
| Ограничение | Что нельзя нарушить | Нельзя показывать клиенту внутренние заметки |
Практический шаг: опишите один путь пользователя пятью глаголами. Если к нему сразу добавляются десять исключений, вынесите их в отдельный список, а не прячьте внутри общей оценки. Paladin Engineering может помочь разложить идею на сценарии и границы MVP через проектирование веб-системы.
CTA: передайте подрядчику одну и ту же карточку проекта и попросите отдельно показать допущения, исключения и то, что не входит в первую версию.
2. Опишите пользователей и роли
Роль — это не только должность. Для оценки важны доступ к данным, допустимые действия и момент, когда требуется согласование. Один и тот же человек может быть автором заявки в одном контуре и проверяющим в другом. Без такой матрицы легко недооценить интерфейсы, серверные проверки и тесты.
| Роль | Видит | Может сделать | Не должен делать |
|---|---|---|---|
| Клиент | Свои заявки и ответы | Создать и уточнить заявку | Видеть внутренние комментарии |
| Менеджер | Назначенные обращения | Изменить статус и ответить | Менять права пользователей |
| Руководитель | Сводку и историю | Утвердить результат | Редактировать чужие данные без причины |
| Администратор | Настройки и журнал | Управлять справочниками | Использовать учётную запись без аудита |
Попросите подрядчика описать не только экраны, но и проверки на сервере: что произойдёт при прямом запросе к API, просроченной сессии, повторной отправке формы и попытке открыть чужой объект. OWASP ASVS можно использовать как ориентир для разговора о проверяемых требованиях безопасности, но он не заменяет анализ конкретной системы.
3. Зафиксируйте границы первой версии
Оценка становится полезной, когда из неё понятно, что именно строится сейчас. Разделите требования на обязательные для запуска, важные для следующего этапа и идеи без подтверждённого приоритета. Не называйте всё MVP: минимальная версия должна быть минимальной для проверки сценария, а не просто первым большим релизом.
- один основной маршрут пользователя от входа до результата;
- минимальная модель данных и справочники, без которых маршрут не работает;
- роли и запреты для каждого объекта;
- интеграции, необходимые для запуска, с владельцем и форматом обмена;
- критерии приёмки для успешного и ошибочного сценария;
- список отложенных функций с причиной, почему они не входят сейчас;
Хорошая граница уменьшает не только объём разработки. Она помогает заказчику сравнить предложения: где один исполнитель считает импорт данных обязательным, а другой оставляет его за рамками; где включены тесты и документация; где поддержка считается частью запуска, а где — отдельной услугой.
4. Подготовьте данные и интеграции
Слова «интеграция с CRM» или «подключить оплату» недостаточны для оценки. Опишите источник истины, события, частоту обмена, формат ошибок и владельца доступа. Если система внешняя, приложите документацию API или хотя бы пример запроса и ответа без секретов.
| Тема | Вопросы для подготовки | Риск при неизвестности |
|---|---|---|
| Источник | Какая система хранит актуальные данные? | Дубли и ручная сверка |
| Событие | Когда должна запускаться синхронизация? | Задержки и повторные операции |
| Идентификатор | Как связать объекты между системами? | Невозможность корректного обновления |
| Ошибка | Кто получает уведомление и что повторяется? | Тихая потеря данных |
| Доступ | Какие ключи и роли нужны на средах? | Задержка и риск лишних прав |
Не передавайте в бриф реальные токены, пароли и выгрузки с персональными данными. Для оценки достаточно обезличенных примеров, схемы полей и описания разрешений. Секреты должны появляться только в защищённом процессе настройки, а не в документе, который пересылают нескольким подрядчикам.
5. Попросите оценку с допущениями
Итоговая цифра без структуры плохо помогает принять решение. Попросите разделить работы на discovery, дизайн, разработку, интеграции, тестирование, запуск и поддержку. Рядом должны быть зависимости: что нужно подтвердить до начала, какие данные предоставить и какие решения могут изменить объём.
| Блок оценки | Что должно быть видно | Хороший вопрос |
|---|---|---|
| Аналитика | Сценарии, роли, модель данных | Какие неизвестные снимаются до разработки? |
| UX/UI | Ключевые состояния и ошибки | Какие экраны нужны для сквозного пути? |
| Backend | Правила, API, журнал действий | Как тестируются права и повторные запросы? |
| Frontend | Состояния загрузки, ошибки, адаптивность | Что увидит пользователь при сбое? |
| QA и запуск | Приёмка, окружения, релиз | Кто и по каким критериям принимает результат? |
Сравнивайте не только сумму и срок. Проверяйте, какие предположения лежат под каждым предложением: количество ролей, число интеграций, объём миграции, наличие готового дизайна, состав поддержки. Если две оценки построены на разных входных данных, разница между ними не показывает, кто дешевле.
6. Составьте чеклист готовности к оценке
- описана бизнес-цель и один сквозной пользовательский сценарий;
- перечислены роли, права и чувствительные данные;
- отделены обязательные функции от идей следующего этапа;
- указаны внешние системы, события и доступные документы API;
- есть примеры данных без секретов и лишних персональных данных;
- согласованы критерии приёмки и негативные сценарии;
- вопросы к подрядчику собраны в одном документе;
- неопределённости явно отмечены как допущения или задачи discovery;
Этот чеклист не превращает раннюю оценку в окончательную смету. Он делает разговор предметным и снижает риск сравнить разные объёмы под одинаковым названием. Discovery всё равно может изменить решение — это нормальный результат, если он фиксирует найденные ограничения до дорогой реализации.
Как Paladin Engineering может помочь
Paladin Engineering помогает подготовить проект к оценке: разобрать цель и роли, описать сквозные сценарии, наметить модель данных, интеграции и критерии приёмки. Для клиентского проекта это может быть короткий предпроектный этап, после которого заказчик получает понятный контур MVP и список вопросов, требующих решения.
CTA: если у вас есть идея, но подрядчики дают несопоставимые оценки, отправьте описание одного сценария и список ограничений — начнём с проверки входных данных, а не с обещания точной цены.
FAQ: подготовка проекта к оценке
Нужно ли писать полное ТЗ до обращения к подрядчику?
Нет. Для первой оценки полезнее согласованный контур, сценарии, роли, интеграции и ограничения. Полное ТЗ может появиться после discovery, когда неизвестные будут проверены.
Можно ли получить точную стоимость по одной идее?
Обычно нет. По идее можно обсудить диапазон и основные факторы, но точность зависит от подтверждённого объёма, данных, интеграций и критериев приёмки.
Что отправить нескольким подрядчикам?
Одинаковый краткий бриф, сценарии, роли, ограничения, примеры данных без секретов и вопросы к оценке. Тогда предложения будут сравнимее.
Нужно ли указывать технологии?
Если есть обязательные ограничения — да, с причиной. Если ограничений нет, лучше описать требования и ожидаемый контур, а стек обсудить после проверки задачи.
Когда нужен discovery?
Когда много ролей, интеграций, исключений или цена ошибки высока. Discovery не гарантирует неизменную смету, но помогает обнаружить неизвестные до основной разработки.
Комментарии