Outsourcing vs software consultancy: как поднять рейты до 75 USD/час

[Об авторе: Сергей Королев — управляющий директор в Railsware с более чем 15-летним опытом работы в ИТ: от стартапов до корпораций. Инженер, продакт-оунер, бизнес-лидер]

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

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

Аналитика мирового рынка IT-услуг

Давайте для начала посмотрим на стоимость аутсорсинга на разных рынках. Мы анализировали средние рейты в следующих регионах: Восточная и Центральная Европа, Азия, Южная Америка, Западная Европа, Северная Америка (последние два пункта для сравнения с родными рынками большинства наших заказчиков).

Данные от Accelerance, Clutch.co и Sensium.com совпадают с нашими наблюдениями в результате многолетнего опыта на рынке и общения с экспертами в индустрии.

Как видим, стоимость разработки в Восточной Европе (25-49 USD/час) в 2-3 раза ниже, чем в Западной Европе и США (50-170 USD/час). При этом качество кода не уступает. Для многих украинских аутсорсинговых компаний одним из главных конкурентных преимуществ остается цена. Ведь при более высоких рейтах они будут выходить на более конкурентные рынки, где нужно играть по другим правилам. И мы решились на этот шаг в 2011 году.

От аутсорса к модели consultancy

Семь лет назад Railsware была типичным аутсорсингом: мы продавали часы инженеров без глубокого погружения в бизнес-задачи клиентов. Мы работали с конкретным скоупом задач, предоставленным заказчиком, но без проактивного участия в формировании концепции продукта.

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

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

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

Стратегия 65

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

Около года мы искали новую модель. Для того, чтоб найти решение, мы использовали не только свой опыт, но также исследовали успешные примеры в индустрии. Мы много общались с лидерами рынка в Силиконовой долине, такими как Pivotal Labs, ThoughtBot, Zurb. Нашей задачей был обмен опытом и изучение успешных кейсов, анализ каждого подхода с точки зрения применимости в нашем бизнесе.

Railswarian-ы обмениваются опытом и подходами с командой Pivotal Labs

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

В результате анализа рынка мы приняли решение в пользу построения consultancy-модели. Что же для этого нужно?

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

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

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

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

  • продакт- и проджект-менеджеры;
  • бизнес-аналитик;
  • дизайнеры — графический и UX;
  • Frontend- и Backend-инженеры;
  • Разработчики мобильных приложений;
  • DevOps;
  • QA.

На разных этапах проекта часть ролей нужны full-time, другие — part-time. Между всеми членами команды должна быть налажена коммуникация. На организацию такой минимальной структуры уходят месяцы. И все равно, нанимая каждого специалиста отдельно, достаточно трудно сбалансировать инвестиции и их результативность.

Если мы собирались предлагать команду полного спектра, 9-10 узкоспециализированных специалистов не окупали бы себя. Потому мы перешли к концепции T-shape, при которой группа из 3-5 экспертов закрывает все роли за счет расширения смежных експертиз. Как результат, наша команда имеет гибкий набор скиллов и может подключаться к разным функциям в зависимости от потребности. При этом количество людей остается небольшим, что позволяет им проще коммуницировать между собой.

Разносторонний набор скиллов и погружение в разные аспекты проекта помогает команде лучше понимать друг друга. Например, наши инженеры могут продумать детали от инфраструктуры до user experience, дизайнеры — самостоятельно создавать прототипы и писать Frontend. В итоге благодаря многостороннему обзору каждый понимает детали процесса лучше и может качественнее делать свою работу.

В момент перехода с аутсорсинга на consultancy команда составляла около 50 человек. Первый этап миграции на новую модель заключался в принятии новых правил игры и занял около года. Software сonsultancy однозначно требует от команды выхода из зоны комфорта, больше работы над собой. Инженеру, например, теперь нужно развивать не только свои ключевые скиллы в разработке, но и коммуникацию, базовые UX-навыки, учиться управлять скоупом. К сожалению, не все были заинтересованы в своем развитии в рамках модели consultancy, потому около 10 человек покинули компанию. Остальная же часть команды успешно адаптировалась.

Изучив подходы лидеров рынка и применив их в наших реалиях, мы в течение года эволюционировали от простого аутсорсинга к software consultancy, которая нам дала, кроме удовлетворения от нового уровня качества сервиса, возможность поднять рейты до 65 USD/час.

Стратегия 75

Нашей следующей задачей было отточить новую модель на практике. Так как мы исповедуем data-driven подход, нам нужно было убедиться в силе Railsware consultancy на нескольких новых проектах. Хорошим примером стали Phillips, Interstellar и Restauranteers.

После года работы над 8 различными проектами мы убедились в том, что можем гарантированно предоставлять хороший результат с применением нового подхода к разработке продуктов. Потому мы решили поднять планку до 75 USD/час. При этом мы говорим о 75 USD/час на средне и долгосрочных проектах (от 2 месяцев до нескольких лет). В отдельных случаях нам удавалось закрывать короткие проекты (1-2 месяца) за 120 USD/час. Это возможно, но такие кейсы достаточно сложно воспроизвести. Эти переходы обеспечили площадку для запуска продуктового направления Railsware, которое мы активно развиваем сейчас.

Что в итоге

Итак, что поможет построить и поддерживать успешную consultancy модель?

Развивайте несколько ключевых доменов одновременно. Для нас это были инжиниринг, дизайн и продакт-менеджмент. Данная тройка составляет базис нашей consultancy-модели совместно с новыми доменами — business advisory и сервисом найма на стороне клиента. Помните, что заказчики готовы платить больше за полный цикл создания продуктов с учетом особенностей их бизнеса.

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

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

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

Развивайте культуру проактивности всей команды (каждый двигает процесс вперед, а не ждет указаний сверху). Мы, например, используем модель collective leadership — у каждого есть возможность проявлять инициативу и участвовать во внутренних проектах, которые помогут сделать наш бизнес лучше.

Похожие статьи:
Привет! Этот дайджест мы решили посвятить Ruby/Rails Gems, собрав гемы для решения типичных задач: от тестирования до безопасности...
[Про автора: Зеновій Верес — керівник освітнього напрямку Lviv IT Cluster, Solution Architect в компанії SoftServe, асистент кафедри...
Не пропустите последний набор в группу для обучения методам программирования на C, Objective-C и iOS. IDAP College с 2011 года...
#ITeaTalks — это разговор двух айтишников и фанатов своего дела за чашкой чая. Автор и ведущий — Alex Grechanowski, marketing...
В выпуске: чего ждать в 2019, безопасность internal сервисов, Cortex в CNCF, 82% компаний уже немного с DevOps, почему Kubernetes...
Яндекс.Метрика