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

Своим опытом делиться Олег Пузанов — предприниматель с 20-летним опытом работы в Tech сфере. Он является соучредителем Mad Devs, международной компании, специализирующейся на разработке программного обеспечения, а также Enji.ai – инновационного продукта для анализа производительности инженерных команд и принятия data-driven решений.

Команда решает использовать три традиционных подхода: 

• Прибегнуть к силе маркетинга через контент и рекламу
• Делать холодные рассылки другим компаниям по электронной почте и сообщениям в LinkedIn
• Отправлять персонализированные письма, которые обычно оказываются в списках спама

 Результат: в их копилке ни одного нового лида. 

Делают ли они что-то не так?

И да, и нет.

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

Что это значит?

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

Особенно, если они не слышали рекомендации о компании от коллег по цеху. 

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

Они в первую очередь обратятся к людям, которым доверяют, за рекомендацией.

Если это правда, почему сервисные компании не фокусируются на построении личных связей?

Ответ кроется в органическом росте многих из них.

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

Почему сервисный подход уступает продуктовому?

Прежде всего давайте рассмотрим разницу между продуктовым и сервисным подходами:

Сервисный подход: ориентирован на решение текущих запросов и задач клиента.

Продуктовый подход: ставит задачу создать долгосрочную ценность для клиента.

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

У них обычно есть два сценария развития:

Сценарий №1: Стихийный

Один программист получает заказ от клиента.

Он выполняет его, и клиент заказывает больше.

Программист приглашает друзей помочь ему.

Теперь у него есть команда, и клиент рекомендует их другим компаниям.

Вскоре они создают компанию.

Сценарий №2: На поводу амбиций

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

Они отделяются от крупной организации и продолжают работать на неё как подрядчики.

Эти сценарии подразумевают, что именно органический рост приносит клиентов для сервисных компаний.

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

Однако сервисный подход ограничивает возможности компании двумя способами. 

Во-первых, работая с чередой клиентов, разработчики становятся просто исполнителями, которые закрывают задачи по запросу, не пытаясь создавать ценность. 

Во-вторых, поиск новых клиентов превращается в постоянный вызов: завершив проект, компания сталкивается с необходимостью тратить значительные ресурсы на привлечение новых заказчиков.

Как решить эти проблемы с помощью продуктового подхода?

Начнем с того, что клиенты не всегда точно знают, чего они хотят.

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

Это фундамент для создания крепких и долгосрочных отношений с клиентами.

Продуктовый подход помогает выйти за рамки простого выполнения задач.

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

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

Более того, такой подход позволяет компании по-новому взглянуть на свою роль в разработке.

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

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

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

Наш продукт Enji.ai — отличный пример того, как продуктовый подход работает на практике. Он показывает, как внимание к деталям и понимание потребностей клиентов помогает не только создать успешное решение, но и привлечь новых клиентов.

Давайте я расскажу об этом подробнее.

Как Enji.ai помогает Mad Devs найти новых клиентов

Сообщение Опыт поиска клиентов с высоким чеком для сервисных компаний [и решение от MadDevs] появились сначала на Kraftblick.Media.

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

Что же делать с бенчем, чтобы свести к минимуму эти негативные факторы?

Как аутсорсеры помогают друг другу использовать свободных специалистов?

Рассказывает Олег Пузанов, Co-founder и CSO в Mad Devs.

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

Но вместо увольнений и других подобных решений им удалось стабилизировать ситуацию благодаря разным способам использования скамейки запасных.

Первую часть статьи, в которой Олег Пузанов рассказывает о том, как компании определить приемлемое процентное соотношение сотрудников на бенче и период простоя, стоит ли раскрывать цифры убытков внутри коллектива и почему люди выгорают, не работая, вы можете прочитать здесь.

Рекомендуем также другие материалы Kraftblick.Media по теме:

Как сервисно-продуктовая компания автоматизировала ключевые процессы, выросла до 250 человек за 4 года и считает рентабельность в один клик. Опыт Symfa Inc. Часть 2.
Как вырастить нишевую экспертизу внутри аутсорсинговой компании и продавать разработчиков в 3 раза дороже рынка.
Партнерская модель Revenue Share. Когда выгодно, как выбирать партнеров и что обсудить первым делом.
Как мы перестали менторить джуниоров и благодаря сетке компетенций сэкономили тимлидам 2 часа в день.

