В 2021 году рынок мобильных приложений снова ощутимо вырос. Европейские пользователи потратили в сервисах на 23% больше, чем в 2020, что в переводе на цифры выручки составило более 18 млрд долларов (по данным Sensor Tower). Из них более 1,24 млрд приходится на долю российской аудитории. А в мире Россия занимает 5-е место по общему числу установок приложений и является единственной страной, у которой из года в год сохраняется рост этого показателя (исходя из отчета Sensor Tower за 4 квартал 2021). Эти цифры говорят нам о том, что все больше и больше бизнеса не просто приходит в онлайн, но и развивается через мобильные сервисы.
Однако идея упаковки продукта в приложение сопровождается вопросом о том, кто будет его разрабатывать? Выбор поставщика всегда сопряжен с риском. А если вы никогда не сталкивались с индустрией разработки приложений, решение может оказаться еще более сложным. Выбор неправильного поставщика не только приведет к потере денег и времени, но и может нанести репутационный ущерб, поскольку отзывы о неудачных приложениях распространяются. Мы постараемся рассказать вам, какие шаги вы можете предпринять, чтобы избежать разочарования при выборе поставщика или хотя бы снизить его вероятность.
Как найти команду?
Самое первое, что обычно делают – это решают, нужна ли будет инхаус-разработка, аустафф или аутсорс. Инхаус – это формирование команды внутри своей компании. В аутстаффе штат сотрудников вам предлагает компания-посредник, вот только, в отличие от аутсорса, этими специалистами управляете вы. Но если кто-то из них не справляется с задачами, аутстафф-фирма его поменяет. Аутсорс – это студия или агентство, которая реализует ваш проект под своим управлением. У вас будет свой менеджер, но все процессы будут идти внутри компании-подрядчика. Обычно большинство проектов реализуется именно аутсорс-командами: их экспертиза наиболее разноплановая, в опыте присутствуют “обкатанные” решения, постоянная вовлеченность в рынок позволяет следить за новейшими идеями. Кого бы вы ни выбрали, лучше, чтобы на стороне клиента был специалист, имеющий как минимум базовое знакомство со сферой IT или желание разобраться.
В качестве промежуточного шага прочитайте материалы Google, Хабре и ВКи подумайте о том, что такое разработка приложений, как выбирать исполнителей и в чем заключаются детали. И именно здесь вы можете почувствовать необходимость отделить “пшеницу от плевел”. В органической выдаче есть материалы, оптимизированные для SEO, а на Хабре и в ВК – качественные тексты и тексты, написанные для рекламы и продвижения бренда, где некоторые нюансы могут быть опущены.
Очень часто для выбора поставщика просматривают сайты рейтингов и читают отзывы. Это разумный подход. Однако подрядчики, занимающие первые места в рейтинге, обычно предпочитают более крупные проекты, и цены у них выше. Кроме того, отзывы могут быть результатом хорошо проведенного репутационного поискового маркетинга (SERM) и не всегда отражают действительность.
Вы видели рекламу, органические рейтинги и рейтинги, вы посещали десятки различных сайтов студий, и поскольку сайт IT-компании является ее “визитной карточкой”, ее “лицом” и точкой генерации лидов, его качество и содержание должны быть соответствующими. Было бы странно, если бы студии не заботились о нем, не дорабатывали и не улучшали его. Клиенты могут ознакомиться с портфолио проектов потенциального подрядчика через сайт, но также стоит обратить внимание на то, являются ли ресурсы живыми, обновляется ли контент и учитываются ли современные тенденции.
Какие вопросы важны?
Поэтому мы решили отобрать несколько компаний для подачи заявки на разработку. Возможно, вы уже получили предложения и думаете, кому отдать предпочтение. Вот некоторые ключевые моменты, которые повлияют на реализацию вашего проекта.
Компетентность команды
Не имея технического образования, трудно оценить уровень вашей компетентности. Скорее всего, вы будете общаться с отделом, отвечающим за обработку входящих запросов. Они знают, как общаться с клиентами, и, скорее всего, слышали каждый запрос. А если у вас нет опыта работы с ИТ-проектами, вас может смутить обилие терминологии, технических нюансов и специфических деталей.
В таких случаях вы можете оценить, имеет ли потенциальный подрядчик соответствующий опыт, изучив его портфолио. Если там нет проектов, похожих на ваш, это не повод сразу отвергать подрядчика. На рынке существует множество уникальных приложений, но они обычно поставляются со стандартным набором функций, таких как вход в систему, каталог, профили пользователей, подписка, оплата и использование навигации. Если в портфолио есть проекты, которые пересекаются с вашим функционалом, вы можете доверить разработчикам реализацию ваших целей. Грамотный специалист может без проблем разработать продукты из разных областей. Это особенно актуально, если у вас уже есть готовые аналогичные решения. Здесь важно максимально подробно донести суть требуемого функционала и убедить заказчика, что вы компетентны и готовы его разработать.
Помимо просмотра примеров на сайте, имеет смысл скачать и опробовать представленные приложения. Если какой-либо из сервисов не работает должным образом или вообще не работает, следует спросить подрядчика, почему. Это довольно распространенный нюанс, когда команда возвращает проект клиенту после внедрения и не поддерживает его. Либо приложение не поддерживается вообще, либо это делает клиент или другая команда, и изначально качественный продукт со временем становится неработоспособным.
Сроки разработки
Временные рамки проекта всегда стараются отразить КП. Нередко это не отражается в реальности, что доставляет боль. Сроки не соблюдаются, и, к сожалению, это нередкая ситуация. Есть только один способ проверить, выполняет ли подрядчик свои обязательства до начала работы: связаться с текущим клиентом и спросить его впечатление о работе со студией.
Однако стоит помнить, что задержки не всегда являются исключительной ответственностью подрядчика. Например, менеджер может попросить клиента согласовать материалы, необходимые для проекта, но клиент может быть слишком занят другими делами, чтобы своевременно включиться в работу. Это может привести к срыву сроков, что неприятно как для команды разработчиков, так и для клиента. Работа над проектом – это всегда симбиоз двух сторон, и только когда обе стороны работают вместе, можно создать качественный продукт.
Лучший вариант – предложить подрядчикам работать итеративно, т.е. поэтапно. Продолжительность этого процесса может быть разной. Могут использоваться спринты, средняя продолжительность которых составляет две недели или даже меньше. В любом случае, важно понимать, как будут предоставляться предварительные результаты. Заказчики должны иметь возможность изучить предварительную версию продукта, чтобы хотя бы проследить, как реализуются определенные функции и соответствуют ли они их ожиданиям. Некоторые компании выпускают отчеты, документирующие их работу за определенный период времени, но это менее наглядно, чем если заказчик получит часть продукта для ознакомления.
Клиенты часто не имеют возможности или желания полностью вовлечься в процесс. Лучше этого не делать. Если не выделить хотя бы один день в неделю и определенный период времени в течение этой недели для участия в происходящем, есть риск, что результат не будет соответствовать ожиданиям. Этот риск существует даже в том случае, если техническое задание и проект разрабатываются совместно.
Стоимость услуг
Это критерий, который обычно оказывает ключевое влияние на итоговый выбор подрядчика. Как заказчику понять, что он не переплачивает?
Хорошим эмпирическим правилом является сбор коммерческих предложений от семи-десяти студий и рассмотрение их условий. Справедливым и широко используемым методом является округление вниз самых высоких и самых дешевых предложений, если они сильно отклоняются от среднего рыночного уровня, оставляя те, которые находятся в том же диапазоне (±15-20%). Однако не всегда возможно определить наилучшие показатели затрат. Часто на этапе запроса отсутствует подробное ТЗ, а иногда предложение основывается на общем понимании задачи потенциального подрядчика, не имея даже подробного описания проекта.
Клиент понимает бюджет мобильной разработки, сроки и ключевые критерии, выделенные на проект. Например, условия технической поддержки, доступ к информации и консультационная поддержка в соответствующих областях: продвижение и работа с отзывами аудитории проекта. Стоит также поинтересоваться у подрядчика, сколько берут эксперты и какие команды формируются для решения проблем. Расценки (или, проще говоря, стоимость) персонала могут варьироваться в широких пределах. Важно выяснить, предлагают ли они начинающих специалистов за меньшую цену и подвергают вас риску провала проекта или плохой реализации, или же они переплачивают за стандартных специалистов, которых на рынке немало.
Не стоит бояться вопросов о бюджете проекта, задаваемых менеджером на начальном этапе обсуждения деталей. Как правило, любая компания, стремящаяся к качественной работе, предложит свои предложения по оптимизации расходов. Даже если вас не устраивает первоначальная предварительная смета, подрядчик должен быть в состоянии предложить вам несколько вариантов, например, сократить количество функций или изменить технологию разработки. У каждой студии своя методика расчета стоимости проекта, но важно помнить, что ни одна команда не заинтересована в завышении или занижении стоимости работ. Низкая стоимость – это демпинг, последствия которого пагубны для рынка в целом, а высокая стоимость – слишком большой риск, угрожающий клиентам. Поэтому ответственный и внимательный подрядчик начнет с составления условий договора, обсуждения всех деталей будущего проекта и только потом представит график с указанием стоимости каждого пункта работ.
Гарантии и исправления
Большинство студий мобильной разработки, ответственных за реализованные проекты, предоставляют гарантию на написанный ими код на срок от трех месяцев до года, при среднем значении в шесть месяцев. Это оптимальный период времени для выявления и реального исправления всех ошибок и стабилизации работы сервиса, что крайне важно для постоянного успеха продукта. Дефекты, вызванные небрежностью разработчика, в течение этого периода исправляются бесплатно.
В стандартных контрактах обычно не указываются жесткие требования к технической поддержке. Для этого уже используются соглашения об уровне обслуживания (SLA). Это обычная практика, но не все компании предоставляют такую форму по умолчанию. В этом контексте подрядчики несут строгую ответственность за соблюдение определенных фиксированных сроков. Это хорошо для клиента, но может привести к дополнительным расходам для подрядчика.
Хорошей практикой является ответ на запросы клиентов относительно неисправностей в течение 24 часов. Если это не преходящие ошибки, подрядчик оценивает и согласовывает с клиентом сроки устранения. В нашей практике серьезные дефекты, требующие немедленного реагирования и мешающие работе над продуктом, обнаруживаются и исправляются в течение полусуток или около того. Однако не все компании утруждают себя определением рамок, поскольку это влечет за собой определенные риски. Разумный диапазон – от одного дня на реагирование и от одного дня до недели на исправление.
Если студия заинтересована в результатах, она предлагает подписаться на техническую поддержку после окончания бесплатного гарантийного периода. В течение этого времени команда может поддерживать код в актуальном и стабильном состоянии или дорабатывать функциональность.
Существуют также очень тонкие и болезненные моменты, касающиеся модификаций и пересмотра в ходе первоначальной реализации проекта. Хотя это редко регулируется условиями договора, важно понимать, что разработчик – такой же бизнесмен, как и заказчик, и что изначально в стоимость его работы входит то количество рабочих часов, которое выгодно его бизнесу. Если заказчик неоднократно отказывается от предоставленных результатов, подрядчик либо прекратит проект и разорвет отношения с таким заказчиком, либо потребует дополнительной оплаты за работу, выполненную сверх первоначальной сметы. Это больше связано с внутренним расписанием специалиста, чем с желанием получить больше денег. На любую качественную работу есть спрос, и большинство студий планируют работу на месяцы вперед. Если клиент вносит слишком много изменений в первоначально согласованный результат работы, это может негативно сказаться на загруженности подрядчика и его способности браться за новые проекты. По этой причине границы (например, определенное количество правок за одну итерацию) должны быть, по крайней мере, определены в устной форме. Таким образом, и подрядчик, и клиент будут понимать, как взаимодействовать с экспертом, и избегать неловких ситуаций.
Менеджмент и коммуникации
Впечатление, которое вы получаете на этапе предпродажной подготовки, имеет решающее значение. Другая информация о человеке и студии должна дать вам представление о том, чувствуете ли вы доверие и безопасность, приятен ли диалог, встретили ли вы компетентного и понимающего профессионала. Если в конце диалога вы чувствуете себя некомфортно, скорее всего, процесс работы складывается не так, как вам нужно. В этом нет ничего плохого, это хорошо. Просто вы не пришли к согласию, и в первую очередь стоит найти другого менеджера. Если вторая попытка не увенчается успехом, попробуйте обратиться в другую студию.
Предусмотренные проектом формы общения также должны соответствовать вашему уровню комфорта. В идеале следует комбинировать средства взаимодействия с вами, наделяя каждый канал связи своим назначением и преимуществами. Для быстрых ответов и комментариев используйте мессенджер, для важной координации – электронную почту. Важные вопросы и детали проекта следует обсуждать по конференц-связи или лично. При выборе подрядчика важно обратить внимание на его гибкость в решении подобных вопросов и на его отношение к общению, которое позволит поддерживать связь в течение нескольких месяцев.
Качество коммуникации и управления проектом можно также оценить по подходу студии к продукту – насколько вовлечена команда с самого начала и анализируются ли идеи. Клиент может неправильно понимать необходимость создания мобильного приложения. Он не является экспертом в этой области, не знаком с маркетингом, и его реальные требования к функциональности могут быть спокойно перекрыты веб-сайтом. Обычно студия специализируется на определенной технологии и создает продукт на ее основе. Однако решать ряд бизнес-задач, для которых подойдет использование готовых решений, с помощью полномасштабной разработки с нуля нецелесообразно. Это можно распознать на этапе анализа, поэтому стоит обратить внимание на то, предлагает ли подрядчик выполнить работу, является ли она платной или бесплатной, и что получит от этого клиент.
Отдельный важный момент – это вопрос публикации готового приложения в сторах. Кто-то выполняет эти работы по умолчанию, кто-то выносит их в отдельную часть и не проговаривает сразу, кто будет выкладывать продукт. Когда клиент заказывает разработку приложения, он чаще всего по умолчанию представляет, что его сервис опубликуют в маркетах. Но в нашей практике неоднократно были случаи, когда подрядчик не занимался публикацией по каким-то причинам. Здесь очень важен экспертный консалтинг от потенциального исполнителя. Ряд функций в приложениях может быть запрещен по правилам сторов, и если подрядчик – в этом случае именно он является профессионалом – не объяснит клиенту, что есть риски, публикация может сорваться, а вся работа будет сделана впустую.
Если только студия не хочет нести дополнительные расходы. Публикация часто является задачей, требующей внимания, времени и затрат. Поскольку эти вопросы не всегда обсуждаются заранее и не всегда включаются в договор, лучше быстро уточнить, кто будет готовить контент (скриншоты, баннеры, описания) и кто будет отвечать за регистрацию аккаунта разработчика “на берегу”.
Размер компании и сроки давности на рынке
Это вопрос доверия, а студия, которая существует два-три года, вряд ли обладает достаточным опытом и доверием. Кроме того, если специалистов мало, значит ли это, что мало клиентов? Такие вопросы мучают клиентов при принятии решений. Однако делать выбор, основываясь только на численности персонала или длительности пребывания на рынке, не совсем то же самое. Важно качество работ в портфолио, компетентность компании в проекте и первоначальное впечатление консультанта. В конце концов, если один подрядчик находится на рынке дольше другого, это еще не значит, что он будет подходить вам в процессе совместной работы. Риск снижается тем, что если компания работает в отрасли уже долгое время, она с меньшей вероятностью будет прыгать через обручи и с большей вероятностью выполнит проект в соответствии с условиями контракта. Численность сотрудников может стать проблемой из-за форс-мажорных ситуаций. Кто-то заболевает, кто-то увольняется, и эти события не должны влиять на сроки выполнения задачи. Поэтому у компаний с числом сотрудников от пяти до десяти человек проектный риск несколько выше.
Вывод
Самое главное, что нужно помнить при поиске партнера по мобильным продуктам, – не бояться задавать вопросы или показаться некомпетентным. Убедитесь, что менеджер, с которым вы работаете, соответствует поставленной задаче. Как клиенты всегда ищут надежных подрядчиков, так и подрядчики заинтересованы в долгосрочном, взаимовыгодном сотрудничестве и реализации интересной работы.
