Проблемы заказчиков при разработке мобильных приложений

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

Проблема №1. Выбор подрядчика.

Вне зависимости от типа проекта всё начинается с того, что для получения результата, требуются компетенции по управлению проектом и специализированные квалифицированные кадры с опытом разработки мобильных приложений. Содержание под проект собственной команды и наработка компетенций в области мобильной разработки, оправдано если приложение играет важную роль в бизнесе. Во всех остальных случаях содержание команды дорого обойдется компании, а результат все равно рискует быть некачественным. Тогда и принимается решение о полном или частичном аутсорсе задач по созданию приложения на сторону подрядчика. Как найти хорошего и не ошибиться при выборе? После первичного исследования рынка, можно прикинут бюджет на разработку и развитие проекта и определится со сроком. Многие компании руководствуются простым принципом выбора подрядчика — “чем дешевле, тем лучше”. Выбор подрядчика по такому принципу приносит максимальное количество проблем. Студии в лучшем случае по максимуму режут косты, экономя на проектировании, тестировании или документировании, а в худшем на качестве разработки. По понятным причинам мы не рекомендуем вам обращаться к фрилансерам или студиям создающим кроссплатформенные приложения на универсальных фреймворках типа PhoneGap/XAMARIN. Для создания шорт-листа потенциальных подрядчиков ориентируйтесь на средние по рынку цены и сроки разработки. На следующем этапе выделите из полученных предложений те студии, у которых был релевантный вашему проекту опыт работы. Изучите портфолио. Приглашайте понравившиеся студии на встречу и ориентируйтесь на наиболее заинтересованное в вашем проекте студии.

Проблема №2. Определение стоимости разработки приложения.

Проводя мониторинг рынка и не имея четкого технического задания, заказчик на этапе запроса цен получает вилку цен, основанную на опыте предыдущих проектов или субъективной оценки подрядчика. Оценка которую проводит подрядчик может включать: на каких мобильных платформах (IOS, Android, Phone) будет работать приложение, будет ли вестись нативная или кроссплатформенная разработка, какие типы устройств должно поддерживать приложение, нужна ли разработка серверной части, API и т.д. Высокая конкуренция на рынке разработки приводит цену к максимальному приближению стоимости к порогу рентабельности проекта для студии разработчика. Однако, как определить завышена ли стоимость разработки проекта? Для этого потребуется примерная оценка общего объема трудозатрат проекта в отношении к бюджету на разработку. Если над проектом в течении месяца работают 2 программиста и дизайнер, то 500 рабочих часов на проекте в принципе не могут стоить 10 миллионов рублей. Мы в WINFOX при оценке проекта на этапе технического задания, всегда предоставляем подробную смету проекта, чтобы вы понимали из чего складывается стоимость создания приложения, плюс мы можем оказать вам услуги по аудиту сметы проекта.

Проблема №3 Взаимодействие с разработчиками

Излишний бюрократизм или попытка тотального контроля может статья проблемой, если заказчик стремится полностью контролировать все этапы разработки. Никто не любит, когда у них “стоят над душой” или продираться через волокиту бюрократического процесса. Работая со средним бюджетом сложно найти подрядчика который будет позитивно реагировать на подобные попытки. Кроме того, настоящие профессионалы лучше других знают, как им выполнять свою работу. Другая сторона, это полное или недостаточное присутствие контроля или инициативы со стороны исполнителя. Случаи, когда заказчик руководствуется принципом, мы заплатили вам деньги дальше вы сами, всегда приводят к негативному результату. В чем заключается формула эффективного взаимодействия с подрядчиком? Без ясного представления, что вы должны получить в итоге, хорошего проекта не получится, поэтому крайне важна корректная постановка задачи. Определите цели проекта и основные требования. Работа над проектом должна проводится на основе точного технического задания с прототипами экранов приложения и календарным плана выполнения проекта. Для проектов с длительным сроком разработки и меняющимися бизнес-требованиями подойдет работа по гибким методологиям Agile или Scrum. Немаловажным фактором является регулярные встречи. Письменный текст — один из худших каналов коммуникации между людьми; чуть лучше дело обстоит с голосовым каналом и видео в дополнение к нему, но ничто не заменит личного общения.

Проблема №4. Срыв сроков

Если шероховатости сервиса и взаимодействия при реализации проекта еще как-то можно скрипя зубами пережить, то вот срыв сроков нет. Наиболее сильно страдают не выполнением сроков фрилансеры. Неопытные подрядчики, не способные адекватно оценить работу, называют в 2 раза меньшие деньги и сроки. Так происходит потому, что они не понимают до конца сложностей проекта и не закладывает дополнительные процессы: проектирование, тестирование, приемку, техподдержку. У них нет знаний в области проектирования ПО и опыта создания архитектуры системы, которая готова к дешевому масштабированию. Однако даже опытные разработчики при оценке трудозатрат вполне могут ошибиться в два раза. Если оценивать проект навскидку, то полугодовой план вполне может превратиться в год по факту. Снизить риски поможет требование соблюдения графика релизов и штрафы за не выполнение этапов проекта. Для этого должны быть пройдены все этапы до разработки: от постановки задач и подготовки ТЗ до прототипирования экранов будущего приложения. Со стороны заказчика при этом необходима дисциплина в согласовании этапов работ и вовремя совершать очередные платежи по договору.

Проблема №5. Отказ от тестирования

С тестированием всё довольно интересно. Подрядчик «просто работает», а потом вылезают ошибки, ущерб от которых растет по экспоненте, и их невозможно исправить без полного переписывания кода проекта. Развитие такой системы невозможно, потому что непонятно, как её развивать. Причина в отсутствии этапа тестирования и QA (quality assurance) как класса и/или его без системное выполнение. Это приводит к процессу отладки по срокам равному самой разработке. Тестирование должно быть – и автоматическое, и ручное, и полуавтоматическое – это три класса, каждый из которых важен по своему. Тестирование тем лучше, чем больше у компании опыта – что само по себе очевидно и логично, но только если ведется наполнение Wiki / БД по пути непрерывного развития.

Проблема №6. Неработающий продукт

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

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