Загляните под юбку разработчику: 8 советов по выбору подрядчика на мобильную разработку30.04.2016 16:37

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

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

Клиенты в ступоре: некоторые особо голодные разработчики готовы наобещать что угодно, только бы получить заказ. Чувствую, настала пора помочь заказчикам разобраться, куда смотреть, чтобы не наломать дров. У меня получилось 8 хинтов по выбору нормального подрядчика (нет, здесь не будет рекламы нашей студии — только «пользуха»).

Хинт № 1. Все врут про бизнес-процессы

Есть два типа компаний. Одни в сложное время мобилизуются и организуются, вторые начинают так прогибаться под каждого конкретного заказчика, что теряют все нити управления в компании, и начинается бардак. Так вот. Полгода назад мы уже фиксировали признаки хаоса в 52% компаний из топ-100. Там даже почту было некому смотреть. А сейчас по нашим ощущениям бардак просто зашкаливает. Разумеется, все будут говорить вам про процессы. А по факту — в компаниях не разработан ни один регламент. А раз не разработан, то и соблюдать нечего. Запросите регламенты студии «на посмотреть». Обязательно у студии должны быть:

• регламент управления проектами;
• регламент управления документами внутри организации.

Эти два регламента покажут, насколько четко будет выполнен проект и насколько будут соблюдены его формальные стороны.

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

Да, это внутренние документы компании. Но это не ноу-хау и не коммерческая информация. Поводов отказаться от отправки лично я не вижу. И если документы существуют — их вышлют в тот же день. Не выслали — студию «фтопку», все разговоры о крутых бизнес-процессах у них — лишь слова.

Хинт № 2. Если ты не быстрый — ты мертвый

О чем бы вы ни говорили с потенциальным подрядчиком, смотрите, как быстро он реагирует. В нашем экспресс-исследовании полугодовой давности мы выяснили, что в течение часа за запросы отвечают только 22% компаний. 12% нужна пара часов, и еще 12% смотрят почту хотя бы в те же сутки. А 16% студий для простой реакции нужно пять и даже больше дней. Думаете, с того времени что-то поменялось? Вряд ли. Тогда никто и ничего менять не собирался. А сейчас стало только больше стонов о том, что заказов нет.

Подрядчик в ответе может только обозначить срок предоставления нужной информации, но коммуницировать должен быстро. Отмазы «у нас много работы, мы не успеваем» — не катят. Если компания действительно зашивается, то сделать ваш заказ в срок просто не сможет. Если же заказов в действительности нет, то разработчик врёт. А врать — это привычка. Оно вам надо?

Хинт № 3. Заглядывайте под юбки

Любое слово подрядчика требует доказательства. Мы всегда говорили, что лучшее доказательство — это видеоинтервью. Сделайте видеозвонок. Смотрите на то, кто с вами говорит (юноша пубертатного возраста — не наш вариант) и что происходит на фоне (ржач или облупленные обои — мимо). Начинают вас пафосно залечивать про «распределенные команды без офиса» — фтопку.

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

Мы провели очень простой анализ: прогнали топ -50 прошлогоднего рейтинга Tagline через сервис GoogleDevelopers. 24 студии разработки не имеют адаптированной для мобильных устройств версии главных страниц сайта. Плюс один сайт сдох и домен продается. Это всё сапожники без сапог? Возможно, тем более что мобильной версии GoogleDevelopers не нашел даже у e-Legion. По этому параметру не нужно отправлять подрядчиков в утиль, но быстрая и внятная мобильная версия сайта уже демонстрирует возможности студии.

Но вернемся к видеозвонку. Во всех отделах смотрите под юбки, кто и на чем работает. Как правило, у говнокодеров все в кучу — одни и те же программисты разрабатывают, тестируют, осуществляют поддержку по остаточному принципу. Если вообще осуществляют. И чем больше отделов работает «по удалёнке» — тем хуже управляемость. А про бардак я уже говорил.

Кстати. В процессе экскурсии спросите невзначай про оргструктуру студии и попросите выслать вам ее описание. Для проектных офисов, как считается, больше всего подходит матричная оргструктура. И тогда рассказ экскурсовода может быть каким-то таким: «Здесь у нас сидит отдел разработки, в нем 9 человек, а это Ваня, его руководитель. Сейчас отдел работает над тремя проектами, и разработчики распределены по PM’ам. Если поступит еще проект, PM сделает запрос Ване, а также руководителям других отделов, они решат, кто и в каких долях будет заниматься этой работой, и у PM появится команда для реализации проекта. Давайте сейчас я вам проект-менеджеров покажу…»

Если рассказ экскурсовода совпадает с тем, что вы видите на экране, а затем и с полученным документом — это много скажет о порядке в компании.

Хинт № 4. Гараж должен быть полным

