Иногда случается так, что нужно отложить релиз мобильного приложения. Безусловно, заказчикам это не по нраву, да и разработчикам тоже. Но помимо отрицательных сторон, есть и положительные, которые вроде и очевидны, но мало кто о них задумывается.
Приведем жизненный пример:
Задержан рейс. Да, неудобно. Но если учесть, что неисправности (недочеты) в самолете были выявлены до взлета, то это решило множество проблем (в том числе и трагических).
Релиз приложения с его недочетами не такая серьезная проблема, как техническая неисправность самолета. Но и этого можно избежать, если понимать, что торопиться тоже не есть правильно.
Вернемся к мобильным приложениям.
Пример: заказчик имеет прекрасную идею, он выстроил всю бизнес-модель, просчитал экономическую сторону, маркетинг и все нюансы. У него стоят определенные дедлайны, чтобы проект приносит свои деньги. Он не готов смещать сроки дедлайна. Приложение выходит в релиз с недочетами. Не глобальными, но все же багами. Так как деньги были вложены и в рекламу, приложение получило хороший отклик по скачиваниям. Вроде пока все хорошо, но это до получения обратной связи от пользователей. Недочеты мешают и раздражают клиентов. И все приводит к тому, что приложение подлежит удалению и негативным отзывам в маркете.
Итог: вернуть пользователей будет сложно или даже невозможно, бюджет на рекламу потрачен впустую. Приложение отдается на доработку А всего этого можно было избежать, если принять факт необходимости отсрочки.
Нет, это статья не для оправдания разработчиков. Это возможность донести обратную сторону медали. К нам часто обращаются клиенты, у которых есть печальный опыт с другими компаниями. Такой заказчик уже не так доверяет и его можно понять. Но для начала мы пытаемся выяснить почему это случилось:
- Неточная оценка проекта, расчет сроков.
- Внесение в проект доп.функционала (по необходимости, при запросе заказчика).
- Ошибки в разработке.
Как решить?
В первую очередь важно выявить причину и не позволять ей повторяться вновь. Если неточная оценка — значит узнать, в чем заключалась проблема: мало вводных данных, плохое ТЗ и т.п. Если в приложение вносятся какие-то доп.функции, заказчик сразу должен понимать, а разработчик информировать о необходимости переноса сроков сдачи проекта. Если в работе были допущены ошибки со стороны специалистов разработки, то выявить конкретные баги + людей кто их совершил. Уточнить причину: недостаточность знаний/практики, узкие сроки, плохое распределение задач руководства и т.п..
Задержка для заказчика проекта — это возможность не допустить репутационных ошибок и материальных потерь
Задержка для разработчиков — это опыт, а он бесценен. Компания Zennex на рынке разработки мобильных и веб-приложений уже 20 лет и у нас тоже случались задержки и совершенно по разным причинам. Откроем секрет — это стандартная практика всех компаний. Но при любом раскладе важно понимать, что и заказчик и разработчик находятся в одной лодке и цель их одна — получение качественного мобильного приложения. Главное быть честным со своим клиентом, говорить с ним на равных и вести открытый диалог.
