×

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 — у каждого есть возможность проявлять инициативу и участвовать во внутренних проектах, которые помогут сделать наш бизнес лучше.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному2
LinkedIn

Схожі статті

  • Про побудову продуктів в аутсорсинговій компаніїПро побудову продуктів в аутсорсинговій компанії

    Victor Haydin

    Розглянемо типовий шлях, який долають аутсорсингові компанії, коли починають писати власні продукти. Я не пропоную тут чеклістів чи рецептів успіху — в мене їх немає. 30

  • Вплив віз H-1B та аутсорсингу на економіку СШАВплив віз H-1B та аутсорсингу на економіку США

    Vasyl Soloshchuk

    Віза H-1B призначена для висококваліфікованих та талановитих іноземців. Я дивлюсь на цю проблему з точки зору нашої IT галузі. В статті я проаналізував працевлаштування спеціалістів за візою H-1B порівняно зі стаффінгом через аутсорсингові компанії. 164

  • Тестування вимог — перший крок в роботі над проектомТестування вимог — перший крок в роботі над проектом

    Igor Luzhanskiy

    Хочеться, щоб ми поглянули на питання роботи з вимогами з висоти пташиного польоту й водночас заглибились у деякі конкретні приклади того, яким чином тестуються вимоги, які є інструменти тестування, які є, передусім, категорії, за якими вимірюється якість вимог.... 12




83 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

@Sergey Korolev, как ваши успехи? Очевидно, вы действительно хороший руководитель и предприниматель, отличный подход к развитию бизнеса (судя по этой и другим статьям).
Вы пишете про такие направления, как "

инжиниринг, дизайн и продакт-менеджмент. Данная тройка составляет базис нашей consultancy-модели совместно с новыми доменами — business advisory и сервисом найма на стороне клиента.

"
С инжинирингом и, возможно, дизайном все понятно — T-shaped специалисты-инженеры однозначно будут стоить дороже, да еще и как команда. Наверняка, вас ценят как технического партнера, <технического> консультанта.

А вот с продакт-менеджмент, business advisory и сервисом найма на стороне клиента — как вы эти экспертизы развивали (развиваете)? Что прокачиваете? Как и что продаете? .

И второй вопрос — у вас вообще ничего не сказано о маркетинге, как сервисе. А без него, мне кажется, бизнес-консалтинг такой себе. Закрываете ли вы вопросы исследования рынка, продвижения?

спасибо !

Елена, спасибо за комментарии. Дела идут хорошо — уверенно движемся к концепции Product Studio. Вот тут можно прочитать детальнее railsware.com/blog/product-studio. Там и про маркетинг рассказывается в том числе.
Касательно

business advisory и сервисом найма на стороне клиента

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

Так как мы исповедуем data-driven подход,

а можно подробнее ?

Сергій, дякую що поділилися і структурувано описали що потрібно для переходу.
Дуже багато знайомих процесів по Стенфай))

Дико режет ухо слово «экспертиза» в значении «опыт».
Всё-равно, что говорить «интеллигенция» в понимании «ум».

intelligence — has been defined in many different ways including as one’s capacity for logic, understanding, self-awareness, learning, emotional knowledge, planning, creativity, and problem solving.
Разве это не свойства „ума”?

expertise — Great skill or knowledge in a particular field or hobby.
В чем противоречие?

В том, что в русском языке что одно слово, что другое имеют совершенно иные значения.
Приведу определения этих слов из толковых словарей:
экспертиза
ЭКСПЕРТИ́ЗА -ы; ж.
1. Рассмотрение, исследование каких-л. вопросов, решение которых требует специальных знаний в области науки, техники, искусства и т.п. Научная э. Судебно-медицинская э. Техническая э. проекта. Отправить на экспертизу.
2. Разг. Комиссия экспертов. Члены экспертизы. Сформировать экспертизу. Э. была высококвалифицированной. Заключение экспертизы.
Большой толковый словарь русского языка. — 1-е изд-е: СПб.: Норинт С. А. Кузнецов. 1998

