В подавляющем большинстве аутсорсинговых компаний предусмотрена почасовая оплата услуг. Такой способ оплаты был избран не сразу, однако сейчас именно он стал основным. Более того, почасовая оплата стала популярной не только в ИТ-аутсорсинге, но и в огромном множестве других отраслей. Почему же вышло так, что исполнителю удобнее, а клиенту выгоднее оплачивать работу именно по количеству отработанных часов?
Чтобы понять, как появилась традиция почасовой оплаты, удобно сравнить услугу ИТ-аутсорсинга со строительством здания с нуля. Клиент обращается к строителю со следующим вопросом: У меня есть земельный участок, на котором я хочу построить здание, как на этом чертеже. Сколько это будет стоить? Я хотел бы услышать точную сумму.
Понятно, что строитель не сможет озвучить точную сумму сразу. Ему нужно будет узнать множество различных подробностей, от которых будет зависеть процесс подготовки участка к строительству и само строительство здания. Да и после всех расчетов смета будет очень приблизительной. Если программист получит задание, сравнимое с приведенным, он посчитает примерную смету, увеличит ее раза в два, добавить процентов 20-40 и возьмется за работу, надеясь на то, что назвал выгодную для себя цену.
Конечно, этот подход нельзя назвать профессиональным. Но как правильно рассчитать стоимость заказанной разработки?
Программист определяет стоимость часа своей работы по заказу, исходя из рыночных цен и своего профессионализма. Эта цена за час работы и будет базовой единицей расчета стоимости работы по заказу. Как только эта цена определена, можно начинать диалог с заказчиком.
Итак, клиент дает задачу, в которой разработчик отлично разбирается. Разработчик называет цену одного часа своей работы и уточняет, что предварительная оценка задачи может быть выполнена бесплатно. Если клиент не знаком с компанией разработчика или с самим разработчиком, он вполне может усомниться в его профессионализме и адекватности цены. В этом случае огромным плюсом разработчику будут всевозможные сертификации и рекомендации других клиентов именно в той сфере, с которой предстоит работать. Тогда разработчик сможет убедить клиента в том, что именно он как нельзя лучше подходит для выполнения поставленной задачи, и сделает ее быстро и качественно. И в этом случае при почасовой оплате клиент заплатит меньше, чем если бы он выбрал другого разработчика, который делал бы эту задачу в три раза дольше.
Теперь, когда клиенту предъявлены доказательства компетентности и профессионализма программиста, нелишним будет обговорить порядок работы. Так, разработчик должен объяснить клиенту все свои действия по отношению к задаче, которые должны быть оплачены. В этот список входят и переговоры с заказчиком. Просто и понятно список оплачиваемых услуг может звучать так: если разработчик выполняет какие-то действия, которых он не делал бы, если бы не было задачи клиента, эти действия должны быть оплачены.
Чтобы клиент мог доверять разработчику относительно затраченного времени, можно договориться о составлении отчетов или использовании системы учета рабочего времени. Такая организация работы позволит заказчику отслеживать ход работы, анализировать и планировать расходы на выполнение проекта.
Профессиональный разработчик не станет завышать цену и списывать времени на работу больше, чем затрачено на самом деле. Ведь разработчику важна его репутация. Если клиент останется доволен сотрудничеством, он обратится еще раз и порекомендует исполнителя своим знакомым. Это гораздо дальновиднее и выгоднее, чем разовые, пусть и большие суммы денег, которые можно выиграть обманом. Тем более, если об этой ситуации станет известно заказчику, то репутацию восстановить будет очень сложно. Поэтому профессиональный разработчик будет действовать из соображений честности и благожелательности.
Если вдруг ситуация будет складываться таким образом, что указанного в оценке задачи времени не хватит на выполнение задачи, то единственным верным решением будет извещение об этом заказчика с предоставлением ему нескольких вариантов продолжения разработки с их временной и, соответственно, стоимостной оценкой. Предлагая клиенту выбирать вариант разработки, исполнитель показывает, что открыт для конструктивных предложений и пожеланий заказчика. В то же время, заказчик начинает доверять разработчику, поскольку не возникает проблем с отслеживанием хода разработки, а также заказчик сможет сам расставить приоритеты выполнения этапов задачи. Иными словами, нежелательная ситуация, при которой разработчик берет задачу и пропадает на месяц, а после представляет выполненную с отклонениями от требований задачу и требует оплаты за месяц работы, не возникнет.
Очень распространена в сфере ИТ-аутсорсинга (да и в других многих сферах тоже) ситуация, когда после выполнения задачи у клиента возникает потребность добавить что-то новое или переделать некоторые элементы. Здесь важно сразу объяснить заказчику, что любая такая доработка должна быть оплачена согласно часовой ставке программиста.
Со стороны может показаться, что почасовая оплата не так уж и выгодна. Однако это не так. И клиенту, и аутсорсеру гораздо удобнее работать по схеме почасовой оплаты и в материальном, и в моральном плане.