Лого vc.ru

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

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

Дмитрий Желнин, основатель и руководитель студии мобильной разработки 65apps, написал для vc.ru колонку о процессе выбора подрядчика на мобильную разработку — на что стоит обратить внимание во время переговоров и какие вопросы задавать.

Поделиться

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

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

Клиенты в ступоре: некоторые особо голодные разработчики готовы наобещать что угодно, только бы получить заказ. Чувствую, настала пора помочь заказчикам разобраться, куда смотреть, чтобы не наломать дров. У меня получилось 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

Статьи по теме
Письмо в редакцию: «Российские мобильные разработчики — ленивые, необязательные и дорогие»17 ноября 2015, 10:58
Популярные статьи
Показать еще
Комментарии отсортированы
как обычно по времени по популярности

За видео просто зачет гигантский!)))

необходим отдельный пост с разбором этого кейса!

Не перестаю улыбаться этому видосу ))

0

Так и хочется перейти на личности после просмотра портфолио, но удержусь )

Это все как вату гонять, если бюджет ниже $50k. Если клиент с баблом, он проведет due diligence, скорее всего лично приедет. Если без бабла (приложение за $5-10k), то ему все эти проверки только время терять.

И в обратку, если говно-студия каким-то чудом урвала заказ от $50k, то только полный олень не создать видимость абсолютно отлаженных процессов (сделает презентацию, посадит подсадных в красивый офис на день и т.п.).

Поддержу. Если бюджет $50к, то можно и pm найти нормального или пригласить как эксперта для выбора команды. А так статья-пиар (заголовок норм), но кто в теме им 8 пунктов ни о чем не говорят, не в теме - из разряда стань pm за 10мин. И о боги - удаленно тоже можно разрабатывать, только контроль жестче и процесс заточен немного по-другому. Насчет бюджетов и сроков - Брукса читай, статью потом кропай.

>Чаще всего смотрят на модель процессора устройства, разрешение и диагональ экрана, наличие сканера отпечатков пальцев, наличие дополнительного графического ускорителя

Ускоритель, really?

>Есть два типа компаний.

Есть два стула...

Узнал в во всех пунктах свое прошлое место работы)

0

Это, конечно, мое субъективное мнение, но статья - несколько очевидных пунктов + самопиар.

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

Очень люблю, когда руководитель студии мобильной разработки рассказывает как выбрать студию мобильной разработки. Вопрос: сколько пунктов в статье написаны с целью чтобы студия автора попадала в эти критерии.

По мне это такой страшный моветон и прямая реклама нежели попытка написать объективно без учета своих интересов. Эйч ар рассказывает как выбрать эйч ара. Интернет маркетолог рассказывает как выбрать интернет маркетолога. Люди, которые никогда не сталкивались с подобным выбором рассказывают как делать выбор. Статьи на тему "как выбрать осла, должны писать, кто купил 10 ослов, а не тот кто торгует ослами". Короче говоря, такие материалы лучше читать от потребителя услуг, а не от производителя.

А вы знаете, бывают у меня такие рекламодатели - что прям сразу им говорю, что не сработаемся, доходит до того что свежую выписку требуют на бумаге и с печатью.

Так и тут - по такому списку если начнут гонять, проще сразу в жопу послать и заняться другими клиентами. Во всем должна быть мера.

Известный принцип "посылаем клиентов 1. 2" и тп.

0

Я себе представляю как клиент, который ничего не понимает в разработке (а именно для таких статья будет откровением), начнет искать косяки у подрядчика. Он будет искать их не с высоты вашего профессионализма, а исходя из своих представлений о том как должна идти разработка.

Заготовка возмущений:

1) Все ряженые хипстеры школьного возраста.
2) Этот тип вообще на пляже 2 года хипует, как он может быть одним из лучших разработчиков?
3) В резюме у всех ни о чем не говорящее смузи, где серьезные люди, отработавшие в этой компании хотя бы 100500 лет?
4) Остальные компании обещали что над нашим проектом будут сидеть всем офисом 3 месяца, а потом еще 6 месяцев поддержки будут ждать от нас багов и наводить красоту в коде. У вас же, наш проект будет одним из многих? Да это же конвейер! Без души!

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

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

Хороший разработчик прежде всего посоветует заказчику построить свою собственную, дружную команду, следуя советам из этих 8 пунктов, проведет экспертизу бизнес-процессов заказчика в той части, что касается будущего жизненного цикла разработанного продукта. Тогда и проект будет живой, и разработчик дополнит команду заказчика, а не заставит его копаться в той области, в которой он ничего не понимает.

Одно время, когда мы часто отказывались от проектов из-за загруженности как моей команды, так и знакомых коллег, я составлял для заказчиков подобные удивительно похожие списки "как найти такую же крутую команду, как и мы". За одним редким исключением результаты следования заказчиков данным пунктам заканчивались очень плохо: у компании есть имя, заказчик мог контролировать все этапы проекта, продукт получался без багов и в срок, но результат = мертвый проект и выброшенные на ветер деньги.

В кризис один джуниор в реальности = два синьора на бумаге)
Главное сроки аргументировать с помощью бла-бла-бла-аргументов)

Прочтите лучше "Империя приложений" - Чед Мурета. Спасибо за статью, но не осилил :)).

0

Хорошие производственные процессы - это хорошо, но не все покупают хорошие производственные процессы. Ваш кейс хорошо работает для портрета клиента, у которого уже был болезненный ожог о "говностудию". Но есть и другие критерии выбора.

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

Я бы, к примеру, ваш сайт не купил бы. Из него не ясно какую вы в принципе доставляете ценность вашим клиентом и каков ваш идеальный клиент.