ЭКСПЕРТИЗА, -ы. ас. Рассмотрение какого-н. вопроса экспертами длявынесения заключения. Медицинская э. Судебная э.
Толковый словарь Ожегова

ИНТЕЛЛИГЕ́НЦИЯ -и; ж.
1. Социальная группа, состоящая из образованных людей, обладающих большой внутренней культурой и профессионально занимающихся умственным трудом. Задачи российской интеллигенции. Творческая и.
2. собир. Люди, принадлежащие к этой социальной группе, интеллигенты. В клубе собралась вся сельская и. Общегородское собрание интеллигенции.
Большой толковый словарь русского языка. — 1-е изд-е: СПб.: Норинт С. А. Кузнецов. 1998

ИНТЕЛЛИГЕНЦИЯ, -и, ж., собир. Люди умственного труда, обладающиеобразованием и специальными знаниями в различных областях науки, техники икультуры; общественный слой людей, занимающихся таким трудом. Российская и.Сельская и.
Толковый словарь Ожегова

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

Да и Вы же почему-то не говорите ничего, вроде «моя интеллигенция позволяет мне решать сложнейшие логические задачи».
За то фразы вроде «Благодаря моей многолетней экспертизе аналогичные проблемы решаются довольно быстро» — это ок)))

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

Самое близкое — компетенция, компетентность. Или просто — опыт.

Риспект. Эта модель гораздо более сложная (и более рисковая), но исключительно перспективная и гарантированно имеет сильное будущее.
Внутри возможно не все так гладко, но описание многообещающее. Ключевые вещи: упор на небольшие сильные команды Т-шейпед людей.
Общаюсь с ThoughtWorks (SG), они именно так и делают, и у них получается ;)

Привіт Сергій! Дуже хороший результат, мої вітання! Реально верхній перцентиль (3-5%) в аутсорсових рейтах. Але і рости в цій категорії набагато важче, і темпи росту як правило нижчі ніж у всього ІТ аутсорса. Ви спеціалізуєтеся на декількох конкретних бізнес-нішах? (e-commerce, banking, insurance, retail etc.)

Вов, привет :)
Я уже писал ниже в комментариях, что скейлить такой бизнес до тысяч или даже сотен людей действительно сложно. При этом основная сложность в количестве экспертов на нашей стороне а не нежелание клиентов платить. У нас нет специализации с точки зрения индустрий, вот тут можно увидеть кейс стади railsware.com/case-studies

концепция T-shape

Это когда стоматолог и за проктолога, и за окулиста. Фул-стек.

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

То о чем ты говоришь это не фулсек и не Tshape — это отсутствие процесса.

не згоден, це — середні очікування від програміста на західному ринку

Якось конкретики мало, от які скілли добавила ваша команда не зрозуміло загалом. Наведу приклад, я 10 років працював як бекенд програміст і зайнявшись своїм проектом прийшлось вивчати що таке Marketing (Facebook, Instagram), реклама у соц. мережах і контекстна реклама, що таке SEO i content marketing, що таке цикл продаж, прийшлось вивчати Google Analytics, щоб відслідковувати конверсії ітдітп. У вашій статті не бачу жодної інфи, що ж все-таки вивчила ваша команда, додали хорошого UX спеціаліста та додали BA і все? Насправді тема досить цікава, хотів б себе як окремий консультант контрактор розвивати, але не зрозумів, що саме потрібно по вашому розвивати, просто бажання вникати у бізнес клієнта це на мою думку не є конкретний скілл :) Чи я щось пропустив?

Дивiться уважнiше: «инжиниринг, дизайн, продукт-менеджмент + business advisory и найм на стороне клиента», «интеграция в бизнес клиента, умение закрывать существующую боль клиента, проактивность и collective leadership».
Центр тI soft skills, якi не «вчаться» та якi не тотожнi просто додаванню UX та BA специалистiв. Це тi навички, якi в вас як в окремому контракторI буде шукати рекрутер дивлячись як ви вирiшували виклики на проектах до цього часу.

