20 вопросов, которые нужно задать перед заказом разработки

Перед заказом разработки ПО полезно задавать вопросы не только о цене и сроках. Нужно понять, как подрядчик уточняет задачу, кто отвечает за архитектуру, что будет передано, как проверяется качество, кому принадлежат код и данные и что произойдёт после релиза.

Ниже — 20 вопросов по темам. Это не гарантия результата: ответы нужно сопоставлять с вашей задачей, договором и конкретными артефактами. Если вопрос пока без ответа, это повод включить исследование в первый этап.

Хотите проверить исходные вводные? Отправьте задачу Paladin Engineering: сначала определим неизвестные, влияющие на объём и риски.

Вопросы о понимании задачи

Сильный подрядчик начинает не с презентации стека, а с бизнес-операции и проверки результата. Эти вопросы показывают, работает ли команда с причиной задачи, а не только с названием продукта.

1. Какую проблему бизнеса решает продукт?
2. Кто пользователи и какие у них роли?
3. Как выглядит основной сценарий от начала до результата?
4. Что обязательно в первой версии?
5. По какому признаку компания поймёт пользу?

Попросите подрядчика пересказать задачу своими словами и назвать допущения. Если стороны услышали разные продукты, лучше обнаружить это до договора.

Вопросы о процессе и первых результатах

Процесс должен давать проверяемый результат раньше финального релиза: карту сценария, прототип, технический spike или первый инкремент. Спросите, что вы увидите и какое решение сможете принять после этапа.

1. Какой результат появится в первые две недели?
2. Какие артефакты будут после discovery?
3. Как проходят демонстрации?
4. Как оформляются изменения?
5. Как фиксируются принятые решения?

Попросите пример структуры отчёта, прототипа, backlog или критериев приёмки без чужих конфиденциальных данных. Методология полезна только тогда, когда помогает получать обратную связь и управлять изменениями.

Правило: после каждого этапа должно быть понятно, что теперь известно, что изменилось в плане и какие риски остались.

Вопросы о команде и ответственности

Название студии не рассказывает, кто принимает технические решения. Уточните фактический состав команды, доступность специалистов и правила замены. Это важно для продукта, который предстоит поддерживать после релиза.

1. Кто отвечает за архитектуру?
2. Кто ведёт коммуникацию?
3. Какие специалисты реально работают?
4. Что происходит при недоступности ключевого участника?
5. Кто сопровождает систему после релиза?

Большая команда не обязательна. Для небольшой задачи может быть достаточно одного сильного разработчика и понятного технического контроля. Важны покрытие рисков и сохранение контекста.

• роли и ответственные за решения
• формат коммуникации
• резерв и передача контекста
• ревью кода и архитектуры
• документация и обучение

Вопросы о цене, сроках и допущениях

Стоимость зависит от функций, вводных, интеграций, рисков, команды и уровня проверки. Одна цифра без допущений плохо подходит для сравнения. Просите объяснить, что входит в предложение и что оценивается отдельно.

1. Какие допущения лежат в оценке?
2. Что не входит в стоимость?
3. Какие решения сильнее всего влияют на срок?
4. Как оценивается изменение объёма?
5. Что считается выполненным для оплаты этапа?

Сравнивайте предложения по одинаковым границам. В одной смете может быть тестирование, миграция и поддержка, а в другой — только экраны. Низкая цена без состава обязательств не доказывает экономию.

Вопросы о качестве, безопасности и данных

Качество описывают проверками, а не словом «аккуратно». Обсудите валидацию, роли, журналирование, резервные копии, зависимости, доступы и ошибки. OWASP ASVS можно использовать как основу проверяемых требований безопасности.

1. Как тестируются основной путь и ошибки?
2. Как проверяются права и чужие данные?
3. Что происходит с исходными и пользовательскими данными?
4. Как организованы резервные копии?
5. Как передаются секреты, исходники и документация?

NIST SSDF связывает практики безопасной разработки с требованиями бизнеса и риском. Набор процедур не обязан быть одинаковым для всех проектов, но подрядчик должен объяснить, какие проверки нужны вашей системе.

• критерии готовности и регрессия
• серверная валидация
• разделение тестовых и production-доступов
• обновление зависимостей
• реакция на дефект
• владелец данных и инфраструктуры

Вопросы о договоре и передаче

Договор должен закреплять не только цену и дату, но и результат, изменения, права на код и данные, доступы, конфиденциальность, приёмку и поддержку. При существенных рисках технические формулировки стоит проверить с юристом.

1. Что считается результатом этапа?
2. Кому принадлежат код, дизайн и данные?
3. Как передаются репозитории и доступы?
4. Как принимаются работы и заявляются дефекты?
5. Что происходит при смене подрядчика?

Существенные решения лучше включать в договор, приложение или согласованный документ, а не оставлять только в переписке. Зафиксированные границы уменьшают дорогие трактовки после старта.

Как использовать список

Не нужно задавать все 20 вопросов подряд. Для внутренней системы важнее роли, данные и поддержка; для SaaS — изоляция клиентов; для интеграционного сервиса — контракты и ошибки. Выбирайте вопросы по цене ошибки.

1. опишите одну задачу и основной сценарий
2. отметьте неизвестные
3. задайте одинаковые вопросы кандидатам
4. попросите образец результата
5. сравните допущения и приёмку
6. зафиксируйте следующий проверяемый шаг

Как Paladin Engineering может помочь. Мы проводим разбор вводных, выделяем первую версию, описываем сценарии и критерии, а затем предлагаем формат разработки и контроля: веб-разработка или обсуждение задачи.

FAQ: вопросы перед заказом разработки

Нужно ли задавать все 20 вопросов?

Нет. Выберите вопросы по риску, но темы задачи, ответственности, цены, качества, данных, передачи и поддержки желательно закрыть до решения.

Какой ответ должен насторожить?

Системная неопределённость: нет владельца решения, допущений, результата этапа или критериев приёмки. Просите конкретный артефакт.

Можно ли сравнивать предложения только по цене?

Нет. Сначала приведите их к сопоставимому объёму, затем сравнивайте цену и риски корзины работ.

Что попросить до договора?

План первых шагов, вопросы к бизнесу, список неизвестных, состав команды, приёмку, допущения и правила изменений.

Кто принимает разработку?

Бизнес проверяет процесс и критерии, технический ответственный — архитектуру и эксплуатацию. Роли могут совмещаться, но ответственность назначается явно.

Нужен ли юрист?

При чувствительных данных, значимых платежах, правах или сложных обязательствах юридическая проверка разумна.