Как проверить партнёра по разработке ПО

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

Большинство процессов отбора сравнивают не то: портфолио, почасовые ставки и то, насколько отполировано коммерческое предложение. В этой статье о том, на что смотреть вместо этого.

Вопросы, на которые не ответить по скрипту

Каждый партнёр скажет, что он гибкий, прозрачный и опытный. Эти слова никого не отличают. Отличают вопросы, которые требуют конкретики:

• «Расскажите о последнем проекте, который пошёл не так. Что вы изменили после него?» Команда, у которой ни один проект не шёл не так, либо сделала их немного, либо чего-то не договаривает.
• «Как бы вы подошли к первому месяцу нашего проекта?» Хороший ответ задаёт вам встречные вопросы. Слабый пересказывает методологию.
• «Кто решает, что делается в каждой итерации, и что происходит, когда мы не согласны?» Вы ищете ясного владельца и способ разрешать разногласия.
• «Что вы делаете с запросом, который считаете плохой идеей?» Вам нужен партнёр, который скажет об этом, объяснит почему, а затем уважит ваше решение.
• «Как выглядит релиз, от слитого кода до продакшена?» Это показывает, есть ли у команды настоящие привычки поставки или она просто пишет код.

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

Читайте в кейсах то, чего там нет

Кейсы относятся к маркетингу, но от этого они не становятся бесполезными. Ищите в них сигналы:

• Проблема. Описана ли она в бизнес-терминах клиента или только списком технологий?
• Объём. Партнёр построил всю систему или одну её часть? Кейс со словами «мы поставили платформу» может означать дизайн и фронтенд.
• Статус. Находится ли продукт в эксплуатации сегодня? Поддерживается ли он и кем?
• Передача. Владеет ли клиент кодом и инфраструктурой? Был ли передан репозиторий?

Отсутствие тоже о многом говорит. Кейс без имени клиента, статуса и объёма работ остаётся картинкой, а не доказательством. Если кейс близок к вашей задаче, попросите поговорить с этим клиентом. Некоторые не могут согласиться по уважительным причинам, но у партнёра с довольными клиентами обычно найдётся тот, кто согласится на звонок.

Познакомьтесь с инженерами, которые будут делать работу

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

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

Спросите также, как собрана команда. Кто уже делал такую работу? Кто новичок? Какую долю времени каждый отдаёт вашему проекту и что будет, если кто-то уйдёт? Партнёр, который не может ясно на это ответить, возможно, собирается набирать людей на ваш проект уже после подписания.

Проверьте партнёрство небольшой оплачиваемой работой

Лучше всего о том, как партнёр будет работать, говорит сама его работа. Прежде чем брать на себя крупные обязательства, закажите что-то небольшое и самостоятельное: этап анализа (discovery), технический аудит или одну чётко определённую функцию.

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

При оценке пробной работы смотрите:

• Относится ли результат именно к вашему бизнесу или мог быть написан для кого угодно.
• Нашли ли они проблемы, которых вы не видели, и сказали ли о них прямо.
• Как они общались, когда что-то было неясно или запаздывало.
• Хотели бы вы проработать с этими людьми год.

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

Договор, код и доступы решайте заранее

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

• Интеллектуальная собственность. В договоре должно быть сказано, что код, дизайн и документация, созданные для вас, принадлежат вам с момента создания или оплаты, без условий, которые вы не сможете выполнить.
• Где живёт код. Репозиторий должен находиться в вашей собственной организации на GitHub, GitLab или похожем сервисе, а партнёр должен быть в ней участником. Если репозиторий лежит в его аккаунте, владение остаётся обещанием, а не фактом.
• Инфраструктура и аккаунты. Облачные аккаунты, домены, страницы в магазинах приложений и сторонние сервисы должны быть зарегистрированы на вашу компанию. Партнёр получает доступ, а ключи остаются у вас.
• Условия выхода. Договоритесь, что происходит, если вы расстаётесь: срок уведомления, документация для передачи, рабочая сборка и развёртывание, которые вы сможете запускать без партнёра.
• Конфиденциальность и данные. Если система работает с персональными или регулируемыми данными, в договоре должно быть сказано, как партнёр с ними обращается и кто может получить доступ к продакшену.

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

Тревожные сигналы, из-за которых стоит уйти

Некоторые предупреждающие знаки стоит принимать всерьёз, даже когда всё остальное выглядит хорошо:

• Фиксированная цена и сроки до того, как кто-то подробно расспросил вас о системе.
• Нет доступа к инженерам до подписания договора.
• Нежелание размещать код в вашем репозитории или давать вам права администратора.
• Команда, которая соглашается с каждой вашей идеей. Вам нужен кто-то, кто будет возражать.
• Размытые ответы о составе команды или частая смена людей, с которыми вы встречаетесь.
• Отчёты о прогрессе, где перечислена активность (часы, задачи, встречи), но нет ничего, что можно запустить или увидеть.
• Давление с целью быстрого решения, например скидка, которая действует только до конца недели.

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

Коротко

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

Хороший партнёр всё это только поддержит, потому что сам выбирал бы партнёра так же.