О договоре работы по часам. Как я строю работу с клиентами по часам и почему для меня это оптимальный вариант

Привет! Я Лена Плинер, ux/ui дизайнер интерфейсов. Работаю как попроектный дизайнер. Сотрудничаю с заказчиками и командами разработчиков. Запускаю MVP, пересобираю и улучшаю уже существующие проекты.

Занимаюсь дизайном больше 10 лет и мне всегда есть что рассказать. Делаю это в своем телеграм-канале, где пишу о том какие проекты запускаю и как, о рутине, процессах, а иногда о чем-то личном )

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

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

Мои проекты часто объемные, сложные, содержащие на старте общие требования, которые в процессе работы трансформируются. Поэтому для клиента и для меня важна гибкость работы.

Основная цель схемы работы по часам — гибко реагировать на изменения бизнес и технических требований в процессе разработки проектов

Какие проекты требуют гибкого подхода?

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

Длительные проекты

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

Объемные проекты

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

Проекты с высокой долей неопределенности

Проекты, где на старте есть только общее описание. Детализация требований проводится в процессе работы над проектом. Появляются новые инсайты, планы.

Плюсы

1. Гибкость

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

2. Прозрачность

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

3. Оптимизация

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

Минусы

1. Отсутствие фиксированной стоимости.

2. Риск перерасхода времени и ресурсов.

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

3. Необходимость активного участия клиента.

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

• Клиент ставит задачи в рамках оплаченных часов*.
• В договоре нет жестко зафиксированного ТЗ.
• Нет конечных сроков и цен.
• Клиент с первого дня получает доступ к отчетам о выполненных задачах и расходе часов.

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

• Четкость терминов и ничего лишнего.
  

Для клиента в договоре только те базовые определения и термины, которые касаются моего процесса работы.

• Понятная структура.

Текст договора разбит на тематические пункты. Один пункт описывает конкретный этап или процесс работы. Так клиенту будет намного проще понимать как построен процесс. Материалы — отдельный пункт, мои контакты — отдельный пункт, как передается результат— отдельный пункт и так далее.

• Пункты размещены в порядке важности информации.

1. Определения
2. Предмет договора
3. Финансовые условия
4. Ответственное лицо
5. Сроки выполнения работ
6. Порядок выполнения работ
и так далее.

• Не перегружен ненужными смыслами, формулировками, дублированием пунктов, от слов-паразитов.

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

• Понятно описывает условия, схему и возможности работы

В договоре просто и понятно описано наше взаимодействие с клиентом. Описаны ситуации, которые могут возникнуть в процессе работы и дан ответ на них. Например:

— в какие сроки клиенту лучше дать обратную связь, чтобы проект не встал на паузу

— в какие сроки я смогу возобновить работу, если клиент пропадает на длительное время (все мы знаем, что такое бывает)

— в каких мессенджерах мы можем созваниваться

— куда и как я передаю результат работы

— где смотреть отчет о расходе часов

— кто получает доступ к этому отчету

и так далее.

Я периодически проверяю договор на актуальность и что-то правлю в нем.

Я не претендую на идеальность документа. В нем есть неточные некритичные (по словам юриста) юридические формулировки.

Я рекомендую при использовании договора адаптировать его под свои условия работы и юридический статус, проверить верность нумерации пунктов. И воспользуйтесь консультацией юриста для актуализации договора, лишнем не будет.

Надеюсь, статья была интересна и полезна. Буду рада слышать мнения коллег.

Спасибо за внимание!

Обо мне, моей работе, проектах и о том, что мне интересно в моем телеграм-канале Дизайнер на всю голову.