Как ты различаешь коммерческий проект и продуктовый проект?

Как я различаю коммерческий проект и продуктовый проект?

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

Определения

Коммерческий проект (Commercial/Client project):

• Решение, разработанное ДЛЯ конкретного клиента
• Финансируется клиентом (обычно на основе контракта)
• Сроки и требования фиксированы в начале
• Данные и инфраструктура принадлежат клиенту

Продуктовый проект (Product):

• Решение, разработанное компанией ДЛЯ себя (в т.ч. для продажи)
• Развивается итеративно, без фиксированного конца
• Требования меняются на основе feedback пользователей
• Данные и инфраструктура компании

Различия в подходе

1. Жизненный цикл

Коммерческий проект:

Фаза 1: Планирование (неделя)
  - Сбор требований от клиента
  - Оценка объёма и сроков
  - Подписание контракта

Фаза 2: Разработка (3 месяца)
  - Реализация по требованиям
  - Регулярные встречи с клиентом
  - Change requests требуют переговоров

Фаза 3: Тестирование и приёмка (месяц)
  - User Acceptance Testing (UAT) клиентом
  - Фиксы багов из UAT
  - Подписание акта выполнения

Фаза 4: Развёртывание (неделя)
  - Миграция данных клиента
  - Обучение пользователей
  - Переход на поддержку

После этого → новый проект

Продуктовый проект:

Итерация 1 (2 недели):
  Планирование → Разработка → Тестирование → Релиз → Мониторинг → Feedback
     ↓
Итерация 2 (2 недели):
  Планирование → Разработка → Тестирование → Релиз → Мониторинг → Feedback
     ↓
... продолжается вечно ...

2. Требования

Коммерческий:

НЕ ясно в начале → Собираем → Фиксируем → Разрабатываем

Требование: "Система должна обработать 10,000 юзеров"
Если в процессе выясняется: "На самом деле 100,000"
→ Это change request, требует дополнительного финансирования
→ Может повлиять на сроки

Продуктовый:

Минимум жизнеспособного продукта (MVP) → Выпускаем → Слушаем пользователей
→ Планируем улучшения → Выпускаем следующее

В начале выпускаем для 10,000 юзеров
Если спрос больше: "Окей, масштабируем инфраструктуру за неделю"
→ Нормальная ситуация, заложено в roadmap

3. Архитектура и качество кода

Коммерческий проект:

# Код должен быть:
- Clean Code (легко читать и модифицировать клиенту)
- Хорошо документирован (клиент будет поддерживать)
- Testable (в т.ч. для UAT)
- Extensible (может возникнуть change request)

# Архитектура:
- По требованиям клиента (иногда неоптимальная)
- Например: клиент просит хранить всё в 1 таблице SQL
  вместо нормализованной БД
- Нельзя отказать без good reason

Продуктовый проект:

# Код может быть:
- Pragmatic (YAGNI — You Ain't Gonna Need It)
- Fast to iterate (главное работает, не идеально)
- Refactorable (знаем что change на основе feedback)

# Архитектура:
- По стратегии компании
- Микросервисы, monolith, serverless — выбираем сами
- Например: в начале простой Python скрипт
  → При масштабировании → переходим на Spark
  → Никто не возражает, это наша инфраструктура

4. Финансирование и бюджет

Коммерческий:

Бюджет фиксирован в контракте: $500,000

Планирование: 20% → Разработка: 60% → Тестирование: 15% → Резерв: 5%

Если потратили 60% бюджета, а покрыли только 40% требований
→ Проблема: либо сокращаем scope, либо просим дополнительные деньги
→ Конфликт с клиентом

Продуктовый:

Бюджет ежеквартально: $1M на всю инжиниринг команду

Распределение: 30% новые фичи, 50% масштабирование, 20% tech debt

Если фича занимает больше, чем ожидали:
→ Перепланируем спринт
→ Сдвигаем roadmap
→ Никакой критической проблемы

5. Данные и ownership

Коммерческий:

Данные = собственность клиента

- Не можем использовать для обучения моделей
- Не можем публиковать case studies без одобрения
- Должны выполнять требования безопасности клиента
- После проекта: миграция данных в их систему

Продуктовый:

Данные = собственность компании

- Можем использовать для аналитики и ML
- Публикуем case studies и metrics
- Следуем своим стандартам безопасности
- Данные остаются в нашей инфраструктуре

Таблица сравнения Data Engineer подхода

Практические примеры

Коммерческий пример: Интеграция CRM для крупной сети магазинов

Требование: "Интегрировать Salesforce в наш локальный data warehouse"
График: 6 месяцев, $200k
Данные: 10 лет истории клиентов (очень чувствительные)

Мой подход:
1. Детальная спецификация (2 недели)
   - Какие данные? (contacts, opportunities, accounts)
   - Какая частота? (ежедневная синхронизация)
   - Какие ограничения на стороне клиента? (legacy БД, медленный API)

2. PoC на тестовых данных (3 недели)
   - Покажу что работает перед полной разработкой
   - Согласую архитектуру

3. Полная разработка с milestone'ами (16 недель)
   - Каждые 2 недели демо клиенту
   - Change requests документируются

4. UAT с клиентом (4 недели)
   - Клиент тестирует с реальными данными
   - Я fixing'ю баги

5. Go-live и поддержка (8 недель)
   - Помогаю пользователям
   - Фиксю production issues

Продуктовый пример: Real-time analytics платформа для стартапа

Миссия: "Дать нашим клиентам видеть метрики в real-time"
Бюджет: 30% инжиниринг бюджета на Q1 (непрерывно)

Мой подход:
Спринт 1 (2 недели):
  - MVP: 10 метрик, 1 час задержка
  - Развертываем на 100 бета-клиентах
  - Feedback: "Хотим 15 минут задержку"

Спринт 2:
  - Переходим с batch processing на streaming (Kafka)
  - Задержка: 15 минут
  - Feedback: "Хотим real-time (< 1 минута)"

Спринт 3:
  - Архитектура: Kafka → Flink → in-memory cache (Redis)
  - Real-time метрики, красивый dashboard
  - Feedback: "Супер! Но нужно 50 новых метрик"

Спринт 4: Добавляем новые метрики...
... и никогда не остановимся ...

Как я выбираю подход на практике

Коммерческий проект → когда:

• Клиент платит за конкретное решение
• Требования ясны и фиксированы
• После проекта не нужна поддержка
• Данные чувствительные/конфиденциальные

Продуктовый проект → когда:

• Развиваем собственный продукт
• Требования эволюционируют
• Долгосрочная инвестиция компании
• Нужна поддержка и развитие

Навыки, специфичные для каждого

Коммерческий:

• Переговоры и управление expectations
• Управление scope (что in, что out)
• Документирование requirements
• Contract knowledge
• Client communication

Продуктовый:

• Product thinking (не только technical)
• Analytics и metrics (успех измеримый)
• Agile methodology
• Leadership и mentoring
• Long-term technical vision

В своей карьере я предпочитаю продуктовые проекты потому что:

1. Больше технической свободы
2. Долгосрочное воздействие
3. Можно видеть результаты использования
4. Менше политики с клиентом

Но коммерческие проекты ценны за:

1. Разнообразие (каждый клиент новый)
2. Финансовый стимул (контракты больше)
3. Опыт работы с different tech stacks
4. Переговорные навыки