Шит хэппенс. Иногда при разработке мобильного приложения приходится расставаться с разработчиком и искать нового.
Мы уже несколько лет работаем в сфере разработки мобильных приложений, и 34% проектов, которые мы разрабатываем для наших клиентов, мы дорабатываем после неуспешных попыток других разработчиков. Один известный клиент в медийной сфере перед тем, как найти счастье в нашем лице, успел сменить аж троих подрядчиков!
Почему так происходит, по каким признакам можно понять, что разработчика пора менять, как минимизировать риски при расставании и передаче проекта — я расскажу в этой статье на основе нашего опыта. Меня зовут Алена, я — основатель компании мобильной разработки Creazard.
Какие проблемы бывают с разработчиками
Главная причина проблем — это некомпетентность. Причем, с обеих сторон: и разработчика, и клиента.
Клиент часто не в курсе, как разрабатывают приложения. Он платит деньги и хочет получить работающее приложение. А сколько специалистов для этого необходимо, клиент знать не обязан: для этого он и платит деньги, чтобы не вникать в технические детали. Но чаще всего клиент думает: «Чего там программировать для телефона-то, и одного программиста, наверное, хватит». Нанимает программиста.
Программист пишет приложение: только фронтенд, только для телефона, а серверные технологии не использует. В итоге упирается в ограничение: оказывается, чтобы добавить пару товаров в магазин, нужно перевыпускать целое приложение!
Самая частая проблема: найти разработчика, который умеет грамотно и чисто писать код. Так, чтобы через пару лет не пришлось переписывать все заново, потому что система не может масштабироваться и развиваться.
Приведем несколько примеров проблем, которые могут стать причиной смены подрядчика.
Пример №1
Наш клиент, с которым работаем уже несколько лет, до работы с нами нанял фрилансера. Программист написал приложение. И впихнул туда ВСЁ, даже музыку на 500 Мб. Размер приложения был почти один гигабайт! Более того: если пользователь удалял приложение (например, чтобы место для фоток освободить), то удалял и весь прогресс, и свои данные. Чудо-программист так накодил, что не было у приложения серверной части, все данные хранились только в памяти телефона.
Пример №2
Наш клиент, известная медийная личность, у которой поменялось 3 подрядчика. Как это происходило: клиент нанял разработчика, они обсудили техзадание, разработчик получил предоплату. И пропадал. То есть, буквально «а что ты мне сделаешь, я в другой стране, бе-бе-бе, и доступы к хостингу с сервером ты не получишь».
Пример №3
Наш клиент — маркетинговое агентство известного трейдера. Предыдущий разработчик взялся, но по какой-то причине не успел сделать вовремя. А у клиента для приложения через 2 месяца уже были спланированы маркетинговые активности: акции, распродажи. Пришлось нашим ребятам работать ночами, чтобы успеть в срок.
Пример №4
Тоже из жизни нашего агентства, это было несколько лет назад. Мы тогда еще были совсем зеленые и для бюджета клиента экономили как могли. Сначала повезло: мы взяли крутого разработчика на проект. Бэкенд, дядька солидный, за 30 лет, уже и семья есть, и ипотеки, все как полагается. Начинает делать. И тут у него на горизонте появляется «клиент мечты»: платит в 3 раза больше нас. А деньги-то нужны. И вот этот крутой разработчик тянет 2 заказа, ни один не бросает. И так упорно не бросает, пока его не увозят в психлечебницу. Два раза. Тогда расстаться с программистом пришлось уже нам: мы решили, что найдем замену, и отпустили человека работать в банк, поближе к деньгам.
Когда такое происходит на проекте, то надо что-то менять. Но можно ведь и не доводить до греха, если вовремя заметить признаки проблемы и решить её до того, как начался пожар.
Признаки надвигающейся беды: как понять — что-то идет не так
Итак, сверяйтесь и ставьте галочки в чек-листе, когда есть смысл насторожиться.
✔️ Когда есть проблемы в коммуникации с разработчиком
Подрядчик отвечает долго, коротко, неконструктивно («ну, мы посмотрим…»).
Или клиент ставит задачу, а разработчик, сказав «сделаем», пропадает из вида на неделю или две.
✔️ Когда разработчик не справляется с расчетом и планированием нагрузки
Например, клиент проводит маркетинговую акцию и видно, что сервер начинает ложиться: приложение работает медленнее, увеличивается время отклика на нажатия и действия в приложении.
✔️ Когда разработчик игнорирует просьбы клиента
Клиент акцентирует внимание разработчика на какой-то важной фиче, но ее не делают: «да-да, сделаем», но ситуация не меняется.
Это может быть косвенным признаком того, что разработчик набрал клиентов и теперь не вывозит. Или того, что рабочий процесс в команде построен неэффективно.
✔️ Когда ваш подрядчик работает по ставкам сильно ниже рынка
Помните про историю с разработчиком выше: ваши подрядчики растут и работать по низким ставкам им выгодно ровно до того момента, пока они не собрали себе хорошее портфолио.
В случаях, когда ситуация выглядит странно и некомфортно для вас, как клиента, есть смысл задуматься о смене разработчика. Это совершенно нормально, вряд ли кто-то во второй раз пойдет к парикмахеру, который не умеет стричь. Главное при смене разработчика — это правильно расстаться.
Что делать, если вы столкнулись с нерадивым разработчиком и решили его поменять
Расставаться лучше, конечно, мирно. Но случается всякое и разное. Поэтому ниже перечислим три обязательных шага, которые клиенту надо сделать для того, чтобы смена разработчика произошла максимально безболезненно.
Первое и главное, что нужно сделать, когда вы меняете разработчика: получить все исходники. Вообще, в идеале, все активы всегда и сразу оформлять на себя, чтобы не выпрашивать доступы и пароли впоследствии.
Часто бывает так: клиент заплатил деньги, разработчик создал приложение, зарегистрировал учетные записи и разместил приложение в сторах.
И, вроде бы, все хорошо, все работает и все довольны.
НО! Если вы расстаетесь с этим разработчиком или решили нанять другую команду, то обязательно попросите, потребуйте, получите доступ к репозиториям, в которых хранится исходный код вашего приложения. Либо зарегистрируйтесь на GitLab или GitHub, и попросите, чтобы весь код вашего приложения залили туда.
Это важно! Вы клиент и заплатили за этот код деньги. Это ваша собственность. Поэтому весь исходный код (или полный доступ к нему) должен быть в ваших руках.
Второе, не менее важное, что надо сделать: проверить, что у вас, как клиента, есть доступ ко всем учетным записям: к хостингу, к сторам и вообще ко всем ресурсам, участвующим в работе вашей системы.
Например, у нас был случай, когда клиент поругался с разработчиком, а тот осерчал, поменял пароль на хостинге и ушел в туман. Клиенту, чтобы восстановить доступ, понадобилось вести длительную переписку с хостингом, отсылать документы на компанию и доказывать, что это его собственность.
Третье: узнайте подробно, на каких языках и с использованием каких фреймворков написано ваше приложение. Так вы скорее подберете новую команду, потому что будете знать, кого искать.
Если вы успешно сделаете все три шага, то, скорее всего, смена разработчика произойдет легко и безболезненно.
И ещё совет. После успешного «развода» с разработчиком не забудьте поменять пароли ко всем ресурсам.
Как Creazard может помочь при смене разработчика
К нам можно прийти на любой стадии вашего проекта, мы готовы включиться. Представим, как события развиваются по лучшему и по худшему сценариям.
Идеальный вариант.
Если вы уже сделали все три шага, которые описаны в предыдущем разделе. Тогда мы просто подхватываем проект и продолжаем работу.
Плохой вариант. Штош…
Тут нам понадобятся контакты предыдущих разработчиков. Мы сами пообщаемся, на одном языке. Дело в том, что иногда клиент просто не знает, что именно нужно сделать при разрыве отношений. То, о чем говорится в предыдущей главе (получить доступы, учетные записи, исходный код).
В этом случае мы подскажем, что именно надо получить. С юридической помощью, если уж дошло до такой стадии, тоже подскажем, посоветуем юристов.
Пара слов о том, почему с нами не произойдет того же, что с предыдущим подрядчиком.
В наших отношениях с клиентами ни разу не было ситуации, чтобы клиент ушел и хлопнул дверью. Наоборот, 78% клиентов к нам возвращаются с новыми проектами или добавлением новых функций в уже работающие приложения.
Мы работаем по договору, в котором подробно прописываем: все сроки, результат, форс-мажоры и т.д. Нескромно скажу, что про компанию мобильной разработки Creazard вы не найдете плохих отзывов.
Вообще, при выборе подрядчика, лучше ориентироваться на живые отзывы знакомых, т.н. «сарафанное радио». Отзывы в интернете на специализированных сайтах можно посмотреть. И взглянуть на список клиентов, с которым уже работал разработчик.
Если вы сейчас думаете о том, не пора ли сменить разработчика и как это сделать, то приходите к нам на консультацию. Разберемся в вашей ситуации и посоветуем, что можно сделать, составим чек-лист «что забрать с собой у предыдущего разработчика». Ну, а если будете действовать сами, то надеемся, что эта статья поможет вам все сделать правильно. Удачи!
