Дмитрий Желнин, основатель и руководитель студии мобильной разработки 65приложений , написал колонку для vc.ru о процессе выбора подрядчика на мобильную разработку — на что следует обратить внимание во время переговоров и какие вопросы задавать.
Рынок заказной мобильной разработки — это трэш и безумие: на рынке до сих пор есть вендоры, способные выполнить проект даже средней сложности.
много меньше, чем работа.
Всем нужны крутые мобильные приложения.
На этом спекулирует огромное количество мелких магазинов, стремящихся хоть откусить кусочек от этого пирога.
На выходе - толпы недовольных клиентов, которым очередные студенты из Саратова сделали очередной откровенный шлак.
Клиенты в ступоре: некоторые особо голодные застройщики готовы пообещать всё, лишь бы получить заказ.
Я чувствую, что пришло время помочь клиентам понять, где искать, чтобы не ошибиться.
В итоге у меня получилось 8 подсказок, основанных на выборе нормального подрядчика (нет, рекламы нашей студии здесь не будет – только «выгоды»).
Подсказка №1. Все врут о бизнес-процессах
Есть два типа компаний.Некоторые мобилизуются и организуются в трудную минуту, другие начинают настолько прогибаться под каждого конкретного заказчика, что теряют все нити управления в компании, и начинается хаос.
Итак, вот оно.
Полгода назад мы уже записано признаки хаоса в 52% компаний из топ-100. Некому было даже просмотреть почту.
А сейчас, по нашим ощущениям, хаос просто зашкаливает. Конечно, все вам расскажут о процессах.
Но на самом деле ни одного регламента компании не разработали.
А раз оно не развито, то и соблюдать нечего.
Запросить регламент студии "посмотреть".
В студии должно быть:
- регламент управления проектами;
- регламент документооборота внутри организации.
Регламент планирования работ и проектов весьма важен на первом этапе.
В общем, он должен разъяснить заказчику, от чего зависят сроки выполнения его проекта.
А если вам будет предоставлено еще и описание системы должностных компетенций, принятой в организации, то вы будете четко знать, от кого в компании нужно требовать решения конкретных вопросов.
Да, это внутренние документы компании.
Но это не ноу-хау и не коммерческая информация.
Лично я не вижу причин отказываться от отправки.
И если документы есть, то их отправят в тот же день.
Меня не выгнали — студия была «фтопка», все их разговоры о крутых бизнес-процессах были просто словами.
Подсказка № 2. Если ты не быстр, ты мертв.
О чем бы вы ни говорили с потенциальным подрядчиком, посмотрите, как быстро он ответит. В нашем экспресс-исследовании шесть месяцев назад мы выяснил Что только 22% компаний отвечают на запросы в течение часа.
12% требуется пара часов, а еще 12% просматривают электронную почту как минимум в течение того же дня.
А 16% студий на простую реакцию нужно пять и даже больше дней.
Как вы думаете, с тех пор что-то изменилось? Едва ли.
Тогда никто не собирался ничего менять.
А теперь только больше стонов по поводу того, что заказов нет. Подрядчик в своем ответе может лишь указать срок предоставления необходимой информации, но должен общаться быстро.
Отговорка «у нас много работы, нет времени» не работает. Если компания действительно занята, то она просто не сможет выполнить ваш заказ в срок.
Если на самом деле заказов нет, то застройщик лжет. А ложь – это привычка.
Тебе это надо?
Совет №3. Загляните под юбку
Любое слово подрядчика требует доказательств.Мы всегда говорили, что лучшее доказательство – это видеоинтервью.
Совершите видеозвонок.
Посмотрите, кто с вами разговаривает (мальчик половозрелого возраста – не наш вариант) и что происходит на заднем плане (смеется или отклеивает обои – обойти).
Начинают пафосно комментировать про «распределенные команды без офиса» — фтопка.
Попросите показать все отделы, которые упомянул на сайте подрядчик, и обязательно посмотрите сам сайт в мобильной версии.
Понятно, почему? Мы провели очень простой анализ: прогнали через сервис топ-50 прошлогоднего рейтинга Tagline. GoogleРазработчики .
У 24 студий разработки нет мобильной версии главных страниц сайта.
Плюс один сайт мертв, а домен продается.
Это все сапожники без сапог? Возможно, тем более что разработчики Google не нашли мобильной версии даже у e-Legion. По этому параметру подрядчиков отправлять в утиль не нужно, но быстрая и понятная мобильная версия сайта уже демонстрирует возможности студии.
Но вернемся к видеозвонку.
Во всех отделах загляните под юбку, чтобы узнать, кто чем занимается.
Как правило, у говнокодеров всё вместе — одни и те же программисты разрабатывают, тестируют, поддерживают по остаточному принципу.
Если они вообще это сделают. И чем больше отделов работают удаленно, тем хуже управляемость.
А про бардак я уже говорил.
Кстати.
Во время экскурсии вскользь спросите об организационной структуре студии и попросите прислать вам ее описание.
Считается наиболее подходящим для проектных офисов.
матрица организационная структура.
И тогда рассказ гида мог бы быть примерно таким: «Вот у нас есть отдел разработки, в нем 9 человек, и это Ваня, его руководитель.
Сейчас отдел работает над тремя проектами, а разработчики распределены по ПМ.
Если поступит еще один проект, ПМ сделает запрос Ване, а также руководителям других отделов, они решат, кто и в каких долях будет выполнять эту работу, и у ПМ появится команда для реализации проекта.
Позвольте мне сейчас показать вам менеджеров проектов…» Если рассказ гида совпадает с тем, что вы видите на экране, а затем с полученным вами документом, это многое скажет о порядке в компании.
Подсказка №4. Гараж должен быть полон
Никто и никогда не просит нас показать парк устройств для тестирования и прислать описание в обычной табличке с кодами IMEI. А это важно.Парк устройств должен быть объемным и разнообразным: от популярных бюджетных устройств до актуальных флагманов известных брендов.
Знаете ли вы, что такое «матрица покрытия конфигурации устройства»? Это набор устройств, обладающих комбинацией характеристик, необходимых для поддержки приложения.
Чаще всего смотрят на модель процессора устройства, разрешение и диагональ экрана, наличие сканера отпечатков пальцев, наличие дополнительного графического ускорителя, размер оперативной памяти и т. д. Если требования к приложению не покрываются имеющейся матрицей устройств, то выход у QA только один — использовать специальные сервисы, которые отнюдь не бесплатны.
А если студия так экономит, что не пользуется сервисами вроде Testdroid, а тестирует приложение на четвертом айфоне и паре личных андроидов из китайского интернет-магазина — это о многом говорит, правда?
Подсказка №5: Нам всем нужна поддержка.
Нет приложения, которое не нуждалось бы в поддержке.
Все параметры оказания поддержки должны быть строго зафиксированы в Соглашении об уровне обслуживания (SLA).
Да и стандартная SLA-структура нормальной студии уже давно разработана.
Если вам обещают поддержку, немедленно запросите документ. И посмотрите, что вам обещают в рамках гарантийной и послегарантийной поддержки.
Гарантийная поддержка должна включать бесплатное исправление любых ошибок приложения.
Ключевой показатель – гарантийный срок.
Не обязательно 2 недели.
Стандартно — 3 месяца гарантийной поддержки, чтобы пользователи опробовали приложение и совершили все возможные каверзные ошибки.
Есть компании, которые объявляют шестимесячную поддержку как дополнительную ценность своих услуг.
Послегарантийная поддержка (она же техническая поддержка) обязательно должна включать в себя внесение изменений в приложение.
Например, это может потребоваться при появлении новой версии мобильной ОС.
Подсказка №6. Ищите слабаков у подрядчика
Профессионализм команды должен быть подтвержден.Запросите, например, резюме ПМ (они отвечают за сроки и порядок), разработчиков и руководителя QA-команды.
Запросите стандартную тестовую документацию и обратите внимание на ее состав (хорошим тоном считается подготовить план тестирования, список тест-кейсов и итоговый отчет с результатами тест-кейсов).
План тестирования, который будет вам отправлен, должен отвечать на вопросы:
- что необходимо протестировать;
- что мы будем тестировать;
- как мы будем тестировать;
- когда мы будем тестировать;
- критерии начала тестирования;
- критерии завершения тестирования;
- трудоемкость;
- сроки выполнения.
Особое внимание можно уделить сертификатам, подтверждающим профессиональные навыки команды.
Для разработчиков это может быть DCP от Oracle или сертификаты других вендоров.
Хорошо, если есть ZCE. Может быть, сертификат от Brainbench или какой-нибудь другой онлайн-школы.
Для менеджеров сертификат PMI считается высшим пилотажем.
Они бормочут, откладывают дела на потом, пытаются что-то придумать на лету — до свидания.
Управлять ПМ так и не научился, тестирование делают первокурсники, а в регламенте управления проектами есть рекламные фразы о скорости и качестве без конкретики — до свидания.
Помните, что уровень команды определяется уровнем ее самого слабого звена.
Подсказка №7. Сильные щедры
Оцените вклад компании в открытый исходный код. Игроки, работающие на профессиональном лимите, склонны сидеть на своих библиотеках, как индейка на яйцах.Только очень уверенные в себе разработчики делают их общедоступными.
Для них не было проблемой придумать собственное решение и не станет непреодолимой задачей создание более совершенных моделей.
Просто спросите потенциальных участников об их вкладе в библиотеки с открытым исходным кодом.
Возможно, вы многое не поймете в этой истории.
Критерий здесь очень простой: есть этот вклад или нет.
Подсказка №8. Вы должны понимать, за что платите
Немедленная отправка проекта на оценку – самый простой способ найти подрядчика.Но не лучший.
В состоянии паники наверняка найдутся те, кто согласится работать за еду и обещает короткие сроки.
Только на выходе вы получите именно то, во что должна превратиться еда, и ждать придется долго – в 2-3 раза дольше, чем вы ожидали.
Проект следует подавать на оценку только студиям, прошедшим все предыдущие проверки.
Из шорт-листа до этой стадии дойдут не более 10%.
И надо смотреть оценки от этих студий.
Если у вас есть хорошо описанная идея приложения, попросите смету с деталями, а не просто одну цифру.
Узнайте, сколько человек планируется привлечь к участию в проекте.
Будут ли они посвящены только вашему проекту или будут работать сразу над несколькими? Обязательно поинтересуйтесь, сколько рисков включено в оценку и что нужно сделать, чтобы их снизить.
И не обрадуйтесь, если подрядчик забыл включить некоторые риски, о которых вы знаете.
Если студия не возьмет это на себя, то вам придется с этим разобраться.
Да, возможно, это дороже, чем у торговцев дерьмом, но это именно тот случай когда скупой платит дважды.
Мы уже видели достаточно случаев по поводу «переделай мое приложение, оно как-то не работает».
В любом случае помните: истории о деньгах, полученных на разработку и не доставленных никогда Существует бесчисленное множество проектов.
А также пошлые темы из серии «ой, бюджета не хватило для завершения проекта, доплатите».
-
Платите Меньше За Новый Компьютер
19 Oct, 24 -
Кража Контента В Китайской Разработке Игр
19 Oct, 24 -
Рит-2007 / Избранное Видео
19 Oct, 24 -
Карта Глобальных Катастроф
19 Oct, 24
