---
# System prepended metadata

title: Инсорсинг МП Спортмастер

---

# Инсорсинг МП Спортмастер

## ЦЕЛИ
- Сделать процесс работы с задачами в Jira более прозрачным (сбор метрик, понимание сильных и слабых сторон команды, возможность их улучшать)
- Получить экспертизу на свой стороне для принятия технических решений в части разработки (стэк, архитектура, тех. практики, ci, самостоятельная разработка)
- Развивить и усилить внутреннюю разработку (увеличить количество проектов с целью удержания разработчиков в компании и облегчения найма)
- Стать более конкрутноспособным как работодатель - Спортмастер Лаб
- Ускорение поставки ценностей за счет сокращения участия менеджеров на стороне подрядчика
- Наладить процесс сопровождения и работы с багами
- Привести приложение к техникам и практикам в соответствии со стандартами компании (внедрить практику регулярной проверки приложения по чек листам от центров компетенций)
- Снизить риски зависимости от подрядчика

## Процессы
- Сделать процесс работы с задачами более прозрачным, а поставку более предсказуемой. Все этапы разработки будут контролироваться нами, будут сниматься метрики по этапу разработки.
- Проводить совместное проектирование решений с участием разработчиков

## Экспертиза
- удерживать экспертизу на свой стороне для принятия решений об архитектурных решений
- развивать и усиливать внутреннюю разработку

### Многомодульность и мульти командность
- Многомодульность и многокомандность на текущий момент могут только усложнить разработку и поставку ценности на прод. Мы не знаем в деталях процесс разработки внутри команды ХХ. Дополнительная команда/отдельные модули потребуют "склейки" процессов ХХ и другой команды.
- дополнительным риском является неоднозначность поставки артефактов модулей, а так же их процесс развития
- сложность определения границ конретного модуля и его зависимостей от других

## Jira
- задачи должны вестись у нас
- флоу можно подстраивать, но ограничено общим процессом (потоком со всеми участниками)

## Confluence
- документация на код должна вестись у нас
- документация контрактов (бек-фронт) должен быть описан

## GitLab
- пайплайн разработки, автоматической сборки, автоматических тестов и деплой должен быть настроен на нашей стороне
- гит флоу должно быть понятно описано и соотвествовать пайплайну сборки
- Заменить доступ уровня Maintainer у подрядчиков на Developer 

### CI
- залоченые ветки для сборки: "dev" (тестовое окружение), "rc" (продуктовое окружение). Изменения можно залить только через pull request
- наличие автотестов (определить % покрытия)
- ветка "master" под вопросом (не факт что нужна)
- с соответсвенной залоченной ветки происходит автоматическая сборка при создании pull request. без успешного прохождения автотестов - ревью проводить нельзя


## План инсросинга 
- Договориться про аутстаф (аутсорс) с возможностью добавлять своих людей в команду.
При организации команды возможно оставить режим привленяения подрядчика как аутсорс + минимальный менеджмент (РП). Но добавить возможность добавлять своих людей в команду.
- Перевести разработку и ведение задач в нашу Jira
- Перевести разработку кода и настроить Pipeline в нашем GitLab
- Спроектировать минимальный и целевой состав команды
- Открыть вакансии и начать найм


```
ПРИМЕЧАНИЕ!!!
- На период инсорсинга не пытаемся настроить мультикомандную и мультимодульную разработку! Переводим разработку как есть.
- При найме своих людей отключение подрядчиков от продукта будет осуществляться через 2 мес после прохождения испытательного срока внутреннего сотрудника
- Вопрос мультикомандной разработки будет решаться позже после появления экспертизы у внутренних разработчиков МП Спортмастер (условие набор достаточного количества людей + обсужление вопроса через 1 год после старта инсорсинга)
- В целевой картине освная разработка должна вестись собственными силами, минимум 75% - внутренние сотрудники, остальную потребность в ресурсах можно покрывать подрядчиками 
```