Касательно бизнес процессов - было полезно почитать ваш пост, у нас, например, далеко не все так.

Самое главное это 2 вещи

1. Квалификации программистов и дизайнера которые будут делать ваш эпп

2. Портфолио успешных эппов


А тем кто считает что бизнес процесс важнее конкретных людей и результата в ай-ти делать нечего.

Советы от гуру аутсорса:
1. Загляните под юбку разработчику
...

Кстати, насчёт заглянуть под юбку...

1. Вот у вас на сайте отзыв из серии "летс ме спик вфом май харт" - "Guys write very worthy code, even Apple’s and Chilean advisers told us they are fine fellows and real experts on their field and we have to take care of them"

2. Битые картинки - dl.dropboxusercontent.com/u/1652081/app.png

3. Практически нет никакой инфо на сайте - ни где вы находитесь, ни имён ваших разработчиков, ни описания процесса - вообще ничего кроме 2-х простых страниц,.

4. Не увидил ни одного эппа из вашего портфолио ни в Гугл сторе ни в Аппле даже со средними загрузками. Вы пишите что у вас 70 проектов - и что ни один из них не скачало больше чем несколько тысяч человек?

Так, хорошо. А самый главный момент вы продолбили — сколько в итоге всё это великолепие должно стоить?

Вот обычное приложение: экран логина, простой REST запрос (email, pass), экран регистрации, такой же REST, плюс экран который после логина показывает рандомное число подтягиваемое из REST.

Здесь дел — на часа два от силы вместе с бэкэндом.

Вопрос, если разложить это на ваш чеклист, это будет стоить меньше 1.5 млн рублей?

0

Если писать хорошо (хотя бы с MVP, тестами и CI), то за два часа можно и не уложиться (я уже не говорю про поворот экрана и сохранение состояния). Ну и вы не написали про обработку ошибок при регистрации/логине. И забыли про SSL pinning из нетривиального, например.

то есть вы оцениваете такой проект на 1.5 млн рублей.
Он вроде говорил что еще стоит смотреть на то что вы хотите заказать, может это студенту стоит отдать и будет готово...

0

Вывод статьи - в 65apps не ходить. Они знаю как пустить пыль в глаза.
Спасибо

Кроме спец пунктов про имеи, можно применять и к консалтерам к отбору. Правда редко но бывают крутые взлеты из комнат с облезлыми обоями.

0

Статья неоднозначная. Есть правильные вещи, есть херня полная. Я бы сказала, что это косвенные признаки в основном. Черт побери! Пункт 1. Вы как заказчик зная портрет компетенций будете знать с кого требовать результат). Заказчик вообще не должен парится, кто там в команде лажает, он должен спрашивать с РП или с КАМа результат, взаимодействовать с одной точкой. Все эти охрененные регламенты процессов и резюме тоже по большому счёту не гарантируют их соблюдения. Только референсы и конкретные результаты, доступные для просмотра, их обсуждение, и конкретное КП в твою сторону с его обсуждением. План реализации проекта со сроками. Но заказчик и сам должен быть грамотным, чтобы различать, где ему лапшу вешают. Все остальное, какие то косвенные признаки. Даже если я вижу в скайпе ресурс менеджера, который мне рассказывает про загрузку программеров, то где гарантия, что он не врет и ресурс будет реально выделен? Только пени за просрочку в договоре).

0

1. Интересно студия разработки мобильных приложений еще и должна быть на все руки мастер, там должна быть обязательно мобильная версия сайта? Как то странно, по идее, они вообще сайт могут заказать у другой фирмы, главное чтобы он выполнял поставленные бизнес задачи...
2. Все должны работать из офиса? нужно провести тур? если вы не верите в распределению разработку или у вас это не получилось, то это еще не значит что она нигде не работает.
3. Про парк оно конечно важно, но у клиента могут быть определенные требования к устройствам и ваш парк там будет просто не нужен... Вы можете прислать все IMEI, но так и никогда не проверять на них, по причине элементарной лени, вот если бы дописали чтоы каждое проверенное устройство включили и чтобы они еще и не были разряжены...
4. Конечно же поддержка вложена в стоимость пропета хоть год, просто если у вас три месяца не значит что у всех должна быть такая же и ни как не может быть стандартом.
5. И самое интересное что даже не упомянули ни отзывы других клиентов, ни опыт работы и разработанные проекты.

0

Возможность комментирования статьи доступна только в первые две недели после публикации.

Сейчас обсуждают
Dmitry Polyakov

Не часто встречаются работы над ошибками. А у Вас есть подобные материалы?

«Я потратил $10 млн и два года на то, что мог выяснить за 4 недели»: основатель Twenty20 об ошибках проекта
0
Dmitri Atname
ATNAME

Прикольно :)

Avito оказалась единственным российским представителем в рейтинге Deloitte Technology Fast 500
−1
Алексей Чингуль

А если необходимо провести возврат денежных средств юридическому лицу, должна использоваться аналогичная процедура? Или есть какие-то нюансы?

Мы хотим попробовать заменить 14 дневный бесплатный тестовый период использования одной услуги на "плати и пользуйся, если что - деньги вернём".

Как правильно оформлять возврат денег клиенту
0
Иван Маяк

Общался я с одним учеником. Парень 16-18 лет а уже специалистом себя считает и обижается на критику. Если взялись учить то не раздувайте эго учеников. Опустите их на землю и заставьте трудится долго и упорно.

Moscow Digital Academy — образовательный проект для молодых digital-специалистов
0
Артем Ярмилко

Согласен! Вообще непонятно, что делать гостям во время того как жених и невеста проходят квест.

Отдельный вопрос - это финансовая часть. Сколько стоит прохождение?

Lama Agency — переносные свадебные квесты
0
Показать еще