Наиболее популярные попытки заставить компанию разработчика поработать «за так»

Заказчики → Наиболее популярные попытки заставить компанию разработчика поработать «за так»

Регулярно получаем различные запросы порисовать что-либо, спроектировать или поделиться мега-идеями «возможной» реализации проекта в Artsofte для того или иного тендера.

Посыл  всегда таков – мы вам не озвучим бюджет, но покажите, что вы можете нам предложить как «готовый» продукт.

1.Неоплачиваемые тендеры.

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

Когда задаешь в лоб вопрос: "Кто будет оплачивать время проектного менеджера, проектировщика или дизайн-звена?" – в ответ почти всегда недоуменное молчание. Такое ощущение, что все сидят и ждут как манны небесной – что-бы такого «за так» порисовать или спроектировать.

Вы любите играть в рулетку в бизнесе? Я – нет.

Мне интересно, где такие «потенциальные Заказчики» видели подобное бизнес-взаимодействие, в котором потенциальный поставщик товара\услуги сначала тратит существенные деньги не зная картины всей сделки?

Более того, запрашиваемые работы ну никак не попадают под pre-sale расходы.  Разработка дизайн-концепции несложного проекта иногда составляет до трети от его сметной стоимости, проектирование сложного проекта это также пару K$.

А ведь даже эти 30% от общей сметы могут быть вообще неподъемными для клиента – и вот смысл важничать, если бюджета на взаимодействие просто нет – страх это услышать?

Тут нужно или корректировать активно объем работ в диалоге с разработчиком, или корректировать бюджет, или же просто сэкономить всем время, в том числе и себе. 

А даже если нужный бюджет у Заказчика, например, есть – лично мне не кажется приемлемым потратить «на-удачу» пару K$, чтобы рискнуть заработать с мультипликатором в 2-3 (это при условии что цена лота известна).

Обычно, как правило, заявленной цены лота просто нет – есть желание набрать больше идей со всех «за так».

И как тогда потом строить рабочие отношения, которые в профессиональном девелопменте базируются на нормовремени Разработчика, а не продуктовом подходе? – никак.

Обычно анализа спам-списка в поле "адресаты" у писем с запросом участия в тендере достаточно, чтобы письмо отправить сразу в Trash.

Единственный допустимый результат участия в оценочном тендере – это сметная декомпозиция продукта, что само по себе уже немаленькая задача, и то, при условии, что список участников прозрачен и сопоставим по уровню.

Нам часто задают вопрос: почему мы не рисуем на тендеры запрашиваемые дизайны, - потому что мы не готовы разбрасываться ресурсами.  

Если какая-то компания рисует в тендер бесплатные дизайны – значит ее дизайнеры сидят без работы (чего у сильной команды быть не может) и\или нормозатраты по сравнению с возможной и известной стоимостью контракта, или качество производимого продукта копеечное.

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

Не важно о чем речь – об айдентике или концепции веб-ресурса.

Сделать в тендер полноценный логотип – значит потратить ресурсы на полноценный логотип.

Сделать в тендер полноценный веб-интерфейс – значит потратить ресурсы на полноценный веб-интерфейс.

Помимо всего прочего, порочность подхода «сначала покажите» определяют и частые кидки со стороны устроителей тендеров. Причем это не зависит от размера компаний (у крупных игроков даже с этим чаще, т.к. концы в их оргструктуре найти тяжелее).

Правильный тендер –  это выбор наилучших идей, и это верно.

Но правильный тендер – это тендер где:

• Известна сумма контракта или ее порядок;
• Привлечены сопоставимые по уровню участники;
• Известны четкие критерии отбора;
• Компенсируются затраты \ или часть затрат на предоставляемый к выбору продукт или не запрашивается ничего кроме сметной декомпозиции;

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

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

Наиболее серьезные тендеры, где соревновательность уже за рамками осметки, а в выборе среди итогового продукта, как раз наоборот сосредоточены на привлечении наиболее квалифицированных исполнителей, причем круг привлекаемых очень узок (не более 3-х компаний) – оплачивать попытки «удивить» всем подряд глупо.

Другая популярная финансовая рулетка – это плата за бизнес результат.

2. Плата за бизнес-результат.

Подход имеет право на жизнь при ряде но:

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

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

Состоятельность модели монетизации проекта и стоимость разработки проекта находятся в разных плоскостях (одна в зоне бизнесовой, а вторая в зоне капитальных затрат). 

В классическом виде участие разработчика в проекте за «бизнес-результат» –  это обычный joint venture. Но такой подход слабо применим в повседневной практике, т.к. заниматься совместным бизнесом со всеми подряд не будешь, в любом проекте всегда нужен инвестиционный кэш, идея должна быть действительно интересной для совместного участия.

Иногда данный подход носит форму  наличия entrance&success fee. Ирония в том, что entrance fee это и есть стоимость разработки целиком, а success fee это то, что должно быть оплачено сверх стоимости разработки в случае достижения базовых метрик проекта.

Как правило, пытаясь применять данный подход, некоторые Заказчики подразумевают под success fee недоплаченную часть от entrance fee – вот тут-то и кроется главный «н@eб».

Зачем разработчику выделять ресурсы под такие эксперименты, если есть рынок, который эти ресурсы оплатит в 100% размере без извращений с неподконтрольными бизнес-рисками? 

С какой стати дисконтировать разработку в обмен на чужие бизнес-риски проекта? Уровень персональных рисков должен быть сопоставим с уровнем персональной отдачи для рискующего.

Если для разработчика на рулетку «бизнес-результата» ставится просто часть базовой стоимости девелопмента, без участия в распределении прибыли и выделения опциона в проекте – это разводка на необоснованный дисконт.

3. Сначала бизнес-наставничество – потом заказ. 

На практике это означает – станьте неоплачиваемым внештатным сотрудником компании Заказчика, и тогда, «возможно», результатом Ваших усилий станет заказ на какой-то другой продукт, а возможно и не станет :-))).

Тут опять кроется подвох – консультации это тоже услуга. Хотите получить нужные компетенции, экспертный аудит, FCF  анализ, медиа планирование, прототипирование и прочее – закажите их и оплатите их.

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

nadeyev

Вернуться к списку постов