Дякую, але усе що ви перелічили окрім «business advisory» думаю будь яка аутсорсингова компанія декларує. Ще треба визначити що таке business advisory, що є реальний контроль за КПІ, «кеш фловом», або що це тоді? А продакт менеджмент може відштовхуватися тільки від цього, тобто аналізу де гроші клієнтів, а з того що я поки що більше бачив менеджерів переназивають в «продакт оунерів» які далі нічого не знають про кінцевих клієнтів/користувачів та очікують задач від СЕО. Тому хочеться все-таки зрозуміти в чому були зміни і чи реально замовники допускали до внутрішньої кухні.

Спасибо за отличный кейс. У меня как раз сейчас стоит задача интегрировать модель консалтинговой компании с реалиями украинского рынка разработки. Развивать скилы по бизнес адвайзингу, продакт менеджменту только силами команды за рубежом кажется самый простым путём, но в долгосрочной перспективе из-за дезинтеграции команд приведёт к проблеме роста. При наличии локальных конкурентов, выдающих качественный MVP за одну неделю! только имея Т-шейп команду можно достигать тех же результатов.

Спасибо за позитивный комментарий. Но у меня ремарка MVP за не делю не делается :)

Крутяк, так 75$ как-то перепадает веслующим в Киеве? И что бы Вы посоветовали чтобы продаваться за 100-150$/hr?

Игорь, к сожалению пока что $75 потолок. Пытались $85 но стало совсем сложно продавать. Психологически клиенту совсем сложно понять как же ж другие предлагают вроде то же самое по $40.

Значит ваши клиенты все еще не видят ценность. BCG / Delloite / Gemini продаются же по $250-$1000, значит вы можете конкурировать с ними по рейтам.

Delloite продаёт в первую очередь свой бизнес опыт и кейсы по работе с сотнями клиентов из твоей индустрии. «Воруй как художник» :)

Разница как «сделайте мне Гугл» на фрилансе и «сделайте мне Яндекс» как предложения Михаилу Парахину и Глебу Абовскому

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

Вы реально крутые

так 75$ как-то перепадает веслующим в Киеве?

?

Судячи з цього рейту у вас зарплати мають бути мінімум $5k

Исходя из отзыва по компании, похоже что ответ прост — НЕТ.

Все правильно, нашо гребцям платити більше якщо і так будуть веслувати?

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

но за всем вместе следить нереально

Реально
Трансформация компании была в 2011-2012, и до сих пор у нас одна из самых сильных Ruby On Rails команд в восточной Европе, то-есть экспертами быть никто не перестал.

Thus, a full-stack developer would be proficient, if not fluent, in:

— Server, network, and hosting environment
— Relational and nonrelational databases
— How to interact with APIs and the external world
— User interface and user experience
— Quality assurance
— Security concerns throughout the program
— Understanding customer and business needs

Как видите, в списке нет „знать Java 6” или „только jQuery”, поэтому не понятно, как новые технологии не возможны у Вас с full-stack инженером.

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

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

Не, вот допустим у вас есть люди быстро усваивающие информацию А и Б. А — фулл стек. Тоесть он с задачами класса Х усваивает 4 часа в месяц. А б — эксперт по X, он на клас Х тратит 40 часов в неделю. Как вы думаете, кто быстрее поймет в чем баг в классе Х?

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

Да и вообще experience это не только способность усваивать информацию, но и взаимодействие с объектами и найденные тупиковые ветки.

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

Вот это мне не понять честно говоря. У меня рейт 100. И я вобщемто считаюсь узким экспертом.
Все очень сильно зависит от бекграунда компании и проектов имеющихся в наличии.

На freelancer 80$ написано. Как вообще с загрузкой и длиной проектов?

На фрилансер вообще нет почасовых. Там они очень неудобные(почасовые тупо зависают, нет механизма их окончания если клиент исчез, ужасная тулза). Почасовые это апворк. Средний проект 10 часов, средняя загрузка ниже 20/неделя. Есть буквально несколько долгосрочных, но обычно все же часы. Если нагрузка поднимается выше 20, я рейт меняю, если две недели подряд ниже 5, понижаю(редко). При высокой загрузке не остается времени на срочные задачи и нет настроения работать, что приводит вобщемто к уменьшению общего дохода. Срочный рейт — двойной.

