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

0
175

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ещё по теме: 

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

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

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

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

Далее: Разработка веб-приложений: этапы, классификация и стоимость

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