Как поменять разработчика мобильного приложения и почему обычно это невозможно

Зачем вообще может потребоваться смена разработчика мобильного приложения? Как правило, по одной или нескольким причинам:

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

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

Когда вы меняете строительную компанию или партнера по логистике, производству — понятно, как это осуществляется. Есть определенные результаты в ходе предыдущей деятельности, известны условия выхода из одного сотрудничества и входа в другое. Тоже с нюансами, но ничего фатального.

Мобильная разработка, да и вообще IT-проекты, отличаются высочайшей зависимостью заказчика от подрядчика.

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

Например, у вас есть согласованное ТЗ (техническое задание), текущие результаты разработки на ваш взгляд не соответствуют, сроки вышли. Значит можно требовать… чего конкретно?

Все что вам должны «передать» как раз и определяет качество выполнения IT-проекта. Можно даже сказать, что когда подрядчик способен и готов выполнить все требования по передаче проекта в полном объеме — нет никакой разумной причины менять его на другую компанию.

Поскольку тут много разных аспектов, их можно упрощенно классифицировать по аналогии с авто-страховками:

Два ключевых слова: код и доступы.

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

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

Тут важно по крайней мере получить полную копию кода своего приложения — выгрузку архивом или ссылкой на репозитории вроде GitHub или GitLab.

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

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

Удивительно, как часто нарушается это очевидное правило. Даже крупные корпорации могут ограничиться формальной «проверкой» наличия ссылки, скриншотов, непонятного набора файлов. Так закладывается мина на будущее.

Далее, нужно получить ВСЕ необходимые и возможные доступы, имеющие отношение к проекту. Например (но не только эти):

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

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

Дальше мы погружаемся в пучину мечтательных хотелок. К сожалению, на обычных проектах не получится требовать ничего дополнительного. Основное бы получить. Однако по-хорошему нужно еще хотя бы три вещи:

Давайте по порядку. Слово «документация» звучит понятно, особенно по контрасту с другими терминами. Но это обманчивое ощущение. Вам нужны исчерпывающие руководства администратора системы, программистов, баз данных, пользователей. Каждое из них детализируется в тома технических описаний. Из них должно быть ясно:

С каждым последующим уточнением все становится не более, а менее понятным. Вам опять нужен внешний аудитор. Точнее, он пригодился БЫ в том случае, если разработчик действительно предоставит полный пакет документации. Но скорее всего этого не произойдет. Что очень жаль, ведь отрывочные описания алгоритмов мало говорят о реализации. Значит, потом будут проблемы.

Changelog описывает последовательность разработки. Что и как меняли, в какой очередности, с какими результатами. Полная картина о ходе проекта, по которой другой разработчик сможет быстро включиться в работу и продолжить развитие продукта. Мог БЫ это сделать, получи он настоящий changelog. Но скорее всего, этого не будет.

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

Допустим, ваш подрядчик оказался «The One», почти как Нео из «Матрицы». Он предоставил код, доступы, документацию, историю разработки и тестирования. Здесь уже стоит дважды подумать, на кого и зачем вы собрались его поменять.

Но возможно этот вопрос не обсуждается. Например, не сошлись по знакам Зодиака. Хорошо, тогда остается еще один последний рывок.

На экране сектор «Приз». Все самое лучшее, чего только можно было ожидать от подрядчика и проекта. Тут можно много нафантазировать, но для счастья достаточно трех главных пунктов:

Снова зовите внешнего аудитора, если он еще не живет в вашем офисе. Нужно инспектировать ТЗ с момента первого согласования, а потом по каждому изменению. «Немного подправить» это «частное техническое задание» (ЧТЗ). Оно отдельно разрабатывается, проверяется на согласованность с прежним планом и ресурсным обеспечением, потом интегрируется в проект и запускается на выполнение. Если так не делать, вы никогда ничего не докажете. Не только в суде, а вообще.

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

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

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

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

Мораль простая: не надейтесь «приструнить» разработчика при необходимости. Вы не сможете этого сделать, просто потеряете время и деньги. Заменить его тоже будет очень сложно, потому что передать новому подрядчику часто буквально нечего.

Сразу выбирайте такого IT-партнера, который обещает сделать все правильно. И обязательно проверяйте его действия с помощью компетентного внешнего аудитора.