Допустим, эти эксперты не сильно напрягаясь получают 25 на руки ($4K). А сколько будет получать фулл-стек с дедлайнами и удовлетворением кастомера?

Вы правы — эксперт в области Х будет лучше, чем просто full-stack инженер, которые просто там работает. Но разница еще будет в том, что эксперт в области Х умеет решать задачу только данным инструментов («когда у тебя в руках молоток, все задачи кажутся гвоздями»), и рассмотреть/понять как решить эту задачу или ошибку ему уже никак, ведь он ограничен только своей специализацией. Пример, когда DBA решает все через базу данных, даже если это разумнее перенести в бекэнд/фронтенд сторону — он это сам не знает, он просто DBA.

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

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

Но я не собираюсь Вас уговаривать на какую либо модель — full-stack или узкоспециализированный инженер. Они отлично уживаются и работают.

это задача архитекта или тимлида

То есть все-таки кто-то должен разбираться во всей архитектуре приложения. Именно таких мы и называем full-stack. У нас каждый инженер может самостоятельно построить MVP достаточно большого продукта в одиночку выполняя роль архитектора.

Вы ведь понимаете что

самостоятельно построить MVP достаточно большого продукта в одиночку

— уже оксюморон?

Ну у всех понимание большого продукта конечно разные. Например MVP (Minimum viable product) этого продукта railsware.com/case-studies/quorso был разработан одним инженером. И эта версия была продана нескольким очень известным компаниям за суммы с 5 нулями. Конечно инженеру помогали продакт менеджер и дизайнеры, но инженер был только один. Потом конечно к нему уже добавилась целая команда что бы расширять продукт и делать его более функциональным и масштабируемым.

Кстати важно сказать что от технологии очень многое зависит; на C/C++ действительно будет сложно сделать что-то самому, это я как бывший C++ инженер говорю :)

Так, навскиду (судячи по файлам JS), не враховуючи всяких JQuery і т.п., він заюзав Mixpanel, MixItUp і Amplitude, які йдуть під комерцйними ліцензіями ?

Например MVP (Minimum viable product) [...] продукта [...] был разработан одним инженером.

удивительно. ну, если бы прототип — то было бы понятно. но bus factor же. или риск незаметен был?

В такой ситуации на месте менеджера меня бы постоянно грыз вопрос, а не разбежится ли в какой-то момент часть команды на топ-позиции в «обычные» компании. Т.е., если человек по факту является архитектом, что его держит на позиции девелопера? Либо формально считать всех архитектами и компенсировать соответственно, либо хотя бы частично внедрять обсуждаемые сейчас «бирюзовые» подходы с открытым механизмом формирования рейтов... Т.е., самый интересный вопрос — что дальше).

Зубы от страха поломает :)
Что дальше — каждая компания решает сама и несёт ответственность за свои решения с учётом состояния рынка.

Что дальше — каждая компания решает сама и несёт ответственность за свои решения с учётом состояния рынка.

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

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

Т.е., если человек по факту является архитектом, что его держит на позиции девелопера? Либо формально считать всех архитектами

Вы не рассмотрели вариант когда архитекторами только формально ))

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

Ну или гараздо более времени тратит на обучение.

Раз уж полез — пусть «мучается», человека никто не заставлял становится «full-stack developer» :)

Ну так от этого он меньше будет работать же. По сравнению с узким. Именно потому у нас вообще есть программисты, а не докторы философии как в 18м веке.

Узкие сидят и пьют чай. А широкие во всем виноваты.

Работает как и все — почасовой же рейтинг :)

И список может быть не полным :)

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

Слушайте, а вашим ребятам нормально в Кракове в 7-8 вечера сидится?
А-то как не проходил мимо вашего офиса, но, Юля, с нулевого этажа я могу просто подойти к окошку и почитать что ваши ребята делают :)
А это знаете-ли — может коммерческую тайну раскрыть.
Близость книжного магазина — это плюс :)

