Как мы пересмотрели подход к аутсорсу внутри компании

Семь лет назад я основал аутсорс-компанию «Волга-Волга» (vvdev). Первое время мы активно развивали штатную команду в Нижнем Новгороде — и выросли до 30+ разработчиков. Мы всегда делали акцент на качестве и доводили проекты до релиза, и за счет этого у нас рос поток проектов по «сарафанке». А благодаря тому, что мы не вкладывались в маркетинг при низкой ставке, нам удалось сохранить маржинальность.

За время существования компания накопила много кейсов, а самое главное — опыта. Мы успели запустить проекты с крупнейшим ритейлером в РФ, поддерживали большие сайты и корпоративные порталы. Но все же мы столкнулись с проблемами: отдел разработки надо было масштабировать, а при росте офиса росли затраты на менеджмент и содержание. Искать программистов в офис в регионе становилось все труднее. Банки начали активно хантить сотрудников по московским зарплатам.

Что делать? Мы решили превратить наш опыт в продукт и сместить акцент с аутсорса. Начали эксперименты: делали продукты, потому что умели — несмотря на отсутствие опыта в маркетинге и десяти неудачных проектов. Как итог нам удалось найти два подходящих направления: Экосистема для ритейла (рабочее место кассира, логиста, курьера, упаковщика, менеджера заказов) и CPA сеть. Если будет интересно — напишу об этом в следующих статьях.

Создав эти два направления, мы заметили, что поток клиентов на заказную разработку продолжает расти. Стало очевидно: закрывать аутсорс нельзя, нужно придумать механику работы заново.

Что мы имели:

Необходимо было выстраивать удаленный формат работы, не теряя при этом производительность и качество, а также слаженность команды при запуске проектов.

Скажу сразу: нам не близок формат работы с удаленщиками, так как хорошие и ответственные ребята стоят дорого. В аутсорсе сохранить адекватную коммерческую ставку при этом кажется нереально. Я не имею в виду, что не надо нанимать таких людей — для продуктов это вполне себе хороший формат. Но на мой взгляд не для аутсорса.

Мы нашли выход — поиск небольших команд до пяти человек, работающих вместе. Это решало часть проблем быстрой коммуникации, контроля времени, обучения, а для нас упрощало масштабирование.

Кроме того, траты на поиски таких команд не сильно больше, чем на поиски хороших разработчиков.

Мы не надеялись, что просто найти команды будет достаточно, так как с этим начинается рост зоопарка решений. Вместе с поиском мы стали активно работать над созданием технических регламентов.

На текущий момент мы работаем в узком стеке: node js, React, React Native. Это упрощает контроль качества, но усложняет поиск команд. Кроме ограничения стека мы стали строить единый процесс управления и контроля проекта. Основные его пункты:

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

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

Да, разработчики приносили работающий проект, но, имея опыт, мы понимали, что он уже через пару месяцев поддержки станет практически не расширяемым (читай легаси) . И именно эту мысль сложнее всего доносить — как заказчику, пришедшему с таким проектом, так и новым разработчикам. В наших критериях мы не стараемся сделать идеальный код ради идеального кода и пытаемся найти компромисс, чтобы проект можно было развивать без особой боли. Именно это и толкало нас работать первые два месяца в таком режиме.

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

Кроме технических регламентов с постоянным контролем пришлось перестраивать менеджмент. Мы подняли критерии для менеджеров проектов и стали уделять больше внимания техническим навыкам. Строить управление проектов решили все же центрировано в офисе.

Это не закрыло все проблемы на 100%, и иногда проекты все же переводятся на ручное управление с вмешательством СТО и лидов. Но, несмотря на это, мы растем и берем все больше проектов в работу, уменьшая количество проблем. При этом заказчик в любом случае в итоге получает запущенный проект с возможностью масштабирования.

И мы всегда в поиске новых команд и интересных решений и рады обмену опытом, партнерству и совместной работе.

Тг: @VladKoshechkin