Что знаешь о формате работы по контракту?

Работа по контракту (Contract Development)

Имею опыт как контрактного разработчика. Это существенно отличается от работы в штате и требует особого подхода.

Различия между контрактом и штатом

# Сравнение моделей
comparison = {
    "штат": {
        "commitment": "Долгосрочный (годы)",
        "scope": "Эволюция продукта, владение системой",
        "responsibility": "За качество и maintenance",
        "compensation": "Зарплата + бонусы + benefits",
        "predictability": "Высокая",
        "risk": "Разделён с компанией",
        "learning_curve": "3-6 месяцев для full productivity"
    },
    "контракт": {
        "commitment": "Краткосрочный (недели-месяцы)",
        "scope": "Конкретные фичи или проекты",
        "responsibility": "За delivery в срок",
        "compensation": "Почасово или за проект",
        "predictability": "Средняя (может быть scope creep)",
        "risk": "На подрядчике",
        "learning_curve": "1-2 недели"
    }
}

Типы контрактов

1. Time & Materials (T&M)

• Оплата за часы работы
• Более гибко для непредсказуемых задач
• Клиент платит за actual effort

# Пример расчета
hourly_rate = 100  # $100/hour
weekly_hours = 40
months = 3

total_cost = hourly_rate * weekly_hours * 4 * months
# $48,000

2. Fixed Price (проектная модель)

• Согласованная сумма за весь проект
• Риск на подрядчике если скоп разрастается
• Нужно точная оценка

# Пример
project_estimate = 800  # 800 часов
hourly_rate = 100
fixed_price = project_estimate * hourly_rate
# $80,000

# Но если задач больше чем ожидал:
# Работаю на себя, не получу дополнительно

3. Retainer (абонентское обслуживание)

• Фиксированная сумма в месяц
• Ограниченное количество часов
• Хорошо для долгосрочной поддержки

# Пример
monthly_retainer = 5000
hours_per_month = 40  # 40 часов включены
extra_hour_rate = 150  # За часы сверх

Мой подход к контрактной работе

Фаза 1: Discovery (первая неделя)

requirements = {
    "business_goals": "Чего хочет клиент достичь?",
    "technical_constraints": "Какие системы нужно интегрировать?",
    "timeline": "Когда нужно?",
    "acceptance_criteria": "Как узнаём что готово?",
    "communication": "Кто owner? Как часто встречаемся?",
    "change_requests": "Как обрабатываем изменения требований?"
}

# Важно ДОКУМЕНТИРОВАТЬ и уточнять в начале
# Это спасает от disputes в конце

Фаза 2: Оценка и contracting

# Мой процесс оценки
estimation = {
    "optimistic": 40,      # часов, best case
    "realistic": 60,       # hours, most likely
    "pessimistic": 100,    # hours, worst case
    
    # Formula: (O + 4*R + P) / 6
    "estimated": (40 + 4*60 + 100) / 6,  # ~63 часа
    
    # Добавляю буфер 20%
    "with_buffer": 63 * 1.2,  # ~76 часов
    
    # Даю диапазон
    "quote": "70-80 часов (или $7,000-8,000)"
}

# Важно: НИКОГДА не даю точное число
# Диапазон даёт гибкость

Фаза 3: Контракт и terms

contract_terms = {
    "scope": "Очень подробное описание того что включено",
    "exclusions": "Что НЕ включено (важно!)",
    "timeline": "Дата старта, дата сдачи",
    "payment_schedule": "50% вперёд, 50% при приёмке",
    "change_process": "Как обрабатываем scope creep",
    "acceptance": "Что значит 'готово'?",
    "support": "Как долго даю support?",
    "ip_rights": "Кому принадлежит код?",
    "nda": "Confidentiality clauses"
}

Scope Creep: главный враг

Как я защищаюсь

# ПРОБЛЕМА: Клиент в день 5 просит новую фичу
# "Пока делаешь, добавь и это тоже"

# МОЙ ПОДХОД:
process = """
1. Документирую исходный scope в контракте
2. Соглашаюсь добавить новое только:
   - Если это 5 минут (не считаю)
   - Если клиент согласен:
     a) Сдвинуть дату
     b) Добавить бюджет
     c) Убрать что-то из исходного scope
3. Всё в письме (слэк, имейл)
   - Ясная коммуникация спасает от споров
"""

Пример диалога

Клиент: "А можешь ещё добавить интеграцию с Stripe?"

Мой ответ:
"Конечно! Это займёт примерно 8-10 часов.
О как мы хотим действовать?

Вариант 1: Сдвинуть deadline на неделю
           (было готово 15 марта, теперь 22 марта)

Вариант 2: Добавить в бюджет $1,000
           (было $7,000, теперь $8,000)

Вариант 3: Убрать email notifications из исходного scope
           (экономит 8 часов, интеграция займёт их место)

Что тебе подходит?"

Практические советы

1. Communication

# Ежедневные standup: даже если 10 минут
# Это спасает от surprises в конце

# Еженедельный review:
weekly_update = {
    "completed": ["Задача 1", "Задача 2"],
    "in_progress": ["Задача 3 (80% done)"],
    "blockers": ["Ждём API документацию"],
    "next_week": ["Планируем Задачу 4 и 5"],
    "estimated_completion": "22 марта (на расписании)"
}

2. Version Control и Documentation

# Git репозиторий с clear commit messages
git log --oneline
# 5f3a2b1 Add Stripe integration
# 3e2c1b0 Implement email notifications
# 2d1a0b9 Fix user authentication bug

# README с инструкциями по деплою
# Code comments для complex logic

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

# Даже если клиент не просил тесты
# Я пишу их потому что:
# 1. Гарантирую качество
# 2. Просто доказать что работает
# 3. Не нужно ручное тестирование в конце

# Минимум: Unit tests
import pytest

def test_stripe_integration():
    result = charge_card(amount=100, card=test_card)
    assert result["status"] == "success"

4. Billing и Invoicing

# Если T&M: Отслеживаю часы
from datetime import datetime, timedelta

work_log = {
    "day_1": {"date": "2024-03-01", "hours": 8, "task": "Setup & API integration"},
    "day_2": {"date": "2024-03-02", "hours": 7.5, "task": "Stripe implementation"},
    "day_3": {"date": "2024-03-03", "hours": 5, "task": "Tests & debugging"},
    # ...
    "total": 72  # часов
}

# Invoice: 72 hours × $100/hour = $7,200

5. После проекта

# Handover:
# - Развернул на prod
# - Показал как менять (training)
# - Документ с инструкциями
# - 2 недели поддержки

# Получаю feedback:
feedback = {
    "what_went_well": "Быстро исправлял баги",
    "what_could_improve": "Хотел бы больше visibility на ход работы",
    "would_hire_again": True
}

# Это нужно для следующего контракта

Когда контракт имеет смысл

Хорошо для контракта:

• Конкретная фича или интеграция
• Временное увеличение capacity
• Специализированный знаток (DevOps, ML)
• Pilot проект перед наймом

Плохо для контракта:

• Долгосрочная разработка продукта
• Критичные части архитектуры
• Требует глубокого знания legacy кода

Итог

Ключь к успешному контракту:

1. Чёткий scope в начале
2. Честная коммуникация о progress
3. Документирование всех changes
4. Качественный код как proof
5. Graceful exit с хорошей handover

В России популярны платформы: Upwork, Freelance.ru, HH.ru (только freelance).