14 ошибок чтобы закопать свой проект мобильного приложения. Часть первая
Привет, меня зовут Громова Алена, я — основатель студии мобильной разработки CREAZARD. Моя компания работает на цифровом рынке с 2018 года, а до ее основания я сама долго работала в найме, так что большой личный опыт по нашей теме в наличии. По долгу своей работы мне часто приходится отвечать как раз на эти же вопросы про «недорого» и «сэкономить». Попробую ответить всем и сразу.
Суть материала
Расскажу, как и на чем пытались экономить наши любимые клиенты, на что «забивали» их исполнители-разработчики, и что получалось в итоге (спойлер: ничего хорошего).
Я собрала самые частые ошибки, прокомментировала, и для каждой привела схему «как делать не надо → к чему приводит такой подход → результат ошибки».
Уверена, мой рассказ поможет избежать ошибок тем, кто собирается заказывать разработку приложения впервые. А тем, у кого уже есть печальный опыт «экономии», поможет понять что и почему пошло не так. Рассказ получился длинным, поэтому я разделила его на две части. Это первая часть.
И еще одно уточнение: речь именно про разработку мобильного приложения, а про не веб-версию сайта или PWA. А теперь — поехали!
Ошибка № 1: Для проекта, который длится дольше 1-2-х месяцев, выбрать фрилансеров
1-2 месяца — это срок для разработки небольшого проекта. Например, для проверки интереса аудитории, для MVP. Разработка чего-то большего потребует других сроков. Я придерживаюсь правила, что масштабной разработкой должна заниматься масштабная команда.
Если неверно заложить фундамент, то через несколько месяцев в геометрической прогрессии начнут копиться большие проблемы.
Дальше реальные примеры из ситуаций, когда клиенты, для которых мы составили ТЗ, решили сэкономить и ушли к «частникам».
Выбрать разработчика по цене, за недорого → получить некомпетентного разработчика и нерабочее приложение → потерять время и деньги
У нас была ситуация, когда клиент пришел после соло-разработчика, который написал приложение без сервера, и такое приложение весило под 1 гигабайт. Понятно, что нам пришлось заново переписывать все приложение с нуля.
Самому вести проект как менеджер и принимать неверные решения → нет важного функционала или приложение плохо написано → потерять деньги
Если у клиента нет опыта в разработке, то он, скорее всего, согласится на большинство решений, которые предлагают разработчики. Высока вероятность, что клиент откажется от важного функционала, просто потому что исполнитель-фрилансер скажет: «нуууу, это сделать невозможно».
Сэкономить на системном архитекторе (в пользу фуллстека или бэкенда) → продукт нормально не работает → клиенты жалуются и уходят, вы теряете репутацию и деньги
Такое решение почти гарантированно приведет к тому, что в приложение будет невозможно добавить новые функции или масштабировать его. Проект может «посыпаться» при добавлении двух кнопок через один год работы, потому что изначально неверно спроектирован исполнителем без должных компетенций.
Надеяться на добросовестность фрилансера → фрилансер может подвести, если попадется более выгодный клиент. То есть, не дописать ваш проект или дописать в спешке → упущенная прибыль и ущерб репутации (если вы запланировали маркетинговые акции в приложении и сообщили об этом вашим клиентам)
Как бывший фрилансер скажу, что зачастую фрилансеры — ребята «голодные», даже если и опытные (а про неопытных и говорить нечего). На фрилансе нет стабильности, и вместе с вашим проектом, скорее всего, исполнитель делает параллельно еще несколько. Откуда я знаю? Сама когда-то через это прошла: сегодня у тебя нет работы, а завтра 3 проекта сразу. Какой уж тут ворк/лайф баланс. Приходится работать ночами до тех пор, пока пальцы шевелятся.
Будет ли фрилансер переживать за ваш проект и думать о его судьбе после релиза? Сложный вопрос. Могу говорить только о себе, и скажу, что тогда (в свою бытность фрилансером) я об этом беспокоилась также, как и сейчас, но не могу ручаться за тех, для кого это подработка, а не стабильная работа. К тому же вашу разработку, хорошую или плохую, фрилансер положит в портфолио для будущих клиентов. Какого качества работа понять сложно, если не видеть изначальное ТЗ.
Соглашаться на любые технологии при разработке → приложение невозможно масштабировать, дорабатывать и обновлять → потерять время и деньги
Очередная история из нашей практики: обратился клиент, который просил целиком переписать бекенд мобильного приложения. Изначально бэкенд был написан на языке Perl. Потому что в команде был только Perl-программист. Но язык Perl устарел уже до начала разработки приложения. Поэтому развивать приложение в современных реалиях невозможно.
Считаем потери времени и денег: чтобы переписать весь бекенд, понадобится полгода и несколько миллионов рублей. В доработках участвует не только бекенд, но и архитектор, фронтенд-программисты, менеджер, тестировщики и другие специалисты. Добавим к этому упущенную выгоду из-за простоя в обновлении приложений в течении полугода.
А надо было всего лишь обратиться в компанию с репутацией, где выбрали бы актуальные языки и средства разработки.
Ошибка № 2: Экономить на доработках валидации
Такое происходит очень часто. И от таких ошибок бывает очень больно.
Экономить на валидации → обнаружить не выявленный вовремя баг в приложении → потерять время и деньги
Наш пример: клиент попросил не тратить бюджет и мы не сделали фильтр приема только цифр в поле ввода количества повторов видео тренировки. Однажды сотрудник клиента в админ-панели вместо числа, ввел букву и система «подавилась»: все тренировки перестали работать на 2 часа пока мы искали корень проблем и исправляли.
Цена отказа от валидации оказалось высока: на разработке сэкономили несколько тысяч рублей, зато получили десятки тысяч сердитых пользователей, которые завалили поддержку жалобами, что не смогли сделать утреннюю тренировку.
Валидация — это то, на чем я крайне не рекомендую экономить. Один такой факап может запросто обрушить репутацию. Особенно в день запуска приложения на широкую аудиторию.
Ошибка № 3: Сразу делать идеальную версию продукта, чтобы успеть обойти конкурентов
Многие клиенты уверены, что их бизнес-идея перевернет рынок. Часто это приводит к попытке реализовать в приложении все уникальные функции сразу.
Пытаться сразу сделать идеальную версию приложения → упустить время и не учесть конкуренцию → потерять деньги, время и место на рынке, утратить доверие к IT и мобильной разработке
Срок разработки полной версии приложения со всем функционалом сразу составляет от 1 года и более. За это время конкуренты выпускают более простые версии для похожего сервиса, обкатывают их, набирают базу пользователей, начинают зарабатывать первые деньги и увеличивают узнаваемость сервиса. К моменту выхода приложения большая часть функционала, запланированного в сервисе к началу разработки, уже неактуальна.
А надо было определить минимальный набор функционала к первой реализации, чтобы разработка не занимала годы. Такой функционал, с которым можно стартовать и начать получать минимальную прибыль, нарабатывать базу пользователей и репутацию для сервиса. Например, программа лояльности со скидками при входе.
Ошибка № 4: Разрабатывать приложение без учета целевой аудитории
Одна из моих любимых ошибок, которые делают клиенты :)
Не учитывать ЦА продукта → после запуска переделывать приложение под ЦА → терять время, деньги, лояльность клиентов
Часто приходят клиенты с идеями, которые, по их мнению, взорвут рынок. Но эти идеи основаны только на мнении клиента. Он сам так придумал, не изучив рынок и не получив обратной связи от потенциальных пользователей. В итоге через полгода разработки мы получаем реальную обратную связь после выхода приложения и начинаем сильно менять функционал.
Финансовые затраты в этой ситуации могут исчисляться миллионами рублей. А потеря времени — месяцами.
Не ленитесь потратить хотя бы 1-2 недели на общение с вашей целевой аудиторией. Кстати, для опросов рекомендую использовать методы из замечательной книги «Спроси маму: Как общаться с клиентами и подтвердить правоту своей бизнес-идеи, если все кругом врут?» (автор Роберт Фитцпатрик). Она реально помогает понять, за что вам готовы платить пользователи.
Ошибка № 5: Придумать дизайн без согласования с разработчиком
А сейчас я говорю (кричу!) от лица всех фронтенд-разработчиков: очень (очень!) нежелательно разрабатывать прототип и дизайн приложения без обратной связи от команды разработки.
Нарисовать с дизайнером красивый дизайн → узнать у разработчика, что закодить такое невозможно → переделывать дизайн, теряя время и деньги
Невозможно измерить сколько крокодильих слез было пролито, сколько виски кофе выпито, когда несчастные программисты пытались верстать мои «дизайнерские» макеты на заре моей карьеры. Никогда не забуду эмоции Юры, iOS-разработчика, когда я упомянула уже в середине разработки, что в приложении планируется еще и ночная тема...
Часто дизайнеры-фрилансеры без команды рисуют макеты по вдохновению, а не по правилам платформ Apple и Google. А после этого неделя тратится на то, что можно было сверстать за один день. А потом это еще и надо привести к адекватному виду на разных экранах и устройствах.
Многие функции в принципе нельзя реализовать быстро, поэтому их оставляют на вторую версию приложения. Если бы дизайнер общался с командой разработки, то знал бы про это и не тратил часы и дни на отрисовку ненужных блоков. В итоге переплата за бесполезную работу дизайнера, программисты убирают или упрощают куски интерфейса, а приложение выглядит уже не так красиво, как в макетах.
Забудьте про вау-дизайн первых версий. Попросите дизайнера подобрать вам на выбор несколько готовых доступных симпатичных фигма-шаблонов, и сделайте приложение, перекрасив элементы в вашем фирменном стиле. Потом, когда будут время и деньги, можно развлекаться с красивыми кнопочками. Так можно сэкономить несколько недель времени и несколько сотен тысяч рублей на работе целой команды.
Ошибка № 6: Сразу писать приложение на Flutter/Nocode/Lowcode
Важно представлять, как будет развиваться приложение. Если такого видения нет, то возможны проблемы.
Не написать план развития приложения → выбрать неподходящий язык/фреймворк → тратить дополнительные время и деньги на поддержку и обновление
Часто клиенты просят написать приложение, например, на Flutter. Flutter — это отличный фреймворк для кроссплатформенной разработки. Если его средств не хватит, всегда можно дописать код нативными языками. Красота. Если ей правильно пользоваться.
Однажды мы с клиентом обсудили план работ и решили писать на Flutter. Через полгода-год разработки, когда давно вышел релиз приложения, мы с клиентом решили добавить будильник в приложение. Обычный будильник, чтобы те, кто не любит пуши и постоянно отключают их, могли пользоваться будильником. Круто? Круто!
Мы потратили очень много времени, но не смогли реализовать эту задумку на Flutter. Ладно, сделать будильник можно нативными средствами. Вот только Flutter выбирают за то, что приложение пишет один разработчик. Когда Flutter не хватает, приходится подключать нативщиков, то есть, поддерживать приложение придется уже не одним, а тремя разработчиками.
Можно, конечно, поискать Flutter-разработчика — выходца из разработчиков Android или iOS, но это уже задача high-уровня, которая займет не один месяц. Подходит ли вам такой вариант? Вам виднее.
Цена такой ошибки, в лучшем случае, увеличение стоимости поддержки, а в худшем — переписывание всего проекта.
С самого начала надо максимально хорошо представлять себе план развития продукта. Так ваша команда примет верное решение при выборе языка/фреймворка.
Ошибка № 7: Не давать разработчику необходимую информацию
Не давать обратную связь разработчику → получить неработающее приложение → потратить время и деньги на исправление ошибок
Еще одна потрясающая ситуация. У клиента был свой бэкенд-разработчик. Нас наняли написать только фронтовую часть. Мы попросили пример реальных данных, которые будут передаваться в приложение на телефоне, чтобы подготовиться к работе, и посмотреть, что и в каком объеме клиент собирается пересылать в телефоны пользователям. Клиент отказался, заявив, что данные содержат конфиденциальную информацию о клиентах.
Когда с нашей стороны все было готово, мы начали получать реальные данные с сервера, и оказалось, что сервер пересылает на каждый наш запрос по 250 тысяч строк. Конечно, к такому потоку данных приложение и вся серверная архитектура, написанная не нашим разработчиком, была не готова. Пользователь нажимал кнопку, а приложение зависало на приеме огромного потока данных. Если бы такой файл нам передали в самом начале, у нас возникли бы встречные вопросы по поводу сервера и методов приложения. Приложение писали бы иначе, с разработчиком клиента обсудили бы изменения.
В итоге: 4 месяца работы в неправильном направлении из-за недостатка данных и скандал с клиентом. А еще угрозы не оплатить услуги по договору даже после того, как наша команда без дополнительной оплаты отказалась от летнего отпуска, чтобы исправить ситуацию. И мы все исправили. С тем клиентом мы больше работать не будем. А всего могло быть иначе.
Поэтому не бойтесь давать разработчику всю необходимую информацию. Разумеется, сначала убедитесь, что информация действительно нужна для разработки, а затем заключайте соглашение о неразглашении.
Вместо вывода
Лично мне, с высоты всей пройденной практики представляется очевидным, что если есть бюджет, то выгоднее работать с профессионалами, уже заслужившими репутацию. Да, на короткой дистанции это будет дороже, но зато вы сразу создаете стабильную масштабируемую отказоустойчивую систему. Ее вы сможете развивать без моральных и финансовых потерь. В перспективе, при работе «в долгую», этот подход выйдет в разы дешевле для бюджета и ваших нервов. Более того, система контроля качества работы, существующая в профессиональных командах, точно будет необходима, если проект ответственный.
Что ж, материал получился масштабный и, надеюсь, убедительный. Вскоре представлю вашему вниманию еще и вторую часть — там я расписала еще 7 ошибок. Например, что бывает, если экономить на тестировщиках и чем опасна работа «по фиксе». До встречи!
Громова Алена, основатель компании CREAZARD.
Реклама, ИП Громова, ИНН 772850165163 erid:2VtzqvkAGZ6