Завершение проекта — ответственный этап, на котором важно корректно передать результаты работы. Разберём ключевые моменты передачи продукта клиенту, включая юридические и технические аспекты.
1. Что именно передаём? Два состояния продукта
🔹 Исходный код
Это "сырые" файлы проекта, которые включают:
- Логику приложения (основной код)
- Стили и визуальные компоненты
- Инструкции по сборке (README, документация)
Как передать:
✔️ Через репозиторий (GitHub/GitLab/Bitbucket) — даём доступ или делаем архив
✔️ На физическом носителе (флешка, диск) — если требуется по договору
✔️ В облачном хранилище (Google Drive, Dropbox)
🔹 Готовое приложение
Это собранная версия продукта, готовая к использованию:
- EXE-файлы (для десктопных программ)
- APK/IPA (для мобильных приложений)
- Деплой на сервере (веб-приложения)
Как передать:
✔️ Размещение на сервере клиента (FTP, SSH)
✔️ Загрузка в магазины приложений (App Store, Google Play)
✔️ Передача установочного файла
2. Где прописываются условия передачи?
Важные пункты договора:
✅ Формат передачи (исходники, сборка или оба варианта)
✅ Способ доставки (репозиторий, носитель, деплой)
✅ Сроки и этапы (если передача частями)
✅ Права на код (лицензия, возможность модификации)
Пример формулировки:
"Исполнитель обязуется передать исходный код проекта через репозиторий GitHub в течение 3 рабочих дней после подписания акта. Готовая сборка размещается на сервере Заказчика по предоставленным credentials."
3. Пошаговая инструкция по передаче
Шаг 1. Подготовка
- Убедитесь, что код чистый (удалены тестовые данные, комментарии)
- Проверьте документацию (как запустить, зависимости)
- Соберите финальную версию приложения
Шаг 2. Упаковка
- Для исходников: создайте архив (ZIP) или настройте доступ к репозиторию
- Для приложения: подготовьте установочные файлы
Шаг 3. Передача
- Отправьте файлы с подтверждением (письмо с ссылкой/чеклистом)
- Если через репозиторий — добавьте клиента в collaborators
Шаг 4. Подписание документов
- Акт приёма-передачи (с описанием переданных файлов)
- Инструкция по эксплуатации (если требуется)
4. Частые ошибки (и как их избежать)
❌ Нет документации → Клиент не сможет разобраться в коде
✅ Решение: Добавьте README с описанием структуры и сборки
❌ Неочищенный код → Лишние файлы увеличивают размер и путают
✅ Решение: Используйте .gitignore, удалите временные файлы
❌ Нет тестовой сборки → Клиент обнаруживает баги после принятия
✅ Решение: Передавайте вместе с собранной версией для проверки
5. Дополнительные рекомендации
🔸 Резервная копия
Храните у себя копию на случай спорных ситуаций (но учтите NDA).
🔸 Видеоинструкция
Запишите скринкаст, как развернуть проект — это сэкономит время на поддержку.
🔸 Post-release поддержка
Обсудите сроки, в течение которых готовы отвечать на вопросы.
Итог: Передача продукта — финальный, но критичный этап. Чем детальнее пропишете условия в договоре и подготовите материалы, тем меньше недопонимания возникнет на завершающей стадии.
Виды поддержки IT-продуктов: гарантия, сопровождение и развитие
После сдачи проекта работа с клиентом часто продолжается. Разберём три основных вида пост-релизной поддержки, которые помогают поддерживать продукт в рабочем состоянии и развивать его.
1. Гарантийное обслуживание: исправляем ошибки бесплатно
Что это:
Обязательная поддержка, при которой исполнитель устраняет критические баги, обнаруженные после сдачи проекта.
Ключевые особенности:
✔ Сроки: от 1 месяца (для небольших проектов) до 1 года (для сложных систем)
✔ Какие баги покрываются: только блокирующие и критические (по классификации из договора)
✔ Сроки исправления: обычно до 3 рабочих дней
✔ Важно: гарантия не распространяется на:
- Проблемы, вызванные действиями клиента
- Внешние факторы (аварии, катаклизмы)
- Изменения, внесённые в код сторонними разработчиками
Финансовые условия:
🔹 Бесплатно для клиента (в рамках оговорённых багов)
🔹 Гарантийный период продлевается на время исправления
2. Техническое сопровождение: поддерживаем работоспособность
Что это:
Платная услуга по поддержанию продукта в рабочем состоянии, когда у клиента нет своей технической команды.
Типичные задачи:
🔧 Мониторинг работоспособности
🔧 Восстановление после сбоев
🔧 Обновление контента (для сайтов)
🔧 Резервное копирование данных
🔧 Консультации через выделенные каналы связи
Организационные моменты:
✔ Оформляется отдельным договором
✔ Фиксированная ежемесячная стоимость
✔ Чёткие SLA (время реакции, часы поддержки)
✔ Не включает разработку новых функций
3. Развитие продукта: улучшаем и масштабируем
Что это:
Доработка продукта по новым требованиям клиента после запуска.
Когда нужно:
🔄 Добавление новых функций
🔄 Изменение дизайна
🔄 Создание маркетинговых материалов (баннеры, презентации)
🔄 Масштабирование системы
Как организовано:
✔ Работа по модели Time & Material
✔ Оплата за фактически затраченное время
✔ Оформляется дополнительным соглашением
✔ Гибкий процесс согласования задач
Сравнительная таблица видов поддержки
Советы по организации поддержки
- Чётко прописывайте условия в договоре:
Какие баги покрываются гарантией
Время реакции на запросы
Порядок приоритизации задач - Используйте системы учёта:
Jira, Redmine или аналоги для трекинга багов
SLA-мониторинг для технического сопровождения - Предлагайте пакеты поддержки:
Базовый (только критические проблемы)
Стандартный (+ контент-поддержка)
Премиум (24/7 мониторинг) - Автоматизируйте процессы:
Автотестирование перед обновлениями
Системы автоматического бэкапа
Помните: Качественная пост-релизная поддержка — залог долгосрочных отношений с клиентом и источник дополнительного дохода!
📌 Какой вид поддержки чаще всего востребован у ваших клиентов? Делитесь опытом в комментариях!