Повременная схема

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

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

Как строится работа на повременной схеме?

  1. Обсуждается проект, подбирается исполнитель из сотрудников компании.
  2. Если необходимо, проводятся предварительные исследования кода и первые оценки.
  3. Заключается договор, вносится предоплата за оговоренный объем часов (от человеконедели до человекомесяца).
  4. Работы вычитаются из предоплаты.

Для кого такая схема может больше подходить?

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

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

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

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

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