Загляните под юбку разработчику: 8 советов по выбору подрядчика на мобильную разработку
Дмитрий Желнин, основатель и руководитель студии мобильной разработки 65apps, написал для vc.ru колонку о процессе выбора подрядчика на мобильную разработку — на что стоит обратить внимание во время переговоров и какие вопросы задавать.
На рынке заказной мобильной разработки трэш и угар: вендоров, способных в принципе выполнить проект даже средней сложности, на рынке
На этом спекулирует огромное количество мелких лавочек, которые пытаются хоть
Клиенты в ступоре: некоторые особо голодные разработчики готовы наобещать что угодно, только бы получить заказ. Чувствую, настала пора помочь заказчикам разобраться, куда смотреть, чтобы не наломать дров. У меня получилось 8 хинтов по выбору нормального подрядчика (нет, здесь не будет рекламы нашей студии — только «пользуха»).
Хинт № 1. Все врут про бизнес-процессы
Есть два типа компаний. Одни в сложное время мобилизуются и организуются, вторые начинают так прогибаться под каждого конкретного заказчика, что теряют все нити управления в компании, и начинается бардак. Так вот. Полгода назад мы уже
фиксировали признаки хаоса в 52% компаний из
- регламент управления проектами;
- регламент управления документами внутри организации.
Эти два регламента покажут, насколько четко будет выполнен проект и насколько будут соблюдены его формальные стороны.
Довольно важен на первом этапе регламент планирования работ и проектов. В целом он должен просветить заказчика, из чего формируются сроки выполнения его проекта. А если вам предоставят еще и описание системы должностных компетенций, принятых в организации, то вы будете четко знать, с кого в компании нужно требовать решения конкретных вопросов.
Да, это внутренние документы компании. Но это не
Хинт № 2. Если ты не быстрый — ты мертвый
О чем бы вы ни говорили с потенциальным подрядчиком, смотрите, как быстро он реагирует. В нашем
Подрядчик в ответе может только обозначить срок предоставления нужной информации, но коммуницировать должен быстро. Отмазы «у нас много работы, мы не успеваем» — не катят. Если компания действительно зашивается, то сделать ваш заказ в срок просто не сможет. Если же заказов в действительности нет, то разработчик врёт. А врать — это привычка. Оно вам надо?
Хинт № 3. Заглядывайте под юбки
Любое слово подрядчика требует доказательства. Мы всегда говорили, что лучшее доказательство — это видеоинтервью. Сделайте видеозвонок. Смотрите на то, кто с вами говорит (юноша пубертатного возраста — не наш вариант) и что происходит на фоне (ржач или облупленные обои — мимо). Начинают вас пафосно залечивать про «распределенные команды без офиса» — фтопку.
Попросите показать все отделы, о которых подрядчик заикнулся на сайте, а сам сайт непременно смотрите в мобильной версии. Понятно же, зачем?
Мы провели очень простой анализ: прогнали топ
Но вернемся к видеозвонку. Во всех отделах смотрите под юбки, кто и на чем работает. Как правило, у говнокодеров все в кучу — одни и те же программисты разрабатывают, тестируют, осуществляют поддержку по остаточному принципу. Если вообще осуществляют. И чем больше отделов работает «по удалёнке» — тем хуже управляемость. А про бардак я уже говорил.
Кстати. В процессе экскурсии спросите невзначай про оргструктуру студии и попросите выслать вам ее описание. Для проектных офисов, как считается, больше всего подходит
матричная оргструктура. И тогда рассказ экскурсовода может быть
Если рассказ экскурсовода совпадает с тем, что вы видите на экране, а затем и с полученным документом — это много скажет о порядке в компании.
Хинт № 4. Гараж должен быть полным
У нас никто никогда не просит показать парк устройств для тестирования и выслать описание в нормальной табличке с
Вы знаете, что такое «матрица покрытия конфигураций девайсов»? Это набор устройств, обладающих сочетаниями характеристик, требуемых для поддержки приложения. Чаще всего смотрят на модель процессора устройства, разрешение и диагональ экрана, наличие сканера отпечатков пальцев, наличие дополнительного графического ускорителя, размер оперативной памяти
А если студия экономит настолько, что сервисами типа Testdroid не пользуется, а приложение тестирует на четвертом iPhone и на паре личных андроидов из китайского
Хинт № 5. Мы все нуждаемся в поддержке
Не существует приложения, которому не нужна поддержка. Все параметры предоставления поддержки должны быть жестко зафиксированы в Service Level Agreement (SLA). И типовая структура SLA у нормальной студии давно выработана. Если вам обещают поддержку — сразу запрашивайте документ.
И смотрите, что вам обещают в гарантийной и внегарантийной поддержке. Гарантийная поддержка должна включать в себя бесплатное исправление любых ошибок приложения. Ключевой показатель — срок гарантии. Это не должны быть 2 недели. Стандартом считается 3 месяца гарантийной поддержки, чтобы пользователи попробовали приложение и совершили все возможные каверзные ошибки. Есть компании, которые в качестве добавочной ценности своих услуг объявляют о полугодовой поддержке.
Внегарантийная поддержка (она же техническая) обязательно должна включать доработку приложения. Например, это может потребоваться при появлении новой версии мобильной ОС.
Хинт № 6. Ищите у подрядчика слабаков
Профессионализм команды должен быть подтвержден. Запросите, например, резюме PM'ов (именно они отвечают за сроки и порядок), разработчиков, руководителя
- что надо тестировать;
- что будем тестировать;
- как будем тестировать;
- когда будем тестировать;
- критерии начала тестирования;
- критерии окончания тестирования;
- трудоемкость;
- сроки.
Запросите документ, описывающий принятые в компании стандарты разработки, регламент ведения проектов.
Особое внимание можно уделить сертификатам, подтверждающим профессиональные навыки команды. У разработчиков это могут быть DCP от Oracle или сертификаты других вендоров. Хорошо, если есть ZCE. Может быть сертификат Brainbench или
Мямлят, тянут, пытаются сочинять на ходу — до свидания. PM нигде не учился управлять, тестированием занимаются первокурсники, а в регламенте ведения проектов рекламные фразы о быстроте и качестве без конкретики — до свидания. Помните, что уровень команды определяется уровнем её слабейшего звена.
Хинт № 7. Сильный — великодушен
Оцените вклад компании в open source. Игроки, работающие на профессиональном пределе, как правило, сидят на своих библиотеках как индюк на яйцах. Только очень уверенные в себе разработчики выкладывают их в открытый доступ. Для них не было проблемой придумать свое решение и не будет неразрешимой задачей создать более совершенные модели. Просто попросите у потенциальных подрядчиков рассказать об их вкладе в пополнение библиотек с открытым кодом. Не исключено, что многого из рассказа вы не поймете. Критерий здесь очень простой: есть этот вклад или его нет.
Хинт № 8. Вы должны понимать, за что платите
Сразу раскидать проект на оценку — самый легкий путь поиска подрядчика. Но не самый лучший. В состоянии паники непременно найдутся те, кто согласится работать за еду и пообещают короткие сроки. Только на выходе вы получите именно то, во что положено превращаться еде, причем ждать придется долго — в 2–3 раза дольше, чем вы рассчитывали. Проект на оценку нужно давать только студиям, прошедшим всю предыдущую проверку. Из
Если у вас есть хорошо описанная идея приложения, то просите оценку с деталями, а не просто одну цифру. Выясните, сколько людей планируется привлечь к реализации проекта. Будут ли они выделены только под ваш проект или работают сразу на нескольких. Обязательно спросите, сколько рисков заложено в оценку, и что необходимо сделать, чтобы их уменьшить. И не радуйтесь, если подрядчик забыл заложить
Да, это может быть дороже, чем у говноделов, но это
ровно тот случай, когда скупой платит дважды. Уж мы навидались кейсов про «переделайте мне приложение, оно
В любом случае, помните: историям о полученных за разработку деньгах и не сданных
никогда проектах — несть числа. Равно как и пошлым темам из серии «ой, бюджета на окончание проекта не хватило,