Перед заказом разработки полезно задать подрядчику не двадцать формальных вопросов, а двадцать вопросов, которые помогают принять решение. Они должны раскрыть границы результата, способ оценки, риски, права на код, порядок коммуникации и поддержку после запуска. Если обсуждение сводится к сроку и ставке, значительная часть стоимости и ответственности остаётся невидимой.
Ниже — рабочий чеклист для первой встречи. Он не заменяет договор и техническое задание: его задача — быстро отличить понятный процесс от обещания «сделаем всё под ключ». Проверяйте ответы на собственной задаче и помечайте неизвестные, а не заполняйте их догадками.
1. Вопросы о задаче и результате
Начните с того, что именно должно измениться после запуска. Хороший подрядчик уточняет не только список функций, но и пользователя, контекст, ограничения и критерий успеха. Если поставщик сразу предлагает архитектуру, не разобравшись в процессе, попросите вернуться к исходной проблеме.
- Какую бизнес-проблему решает продукт и что произойдёт, если ничего не менять?
- Кто основной пользователь и какой путь он должен пройти?
- Какой результат первой версии будет считаться полезным?
- Что точно не входит в первую версию?
- Какие ограничения по данным, платформам, интеграциям и безопасности уже известны?
Нужен разбор задачи? Опишите процесс, ограничения и желаемый результат в контактной форме — Paladin Engineering поможет превратить вопросы в проверяемый план работ.
2. Вопросы о составе оценки
Оценка полезна, когда её можно связать с результатами и допущениями. Одно число без состава не помогает сравнить предложения: команды могут считать разные объёмы, уровни тестирования и объём поддержки.
| Вопрос | Что должно быть в ответе | Сигнал для уточнения |
|---|---|---|
| Из чего состоит оценка? | модули, сценарии, этапы и результат каждого этапа | «Всё включено» без расшифровки |
| Какие допущения сделаны? | данные, доступы, API, роли и внешние зависимости | неизвестные спрятаны внутри суммы |
| Что изменит бюджет? | условия пересмотра и порядок change request | любые изменения обещают «учесть» без правил |
| Что входит после разработки? | релиз, документация, гарантия, поддержка и мониторинг | поддержка обсуждается только после оплаты |
Сравнивайте предложения по одинаковой границе. Если в одной смете есть UX, тестирование, аналитика и релиз, а в другой только разработка экранов, более низкая цифра не означает более выгодный выбор. Попросите каждую команду описать, что вы получите на выходе и что останется на вашей стороне.
3. Вопросы о процессе и коммуникации
Процесс важен не ради ритуалов. Он определяет, как рано заказчик увидит ошибочное понимание задачи и как будет принято решение, если требования изменятся. Уточните роли и ритм работы до старта.
- Кто отвечает за продукт, технические решения и приёмку?
- Как часто проходят демонстрации и где фиксируются решения?
- Как выглядит работа с изменением scope?
- Какие артефакты появляются после аналитики и каждой итерации?
- Кто сообщает о риске и в какой срок после его обнаружения?
Для сложного проекта полезен короткий discovery: команда исследует пользователей, процесс, данные и интеграции, а затем предлагает границы MVP. Это не гарантия результата, но способ не подписывать большой объём на основании нескольких общих фраз.
4. Вопросы о коде, данных и безопасности
Заказчику важно заранее понимать, кто контролирует то, без чего продукт нельзя поддерживать. Это касается репозитория, доменов, облачной инфраструктуры, секретов, данных пользователей и документации. NIST SSDF рассматривает безопасность как набор практик жизненного цикла разработки; на встрече это переводится в конкретные вопросы.
| Область | Спросить | Что зафиксировать |
|---|---|---|
| Код | где хранится репозиторий и кто имеет доступ | права, передача и резервная копия |
| Данные | кто владеет данными и как выполняется экспорт | формат, доступ и удаление |
| Доступы | как выдаются и отзываются права | минимально необходимые роли |
| Ошибки | где журналируются инциденты и кто реагирует | канал, SLA/ожидания и эскалация |
| Зависимости | как обновляются библиотеки и внешние API | владелец и порядок проверки |
Не просите обещать абсолютную безопасность. Просите показать практики: разделение доступов, хранение секретов вне кода, проверку входных данных, резервирование, журналирование критичных действий и процедуру исправления уязвимостей.
5. Вопросы о приёмке и запуске
Критерий «работает удобно» трудно проверить. Для ключевых сценариев заранее опишите входные условия, действие, ожидаемый результат и поведение при ошибке. Приёмка должна охватывать не только happy path, но и права, пустые данные, недоступность интеграции и восстановление после сбоя.
- Как выглядит демонстрация готового сценария?
- Какие тестовые данные и доступы нужны заказчику?
- Что считается дефектом, а что новым требованием?
- Кто готовит публикацию, миграцию и откат?
- Как фиксируются известные ограничения первой версии?
Как использовать чеклист на встрече
Не обязательно задавать вопросы строго по порядку. Выберите пять самых рискованных для конкретного проекта, попросите показать пример ответа и зафиксируйте открытые пункты. После встречи сведите ответы в таблицу: факт, предположение, владелец проверки и влияние на решение.
Обсудить следующий шаг можно в Telegram или через контактную форму: принесите текущий процесс и список неизвестных, чтобы оценка начиналась с фактов.
Paladin Engineering подключается к задачам на этапе идеи, discovery, оценки и разработки веб-сервисов, мобильных приложений, внутренних систем и ИИ-решений. На первой встрече полезно принести этот чеклист и описание текущего процесса — так обсуждение быстрее переходит к границам MVP и критериям приёмки.
Частые вопросы о выборе подрядчика
Можно ли выбрать команду только по портфолио?
Портфолио показывает опыт, но не раскрывает процесс, границы задач и поддержку. Дополните его вопросами об оценке, передаче результата и работе с изменениями.
Стоит ли собирать три коммерческих предложения?
Да, если сравнивать одинаковый scope и допущения. Три несопоставимые сметы создают видимость выбора, но не помогают оценить риски.
Нужен ли NDA до первой встречи?
Зависит от чувствительности информации. Часто на первом разговоре достаточно обезличить данные и описать процесс без раскрытия коммерческих секретов.
Что важнее: низкая ставка или состав команды?
Ни то ни другое отдельно. Смотрите на полную стоимость, роли, доступность ключевых специалистов, качество коммуникации и ответственность за результат.
Как проверить обещание «быстро запустим»?
Попросите назвать границы первой версии, зависимости, критерии готовности и то, что не входит в срок. Без этого «быстро» не является проверяемым условием.
Когда можно подписывать договор?
После того как понятны предмет работ, результат этапов, порядок изменений, права на результат, условия оплаты, приёмка и поддержка. Открытые вопросы должны быть явно перечислены.
Комментарии