Самые распространённые проблемы при заказе мобильных приложений и сайтов для бизнеса

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

Добрый день, дорогой читатель! Сегодня я постараюсь расписать все основные проблемы, которые возникают при разработке мобильных приложений, сайтов и других IT-продуктов для бизнеса. Дело в том, что IT-продукты недешёвые, а клиенты часто допускают типовые ошибки, наступая на одни и те же грабли. Наблюдать за этим из года в год хоть и забавно, но осложняет работу как исполнителю, так и заказчику. Итак, начнём!

Ошибок может быть много, остановимся на самых распространенных, которые допускает преобладающее число людей, сталкивающихся с подобным бизнесом впервые. Я буду опираться как на опыт разработки Bronixs (мой личный проект), так и на опыт своих клиентов.

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

1.1. Отсутствие понимания процесса монетизации (на каком этапе происходит оплата услуг сервиса)

Первый вопрос, который я задаю клиенту - это на каком этапе пользователь будет платить. Люди начинают думать об этом в последний момент, тогда как любой агрегатор создаётся в первую очередь для получения прибыли и уже во вторую очередь для упрощения жизни. Недавно мы закончили разработку приложения, подобного Airbnb, но в очень упрощенном варианте. Заказчик сразу отметил, что в сервисе будет отсутствовать оплата услуг агрегатора, и отказался прорабатывать приложение, указывая на то, что к данному аспекту можно будет вернуться позже. Однако на практике это потребует существенных изменений, как на стороне backend разработки, так и в целом механики приложения. Несмотря на это, мои просьбы были отклонены. Данный пункт особенно актуален для продуктов, которые получают доход со сделки, происходящей внутри агрегатора. В подтверждение моих слов вы можете ознакомится с механиками фриланс площадки Kwork, где запрещён ввод личного номера телефона и почты в чат с исполнителем, а при попытке обойти блокировку санкции вводятся в отношении как исполнителя, так и заказчика.

1.2. Неправильное распределение прав пользователей внутри системы

Отсутствие понимания прав пользователя внутри системы - редкая ошибка, но она свойственна крупным продуктам. Сейчас я работаю с производителем крупной CRM системы для бизнеса кафе. Обсудив все основные моменты продукта, мы приняли решение, что структура прав доступа будет распределяться следующим образом. Есть верховный администратор, который сам создаёт точки (кафе) и наделяет их правами (для доступа к функционалу). Заказчик упорно отстаивал данную модель бизнеса, но спустя полтора года разработки было решено изменить стратегию в пользу пакетных тарифов, между которыми может переключаться сам клиент. Однако для этого пришлось переделывать весь бэкенд. Как итог, большой объем финансов, времени и сил был потрачен впустую.

1.3. Отсутствие отлаженной работы вне сервиса

У нас был заказ по разработке площадки на подобие Wildberries. Реализовывали на CMS Wordpress и плагине WCFM. После реализации и внесения правок выяснилось, что товар может стоить 600 рублей, а доставка 1000 рублей. Проблему необходимо было решать через систему складов, однако клиент не был готов к решению проблемы такого уровня. После чего последовали попытки менять людей, отвечающих за продвижение площадки. Однако по итогу всё пришло к заморозке проекта.

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

«Заказчик» на этапе составления технического задания (ТЗ) и разработки макета дизайна - это часто разные люди. Зарисовки позволяют охватить саму идею значительно шире, чем текст, и чем больше человек понимает размах, тем сильнее ему хочется внести дополнительный функционал, что, к сожалению, является ещё одной ловушкой. Понимание необходимости функционала может возникать только на основе опроса потенциальных клиентов и анализа конкурентов. Самый идеальный вариант - это анализ клиентов конкурента. Лучший вариант - это запуск MVP с последующим внедрением функционала и проверкой через A/B тестирование. Это относится и к функционалу и к дизайну.

