Штатная команда: когда все свои

Первый пост (и очень длинный) из серии про типы команд. Начну с классики — все в одной компании/группе компаний, один работодатель.

Кажется, это идеальная модель. На практике штатная команда даёт вещи, которые сложно получить в других моделях.

Но у любой модели есть цена. Хотя если команда распределённая — часовые пояса и доступы догонят и тут.

Сначала плюсы)

Всё внутри. Кодовая база, документация, архитектурные решения, экспертиза по продукту принадлежат компании. Единые стандарты качества, CI/CD и инфраструктура под контролем. Решения принимаются быстрее — не нужно согласовывать изменения с внешним подрядчиком. И команда живёт с последствиями своих решений поэтому техдолг не копится бесконтрольно.

Безопасность коммуникации. Вся переписка по продукту — внутри корпоративных средств. Меньше риск утечки, проще контролировать доступы.

Единая среда. Корпоративные мероприятия, общие стандарты разработки, одинаковые праздники и выходные. Снижает трение в ежедневной работе т.к. одни правила для всех.

Долгий и глубокий контекст. Нет резкого переключения между проектами — человек живёт в продукте месяцами. Но дело не только в коде. Корпоративная среда даёт понимание, для кого ты строишь. Я однажды ездила на площадку добычи нефти помогать проводить конкурс профмастерства. После того как познакомилась с мастерами, которые каждый день работают с планшетами — фраза «проектируем интерфейс под крупные руки операторов» перестала быть абстракцией. Всегда есть контекст, который сложно передать в ТЗ. (фото с той самой поездки. 2018г.)

Предсказуемость. Известна скорость каждого члена команды, кто в чём силён, можно планировать спринты точнее. Справедливости ради — в долгосрочных смешанных командах это тоже нарабатывается, но в штатных командах происходит быстрее.

Еще один бонус — имя компании. Правда, не у всех оно работает как магнит для найма, но если работает — закрывать позиции кратно легче.

Менторинг, обучение, рост грейдов — всё это имеет смысл, потому что человек остаётся в компании. По крайней мере, вероятность сохранить сотрудника выше. Риск «научился и ушёл» есть всегда, но в внутри компании есть возможность повлиять на среду, которая удерживает — от корпоративного обучения и ДМС до нематериальных вещей вроде причастности к продукту.

Но у инхауса есть своя цена.

Зависимость. Если ключевой человек уходит — уходит и контекст. Чем глубже погружение, тем больнее потеря.

Стоимость. Штатная команда — это не только зарплаты, это налоги, ДМС, оборудование, обучение. Для бизнеса это долгая инвестиция, и не каждый проект её оправдывает.

Скорость масштабирования. Нужно ещё два разработчика на следующий месяц? Это найм, онбординг и 2–4 месяца до продуктивности. В других моделях может быть быстрее (при определенных обстоятельствах).

А так же наличие штатных разработчиков не гарантирует качество кода. Если процесс ревью слабый/отсутствует, а грейды не калиброваны, то качество будет плавать независимо от модели команды.

Штат — это фундамент. Но фундамент работает, когда на нём строят осознанно, а не “как пойдет”.

Следующий пост будет про смешанные команды, где штатные разработчики и подрядчики работают бок о бок.

Какая у вас модель? Полный инхаус, миксуете или полный аутсорс?