Когда компании нужно больше инженерных мощностей, чем она успевает нанять, она обычно рассматривает три модели: усиление команды (staff augmentation), выделенную команду или управляемую разработку (managed delivery). Подрядчики используют эти названия вольно, и один и тот же договор может описывать совсем разное устройство повседневной работы. Названия важны меньше, чем два вопроса: кто направляет работу и кто отвечает за результат.
Ответьте на них, и остальное станет ясно: что должны предоставить вы, что должен предоставить партнёр и как такое сотрудничество, скорее всего, пойдёт не так.
Кто направляет работу, кто отвечает за результат
Расположим три модели на одной линии.
- Усиление команды. Вы направляете работу и отвечаете за результат. Партнёр предоставляет инженеров.
- Выделенная команда. Вы задаёте направление и приоритеты и отвечаете за результат продукта. Команда сама организует повседневную работу и отвечает за качество того, что поставляет.
- Управляемая разработка. Вы согласуете результат и ограничения. Партнёр планирует, направляет и выполняет работу и отвечает за итог.
Двигаясь вдоль этой линии, вы отдаёте повседневный контроль и берёте на себя меньше управленческой нагрузки. Ни один край не лучше другого. Правильная точка зависит от того, сколько у вас инженерного руководства и насколько ясно вы можете сформулировать, чего хотите.
Усиление команды
При усилении команды отдельные инженеры входят в вашу существующую команду. Они приходят на ваши стендапы, работают в вашем трекере, следуют вашим стандартам кода и подчиняются вашему руководителю разработки или техлиду. Изнутри они выглядят как коллеги, у которых просто другой работодатель.
Это хорошо работает, когда:
- У вас уже есть работающая команда, процесс и техническое руководство.
- Не хватает мощностей или конкретного навыка, а не направления.
- Работа постоянная и разнородная, а не отдельный проект с чёткими границами.
Что нужно от вас: лид, который может распределять задачи, ревьюить код и быстро отвечать на вопросы; документация для онбординга или человек, который его проводит; доступ ко всему, чем пользуются ваши собственные инженеры. Привлечённые инженеры наследуют ваш процесс, а значит, и его пробелы.
Выделенная команда
Выделенная команда устроена как полноценное подразделение (инженеры и обычно тимлид, QA, а иногда дизайнер или бизнес-аналитик), которое работает над вашим продуктом полный рабочий день. Вы задаёте приоритеты и принимаете результаты. Команда сама ведёт поставку: планирование, оценку, ревью кода, тестирование и релизы.
Это хорошо работает, когда:
- У вас есть продукт или понятная его часть, которую можно передать, например новый модуль, мобильное приложение или миграция платформы.
- Вы можете выделить владельца продукта, который задаёт приоритеты и доступен команде, но не хотите управлять инженерами по отдельности.
- Работа продлится много месяцев и выиграет от стабильной команды, которая накапливает знания.
Что нужно от вас: владелец продукта с полномочиями, понятная зона ответственности и согласованный порядок отчётности. Команда должна регулярно показывать работающее ПО, а вы должны видеть её бэклог, скорость и проблемы, не спрашивая о них.
Управляемая разработка
При управляемой разработке вы и партнёр согласуете результат, например первый релиз с определённым объёмом, завершённую миграцию или процесс, который работает быстрее на согласованную величину, а также ограничения: диапазон бюджета, сроки, стандарты. Дальше партнёр решает, как к этому прийти: состав команды, последовательность, технический подход. Вы оцениваете результаты, а не задачи.
Это хорошо работает, когда:
- У вас нет собственного инженерного руководства или оно полностью занято другим.
- Цель можно описать и измерить.
- Вы хотите, чтобы за её достижение отвечала одна сторона.
Что нужно от вас: ясное определение результата и того, как он будет измеряться, быстрые решения, когда они нужны партнёру, и готовность услышать, что часть плана стоит изменить. Управляемая разработка проваливается, когда результат размыт, потому что тогда никто не может сказать, достигнут ли он.