В статье вы прочитаете:

• Как получить профит, отдавая разработчиков бесплатно
• Ваши сотрудники как соинвестиция в проект клиента
• Как использовать бенч в продажах
• Как Pet-проекты помогают накапливать экспертизу
• Как сохранить лояльность специалистов, если бенч становится проблемным

Как получить профит, отдавая разработчиков бесплатно

Первый и самый простой вариант — сдавать людей с бенча бесплатно своим текущим клиентам.

Почему-то вижу среди фаундеров и сейлзов некое сопротивление такому предложению. Мол, зачем давать что-то бесплатно? Клиент привыкнет не платить и потом от него уже не добьешься адекватной оплаты.

Но я считаю, что абсолютно нормально проговорить условия.

Если у вас есть Major Client, с которым работаете уже много лет, почему бы просто не дать ему людей бесплатно? Однозначно на проекте есть какие-то задачи, до которых просто еще не дошли руки или на которые у заказчика пока нет бюджета.

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

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

Сообщение Что IT компании делать с сотрудниками на бенче, чтобы не растерять таланты и получать профиты. Опыт Mad Devs. Часть 2 появились сначала на Kraftblick.Media.

Часть сотрудников скучает на бенче в ожидании новых проектов?

Сегодня это типичная ситуация для многих аутсорсинговых компаний. Что же делать с теми, кто временно остался не у дел?

Какой процент и сроки бенча допустимы, а какие способны потопить компанию? И что придумать, чтобы таланты не разбежались по рынку в поисках занятия?

Своим опытом делится Co-founder и CSO в Mad Devs Олег Пузанов.

Mad Devs — аутсорсинговая IT компания (130+ человек) со штаб-квартирой в Лондоне. Основные клиенты — средний бизнес и энтерпрайзы из стран Европы, США и Юго-Восточной Азии.

На счету компании более 70 успешно реализованных проектов в таких областях, как Blockchain and Crypto, Fintech, Transportation, HealthTech, eCommerce, EdTech, AdTech, IoTs, BYOD и другие.

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

Но вместо массовых сокращений Mad Devs решили пережить сложный период с минимальными потерями по хэдкаунту.

О том, как этого удалось добиться, Олег Пузанов и расскажет в этом материале. 

Обратите также внимание и на другие статьи Kraftblick.Media по теме:

Как быстро распродать программистов с бенча? Подборка рекомендаций от четырех IT компаний со штатом от 35 до 250 человек.
Как дела с лидами и каково состояние рынка? Результаты опроса сервисных IT компаний (Часть 2).
Как IT компании построить прозрачные процессы, чтобы у стейкхолдеров не возникало вопросов, куда потрачены деньги. Опыт Mad Devs (130+ человек). Часть 2.
Как аутстафф-команда в кризис выросла в 6 раз, освоила новые технологии и рынки. Опыт TechinBy.

В статье вы прочитаете:

• Как определить, какой бенч в процентном соотношении и по времени приемлем
• Кто в компании должен знать о простое команды и цене этого
  
• Как могут выгорать сотрудники, не работая

Как определить, какой бенч в процентном соотношении и по времени приемлем

Бенч в IT компании — своего рода скамейка запасных игроков. Это сотрудники, которые по разным причинам временно не задействованы в коммерческих проектах и не приносят профит компании.

Каких сотрудников вообще считать бенчевыми? Оговорюсь, что я беру расчет только тех, кто относится к профстаффу — те, кого компания продает клиенту (разработчики, тестировщики и др.).

Кроме того, существует два типа бенча:

• Тотальный — сотрудник вообще не задействован ни в каких коммерческих проектах, на 100% свободен.
• Частичный — сотрудник недостаточно загружен, его занятость не охватывает полный день.

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

Когда появится новый клиент или проект, будет преимущество — доступные и готовые к работе сию минуту сотрудники.

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

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

Проблемы начинаются, когда бенч большой. Тогда компания уже теряет деньги: продолжает платить сотрудникам зарплату, но прибыли от коммерческих проектов не получает.

У каждого бизнеса есть свой запас прочности — процент сотрудников и в течение какого периода времени они могут быть не у дел.