Проблема бизнеса по подписке в том, что путь к точке безубыточности очень долгий. Кроме затрат на разработку, рекламу, существует большое количество небольших платежей, начиная от оплаты домена, заканчивая ПО для анализа продукта. Из предыдущего пункта следует другая проблема - увеличение бюджета в сторону разработки, а не маркетинга. С такой проблемой столкнулся и я, когда впервые разрабатывал своё мобильное приложение по фитнесу. Бюджет был смещён в сторону продукта, что привело к тому, что проект попросту не вышел в точку безубыточности.

Любые проблемы, связанные с продуктом и финансами, можно преодолеть, НО

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

Часто заказчик не понимает, какие шаги он будет предпринимать для продвижения своего продукта. Недавно мы завершили разработку очередного мёртвого интернет магазина. Человек потратил несколько тысяч долларов на реализацию продукта и индивидуального интерфейса, но заложил на рекламную компанию всего лишь 10.000 рублей в месяц при рекомендации со стороны специалиста иметь бюджет более 150 тыс. рублей. Бюджет может быть небольшим лишь первое время для выявления ошибок со стороны продукта, проведения тестирования каналов продвижения для выявления наиболее подходящего. Однако, увидев отсутствие ощутимых результатов от проведения малобюджетных рекламных кампаний, заказчик может допустить ошибку №4 или поспешить и совершить ошибку №3.

Эта ошибка настолько фундаментальна, что применима не только к разработке сервисов, но и к другим бизнесам. Существуют разные методологии, такие как SCRUM и Agile, но начать стоит хотя бы с простого Excel. Задача должна быть грамотно записана и иметь по возможности дедлайн (крайний срок выполнения), описание и степень важности. И хотя в теории это звучит довольно просто, на практике все намного сложнее, так как данную инициативу будут саботировать как работники, так и глава команды. Происходит это по следующей причине:

Лично мы используем Yougile (я пока морально не дорос до внедрения SCRUM или иных инструментов).

Общение с клиентами - очень сложный процесс, поскольку люди бывают очень разные. В то время, как для одних клиентов задумка может показаться очень интересной, другие могут совсем не понять, о чём вы говорите. Однако многие акселераторы на подобие «Y Combinator» требуют от вас наличия круга заинтересованных людей, которые оценили вашу идею на высоком уровне. Когда мы только начинали разработку Bronixs, мы не знали о методе получение оценок идеи по 10 бальной шкале от клиента, и проработали данный момент по-своему. Другой вопрос, что не всем было понятно, о чём идёт речь. Наш продукт строится по принципу конструктора сайта. Пользователь вносит расписание, список своих услуг, и для него формируется страница, на которой клиент нашего пользователя может произвести запись на услуги. Для того чтобы по-человечески донести смысл сервиса, мой штатный дизайнер сделал зарисовки продукта, и дальше мы уже с готовым макетом пошли по клиентам. Так как зарисовки были сделаны в Figma, то мы смогли добавить интерактив, и клиенты буквально нажимали на кнопки, что приводило их в восторг.

Если вы заказываете продукт под заказ у организации вроде моей, то вы сразу снимаете с себя часть проблем по причине наличия договора. Для начала вам нужен MVP, и тут моя рекомендация идти на фриланс, потому что компании делают качественно, но дорого. Однако всё-таки обратитесь для начала в организации - пусть они поскидывают КП - может вам, что-нибудь и приглянется. Мой главный посыл: чем больше ваши отношения находятся в юридической плоскости, тем лучше. Я это говорю не с позиции, что ваша идея уникальна. ЗАПОМНИТЕ

Другой вопрос, что пройти весь путь от идеи до выхода на рынок - это невероятно сложно и требует длительных вложений сил, энергии и времени.

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

#мобильные_приложения #сайтыдлябизнеса #ошибки #сайтыназаказ #сайты #приложениедлябизнеса #опытразработки #личныйопыт