Как выбрать партнёра по разработке: 12 вопросов до договора

Короткий ответ: сравнивайте доказательства, а не уверенность на встрече

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

Задайте всем кандидатам одинаковые 12 вопросов и попросите короткий письменный ответ с примером артефакта: планом discovery, критериями приёмки, шаблоном отчёта, описанием релизного процесса или перечнем передаваемых доступов. Так вы сравните реальные границы ответственности, а не разные по красоте презентации.

1. Как вы проверите, что мы решаем правильную проблему?

Хороший ответ начинается с пользователей, текущего процесса, ограничений и измеримого изменения, а не с выбора фреймворка. Попросите кандидата назвать вопросы discovery, людей, которых он хочет услышать, реальные случаи, которые изучит, и критерий решения go/no-go.

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

2. Кто фактически будет работать и кому принадлежат решения?

Уточните не только должности на презентации, но и состав рабочей команды по этапам: кто отвечает за продукт, исследование, дизайн, архитектуру, разработку, QA, релиз и эксплуатацию. GOV.UK рекомендует междисциплинарные команды, потому что продуктовые решения требуют разных навыков и меняются на протяжении жизненного цикла.

Доказательство — имена или роли реальных исполнителей, доступ к ответственному человеку и понятная матрица решений. Зафиксируйте, кто может согласовать объём, принять сценарий, остановить релиз и заменить участника без потери контекста.

3. Что мы увидим до начала production-разработки?

Попросите разделить исследование, прототип и production-код. До крупного обязательства должны появиться карта задачи, критический пользовательский путь, рискованные предположения, прототип и объяснимая граница первого релиза. Это не обязательно большой документ, но материал должен позволять принять решение.

Доказательство — пример прототипа и перечень вопросов, которые он проверял. Важно услышать, что команда готова отбросить неработающую идею: прототип, который можно только одобрить, не снижает риск.

4. Из чего состоит оценка и как управляются изменения?

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

Доказательство — допущения оценки, список in/out, критерии приёмки и процедура change request. GOV.UK описывает agile-планирование как видимое и уточняемое по мере обучения; это не означает бесконтрольный бюджет, если влияние каждого изменения показывается до выполнения.

5. Как я буду видеть прогресс и принимать решения?

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

Доказательство — пример краткого статус-отчёта с результатом, решениями, блокерами, изменениями и следующим проверяемым результатом. Со своей стороны назначьте владельца продукта, который может отвечать вовремя: прозрачность не помогает, если решения неделями ждут клиента.

6. Как вы докажете качество до релиза?

Попросите описать уровни проверки для вашей задачи: review кода, автоматические и ручные проверки, критические сценарии, ошибки и пустые состояния, права доступа, устройства, медленную сеть, интеграции, миграцию и восстановление. Не каждый проект требует одинакового набора тестов, но выбор должен следовать риску.

Доказательство — критерии готовности, пример тестового сценария и правило работы с дефектами. Уточните, кто может остановить релиз, какие ограничения допустимы и как подтверждается исправление, а не просто закрывается задача.

7. Как безопасность встроена в разработку?

Фраза «мы пишем безопасный код» слишком общая. Попросите показать, как команда управляет зависимостями и секретами, проверяет изменения, ограничивает доступы, моделирует угрозы, обрабатывает уязвимости и готовится к инциденту. NIST SSDF и OWASP SAMM рассматривают безопасность как набор практик от управления и проектирования до проверки и эксплуатации.

Доказательство — применимый к вашему риску security checklist, схема доступов и порядок сообщения об инцидентах. Сертификат может быть полезен, но не заменяет объяснение того, какие меры будут работать именно в вашем продукте.

8. Что происходит с нашими данными и сторонними сервисами?

Уточните, какие персональные и коммерческие данные получает команда, где находятся production, backup и development-копии, кто имеет доступ, каковы сроки хранения, используются ли субподрядчики и внешние AI-инструменты и что удаляется после завершения договора. Ответ зависит от юрисдикции и требует юридической проверки со стороны клиента.

Доказательство — перечень потоков данных, процессоров и субпроцессоров, технические и организационные меры и договорные условия возврата или удаления. ICO прямо связывает выбор обработчика с достаточными гарантиями, письменным договором, безопасностью, аудитом и условиями окончания обработки.

9. Какие нефункциональные требования войдут в приёмку?

Продукт может выполнять основной сценарий и всё равно быть непригодным из-за медленной работы, недоступности, отсутствия аналитики, плохой индексации или нестабильности. Спросите, как команда определит требования к производительности, доступности, совместимости, наблюдаемости, SEO и восстановлению.

Доказательство — измеримые критерии и способ проверки в подходящей среде. Для доступности используйте релевантные критерии WCAG, для производительности — согласованный бюджет и реальные ключевые сценарии. Не принимайте универсальное число без связи с пользователями и риском.

10. Чем именно будет владеть наша компания?

До договора перечислите исходный код, дизайн-файлы, документацию, тесты, данные, домены, репозитории, облачные аккаунты, store-аккаунты, аналитику, ключи, лицензии и компоненты третьих сторон. Для каждого элемента должно быть понятно, кто владеет им во время работы и после оплаты, а также какие ограничения остаются.

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

11. Как пройдёт запуск, миграция и возможный откат?

Спросите, кто готовит production, переносит данные, проверяет их полноту, управляет доменами или магазинами, наблюдает за первым трафиком и принимает решение об откате. Релиз — отдельная управляемая операция, а не последняя задача в списке разработки.

Доказательство — release checklist с владельцами, резервной копией, критериями go/no-go, rollback и проверкой после публикации. Для внешних платформ честный партнёр отделяет собственную готовность от времени проверки магазина, DNS или другого независимого сервиса.

12. Как устроены поддержка, передача и выход из сотрудничества?

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

Доказательство — условия поддержки, operational runbook, комплект документации и exit-план. Хорошая передача позволяет клиенту сохранить работу продукта даже при смене партнёра; это не отказ от долгосрочного сотрудничества, а проверка его зрелости.

Как сравнить ответы без ложной точности

Создайте одну таблицу: вопрос, письменный ответ, показанное доказательство, исключения, владелец решения и действие до договора. Не складывайте всё в один искусственный балл. Отдельно отметьте стоп-факторы — например, отсутствие права на код, неизвестные субпроцессоры или невозможность получить production-доступ.

Затем проведите небольшой оплачиваемый первый этап с реальным результатом: discovery, риск-прототип или технический аудит. Он не гарантирует будущий успех, но даёт более сильное доказательство совместимости, качества мышления и прозрачности, чем ещё одна встреча с отделом продаж.

Источники

GOV.UK Service Manual: роли в междисциплинарной продуктовой команде

GOV.UK Service Manual: видимое и адаптивное планирование

NIST: Secure Software Development Framework

OWASP SAMM: модель зрелости безопасной разработки

ICO: договоры между контролёрами и обработчиками данных

W3C: краткий справочник WCAG 2.2

Познакомиться с ZeroBlack