Аутстаф и аутсторс в разработке софта: что это, с чем их едят, и как обманывается рынок
Привет! На связи Кирилл Левин, CEO NLABTEAM. Сегодня — о самой центральной теме в любом бизнесе: о продажах. Дисклеймер: нижесказанное — исключительно частное мнение, и у кого-то всё может работать совсем наоборот. Для меня этот текст — осмысление и систематизация. Для вас — надеюсь, взгляд с чуть другой точки зрения и возможность «уцепить» что-то новое.
Аутстаф
Начнём с простого кейса: аутстаф (это когда вы нанимаете сотрудника и потом перепродаёте его услуги подороже).
Формируется порой весьма длинная цепочка: сотрудник — небольшая компания — интегратор — конечный заказчик.
Каждое звено накидывает свой интерес, поэтому до конечника долетает ресурс, стоящий в разы дороже исходного разработчика.
Плюсы для заказчика: любое количество ресурсов в нужное время без головной боли об отпусках, больничных и увольнениях. Никаких фиксированных затрат (CAPEX), что очень любит большой бизнес.
Плюсы для программиста: стабильная работа — как правило, в больших проектах, она очень размеренная, идущая по настроенным процессам.
Ключевой момент для тех, кто между разработчиком и заказчиком: стать как можно ближе в «пищевой цепочке» к заказчику. Тогда и рейты можно повыше поставить, и легче осуществлять масштабные продажи.
Долго сопротивлялся этому формату бизнеса, он мне казался «бездуховным», но опытные владельцы бизнесов с самого начала говорили, что «куда я денусь». Аутстаф позволяет сглаживать неравномерность проектных работ (как правило, на аутстафе можно предлагать разработчиков на год и более).
В 2025 пробую раскачать направление аутстафа в рамках концепции «держите яйца в разных корзинах».
Забавно наблюдать, как весь рынок молчаливо друг друга обманывает. Например, сеньорный разработчик на hh.ru стоит раза в 1,5–2 больше мидла, а вот в ставках разница между мидлом и сеньором — максимум процентов 10–20.
Понятно, что так большой бизнес защищается от того, чтобы джуна натаскивали на прохождение собесов в роли сеньора. Но всё равно кажется, что это противоестественно. Видимо, нужно повариться побольше в аутстаф-мире — привыкну и постигну скрытые истины.
Второй самообман рынка (связанный с теми же накрутками рейтов) — ставки в начале цепочки серьезно занижены.
Как-то пробовал на время усилить команду одного из проектов аутстаф-разработчиками: партнёры предложили с пяток кандидатов-сеньоров — по нашим внутренним требованиям они и на мидла с трудом тянули.
Вот такие дела: сейчас активно общаюсь с партнёрами, с заказчиками, оптимизирую накладные расходы, чтобы сыграть по правилам аутстафа. Из того, что уже понял: ключевой компетенцией в аутстафе является HR: быстрый наём по приемлемым рейтам, быстрый онбординг и удержание сотрудника.
Последнее наиболее сложно, т. к. сотрудник на аутстафе большую часть времени проводит с конечным заказчиком, погруженный в его процессы и ценности.
Аутсорс-проекты
Именно с таких проектов и начинался NLABTEAM. Как правило, тут прямая связь с заказчиком (во всяком случае, на наших проектах).
Прямая связь с заказчиком и погруженность в его бизнес-потребности даёт возможности прокачать креатив, навыки аналитики, расширяет технологический стек и инициативу разработчиков.
Ещё один важный бонус (главный для меня) — это насмотренность на различные бизнесы, их боли. Это база для обдумывания собственных продуктов, о чём мечтаю с начала основания. Если сейчас оглянуться назад, то даже неловко за нашу наивность в продажах: мы писали, что можем всё. И ведь не врали, просто такое совсем плохо продается.
Чуть набравшись опыта и объёма в реальных проектах, добавили сегментацию по отраслевым решениям, убрали непрофильные услуги.
Сейчас, когда мне предлагают поменять сайт или презентационные материалы, я задаю себе вопрос: «Как зародить у клиента такой минимум доверия, чтобы он оставил свои контакты или позвонил?»
И, если раньше мы описывали проектные кейсы двумя-тремя абзацами, теперь рассказываем полноценную историю совместной работы с заказчиком, от знакомства и написанного «вилами на воде» ТЗ на старте до финального релиза и запуска в прод.
Понятно, что небольшой лоск на такие рассказы наводится, но принципиально мы пишем обо всём: и об удачных решениях, и об ошибках.
В 2025-м, наконец, доросли до масштабирования продаж — маркетинг стал генерировать лидов гораздо больше, чем может переварить один человек.
Тут стоит упомянуть о граблях, на которые я наступил старте: я решил, что сам продаю так себе, поэтому мне срочно нужен специально обученный менеджер.
Сказано — сделано: год работал с менеджером по продажам. Эффект был: я залез в продажи даже глубже чем раньше, осознал, что нужно четче строить позиционирование, что нужно строить лидогенерацию, что продажи нужно «прожить» самому, прочувствовать их до деталей.
И вот сейчас, спустя несколько лет, обратно вернулся к команде продаж, но уже более подготовленным со стороны и маркетинга, и процессов. Дальше — время покажет.
Кстати, о лидогенерации и позиционировании. Чем больше становится компания, тем чаще задаю себе вопрос: «Что мы НЕ будем делать?» Поток лидов от маркетинга позволяет теперь избирательнее относиться к входящим запросам.
Клиент, конечно, прав, но отнюдь не всегда. Мы уже набрали достаточно опыта, чтобы оценить, будет ли от проекта толк и для заказчика, и для нас. Поэтому каждый новый запрос оценивается с нескольких точек зрения:
Есть ли бюджет?
Запрос соответствует нашим компетенциям?
Понимает ли клиент, какую задачу он хочет решить и какую пользу он получит?
Готов ли слышать наши предложения?
Есть ли у клиента опыт заказа программного обеспечения?
Про бюджет все тривиально: в NLABTEAM собрана крутая команда разработки, и это не может быть дешево.
Про компетенции — если тиражировать знания и навыки в новых проектах, выходит выгоднее и для нас, и для клиентов. Поэтому от непрофильных технологических стеков, от совсем далеких отраслевых направлений проще отказаться, чем потом мучительно сдавать «франкенштейна».
Третий пункт (о понимании задачи клиентом) — самый сложный: часто первый контакт идет от менеджера, который не сильно задумывается о целях проекта. Поэтому стараемся выйти на стейкхолдеров, которые чётко понимают, зачем им новое программное обеспечение.
После этого нередко оказывается, что написанное заказчиком ТЗ не решает исходной задачи. В этот момент, заодно, проверяем пункт 4 — адекватный заказчик будет только рад, если ему предложат другое, но более оптимальное решение.
Последний пункт, про опыт заказа разработки, соблюдается не всегда. Бывает, мы работаем с теми, кто еще никогда ПО не заказывал. Но тогда мы сразу закладываем в проект дополнительное время и ресурсы: нужно будет познакомить клиента с процессом, обработать миллион дополнительных хотелок, про которые он не подумал на старте.
Текст получился длинным, поэтому не уместилась часть истории про upsale и роль руководителей проектов и тим-лидов в этом процессе, не влезла тема продуктовых продаж. О них — в другой раз.
Буду рад, если вы поделитесь в комментариях своим видением.
А если вам интересно узнавать ещё больше из мира ИТ, подписывайтесь на мой Telegram-канал «Айтигородские байки».