Различная специфика дизайн проектов требует различных подходов к оплате за подобные услуги. Разнообразие дизайн-проектов и, подчас, непредсказуемость их реализации ставит стороны перед почти неизбежным риском потери своей выгоды при финансовом расчете. Существует множество моделей определения стоимости труда дизайнеров, подходящих для различных случаев и особенностей процессов разработки дизайнов. Причем, в процессе реализации проекта, совсем не обязательно следовать только одной из моделей. В зависимости от особенностей фактического протекания проекта по разработке дизайнов, модели оплаты труда разработчиков дизайна могут также меняться и комбинироваться. В этой статье подробно рассматриваются самые распространённые способы определения стоимости труда разработчика дизайна, а также их достоинства и недостатки.
Фиксированная оплата за проект
Подразумевается выплата заранее оговорённой сторонами суммы за определенное количество работы. Собственно ключевые определения тут «заранее оговоренная сумма» и «определенное количество работы». И одного не может быть без другого, категорически. При применении модели фиксированной оплаты, сторонам заранее необходимо весьма четко (насколько это возможно) детально определить количество работы и ту сумму, которой эта работа будет оплачена. Договориться еще «на берегу» и строго придерживаться этих договоренностей в процессе своего взаимодействия, поскольку в противном случае возникнут неизбежные разногласия.
При фиксированной оплате сторонам необходимо заранее четко определить объем работ и сумму, которой эта работа будет оплачена.
Для заказчика дизайна эти модель удобна тем, что он заранее понимает: сколько точно он потратит на услуги разработчика дизайна, что весьма привлекательно в условиях необходимости соблюдения строго фиксированных расходов на дизайн. При этом заказчик может даже еще и сэкономить, если ему удастся договориться с исполнителем на меньшую сумму. А неудобство для заказчика фиксированной оплаты в том, что в любом случае придется четко придерживаться заранее оговоренного объема работ. Если в процессе разработки дизайна заказчик поймет, что для получения устраивающего его результата необходимо большее количество работы исполнителя, нежели было с ним заранее оговорено – значит неизбежно придется платить за дополнительную работу. Так что заказчику, ради сохранения бюджета, необходимо четко следить за тем, чтоб не исчерпать, выделенный ему за этот бюджет, объем работ разработчика.
Для разработчика дизайна фиксированная оплата за проект удобна тем, что он четко знает: сколько именно работы ему придется сделать, чтоб получить оговоренную сумму. Если данную работу получится сделать быстрее, либо она на деле окажется менее трудоемкой – то разработчик окажется в дополнительном выигрыше. Но если заранее оговорённая с заказчиком работа потребует большего времени или усилий, то тогда разработчик явно оказаться в проигрыше.
Таким образом, при фиксированной оплате сторонам необходимо заранее четко определить объем работ и сумму, которой эта работа будет оплачена. В процессе работы над дизайном заказчику необходимо следить за тем, чтоб у него по ходу работы не возникло дополнительных желаний, исполнение которых потребует дополнительной работы разработчика дизайна, поскольку у того, по понятным причинам, без соответствующей дополнительной оплаты совершенно не будет мотивации выполнять эту дополнительную работу. Разработчику дизайна также необходимо следить за тем же и «придерживать» своего заказчика в рамках заранее оговоренного сторонами объема работ.
Повременная оплата
Как можно понять из названия, оплата труда происходит за определенные промежутки времени, потраченные разработчиком дизайна на фактическую работу. В зависимости от трудоемкости задачи и особенностей конкретного проекта: эти промежутки времени могут измеряться: часами, днями или неделями. При повременной оплате, стороны заранее договариваться о конкретной трудоемкости той или иной работы и о ставке оплаты за один час, день или неделю.
При повременной оплате, сторонам, а прежде всего разработчику дизайна, необходимо четко и регулярно согласовывать количество потребного времени на выполненные той или иной работы. Делать это следует, разумеется, заранее.
Измерение трудоемкости в часах больше всего подходит для проектов, подразумевающих в себе небольшое время работы разработчика: на одну мелкую работу, на серию небольших работ или при разбиении большой работы на мелкие составляющие. При этом каждая этих составляющих должна иметь какой-либо промежуточный результат, подлежащий оценке заказчиком. Главное правило при почасовой оплате: общая трудоёмкость в часах не должна суммарно превышать двух-трех дней, иначе уже теряется эффективность почасового измерения работы в силу неизбежных округлений.
Поденная оплата хороша для оценки большего количества работы, когда разработчику дизайна необходимо несколько дней на предоставление своей работы на суд заказчика. Опять же, главное правило – поденная оценка суммарно не может быть больше двух недель.
По неделям удобно оценивать трудозатраты на крупные проекты, где требуется проделать очень большой объем работы. Верхнего предела здесь не существует – главное не округлять по месяцам, иначе это уже напоминает традиционную в нашей стране форму оплаты штатных сотрудников.
Самым правильным и удобным для сторон, будет последовательное применение всех трех категорий оценки повременной работы в рамках одного проекта. Когда какие-то очень трудоемкие процессы оцениваются и оплачиваются понедельно, менее крупные поденно, а мелкие почасовым методом, но для этого сторонам необходимо еще до начала работ, разбить проект на соответствующие стадии и договориться: что и по каким промежуткам времени будет оцениваться и оплачиваться.
Для заказчика, повременная оплата удобна, прежде всего, тем, что ему нет необходимости заранее определять точный объем работ по своему проекту. В зависимости от промежуточных результатов проекта, либо по иным причинам, заказчик может изменить количество работы: добавляя что-либо, либо наоборот: отказываясь от чего-либо. Однако, при этом может существенно измениться общий бюджет проекта: как в большую сторону, если для достижения результата потребуется больший объем работ, нежели заказчик предполагал изначально, так и в меньшую сторону, если по ходу выполнения проекта выявится отсутствие необходимости в части заранее предполагаемых работ.
Для разработчика дизайна, повременная модель оплаты привлекательна тем, что он застрахован от недоплаты своих трудозатрат в случае появления дополнительной работы по проекту. Он получает оплату за фактический расход своего времени – ровно за столько, сколько ему пришлось проработать, чтоб выполнить все пожелания заказчика: как изначально планировавшиеся, так и все дополнительные. Однако при этом стоит помнить, что трудоемкость проекта будет учитываться только по количеству расходованного времени, а затраченные в ходе этого времени усилия и понесенные возможные издержки не будут приняты в расчет. Работал ли разработчик в одиночку или привлекал кого-либо еще, легко ли шла работа, либо нет; достаточно ли было разработчику ресурсов, либо пришлось докупать что-то – все это при повременной оплате не имеет значения.
При повременной оплате, сторонам, а прежде всего разработчику дизайна, необходимо четко и регулярно согласовывать количество потребного времени на выполненные той или иной работы. Делать это следует, разумеется, заранее. Неприемлемо: разработчику в процессе работы изменять заранее объявленную повременную трудоёмкость в большую сторону, а заказчику оспаривать количество потраченных разработчиком часов уже после того, как работа была сделана.
Повременная модель оплаты, наиболее привлекательна в случаях выявления каких-либо дополнительных доработок по проекту: когда необходимо разработать дополнительные варианты или еще более глубоко доработать текущие. Либо в случае необходимости разработки, в поддержку более крупного проекта, каких-нибудь дополнительных дизайнов, изначально не планировавшихся (сувенирная продукция, дополнительная упаковка или последующие текстовые правки в нее, POSM и т.п.).
Предоплата
Заблаговременная оплата труда разработчика дизайна, подразумевает в не просто принцип, «утром деньги, днем стулья», а предоставление разработчиком дизайна определенной скидки для заказчика за его готовность оплатить еще не сделанную работу, причем с не фактическим, а только прогнозируемым результатом. Сумма предоплаты может быть: либо частичной – и тогда скидка меньше, либо полной – и тогда заказчик справедливо может рассчитывать на более привлекательную скидку. Не следует путать предоплату с задатком, поскольку в отличие от последнего – предоплата не возвращается, если разработчик дизайна вдруг совсем или частично не выполнит свои обязательства.
Предоплата удобна в случаях когда заблаговременно очевиден большой объем четко понятной сторонам работы, а разработчик дизайна может достаточно точно просчитать свои трудозатраты и невелик риск появления дополнительной работы.
Предоплачено может быть только четко определённое количество работы, выраженное в часах, либо ином количественном показателе. Причем именно в количественном, поскольку качественный анализ работы дизайнера – это достаточно субъективный анализ с точки зрения предоплаты. Также нельзя связывать с предоплатой, косвенные понятия, относящиеся к дизайну: такие как, например: «рост, в течение года, продаж продукции с новым дизайном не менее чем на 15 % по сравнению со старым», поскольку продажи зависят не только от дизайна.
Для заказчика предоплата привлекательно возможностью существенно сэкономить при большом объеме работ, поскольку чем больший объем работ, тем больше скидку по предоплате можно получить. Однако при этом заказчику необходимо очень тщательно оценить заранее объявляемые разработчиком трудозатраты, поскольку он заранее их оплачивает в полном объеме и если разработчику в реальности потребуется меньше времени на работу, то деньги за его неиспользованное время вернуть не удастся.
Разработчику дизайна предоплата выгодна конечно тем, что тот получит сразу всю сумму за всю предполагаемую будущую работу. Это позволит не только быть уверенным в том, что его работа оплачивается, но при необходимости привлечь дополнительные ресурсы. Однако в этом кроется и один из основных недостатков предоплаты для разработчика дизайна – если придется привлекать дополнительные, предварительно не запланированные ресурсы, то окупить трудозатраты уже может и не получиться. Кроме того, необходимость предоставления заказчику скидки, в зависимости от величины предоплаченной им работы, также негативно сказывается на общей прибыльности проекта для разработчика дизайна.
Предоплата удобна в случаях когда заблаговременно очевиден большой объем четко понятной сторонам работы, а разработчик дизайна может достаточно точно просчитать свои трудозатраты и невелик риск появления дополнительной работы. Также в случае ограниченности бюджета у заказчика, работа по предоплате позволяет уменьшить его расходы на проект.
Оплата за выделенные ресурсы
Выделение ресурсов подразумевает под собой фактическую «сдачу в аренду» разработчиком дизайна части своей инфраструктуры – когда на четко определенный сторонами период времени в распоряжение заказчика поступает дизайнер, либо группа дизайнеров, которые все это время работают только в интересах этого конкретного заказчика. Иногда такую форму сотрудничества шутливо называют «продажей дизайнеров во временное рабство». При этом заказчик платит только за то время, на которое он по сути временно «выкупает» ресурсы разработчика без привязки к конкретным задачам. Как и в случае предоплаты, если ресурсы разработчика арендуются на достаточно продолжительный срок, то заказчику также может предоставляться скидка (как при аренде автомобиля или инструмента, например).
Оплата за выделенные ресурсы наиболее привлекательна для сторон при долговременном и, желательно, ранее устоявшемся сотрудничестве.
Важно понимать, что подобная форма оплаты подразумевает достаточно доверительные отношения между сторонами. Во-первых, с точки зрения оценки времени на ту или иную работу, заказчик не должен злоупотреблять трудозатратами «арендуемых» у разработчика дизайнеров (не стоит выжимать из них последние соки за оплаченное время их работы) – необходимо с пониманием относиться к тем срокам, которые ему объявляют. А разработчик дизайна также не должен злоупотреблять доверием своего заказчика: он должен объявлять ему только действительно необходимое время. Во-вторых, в процессе подобного длительного сотрудничества, существует риск переманивания сотрудников от разработчика к заказчику. Подобное может произойти когда например: в роли заказчика выступает также дизайн-агентство, которому часть своей работы приходится отдавать другим агентствам, либо когда заказчик дизайна решает что объем работы настолько велик, что уже пора бы нанять себе дизайнер в штат и самая лучшая кандидатура – тот дизайнер из агентства разработчика дизайна, что делал для него ту же работу все последнее время…
Оплачивая выделенные ресурсы, заказчик имеет следующие плюсы. Первое – это получение в собственное распоряжение дизайн ресурсов, которые будут выполнять все его соответствующие задачи в течение оплаченного времени. С выделенными ему работниками можно установить достаточно плодотворные отношения, что еще более благоприятно скажется на эффективности взаимодействия с ними. Второе – это возможность экономии бюджета при получении скидки в случае долгосрочной «аренде» ресурсов разработчика. Третье – в случае продления работ или нового проекта, заказчик может рассчитывать на выделение той же команды дизайнеров, уже знакомых со спецификой как проекта, так и работы этого заказчика. Но минусом для заказчика является необходимость обеспечения постоянной загрузкой выделенных ему дизайнеров, дабы оплаченное им время не пропало, когда те либо сидят без работы, либо вообще могут трудиться на благо совсем другого заказчика во времена подобных простоев. За этим нужно четко следить, поскольку при подобном сотрудничестве именно заказчик, а не работодатель временно выделенного ему дизайнера должен обеспечивать постоянное наличие работы к исполнению. Кроме того, приходится доверяться разработчику в его добросовестной оценке потребного времени на свершение той или иной работы, в надежде что она действительно не занимает меньшего времени, а оплаченный заказчиком излишек не будет потрачен совсем на другого клиента…
Несомненным плюсом для разработчика дизайна будет гарантированная оплата времени его работы и соответствующих трудозатрат. Ему можно спокойно быть уверенным, что на какое-то время его будущая работа по сути уже оплачена. Причем в случае еще и предоплаты, разработчик, получив деньги вперед, может раньше вложить их в развитие своего бизнеса. Недостатки оплаты для разработчика оплаты за его выделенные ресурсы следующие. Первый – это необходимость делать скидку при резервировании заказчиком значительного количества его времени, поскольку это все-таки негативно сказывается на общей прибыли. Поэтому подобная модель оплаты крайне невыгодна разработчику при кратковременном сотрудничестве с заказчиком, поскольку из-за необходимости давать скидку он первый лишается значительной части прибыли, которую он мог бы получить используя иные модели оплаты своего труда. Второе – это вероятность попыток заказчика занизить потребное время работы разработчика, с целью исполнения им большего объема работ за тоже самое время. Либо выдаче разработчику заблаговременно ненужной для заказчика работы (которая потом весьма вероятно «пойдет в корзину»), поскольку: время его работы итак уже оплачено и пусть он не сидит без работы, либо есть желание заказчика отработать несколько заведомо тупиковых ветвей разработки дизайна с целью получения дополнительных доказательств их негодности, на что заказчик никогда не пошел бы при иных моделях оплаты труда разработчика.
Модель оплаты за выделенные ресурсы наиболее привлекательна для сторон при долговременном и желательно ранее устоявшемся сотрудничестве. Это проекты по дизайн-поддержке ранее исполненных больших проектов. Или наоборот, при наличии постоянного объема небольшого количества работы: например, постоянные текстовые правки, переверстка дизайнов на новые форматы, несложный креатив, адаптации и т.п. Главное, чтобы у заказчика был постоянный поток подобной работы, обосновывающей долговременное выделение на нее ресурсов разработчика.
Как мы уже отмечали в самом начале этой статьи: каждая из перечисленных моделей оплаты может применяться не только отдельно сама по себе, а можно применить последовательно несколько моделей в зависимости от условий протекания проекта по разработке дизайна. Подходить к выбору нужно ответственно: заранее просчитывая все выгоды и потери от применения той или иной модели. Договариваться надо, как говориться: «на берегу» и не пересматривать договорённости в процессе работы до тех пор, пока не пройдет заранее оговоренный период действия выбранной сторонами модели оплаты. Стоит обратить внимание, что при выборе способа финансового подсчета труда разработчика дизайна, стороны должны руководствоваться не сугубо личной, а прежде всего обоюдной выгодой, поскольку в этом случае они обеспечивают синергию своего взаимодействия, что самым благоприятным образом сказывается как на протекании проекта, так и, разумеется, конечном результате – дизайне. При этом стороны создают благоприятный задел для будущего эффективного сотрудничества.