У нас никто никогда не просит показать парк устройств для тестирования и выслать описание в нормальной табличке с IMEI-кодами. А это важно. Парк девайсов должен быть объемным и разноплановым: от бюджетных популярных аппаратов до актуальных флагманов известных брендов.

Вы знаете, что такое «матрица покрытия конфигураций девайсов»? Это набор устройств, обладающих сочетаниями характеристик, требуемых для поддержки приложения. Чаще всего смотрят на модель процессора устройства, разрешение и диагональ экрана, наличие сканера отпечатков пальцев, наличие дополнительного графического ускорителя, размер оперативной памяти и т. д. Если требования к приложению существующей матрицей устройств не покрываются, то выход у QA один — использовать специальные сервисы, которые отнюдь не бесплатны.

А если студия экономит настолько, что сервисами типа Testdroid не пользуется, а приложение тестирует на четвертом iPhone и на паре личных андроидов из китайского интернет-магазина — это о многом говорит, правда?

Хинт № 5. Мы все нуждаемся в поддержке

Не существует приложения, которому не нужна поддержка. Все параметры предоставления поддержки должны быть жестко зафиксированы в Service Level Agreement (SLA). И типовая структура SLA у нормальной студии давно выработана. Если вам обещают поддержку — сразу запрашивайте документ.

И смотрите, что вам обещают в гарантийной и внегарантийной поддержке. Гарантийная поддержка должна включать в себя бесплатное исправление любых ошибок приложения. Ключевой показатель — срок гарантии. Это не должны быть 2 недели. Стандартом считается 3 месяца гарантийной поддержки, чтобы пользователи попробовали приложение и совершили все возможные каверзные ошибки. Есть компании, которые в качестве добавочной ценности своих услуг объявляют о полугодовой поддержке.

Внегарантийная поддержка (она же техническая) обязательно должна включать доработку приложения. Например, это может потребоваться при появлении новой версии мобильной ОС.

Хинт № 6. Ищите у подрядчика слабаков

Профессионализм команды должен быть подтвержден. Запросите, например, резюме PM’ов (именно они отвечают за сроки и порядок), разработчиков, руководителя QA-team. Запросите типовую тестовую документацию и обратите внимание на ее состав (хорошим тоном считается оформление плана тестирования, списка тест-кейсов, итогового отчета с результатами прохождения тест-кейсов). Тест-план, который вам отправят, должен отвечать на вопросы:

• что надо тестировать;
• что будем тестировать;
• как будем тестировать;
• когда будем тестировать;
• критерии начала тестирования;
• критерии окончания тестирования;
• трудоемкость;
• сроки.

Запросите документ, описывающий принятые в компании стандарты разработки, регламент ведения проектов.

Особое внимание можно уделить сертификатам, подтверждающим профессиональные навыки команды. У разработчиков это могут быть DCP от Oracle или сертификаты других вендоров. Хорошо, если есть ZCE. Может быть сертификат Brainbench или какой-то другой онлайновой школы. У управленцев высшим пилотажем считается сертификат PMI.

Мямлят, тянут, пытаются сочинять на ходу — до свидания. PM нигде не учился управлять, тестированием занимаются первокурсники, а в регламенте ведения проектов рекламные фразы о быстроте и качестве без конкретики — до свидания. Помните, что уровень команды определяется уровнем её слабейшего звена.

Хинт № 7. Сильный — великодушен

Оцените вклад компании в open source. Игроки, работающие на профессиональном пределе, как правило, сидят на своих библиотеках как индюк на яйцах. Только очень уверенные в себе разработчики выкладывают их в открытый доступ. Для них не было проблемой придумать свое решение и не будет неразрешимой задачей создать более совершенные модели. Просто попросите у потенциальных подрядчиков рассказать об их вкладе в пополнение библиотек с открытым кодом. Не исключено, что многого из рассказа вы не поймете. Критерий здесь очень простой: есть этот вклад или его нет.

Хинт № 8. Вы должны понимать, за что платите

Сразу раскидать проект на оценку — самый легкий путь поиска подрядчика. Но не самый лучший. В состоянии паники непременно найдутся те, кто согласится работать за еду и пообещают короткие сроки. Только на выходе вы получите именно то, во что положено превращаться еде, причем ждать придется долго — в 2–3 раза дольше, чем вы рассчитывали. Проект на оценку нужно давать только студиям, прошедшим всю предыдущую проверку. Из шорт-листа до этого этапа доберётся не более 10%. И оценку нужно смотреть именно у этих студий.

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

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

В любом случае, помните: историям о полученных за разработку деньгах и не сданных никогда проектах — несть числа. Равно как и пошлым темам из серии «ой, бюджета на окончание проекта не хватило, доплатите-ка ещё».

Присылайте колонки, соответствующие требованиям редакции, на secret@vc.ru