10 ошибок при выборе подрядчика по мобильной разработке
1. Самая низкая цена
Фактор цены остается доминирующим при принятии решений у большинства заказчиков. Неважно кто, неважно как — лишь бы цена за проект была минимальной. О том, что за дешевую разработку придется платить снижением качества либо длительными сроками разработки, заказчик, «купившийся» на кричаще маленький ценник, предпочитает не думать.
Выбор разработчика исключительно на основе минимальной стоимости среди всех предлагаемых вариантов приводит к разочарованию качеством, сроками и параметрами разработки. В итоге компания-заказчик зарекается вообще в дальнейшем создавать какие-либо мобильные приложения, будучи уверенным, что все разработчики одинаковы («потому что делают какой-то унылый и неполноценный продукт, еще и денег хотят за это»).
К примеру, мы в Componentix сразу предупреждаем заказчиков, что понятие «дешевая разработка» означает игнорирование рыночного подхода и необходимость пожертвовать чем-то из двух: либо функциональностью приложения, либо скоростью его создания.
2. Гонка за скоростью
«Надо разработать через неделю / на вчера / до конца месяца» — типичная фраза заказчиков в лице менеджеров проекта, которым руководство внезапно «спустило план» по разработке мобильного приложения, но не рассказало, когда, как и в какие сроки обычно такие приложения создаются.
В погоне за тем, кто предложит наиболее быструю разработку, компания-заказчик рискует столкнуться с «поделкой» на основе конструктора мобильных приложений и получить в итоге не нативное, а гибридное приложение. О том, чем эти виды приложений отличаются между собой, мы уже рассказывали ранее. Заказчик, не знающий о таких нюансах, а также не очень знакомый с работой онлайн-конструкторов, рискует получить продукт, лишь наполовину отвечающий его ожиданиям.
Есть четкие сроки и возможности каждого специалиста (от программиста до QA и дизайнера), и заставить его работать «быстрее» и реализовать (условно говоря) 10 строк кода в секунду вместо двух — это нечто, мало связанное с реальной практикой разработки.
3. Гонка за скидками
Зачастую крупные студии предлагают разработку по заведомо завышенной цене, а когда заказчик, «прижатый к стене» необходимостью получить качественный продукт, начинает вести торг за получение другой цены, то ему предлагают скидку. Гонка за скидками у разных крупных студий приводит к перекрестной конкуренции нескольких составляющих: цены, которую готов платить заказчик, качества итогового продукта и аппетитов студии. Вместо задачи «получить качественный продукт» у заказчика появляется задача «выбить скидку на разработку». А качество? «Ну за такие-то деньги качество наверняка будет…» Последнее — типичная ошибка неопытного подрядчика. Высокая цена не гарантирует качества, также как дешевая и «быстрая» разработка.
4. Отсутствие весомого портфолио проектов без объективной причины
Студия с оптимальной ценой услуг и более-менее адекватными сроками выполнения поставленной задачи без существенного портфолио всегда выглядит подозрительно. Выводов два: либо студия возникла недавно, и опыта высоконагруженных проектов у нее нет; либо студия ранее делала проекты, которые по разным причинам нельзя показать широкому кругу потенциальных заказчиков. Если речь идет о разработке под NDA — хорошо. Остальные варианты не очень устраивают подрядчика. Так что попытайтесь выяснить: проектов в портфолио мало, потому что студия работает недавно, потому что они под NDA или потому, что ранее продукты были слишком мелкими.
5. Отсутствие собственного офиса у компании-подрядчика
Сколько историй про гибкость и удобство удаленной работы не рассказывай, особо качественными и надежными проекты, которые создают «фуллтайм-фрилансеры», не назовешь. Команда, собранная хотя бы какую-то часть дня «на одной территории», работает в разы эффективнее, чем масса одиночек, разбросанных по кафе, коворкингам и собственным квартирам.
Поинтересуйтесь, есть ли у потенциального заказчика собственный офис, где можно регулярно собирать разработчиков, ставить задачи и как-то контролировать их работу над проектом.
6. Аутсорсинг дизайна UI / UX
«У нас своя команда разработчиков, а дизайн мы заказываем у внештатного специалиста» — предложение, которое должно вас насторожить. Штатный UI / UX специалист и дизайнер необходимы проекту (равно как хотя бы один QA-специалист). Когда команда подчиняется единому стилю управления, системе постановки задач и контроля версий, итоговый продукт будет более целостным и эффективно работающим.
7. Разработка несколькими подрядчиками разных частей приложения
«Собрались Лебедь, Рак и Щука…» — дальше продолжать? Каждый пишет часть кода, а потом всё сводят воедино, и кто-то еще тестирует — обычно из этого не получается ничего хорошего.
Если вы хотите получить нормально работающее приложение, не стоит разделять разработку между несколькими разными подрядчиками.
8. Подрядчик не может предоставить четких сроков и итераций по проекту
Как правило, невозможность этого вызвана отсутствием элементарных навыков тайм-менеджмента и умения ставить приоритеты, пользоваться системами менеджмента проектов и визуализации целей. Разработка — это деньги, а деньги не терпят абстрактных категорий. Подрядчик, которые не может показать, когда, как и на каких условиях он готов представить те или иные стадии разработки продукта, вряд ли поможет вам создать мобильное приложение, которое вас полностью устроит.
9. Тендер превыше здравого смысла
Если заказчик избирает тактику «мы не выбираем исполнителя, не участвовавшего ранее в тендерах», значит, перед вами — большой любитель бюрократической волокиты. Выбирайте подрядчика не только по степени его вовлеченности в процесс подготовки тендерной документации, а скорее по его профессиональной экспертизе, качеству ранее представленных приложений и навыкам проектного менеджмента.
10. Микроменеджмент как обязательное условие сотрудничества
По-простому это можно назвать «желание стоять над душой»: если заказчик выбирает только того подрядчика, которому он может каждый день по несколько раз в сутки указывать, что, как и когда делать для получения тех или иных результатов, — работы не будет. Сразу стоит разграничить сферы, в которых заказчик участвует / не участвует, и уровень самостоятельности в принятии решений командой компании-подрядчика.
