Лого 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

У меня огромный опыт по подбору разработчиков. Я протестировал боле 300 компаний, многие из них в рейтинге ТОП в мирек. Это вообще просто смех. Выглядит это так.

1. Ни у кого контактов на сайте нет, какие-то убогие формы, или общие e-mail. Никакого личного контакта.

2. Ты заполняешь занудную форму, отсылаешь. В лучшем случае ответ приходит через неделю. Чаще всего это автоматизированные темплейтные письма

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

4. Абсолютно ноль участия в понимание задачи. Это разговор слепого с глухим. Все сводится к тому что "Ну, ты заплати, мы тогда может начнем думать". А если вы не способны думать или ваш уровень ниже плинтуса?

5. Результаты присылюет в виде e-mail. Гора текста с таблицами. Какая-то несуразная таблица, со стандартными пунктами, из которой ничего не понятно. Некоторые делает в виде PDF с кучей какой-то рекламы и описанием процессов и какие они хорошие. Почему на это ушли недели совершенно непонятно.

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

Это 1-10 по каким-то там рейтингам
Примерно так: clutch.co/directory/mobile-application-developers

Хорошо, а аббревиатуру как расшифровать?

Это английское слово TOP. как Top 10

Не стоит ориентироваться на ошибки других.

А как по-вашему выглядит правильный, идеальный процесс ?

С пунктами 1, 2, 3 - понятно. А что можно предложить по пункту 4, скажем. Зачем кому-то тратить свое время, если клиент не знает что хочет и вообще может ничего заказывать не будет ? Как тут быть ?

и что с пунктом 5 ? Как присылать результаты ?

0

Андрей Захаров,

4. "зачем тратить свое". Хотя бы для того, что это дает шанс получить контракт. Но ни один клиент точно не будет работать с компанией, которая работать не хочет.

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

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

Как с подобным кидаловом бороться тогда ?

По поводу п. 5 я не понял, как должны оформляться результаты, если email / PDF не подходят. Как сделать лучше ? Вот в чем был мой вопрос.

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

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

Однозначно, процессы общения с клиентом и разработчиком должны перейти на другой уровень.
1. Любое обращение должно мгновенно становиться проектом, над которым работает все команда. Какой-то инструмент, куда может зайти клиент, выложить свои идеи, спросить совета и т.п. Чтобы все коммуникации были наглядными и т.п. что-то типа Slack + Scrum.
2. Категорически исключить из процесса все ненужные звенья вроде Business Development, Продавцы и прочие некомпетентные элементы.
3. Четко определить грань, где бесплатная консультация, где уже платные сервисы. Можно разбить на части. Например, хотите мокап, это будет стоить столько то.

Спасибо за развернутый ответ ! Вы не зря потратили время формулируя его, я наконец-то понял ;-)

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

Мне нравится ваш подход )
Нам как раз нужно мобильное приложение!

Если только под Windows Phone ;-)

0

65apps вообще не врубаются, что самое главное, это сделать так чтобы клиенту было с тобой удобно общаться. А не формочки сделанные говноделами

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

Это все как вату гонять, если бюджет ниже $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 проектов - и что ни один из них не скачало больше чем несколько тысяч человек?

Вот, только что получил ответ от разработчика www.softeq.com. Прошло 1.5 месяца :-)
-----------------------
Hi,

Sorry for the delay in reply, i was on vacation.
I will revert to you within this week.
Thank you.
Kind Regards,

Elena Birulia
Sales manager

Softeq Development Corporation HQ: 1155 Dairy Ashford, Suite 125, Houston, TX 77079 www.softeq.com Phone: 281.552.5039 Cell: 267.581.5338
-----------------------

0

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

Вот обычное приложение: экран логина, простой 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

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

Сейчас обсуждают
Александр Ухин

Так ребрендинг или рестайлинг? Так брендбук или руководство по фирменному стилю?

Медицинская компания Invitro провела ребрендинг для отражения статуса «лидера сферы»
0
Александр Рычков
SalesMan

Так с 2008 году случился бум продаж китайских подделок. Меньше чем за полгода половину местного ЦКР заняли китайцы. Продавали так "хорошо", что позакрывалось много брендовых розничных магазинов. Но! Открылись новые, которые стали продавать китайские товары и одежду уже при сотрудничестве с китайскими поставщиками, т.е. фактически произошла некая легализация продаж подделок.

«Подделки принесли нам 1,5 миллиона рублей за два месяца»
0
designer fake
A1QA

закусывать надо

Элон Маск анонсировал систему межпланетных перелётов и представил план колонизации Марса
0
Виталий Желтяков

Еще один занимательный факт о налогах в России:
- в 2000 году фактическая сумма всех налогов была 40% !!!
То есть за 16 лет своего правления наш горячо любимый президент Владимир Владимирович Путин повысил налоги на 7%...

Страны с наиболее высоким уровнем налогообложения — отчет WEF
0
TonyOn

Можно я робко спрошу: должен отвечать покупатель или продавец? В данной статье указанные товарищи изначально - покупатели: приехали на указанный "рынок" и купили. И пошли продавать исходя из того, что это - не подделка :-)

Или все не так?

«Подделки принесли нам 1,5 миллиона рублей за два месяца»
0
Показать еще