5 болей или типовые проблемы с которыми к нам обращаются клиенты

Без лишней скромности, мы как команда уже давно представлены на рынке разработки мобильных приложений РФ. «Давно» по меркам мобильного рынка, разумеется. В большинстве отраслей 6 лет это мало. Не то чтобы мы этим сильно гордились или чересчур выпячивали сей факт в своем маркетинге. Ведь судить надо в первую очередь по достижениям, а не просто по выслуге лет…

Но в одном нашему стажу точно не откажешь. Мы видели и слышали, кажется, почти все проблемы с которыми может обратиться клиент к исполнителю. Видели, слышали, записывали и классифицировали «боли» для внутренних и внешних нужд. И сейчас в этом коротком посте готовы обобщить и поделиться типовыми проблемами заказчика, заинтересованного в реализации мобильного проекта iOS / Android.

Почему это может быть интересно лично вам?

Что-то мне подсказывает, что если вы пока только размышляете о приложение и/или уже находитесь на каком-либо из этапов его разработки – эта информация может помочь вам избежать кочек в пути. :)

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

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

ТИПОВАЯ ПРОБЛЕМА #1. Вне зависимости от того о каком именно виде проектов мы говорим – бизнес-приложение, стартап или игра – всё начинается с того, что инициатор осознает, что у него сейчас нет узко специализированных и высоко квалифицированных кадров с опытом решения задач в мобильной среде.

Их поиск, найм и содержание под проект по отдельности дорого обойдется компании, а результат все равно рискует быть некачественным. Тогда и принимается решение о полном, либо частичном аутсорсе задачи на сторону вне штатных подрядчиков. Где найти хороших и как не ошибиться в выборе?

ТИПОВАЯ ПРОБЛЕМА #2. Тут мы плавно переходим ко второй распространенной проблеме – отсутствие четкого понимания сферы и важных для работы (и принятие решения о выборе подрядчика) критериев у человека с улицы. Это логично. Если вы никогда в жизни не строили дом, ваше знание темы ограничивается базовым пониманием. Есть фундамент, есть стены, есть шпаклёвка и обои. Ну а потом мы мебель завезем.

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

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

Многообразие вариантов при запросе сметы поражает воображение заказчика. Но найти адекватное предложение в среднем ценовом сегменте по принципу «value for money» по-прежнему не тривиальная задача. Это вообще частая история в интернете. Мы уже писали об этом на своем примере аутсорсинга SEO, к слову.

ТИПОВАЯ ПРОБЛЕМА #3. Если рынок веб-разработки и сайтов уже как-то стабилизировался и перешел в фазу размеренного взросления. Рынок мобильной разработки был широко представлен публике только в 2008 году. Это ведет нас к третьей типовой проблеме – «молодость сервиса».

Я поясню что имею в виду. Клиент всегда хочет гибкость, клиент всегда хочет привилегированного к себе отношения. Тем более в теме, где средний чек вполне сойдет для покупки автомобиля средней руки.

Но пока найти тех кто будет отзеркаливать ваши методы работы и делать мобильный проект в точности так, как хотите вы, без VIP / PREMIUM / SUPERSTAR бюджетов сложно. Гораздо чаще попадаются крайности.

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

ТИПОВАЯ ПРОБЛЕМА #4. Если шероховатости сервиса и взаимодействия при реализации проекта еще как-то можно скрипя зубами пережить, то вот срыв сроков, например, или ловушки сотрудничества – нет.

Когда работа ведется не до результата, а до конца оплаченных часов. Когда любые мелкие отступления от подписанного ТЗ в процессе работы караются дополнительными счетами. Когда задержки не штрафуются, а ответственность за них кочует где-то вахтовым методом. С таким обычно не мирятся, и дело заканчивается судом.

ТИПОВАЯ ПРОБЛЕМА #5. Еще немного ужасов, и я заканчиваю с этим блоком, обещаю. Хотя казалось бы что теперь может усугубить историю? Например, неработающий продукт на выходе в результате отсутствия или неправильного подхода к тестированию.

Когда, не смотря уже на задержки в пути, в конце реализации проект все равно сдается клиенту в сыром виде. Этап тестирования и QA (quality assurance) отсутствует как класс и/или выполняется без системно, что приводит к процессу отладки по срокам равному самой разработке.

Всё, я заканчиваю нагонять страх. :)