Например, для нас 5-10% — это приемлемый запас. 30% уже считается критическим значением.

Но у крупных компаний внутренняя политика обычно позволяет держать бенч и до 30% профстафф-сотрудников в течение года. Тут помогает солидная финансовая подушка.

С другой стороны, если весь профит инвестируют в бенч, то ничего не остается условным фаундерам, ничего не направляется на развитие. Это ведет к тому, что компания теряет позиции на рынке и клиентов.

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

По истечению срока нужно принимать решение и кого-то увольнять. Это крайняя мера.

Часто сроки и объем допустимого для компании бенча зависят не от размера компании, а от бизнес-модели. Некоторые меньше зависят от клиентов, т.к. получают профит от продуктов, которые делают.

Другие компании годами существуют за счет высокомаржинальных проектов, которые, в свою очередь, финансируют другие, менее прибыльные.

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

Если этого сделано не было, то можно попытаться считать вручную. Это долго и не очень приятно, ведь нужно учесть массу переменных и “если вдруг”.

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

Первый месяц окей, второй… А на третий вдруг выясняется, что уже не получается выплачивать зарплату, потому что какой-то из клиентов задержал оплату. Вот и приехали.

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

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

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

Т.е. если условный Петя получает на руки зарплату $1k долларов, компании он может стоить все $3k. Это надо учитывать при планировании.

Кто в компании должен знать о простое команды и цене этого

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

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

Одно дело, когда мы знаем, что не у дел до 30% сотрудников и вроде ничего страшного. Другое, когда понимаем, что при этом за 1 месяц простоя компания теряет $300k.

А вот самим профстафф-сотрудникам не всегда стоит знать, во сколько компании обходится их режим ожидания.

На этот счет есть отличная статья Dark side of transparency от McKinsey.

В ней говорится об исследовании, которое показало, что радикальная прозрачность часто создает огромное количество флуктуаций внутри компании, потому что сотрудники очень разные по уровню зрелости и ответственности.

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

Поэтому такую информацию стоит открывать только тогда, когда уже сформирована культура полной прозрачности.

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

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

В MadDevs мы уже достигли того уровня прозрачности и взаимопонимания, что можем делится со всеми сотрудниками и проблемными моментами, и победами, не замалчиваем ничего.

У нас есть ежемесячные АМА-сессии, где ребята могут поднимать абсолютно любые вопросы и при этом оставаться анонимными.

Мы (руководство) отвечаем, если можем. Это важно, чтобы не разрушить устоявшиеся границы прозрачности: часть цифр и проектных рисков доступна всем, но всю монетарную картину видят только топ-менеджеры.

На наш взгляд, пока это работает эффективно.

Как могут выгорать сотрудники, не работая

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

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

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

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

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

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

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

Второй риск, который может возникнуть, если ничего не делать с бенчем: сотрудники начнут терять скиллы, свой опыт — попросту деградировать.

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

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

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

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

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

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

Стало ясно, что у ребят, которые почти год работали над некоммерческими проектами, ушел условный навык работы под давлением (когда давят сроками, ограничениями) и снизился навык социальной адаптации (когда приходится вовлекаться в другую команду).

Это показало, что нам надо продумывать тщательнее занятость во время бенч-периода. Например, делать ротацию сотрудников по командам, чтобы регулярно мелькали новые лица, чтобы человек за год “не-работы” не утратил социальные скилы.

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

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

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

Таким образом, мы пришли к выводу, что бенч обязательно надо каким-то образом использовать. Должен быть pipeline из каких-то дел, которые не просто чем-то занимают сотрудников, но и интересны им. А в идеале еще и приносят какую-то прибыль компании. интересно.

И во второй части статьи я расскажу, какие тут могут быть варианты. И еще чуть детальнее поговорим о том, как поддерживать лояльность сотрудников.

Материал подготовлен при участии журналиста Kraftblick.Media Юлии Шрамковой.

Сообщение Что IT компании делать с сотрудниками на бенче, чтобы не растерять таланты и получать профиты. Опыт Mad Devs. Часть 1 появились сначала на Kraftblick.Media.