У нас свободный график если ты приходишь на работу в 12, то работать до 7-8 вполне нормально.
Что бы прочитать что-то реально ценное тебе нужно будет стоять и вглядываться в окно, и там будет сложно не обратить внимание на тебя :)

и там будет сложно не обратить внимание на тебя :)

Ну, с учетом того что у вас там есть standing desk прямо у окна, за которым часто кто работает, и с большим монитором, а на улице темно — сам понимаешь :-)

Надо припарковать авто с регистратором

Да у вас прямо софтверный бутик :)
По факту подсматривания — а как страдают бедные сотрудники коворкингов. Так может нужно просто рабочую культуру соблюдать?

стоимость разработки в Восточной Европе (25-49 USD/час)

Не могли бы подробнее разъяснить, что имеется ввиду и какие расходы входят в эти $25?
Я думаю многие девелоперы не видели зарплат более чем $15/час.

25-49 это внешние рейты которые выставляют аусорсинг компании для клиентов.

Это круто, что берёте интереснее проекты и повышаете зп сотрудникам.

Но а как с командой дальше? На сколько тяжело искать новую рабочую силу, адаптировать её и обучать? Как масштабируетесь? Сколько человек в команде сейчас?
Ведь после такого качественного скачка, для повышения прибыли проще расти количественно, до определённого предела. Вы в него уже упёрлись?

Андрей, скажу честно, масштабировать такой бизнес нелегко, просто очень сложно найти экспертов нужного уровня. Вообще наша стратегия плавный переход в продуктовую компанию. И увеличивать профит нелинейно. Мы уже успешно запустили пару собственных продуктов (mailtrap.io, goo.gl/kbk8xM) и работаем над новыми.

Спасибо за интересную статью.
Скажите, Сергей, какие навыки преобладают в ваших T-shape Ruby инженеров кроме собственно Backend? Есть ли DevOps + Backend или, например, фулл стек с React/Angular/Vue вплоть до верстки HTML/CSS? Если взять среднего бекенд разработчика который имеет достаточно глубокие знания и опыт в бекенде, немного знает про деплой на тот же Heroku или амазон, может настроить s3 bucket/cloudfront на AWS, умеет писать автотесты (rspec/cucumber) и знает немного про фронтенд фреймворки (может помогал немного по фронтенде на проекте с React), но абсолютно не умеет верстать — вяжется ли такой девелопер в T-shape?

Виталий, у нас нет front-end и back-end инженеров. Каждый инженер full-stack и продумывает фичу начиная от инфраструктуры и до client-side. Тут можно найти описание позиции railsware.com/...​full-stack-ruby-engineer

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

Извиняюсь что я отвечаю на вопрос адресованный Сергею, но это обобщенный опыт общения со множеством сотрудников консалтинговых компаний с зарплатами за 110-150К в год.
Средняя продолжительность проекта, в течение которых команда таких бойцов выдаёт кастомные решения заказчикам от трёх до шести месяцев. И это не формы логина за два спринта, а сложные доменные модели.
Если клиент доволен и в планах быстро расти дальше — продлевают до года-двух, потом развиваются за счёт внутренней команды и оутстафинга с более низкими рейтами.

А какие внутренние рейты у ваш консультантов?

Скорее всего рейты раскроют на собеседовании, всё индивидуально же)

Но то, что раскрыли общие цифры, мне кажется, говорит об отсутствии жадности.

Ну грубо делите озвученые цифры на 3 — это и будет рейт ̶г̶р̶е̶б̶ц̶а̶ консультанта.

Точнее будет сказать на 2, так как 50% всего инкама уходит на компенсацию в том или ином виде — зарплаты, бенефиты, бонусы.

Правда, что самые сильные члены команды получают больший процент 70-80%, а не выставляются за большие суммы, поддерживая тот же уровень 50%?

В компании нет подхода «это специалист дороже или дешевле» (как мне известно)

Підписатись на коментарі