Теперь давайте снимать депрессию и думать позитивно. Как с этим всем взлетать. Или, еще лучше, заранее не допустить появления этих проблем в вашей жизни. Для разнообразия, теперь пойдем в обратном порядке.

5.  С тестированием всё довольно интересно. Недавно как раз обещали дать жизнь новому циклу статей и разобрать эту, чаще всего, забываемую многими тему по косточкам.

Пока скажу лишь, что (1) тестирование должно быть – и автоматическое, и ручное, и полуавтоматическое – это три класса, каждый из которых важен по своему; (2) тестирование тем лучше, чем больше у компании опыта – что само по себе очевидно и логично, но только если ведется наполнение Wiki / БД по пути непрерывного развития.

4-3. Ранее мы всегда говорили следующее. Снизить риски и уберечь от опасности остаться в дурак при найме не того человека или команды поможет: (1) вербальное и подробное обсуждение всех тонкостей взаимодействия заранее, (2) тест-драйв, желательно бесплатный, на первом практическом кусочке работ и (3) привилегированный, рамочный договор, который всё равно поможет в случае чего выйти из контракта с минимумом потерь.

Это действительно так, но всё еще не достаточно сильно.

Совсем недавно мы решили дополнить свои стандартные 5 гарантий еще одной. Такой, которая, во-первых, поможет нам выделиться среди конкурентов, а во-вторых будет по-настоящему беспрецедентной, бомбовой. Чтобы клиент видел и слышал не только рекламные лозунги и обещания, но и чувствовал, ощущал, опирался ногами на твердое.

Был нужен монолитный фундамент страхующий по-максимум. И мы решили его дать. Вот честно – не хочу чтобы это сейчас воспринималось как чисто рекламный и продающий пост, поэтому только кратко:

«Если вам не понравится как мы реализуем ваш проект, мы вернем вам 100% его себестоимости. Без дураков. Но при условии, что вы обязуетесь не использовать результаты нашего труда.»

Все остальные подробности будут доступны по факту обновления маркетинговой упаковки SpaceshipApps до версии 6.0 – к середине осени, ориентировочно.

2. Возвращаясь к истории с древнегреческой горой Олимп в мобайле… Что тут можно посоветовать? Для начала, после первичного исследования рынка, крайне желательно определить с бюджетом по инвестициям и срокам. И дальше плясать уже исключительно от него.

Мы по-прежнему не рекомендуем обращаться к фрилансерам (вот подробнее почему) или дешевым студиям клепающим неликвид на универсальных фреймворках типа PhoneGap, XAMARIN, Titanium etc. Что же тогда делать если нет денег на премиум-сегмент?

Искать где-то посередине. Не опускаться до подножия горы, но и не пытаться сходу работать на уровне Билайна, например. Мы не навязываем свою команду и свой сервис, хотя бы потому что не считаем их средними. Помимо нас есть еще довольно сильный костяк нормальных ребят. Выбирайте среди них. И рационально и иррационально. Химия важна. :)

1.  Что касается проблемы отсутствия квалифицированных мобильных разработчиков в штате… В среднем качественный проект требует участия 5-6 узких специалистов – вот здесь писали почему – есть ли возможность снизить расходы при аутсорсинге и/или соблюсти потребность лишь частичной передачи работ на подряд?

Потенциально, возможность имеется. Если у вас есть на примете по-настоящему хороший дизайнер, который может быть и не работал ранее по мобильным гайдлайнам UI/UX – но очень хочет и может развиваться. Тогда можно попробовать удаленно взаимодействовать с ним, консультируя по узким моментам проектирования.

Однако, например, серверную разработку отдавать в отрыв от клиентской части для iPhone / iPad / Android мы не рекомендуем. Каждый подобный опыт говорит не в пользу данного решения. Выбирать в любом случае вам. Тут, так же как и с бюджетом, нужно ваше принципиальное видение в качестве точки опоры.

Резюмирую. Сложно делать какие-то выводы и призывать к чему-то в этом посте – ведь типовые проблемы на то и типовые, что встречаются на постоянной основе и исключить их полностью невозможно. Зло в мире должно балансировать добро. :)

Надеюсь, этот поток мыслей послужит вам в качестве подсказки и вспомогательного материала. Напоследок хочется поделиться напутствием, в т.ч. для нас самих:

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

Делайте мобильные приложения! :)