Как найти хорошего партнера по разработке: чек-лист

Почти каждый день я общаюсь с основателями и топ-менеджерами компаний, которые приходят в Spider Group обсуждать свои проекты. Для многих из них это не первый опыт привлечения партнера по ИТ-разработке. Некоторые ищут замену нынешним партнерам, которые не оправдали ожиданий. Люди жалуются на трудности в коммуникации, на непонимание их потребностей, низкое качество отчетности или кода.

В такие ситуации лучше не попадать. Разработка нативных приложений для iOS, Android, веб-приложений, сложных клиент-серверных систем и даже обычного сайта — это большая систематическая работа. Она может пройти гладко только в руках профессионалов. На основе своего опыта я постараюсь рассказать, как выбрать такого партнера.

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

Будьте дипломатичны даже в конце

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

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

Смена партнера — это стресс. Самым продуктивным вариантом окончания отношений будет открытый разговор о проблемах. Если вы откровенны (аккуратно, без обвинений и перегибов), есть вероятность, что коллеги отплатят тем же и предложат компромисс, который позволит продолжить сотрудничество. Этот вариант стоит рассмотреть, потому что уход влечет затраты, иногда неочевидные, вроде потери клиентов из-за затруднений в поддержке продукта.

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

Стоп-факторы в партнерстве

Я управляю Spider Group больше 20 лет. У меня был другой бизнес, были стартапы. Кроме этого за годы практики ко мне приходили сотни предпринимателей, которые делились своими болями в работе с подрядчиками.

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

1. Нет возможности проверить компетенции и опыт команды, которую вам продают.
2. Непрозрачный расчет времени реализации. Почти всегда это нельзя зафиксировать до конца, потому что появляются пожелания, преграды, варианты реализаций; но это не значит, что нельзя детализировать, что на такую работу уйдет столько-то времени таких-то специалистов.
3. Заметна спешка в заключении контракта, вас торопят — у авторитетных компаний просто не бывает свободных команд, готовых приступить здесь и сейчас, придется подождать хотя бы пару недель, пока менеджеры согласуют детали и перераспределят нагрузку.
4. Фиксирование цены до полного определения функций хотя бы первой итерации продукта. Сначала нужно согласовать, что мы делаем, потом цену. Со временем и ростом доверия можно перейти на time & material.
5. Отсутствие ясности с правами на интеллектуальную собственность. Вас может удивить, как некоторые агентства изобретательны в юридическом обосновании повторного использования кода заказчика, который им не принадлежит, или в закупках готовых решений, которые они не разрабатывали, со всеми уязвимостями и тем, что в англоязычных странах называют shitcode.
6. Нереалистичные планы по скорости разработки. Их лучше оценивать со специалистами. Можно даже обратиться к другому подрядчику, который прокомментирует выкладки коллег. Возможно, после хорошего комментария вы предпочтете уйти к нему.
7. Вам говорят только то, что вы якобы хотите услышать, не подвергая планы аргументированной критической оценке — скорее всего, у партнера либо нет опыта, либо нет желания разбираться с вашим проектом всерьез.
8. Партнер берется за все подряд. Возникают сомнения в том, что у него в штате есть подходящие специалисты, и он не спихнет проект на субподряд без вашего ведома.

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

С другой стороны

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

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

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

Процесс перехода

Итак, вы решили сменить разработчиков. Шаги такие:

1. Заручиться поддержкой новых разработчиков, проверив их по чек-листу.
2. Убедиться в передаче вам кодовой базы и документации, загрузить все в ваш репозиторий.
3. Получить доступы ко всем аккаунтам, поменять все пароли.
4. Убедиться в выполнении всех контрактных обязательств с обеих сторон.
5. Пройтись по старому и новому договору с юристом.
6. Вместе с новым подрядчиком оценить качество кода, документации, а также вынести решение, что проще сделать — погружаться к имеющийся код, переписать часть проекта или проект целиком. Если документации нет, а код написан грязно, чаще всего и выбора у вас тоже нет, обратный инжиниринг будет сложнее написания с нуля.
7. Получить более одной оценки качества кода — не торопитесь принимать решения на этой развилке. То же самое, кстати, можно сделать при подборе партнера. Оценивая его, поговорите с несколькими заказчиками из его портфолио и сложите картину из нескольких независимых мнений.

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

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