Выбор типа контракта для нового проекта

Решение

1. Рекомендуемый тип контракта: Time & Material (T&M)

Почему именно T&M, а не другие варианты:

Эта ситуация идеально подходит для T&M по нескольким причинам:

Фактор 1: Неопределённость требований

• Клиент имеет только "общее видение", нет детальных требований
• Мобильное приложение это сложный продукт с множеством unknowns
• Fixed Price в этом случае создаст риск недооценки (мы потеряем деньги)

Фактор 2: Желание контролировать процесс

• Клиент хочет "максимально контролировать разработку"
• T&M идеально подходит: он видит team, влияет на приоритизацию, может менять требования
• Fixed Price создаст конфликты: клиент захочет менять scope, мы скажем "это переделка, платите ещё"

Фактор 3: Готовность расширить бюджет на 20%

• Это сигнал что клиент гибкий и готов инвестировать в качество
• T&M это именно про то: платите за качество и результат, а не за обещание цены

Фактор 4: Стартап менталитет

• Стартапы обычно итерируют быстро, меняют направление
• Нужна гибкость T&M, а не жёсткость Fixed Price

2. Сравнение вариантов с обоснованием рисков

Вариант 1: Fixed Price (НЕ рекомендуется)

Что это значит:

• Мы оцениваем проект: "20,000 часов = 400,000 долларов"
• Клиент платит эту сумму, независимо от финального scope

Риски для нас (разработчика):

• Underestimation: стартапы часто расширяют требования. Если оценили на 20 часов, а надо 30, мы теряем 10 часов работы
• Scope creep: клиент сказал "А давайте ещё добавим..." Это change request, но клиент может не захотеть платить ещё
• Unknown unknowns: мобильные приложения непредсказуемы. Может потребоваться рефакторинг, интеграции, тестирование
• Client контроль: если клиент хочет контролировать, но мы заказали на Fixed Price, будет конфликт. "Почему я не могу изменить требования, я же платят?"
• Качество страдает: если мы в убытке, тема к сокращению scope и качества

Риски для клиента:

• Если смета 200к, клиент платит 200к even если проект закончится в 150k часов
• Может получить продукт плохого качества если мы режем корнеры

Вывод: Fixed Price только если требования 100% ясны и продукт простой. Здесь не подходит.

Вариант 2: Time & Material (РЕКОМЕНДУЕТСЯ)

Что это значит:

• Платите за реальные часы: $50/hour × фактические часы (или через dedicate team monthly fee)
• Scope может меняться
• Клиент видит что происходит, влияет на приоритеты
• Budget есть (например, "до 500k"), но гибкий

Плюсы для нас:

• Справедливо оплачиваемся за реальную работу
• Если требования растут, клиент платит за это
• Низкий риск убытков
• Можем предложить более high quality, без необходимости резать

Минусы для нас:

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

Плюсы для клиента:

• Платит только за реальную работу
• Может контролировать: видит что делается, может менять приоритеты
• Если проект заканчивается рано (мы эффективны), платит меньше
• Гибкость: не привязан к фиксированному плану

Минусы для клиента:

• Неопределённость цены: может стоить 300k или 500k
• Зависит от нас: если мы неэффективны, он платит больше
• Нужна дисциплина: без хороших процессов может стать дорогим

Вывод: Идеально для ситуации с неопределённостью и контролем.

Вариант 3: Dedicated Team (возможно, но с оговорками)

Что это значит:

• Клиент платит за team: "3 разработчика, 1 дизайнер = 100k/месяц"
• Team работает на него full time
• Scope и timeline гибкие

Плюсы:

• Это по сути T&M, но с месячной оплатой вместо hourly
• Клиент видит dedicated team, получает контроль
• Мы знаем доход (100k/месяц стабилен)
• Хорошо для long-term проектов

Минусы:

• Требует commitment: клиент должен быть готов 3+ месяца
• Expensive для стартапа
• Если требования маленькие, может переплачивать

Вывод: Может работать, но скорее всего клиент не готов платить 300k+ за 3 месяца. T&M flexible лучше.

3. Условия в контракте для защиты интересов

Секция 1: Цена и оплата

1. Hourly rate или team rate (выберете)

   • "Стоимость разработки: $65 за час (senior разработчик), $45 за час (junior)"
   • Или: "Dedicated team 1 senior + 1 mid: $12,000/месяц"

2. Budget cap с комментарием

   • "Estimated budget: $100,000-150,000 (на основе текущего scope)"
   • "Клиент уведомляется если использовано 80% бюджета"
   • "Дальнейшая работа обсуждается и одобряется письмом"

3. Трассируемость времени

   • "Все часы трассируются в Jira/Toggl с категоризацией (development, meetings, support)"
   • "Еженедельный отчёт о потраченных часах и remaining budget"

4. Процесс изменения scope

   • "Любое изменение требований, addition fiche, или уточнение должно быть:"

     - Согласовано письмом (email OK, но письменно)
     - Оценено временем ("это добавит 10 часов")
     - Одобрено клиентом перед началом работы

• "Без письменного approval, изменение не выполняется"

Секция 2: Управление требованиями и процесс