Сообщение Как IT компании построить прозрачные процессы, чтобы у стейкхолдеров не возникало вопросов, куда потрачены деньги. Опыт Mad Devs (130+ человек). Часть 2 появились сначала на Kraftblick.Media.

Сообщение Как IT компании построить прозрачные процессы, чтобы у стейкхолдеров не возникало вопросов, куда потрачены деньги. Опыт Mad Devs (130+ человек). Часть 1 появились сначала на Kraftblick.Media.

Почему Open Source продукты так важны? Какие способы и каналы их продвижения являются наиболее эффективными?

Как понятно и интересно рассказать о специфичном проекте с открытым исходным кодом, чтобы это видео заинтересовало 11,000 уникальных пользователей?

Об этих и других тонкостях на примере кейса по продвижению бойлерплейта (шаблонного кода) AWS-EKS-Base рассказывает Олег Пузанов, co-founder и CSO в Mad Devs.

Mad Devs — это full-stack компания разработки и администрирования крупных IT продуктов. Основана в 2016 году, на данный момент в ней работает 120+ сотрудников из разных стран мира.

Домены: финтех, транспорт и логистика, медицинские технологии, электронная коммерция, электронное обучение, блокчейн, FoodTech, AdTech, IoTs, BYOD и другие.

В портфолио Mad Devs порядка 100+ проектов с открытым кодом на GitHub, и 70+ проектов для клиентов из США, Европы и Юго-Восточной Азии. Средний чек — $25-30k.

Рекомендуем также другие материалы Kraftblick.Media по теме:

Как IT компания сожгла $150k на продвижение: конференции, рекламу, холодные рассылки и звонки. И как делать это правильно.
“На продвижение нового приложения тратим $50k-$100k”. Интервью с Антоном Марченко, VP of Marketing в Apalon.
Кейсы, дайджест, Open Source. Как IT компании рассказывать о себе. Опыт Evrone.
Как проанализировать активность конкурентов. Разбор от маркетолога на примере EPAM и Yalantis.

В этой статье вы прочитаете:

• Почему мы верим в эффективность Open Source проектов
• Как выбрать идею для продукта с открытым кодом
• Как анализ конкурентов повлиял на нашу разработку и оформление документации (премиум контент для зарегистрированных читателей)
• Какие каналы мы использовали для продвижения бойлерплейта
• Каких результатов мы добились, проведя кампанию

Почему мы верим в эффективность Open Source проектов

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

Во-первых, молва идет впереди нас и сообщество само по себе делится годным проектом.

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

К тому же это довольно творческая работа, когда вы определяете какую-то проблему/боль, придумываете решение и показываете миру. Отличный способ проверить свои навыки и показать, из какого теста сделана компания.

Но это отнюдь не значит, что каждый Open Source (OS) проект становится успешным. Есть определенные условия, при которых шансы продвижения возрастают.

Mad Devs может поделиться своим опытом в этом вопросе на примере конкретного кейса — бойлерплейта для базовой AWS инфраструктуры с кластером EKS, который мы запустили в 2021 году.

Сразу объясню, что “boilerplte” с английского языка можно перевести как “шаблон”, “шаблонный код”.

Он используется там, где части кода повторяются несколько раз и остаются при этом практически без изменений.

Т.е. основное предназначение бойлерплейта — экономия времени разработчиков на реализацию какой-то базовой функциональности продукта.

Как выбрать идею для продукта с открытым кодом

Главный фактор при выборе проекта — это его ценность.

Мы верим то, что продукты и фичи, разработанные нами, будут полезны нашим клиентам. Не стал исключением и бойлерплейт.

Наш OS проект был разработан для DevOps и Cloud инженеров. Он содержит модули Terraform для быстрого развертывания кластера Kubernetes, вспомогательных сервисов и базовой инфраструктуры в AWS.

За время работы нашей компании мы перепробовали множество инфраструктурных решений и сервисов и прошли путь от локального оборудования до бессерверного. И на сегодняшний день Kubernetes стал нашей стандартной платформой для развертывания приложений, а AWS — основным облаком.

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

Узнавайте о новых статьях на Kraftblick.Media!

Сообщение Как продвигаться через Open Source проекты. Опыт Mad Devs на примере бойлерплейта AWS-EKS-Base появились сначала на Kraftblick.Media.