1. Kickoff и requirements gathering

   • "Фаза 1 (неделя 1-2): Requirements gathering и planning (макс 40 часов)"
   • "Deliverable: Product Requirements Document, user stories, timeline"
   • "Клиент одобряет PRD перед началом разработки"
   • "Изменения после одобрения PRD = change request"

2. Communication и доступность

   • "Клиент предоставляет primary contact (основной контакт) и backup"
   • "Response time: клиент отвечает на вопросы в течение 24 часов (рабочие дни)"
   • "Встречи: еженедельно понедельник 10:00 UTC (status, decision making)"
   • "Если клиент не отвечает >48 часов: время ставится на паузу (не чинится для bill)"

3. Итеративный процесс

   • "Разработка в спринтах по 2 недели"
   • "Демо каждый спринт (среда 14:00)"
   • "Feedback от клиента: max 2 дней"
   • "Доработки на основе feedback: включены в next sprint"

Секция 3: Риски и изменения

1. Unforeseen complexity
   • "Если во время разработки выявляется существенная сложность (архитектурные issues, платформенные ограничения и т.д.), которая не была видна на этапе planнинга:"

     - "PM информирует клиента"
     - "Обсуждаются варианты (дополнительное время? reduced scope?)"
     - "Решение документируется и подписывается"

1. Change requests

   • "Change request form: что меняется, почему, сколько часов"
   • "Процесс: PM -> developer estimate -> client approve -> execution"
   • "Emergency changes (critical bugs): обсуждаются в течение 4 часов"

2. Budget overruns

   • "Если текущий спент + estimate для завершения превышает budget на >10%:"

     - "Клиент уведомляется immediately"
     - "Опции: сокращение scope, расширение бюджета, или pause"
     - "Без письменного согласия, work stops"

Секция 4: Качество и дефекты

1. Testing и QA включены

   • "Все часы для тестирования, bug fixing, code review = включены в budget"
   • "Не есть extra costs"

2. Defect priority

   • "Critical: data loss, security, app crash - fixed within 24 hours"
   • "High: major feature broken - fixed within 48 hours"
   • "Medium: minor feature issue - fixed within 1 sprint"
   • "Low: cosmetic - backlog"

3. Warranty period

   • "После launch: 30-day warranty (critical bugs fixed for free)"
   • "После 30 дней: support контракт отдельно"

Секция 5: Интеллектуальная собственность

1. Code ownership

   • "Весь исходный код, designs, и документация = собственность клиента"
   • "После полной оплаты: repo, documents, design files переданы клиенту"

2. Our rights

   • "Мы можем использовать код/технологии в своих projects (sanitized, без вашего кода)"
   • "Мы можем добавить в portfolio как case study (с your approval)"
   • "Не раскрываем детали других клиентов"

Секция 6: Termination и выход

1. Termination by client

   • "Может прекратить контракт в любой момент с 2-week notice"
   • "Платит за все часы до даты termination"
   • "Получает доступ ко всему коду и документации"

2. Termination by us

   • "Редко, но: если клиент не платит 30 дней, project suspends"
   • "Или если клиент нарушает условия контракта (e.g., no communication >2 weeks)"

3. Knowledge transfer

   • "При termination: 40 часов knowledge transfer (онбординг нового team)"
   • "Включено в project если termination по нам"
   • "Extra часов если termination по клиенту и он хочет больше"

Секция 7: Rate и timeline

1. Rate escalation

   • "Если проект >6 месяцев: rate может переоцениваться каждые 6 месяцев (макс +5% за инфляцию)"
   • "Обсуждается и согласуется отдельно"

2. Deadline

   • "Estimated deadline: [дата] для MVP"
   • "Это estimate, не guarantee"
   • "Зависит от:"

     - "Доступности клиента для feedback"
     - "Stability требований"
     - "Unforeseen technical issues"

• "Каждый спринт: updated estimate для remaining work"

4. Структура предложения клиенту

Email/proposal:

"На основе вашего описания, мы рекомендуем Time & Material модель. Вот почему:

За:

• Требования ещё не ясны, T&M даёт гибкость
• Вы можете контролировать: видеть team, влиять на приоритеты
• Платите только за реальную работу, не переплачиваете
• Если результат лучше быстро, платите меньше

Рекомендуемая структура:

• Неделя 1-2: Requirements & planning (включено 40 часов)
• Неделя 3+: Разработка в спринтах
• Бюджет: $100-150k (estimate на основе typical mobile app)
• Team: 1 senior + 1 mid разработчик, part-time дизайнер
• Еженедельные демо и update

Защита для вас:

• Все требования документируются
• Изменения = change request (оценка + approval)
• Budget alert на 80%
• Трассирование времени

Защита для нас:

• Справедливая оплата за реальную работу
• Риск управляется через process
• Возможность расширить budget если needs растут

Давайте начнём с requirements gathering (2 недели). Потом будет clearer timeline и budget."

Итог

Time & Material это правильный выбор для стартапа с неопределёнными требованиями, который хочет контролировать процесс. Контракт должен защитить обе стороны через ясные процессы change management, трассирование времени, и регулярную коммуникацию. Это создаёт доверие и partnership mindset, не adversarial.