In house разработка что это

От аутсорсинга до in-house, или От обычной драмы до довольных разработчиков

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

Если вы задумываетесь о том, чтобы перевести разработку и внедрение с аутсорсеров в in-house (или наоборот!), приглашаем под кат. Если же вы разработчик и рассматриваете предложения от интеграторов и скучного enterprise, то тоже сможете почерпнуть из этой истории что-то полезное.

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

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

Из всего обилия систем в ДИТ ВТБ Лизинга хочется рассказать про АСССК — автоматизированную систему службы сопровождения клиентов и корпоративную CRM-систему, с которой все и начиналось.

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

Исторически первой была CRM-система на базе Microsoft Dynamics CRM 2011, которая внедрялась и потом обновлялась до актуальных версий нашим партнёром-интегратором. Основную работу он делал сам, а нашим IT-специалистам доставалась довольно скучная роль обслуживающего персонала: работа на подхвате, какие-то мелкие правки, обеспечение интеграций с другими системами, работа с документами. Сказать, что это не нравилось нашим коллегам, значило бы существенно преуменьшить их недовольство.

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

сбор требований;
написание ТЗ;
фиксация ТЗ;
расчёт стоимости работ;
подписание договоров;
календарное планирование;
реализация;
приемка;
подписание закрывающих документов.

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

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

Чтобы хоть как-то изменить этот печальный тренд, было решено перейти с фиксов (контрактов с фиксированной стоимостью) на T&M (время и материалы) с оплатой рабочего времени сотрудников подрядчика. Так перенесли управление проектами из зоны ответственности интегратора в нашу. Это же дало возможность распоряжаться временем сотрудников подрядчика, в рамках постановки целей и задач. Стало легче, но незначительно: накопленных проблем всё равно было слишком много. Несмотря на изменение условий договора мы замечали, что качество работы внешних сотрудников было не на высоте. Приходилось терпеть и тащить эту историю дальше. Стоимость и сроки внедрения новых функциональных возможностей росли в арифметической прогрессии. Возрастала и стоимость сопровождения: технический долг увеличивался, и под нагрузкой CRM работала всё менее и менее надёжно. Сбои во время работы и многочисленные дефекты после каждого релиза стали нормой жизни.

И этому нашлось объяснение. Вот немного откровений от Виктора — руководителя проектов, который перешёл из штата нашего контрактного подрядчика к нам в in-house:

«Консалтинг подписывается практически на всё. Платите деньги — и мы сделаем всё, что вы хотите! А о том, что какие-то разработки при масштабировании вызовут проблемы, на этом этапе никто не думает. Проектирование идёт, чтобы выполнить задачу на будущий год. Без учёта возможного роста числа пользователей в 2–3 раза или увеличения количества данных. В итоге данные не смогут обрабатываться не потому, что там недостаёт аппаратной части, а из-за проблем в самой системе. Потому что сделанное не сможет быстро перевариться. Многие вещи, которые считаются моветоном среди разработчиков, будут использованы в угоду скорости. К примеру, есть руководитель проекта, и он говорит: надо сделать в этот срок этот релиз только потому, что у нас мало задач, которые мы сможем сдать в этот период и закрыть актами.

После перехода в штат компании начинаешь понимать, что тебе с этой системой работать, тебе её поддерживать и тебе же её в будущем дорабатывать. Начинаешь выстраивать партнёрские отношения с бизнес-заказчиком, а не брать всё подряд в работу «как есть». Отсюда и отношение другое к проектированию — коллегиальное. В консалтинге сотрудники по пунктам выполняют свою работу, не думая о каких-то посторонних вещах: дополнительные службы, запуски процессов и так далее, — всё это не прорабатывается. Частые жалобы: «того не дали», «этого нет», «я не нашёл информацию» и т. п. Есть стремление не решить проблему, а показать, как ты усердно трудишься.

Когда находишься во внутренней команде, гораздо проще исправлять ошибки. Проще решать, что нужно взять в спринт; даже если он уже идёт — окей, давайте мы в него ещё вот это добавим. А если сроки чуть-чуть съедут в следующий спринт, то и этот вопрос решить проще, чем при работе с внешним подрядчиком».

Свой продукт с блэкджеком и сегментацией

Во время изучения очередного пула задач от службы сопровождения клиентов мы подумали, что можно сделать отдельную от большой CRM систему АСССК, предназначенную только для этого направления бизнеса. Уровень неопределённости на начальном этапе был большой, и именно поэтому реализовывать систему по Waterfall’у было странно, но начали делать именно так.

Несмотря на то что формально предлагалось создать и внедрить ещё один продукт в том же сегменте, предполагаемые плюсы этого решения перевешивали недостатки:

вместо большого и дорогого комбайна со всеми опциями по максимуму, которым являлась CRM-система, — конкретное решение под определённого заказчика;
вместо привязки к релизам и доделкам большого продукта — независимые обновления и минимизация зависимостей частей системы друг от друга;
вместо большой и хрупкой системы с множественными связями и сотнями потенциальных точек отказа — небольшая.

Что же, финалист определён, новый контракт подписан: новый проект для АСССК, новый интегратор и даже новый стек (с Microsoft Dynamics CRM — DotNet, MS SQL, вот это всё — мы планировали перебраться на 1С). В общем, всё по-новой…

Мы справедливо надеялись на хорошие результаты. Но получилось так: спустя полтора года в новом проекте был сдан только первый этап функциональности (из восьми!).

Мы всё переосмыслили

В этот момент мы поняли, что waterfall точно не подходит и налицо все «признаки Scrum’a». Антикризисным решением стало создание своей команды разработки, которую на первых порах усиливала команда интегратора. Это решение должно было обеспечить безопасность компании и увеличить скорость внедрения изменений. Одновременно с этим — привить новую культуру, которая позволила бы достичь высокого уровня взаимопонимания между разработчиками и стейкхолдерами.

Своя команда вместо попытки реализовать необъятное начала с декомпозиции, приоритезации самых важных для бизнеса задач, их разбора на отдельные юзер-стори для последующей реализации в соответствии с актуальными приоритетами. В результате изменилось взаимодействие с бизнесом, а его участие и погружение в процесс разработки возросло: если раньше подрядчик не погружал бизнес в детали проектирования и разработки конкретных фич и не мог себе позволить гибко реагировать на изменения и корректировку требований, то теперь наша команда анализирует риски и потенциальные проблемы, выясняет, насколько всё это действительно нужно и важно, и управляет ожиданиями заказчика. Благодаря собственной команде появилась возможность менять приоритеты задач очень быстро. Всё это повышает вовлечённость бизнеса, качество работы с ним и, конечно же, максимизирует ценность регулярно выпускаемых инкрементов функционала. Этот прогресс, а также грамотная работа с техническими рисками привели к тому, что время на конечную реализацию не увеличилось, а сократилось. Поменялось и отношение к продукту: стейкхолдеры и ИТ-команда стали понимать, что им предстоит долго совместно работать с этой системой, поэтому ответственность и продуманность их действий вышли на новый уровень.

Где фактура, Лебовски?

Кто-то скажет: а где фактура? Даты, сроки, имена? По понятным причинам названия интеграторов указать здесь я не могу, зато могу сказать про сроки и этапы. Сравните: компания, взявшаяся за написание АСССК, чуть больше чем за полтора года смогла сделать только часть функциональных модулей. При том, что этот срок выделялся на весь проект! Когда нанимаешь интегратора, имеешь довольно высокие, но справедливые ожидания: все необходимые компетенции для нужд проекта, возможность гибко управлять количеством людей на проекте, большой и разнообразный опыт (не только технологический, но и продуктовый), но самое главное — выполнение задач в срок. Увы, все преимущества интегратора не смогли помочь в реализации последнего, но самого важного ожидания.

После того как мы провели Agile-трансформацию проекта, появился владелец продукта. Мы начали нанимать людей в октябре 2020 года и укомплектовали команду к маю 2021 года. Размер собственной команды составил пять человек плюс пара работников от компании-подрядчика. Сегодня подрядчики участвуют только в сопровождении и баг-фиксинге продукта.

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

Отзыв продакт-оунера Влады

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

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

Ещё хочу отметить бережное отношение команды к продукту. Несмотря на то, что есть сроки, команда старается сделать всё аккуратно, без костылей. И это правильно: нам не просто нужно сдать продукт к сроку (как, например, бывает с подрядчиками), но ещё и поддерживать его в будущем. Поэтому чем качественнее получится продукт сейчас, тем легче нам будет дальше работать над его развитием и поддержкой».

Итогом внедрения второго этапа стал отзыв ключевого заказчика Сабины:

«Рост скорости и качества обслуживания наших клиентов — основная цель внедрения этой системы. Значительная доля успеха в любом деле зависит от участников, а глаза у нашей новой команды буквально «горят». С учётом уже реализованного уверена, что цели будут достигнуты».

Опыт успешного внедрения собственной продуктовой команды на этом продукте положил начало преобразованию компании. Глядя на нас, другие бизнес-юниты тоже захотели реализовывать свои системы именно с помощью in-house разработки. Вместо тяжёлого и неповоротливого монолита мы идём к IT-ландшафту, который будет естественно повторять оргструктуру компании. Вдобавок интересные проекты дают второе дыхание сотрудникам и упрощают наём кандидатов, что критично в условиях постоянного расширения нашего бизнеса. Мотивация тех людей, которые перешли к нам работать из команд подрядчиков, выросла, и теперь задачи стали интереснее, появилась возможность создавать «от» и «до» действительно крутые продукты и видеть, как они приносят пользу клиентам. Больше дела, меньше бюрократии. Больше гибкости в принятии решений. Лучшая проработка и проектирование решений — ну а какой разработчик не любит проектировать и создавать по-настоящему хороший продукт? Так, несмотря на отсутствие магической «шкатулки» с людьми и компетенциями, своя команда смогла сделать то, что не смог сделать подрядчик.

Как ни посмотри, вовремя принятый на себя риск открыл новые возможности и для компании, и для её работников. Так что можно считать, что эта история закончилась успехом. А был ли у кого-то из вас подобный опыт? Расскажите в комментариях!

АУТСОРСИНГ VS IN-HOUSE: ВЕЧНАЯ БОРЬБА

—>

Наш коллега из дружественного SMM-агентства как-то отметил: «Вот так ведешь клиенту сообщества в соцсетях и все хорошо. Но потом он начинает пытаться сам это делать, не желая «переплачивать» подрядчику. И качество падает очень быстро».

Так каких же специалистов есть смысл нанимать или «выращивать» у себя, а каких лучше всего привлекать на аутсорсинге? И кому стоит платить много, за то, что он «закрывает» какие либо задачи? Мы решили рассмотреть эти вопросы в отдельной статье.

Рассмотрим несколько типов специалистов: SMM-специалисты (контент-менеджеры и таргетологи), директологи и SEO-шники, дизайнеры, администраторы сайтов и разработчики; определим, когда лучше нанимать подрядчиков, а когда «выращивать» своих профессионалов. Также рассмотрим два примера, когда бизнес существенно терял в своем развитии, потому как приоритеты были расставлены неверно.

SMM – специалисты. Безусловно, это направление становится все более популярным, есть ниши бизнеса, где мало какие каналы продвижения дадут хороший результат, кроме того же Инстаграм или Вконтакте. Есть ниши, где на вопрос клиента «какие каналы для продвижения бизнеса выбрать?» мы с ходу знаем ответ. Чем отличается эта сфера продвижения в Интернете: здесь не так много агентств, специализирующихся только лишь на SMM; зато почти каждое агентство, которое занимается продвижением, «заодно» предлагает и SMM (при этом оно может не иметь хороших специалистов; может работать с фрилансом или удаленными сотрудниками и т.д.). В этой нише очень много частников, работающих с той или иной степенью качества и демпингующих, их больше чем разработчиков сайтов. Причем, если фрилансер сделал сайт плохо (как часто бывает) это видно быстро; что касается продвижения в соцсетях – тут не сразу понятно, как контролировать эффективность.

В чем же дилемма: вроде бы «выращивать» своего специалиста — это дешевле, чем платить подрядчику (он ведь, такой-сякой, не только своим сотрудникам платит зарплату, но и зарабатывает прибыль), и вроде бы IN-HOUSE он сидит в офисе, под контролем и должен лучше вникнуть в бизнес клиента. С другой стороны, с агентства можно спросить, как следует, и пусть даже его услуги стоят дороже; там есть руководители, которые вполне обычные предприниматели, а значит, ориентированы на результат (вероятно).

И тут есть две крайности: во-первых, точно имеет смысл брать некоторые работы IN-HOUSE, а некоторые не брать, если у вас реально не огромный бизнес (поговорим об этом ниже). И ошибки в этом могут дорого стоить. В некоторых случаях, свой сотрудник может очень оперативно работать и действительно «радеть за дело»; в некоторых случаях попытка сэкономить и нанять человека на зарплату встанет «в копеечку». Гораздо эффективнее нанять на аутсорсинг специалиста, который много лет ведет проекты, в том числе для «сложных» клиентов, имеет «за плечами» не одни профильные курсы и обширную практику. У специалистов на окладе просто может не быть такой практики, и обучение займет годы.

Коли уж начали говорить про соцсети, хороший SMM-проект имеет две основных составляющих: работа с контентом и модерацией сообществ и собственно реклама (таргетированная) либо реклама в сторонних сообществах и т.д. Скажем сразу: IN-HOUSE выгоднее брать контентщика. Можно найти сотрудника, который грамотно и интересно пишет, сработаться с ним. Попросить агентство, чтобы они обучили его адаптировать контент под все соцсети; отвечать на комментарии и заявки из сетей, модерировать сообщества и т.д. Такой специалист действительно может работать на окладе, выполнять в целом функцию PR-щика, например, еще и готовить пресс-релизы, общаться со СМИ и бывать на оффлайн-мероприятиях, представляя компанию. Потом тут же писать событийный контент.

Контент-менеджер – может быть в целом как аутсорс так и IN-HOUSE; главное, чтобы человек выделял время, писал эффектно и грамотно (!), профессионально и вам нравился результат. Чтобы «чувствовал» проект. Как правило, это вопрос профессионализма (с обеих сторон) и взаимопонимания.

На аутсорсинг лучше взять таргетологов. Это сложная работа и нужно специально ей учиться, нарабатывать практику, много времени потратить на обучение. Лучше не ждать, пока научится «свой», легче договориться за адекватную цену с агентством. Кстати, в стоимость войдет так же строгая отчетность и соблюдение итоговых показателей. Задача нанять и обучить, а главное, контролировать таргетолога – обычно слишком сложна для заказчика.

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

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

Если же у вас большой бизнес, известный бренд, то гораздо эффективнее платить от 50 – 100 тыс. рублей в месяц профессиональному агентству. Они обеспечат показатели (это будет прописано в договоре), эффективность и бесперебойную работу по продвижению. Если за вами стоит бренд – нельзя портить себе репутацию некачественными объектами в социальных сетях.

Особо так же отметим, что с маленькими бюджетами (до 10-20 тыс. рублей в месяц) в SMM-продвижении работать очень сложно. Работы много, а результат, зачастую мал. Увы.

Поговорим о дизайне. Дизайнеры бывают двух категорий – полиграфисты и веб. Они работают по-разному. Дизайнера полиграфии – можно брать IN-HOUSE спокойно (при наличии должного объема работы). Можно нанять человека и он будет работать за стабильную зарплату. Таких на рынке труда много, и если сработаться – то это партнерство на долгие годы. Здесь опять встает вопрос профессионализма и понимания, а еще – ответственности.

А вот веб-дизайнера лучше всего брать на аутсорсинг. Человек, который профессионально рисует сайты, покажет вам портфолио, и можно определиться, подходит ли вам его стиль; либо агентство выделит сотрудника под ваш проект. Огромная ошибка – брать в штат программиста и заставлять его делать дизайн сайта. Это не его профиль и потом, скорее всего, придется все переделывать или «жить» с сайтом без дизайна. Так делают многие и это сразу заметно.

Администрирование сайтов (размещение новостей, ведение блога) лучше поручить сотруднику IN-HOUSE. Это, по сути, тоже контент-менеджер, он может так же одновременно заниматься контентом в социальных сетях. Техническую же поддержку сайтов (почистить сайт от вирусов, оптимизировать какие-то SEO-моменты, поправить верстку) – лучше не пробовать осуществлять самостоятельно, если в штате нет опытных программистов. Можно «сломать» сайт. Лучше платить небольшую сумму ежемесячно агентству, которое по необходимости выделит на часок – другой соответствующего сотрудника. Лишком много всего может случиться.

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

Ситуация 1. Торговая компания, занимаются продажей крепежных изделий. Сайт старый, нужно разработать новый интернет-магазин, с интеграцией 1С и платежных систем. Проводят конкурс. Среди предложений были суммы и 2 млн. рублей, и 400 тыс. рублей, и 800 тыс. рублей, и одно из них было нашим. Но они решили, что выгоднее нанять программиста, который им за зарплату все напишет. Не напишет, как мы и думали. Год прошел – воз и ныне там. Сложная разработка — это продукт команды специалистов разного профиля с глубокими компетенциями каждого в своей сфере. И наш потенциальный заказчик недополучает прибыль. Либо, нанятый человек будет делать этот сайт в течение года и за это время «проест» гораздо больше денег при сомнительном успехе всей затеи.

Ситуация 2 – сайт комплекса отдыха. Его написал IN-HOUSE сотрудник на своем коде, делал полгода, более-менее нормально получилась только главная страница. Но он уволился, мы стали оказывать техническую поддержку и оказалось, что разбираться в его коде и работать с сайтом невозможно. Многие вещи еще даже не написаны! Сложная ситуация. Выход – переделывать сайт заново. И это печально. Жаль не только денег, но ведь это еще и большая работа: согласовывать дизайн, готовить контент и т.д.

Единственное исключение, когда можно взять разработчиков сайтов и мобильных приложений IN-HOUSE – если у вас реально крупный бизнес, например, розничная сеть, мобильное приложение и сайт использует много людей. Тогда имеет смысл построить своей серьезный отдел, где будет и дизайнер, и аналитик, и разработчики. Но в случае разовой, пусть даже дорогой разработки – компания на аутсорсинге, которая уже реализовала много таких проектов, с радостью все исполнит, и сработает на качество – ведь это их бизнес. А не работа, которую шеф «докинул» к основному кругу обязанностей.

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

SEO-специалисты и директологи (контекстная реклама Яндекс и Google) — редко работают IN-HOUSE. Чаще всего люди, которые умеют это качественно делать, без работы не сидят. И либо это фрилансер, который работает из дома и ему совсем не хочется сидеть у вас в офисе, либо это человек, который уже работает в агентстве на хорошей зарплате и ведет много проектов, и он профессионал с многолетним опытом в самых разных нишах. «Доморощенные» эксперты в штате по таким видам продвижения – очень плохой выход.

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

+7 (3852) 57-07-32
Заказать звонок

В чем разница между «in house», «remote», «freelance»?

Как пример, на https://toprubyjobs.com, часто вижу такие фильтры. Это же все удаленная работа, т.е для фрилансера или нет?

Вопрос задан более трёх лет назад
29114 просмотров

Комментировать
Решения вопроса 2
Full-stack developer (Symfony, Angular)

In-house это не «работа у себя дома» а у работодателя, то есть в офисе. remote — удаленно но в рамках одного работадателя. freelance — на конкретный проект.

Ответ написан более трёх лет назад
Нравится 9 1 комментарий
rusik @rusik Автор вопроса
Сергей, спасибо за ответ,а по подробней можно? В сo-working center может?

RicoX

Ушел на http://ru.stackoverflow.com/

In-house — работа в офисе
remote — удаленная постоянная работа в рамках одного или нескольких заказчиков.
freelance — шабашка, ну когда заказчиков много разных на разовые проекты или задачи.
Если вам платят за ваше существование вне зависимости отобъема проделанной в месяц работы — это удаленка или remote, если за конкретные задачи и проекты — это фриланс.

Купить или создать: особенности in-house разработки технологических решений в финтех-компании

Рассказ о том, как правильно расставить приоритеты и грамотно построить процессы in-house разработки.

Создание новых технологических решений, лежащих «под» продуктовой логикой и бизнес-процессами, — это сложная задача для компании любого масштаба. Учитывая, что сегодня у компаний есть выбор, — создать новое с нуля или приобрести готовое решение, главное — правильно этот выбор сделать. Кирилл Ермаков, Chief Information Officer QIWI Group, рассказал, как правильно расставить приоритеты и грамотно построить процессы in-house разработки.

Кирилл Ермаков
Chief Information Officer QIWI Group

Дилемма инноватора

Запуск любого IT-продукта — это долгий и трудоемкий процесс, при котором всегда что-нибудь идет не по плану. Перед деплоем всплывают серьезные баги, сроки сдвигаются, а иногда резко меняется стратегия — и продукт приходится изобретать заново. Особенно это касается масштабных запусков: по данным McKinsey, крупные IT-проекты в 45% случаев выходят за рамки бюджета, в 7% — за рамки дедлайна. От запланированных сроков исполнения вообще зависит многое — каждый дополнительный год разработки увеличивает сверхнормативные расходы на 15%. Обычно они связаны с некорректным планированием или исполнением: например, команда изначально поставила неверную цель или установила нереалистичный дедлайн.

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

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

Интересно, что три года назад аналитики IDC прогнозировали, что к 2020 компании будут тратить на покупные решения больше, чем на собственные разработки. Действительно, сегодня доступных SaaS-решений стало больше, а их средняя стоимость снизилась. Параллельно с этим развиваются open source платформы. Предполагается, что уже к 2021 две трети всего софта, используемого корпорациями, будет с открытым кодом. Многие также используют гибридный подход — например, создают собственное решение, дорабатывая open-source продукт, или комбинируют несколько готовых решений, создавая свою кастомизированную версию.

Собственные разработки: кому и зачем нужны

In-house разработка в компаниях — как технологических, так и финтех- и банках — существует на двух уровнях:

продуктовая разработка — технологию рассматривают как готовый продукт, являющийся драйвером для бизнеса, и в процессе участвуют продуктовые команды;
технологический in-house — компания изобретает технологическую платформу «под капотом», которая решает конкретную проблему, при этом продуктовая бизнес-логика на этом уровне не применяется.

Например: движок базы данных — это технология, а когда его дорабатывают, дополняют интерфейсом, бизнес-логикой и интегрируют с другими сервисами — это уже продукт

Для начала разберем плюсы и минусы in-house разработки. Можно выделить как минимум четыре недостатка технологических решений своими силами:

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

Но плюсов все же больше:

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

Возьмем, к примеру, небольшой стартап, которому нужна умная CRM-система или платформа для бухучета. В этом случае in-house разработка не имеет смысла — вы зря потратите время и деньги. Но крупная технологическая компания, которой нужны комплексные и нестандартные продукты, извлечет из in-house большую выгоду. Особенно это касается сферы финтеха. Традиционно это более гибкая и адаптивная отрасль, в которой IT-составляющая всегда играла важную роль. Классические финансовые компании обычно покупают готовые сервисы — далеко не у всех есть своя система процессинга платежей или АБС.

Мы изначально не пошли по такому пути финансовых компаний. С момента создания QIWI работала как IT-компания и с нуля создавала процессинг терминалов. Поэтому мы сразу же делали ставку на in-house и для этого строили культуру внутренней разработки и автоматизации. Сразу стало понятно, что технологической компании нужны мощные подразделения с командой сильных программистов — скромного IT-отдела будет недостаточно. А для этого нужно наращивать экспертизу за счет разработки собственных технологий.

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

Постепенно мы пришли к гибридной модели разработки и в других подразделениях. В общей сложности сегодня QIWI использует шесть собственных процессингов и два покупных решения — это АБС и карточный процессинг. Кроме того, мы построили собственный отдел разработок в сфере информационной безопасности, а также подразделение, которое создает продукты для бэкофиса. Это помогает с легкостью кастомизировать покупные продукты и оптимизировать их под свои задачи, продолжая при этом работать над in-house разработками и выкладывали решения в открытый доступ.

Так, например, благодаря собственному отделу ИБ-разработок QIWI смогла создать платформу для обнаружения утечек исходных кодов Leak-Search — она помогает компании отслеживать утечки исходных данных и чувствительной информации. Например, если сотрудник выкладывает код в репозиторий, не осознавая, что в нем содержатся пароли от базы данных или конфигурации сетей. Мы просто не нашли в тот момент достойного и быстрого решения для автоматического мониторинга, поэтому разработали его своими силами и начали использовать в контуре компании — а затем, убедившись в эффективности платформы, предложили ее рынку.

Build vs. Buy: как определиться

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

Определяем цели и желаемый результат — это помогает четко сформулировать, что именно нам необходимо.
Проводим продуктовый анализ: изучаем, какие альтернативы уже есть на рынке и решают ли они поставленную задачу. Если находим целесообразное решение, отказываемся от in-house разработки. Если нет, переходим к третьему пункту.
Оцениваем не только стоимость разработки, но и косты дальнейшей поддержки с учетом количества задач и затраченных на них часов (cost of ownership). Лучше измерить потенциальные затраты помогает оценка в диапазоне 3-5 лет с учетом всех будущих апдейтов. Очевидно, что статичный продукт нам не нужен, поэтому инвестировать в него придется постоянно.
Заранее выясняем, есть ли продуктовый потенциал и можно ли построить отчуждаемое решение, которое сможет существовать независимо от инфраструктуры QIWI.

In-house в технологических корпорациях

Построение отдельного бизнеса на базе технологического in-house — нормальная практика в IT. Часто гиганты рынка создают профильные решения под свои нужды, а потом масштабируют и выкладывают в открытый доступ. Так делают и Google, и Яндекс. Один из самых успешных кейсов — Amazon, которая до недавнего времени получала основную долю прибыли не от своего торговой площадки, а от облачной системы AWS. Пример технологического in-house на российском рынке — Mail.ru и ее база данных Tarantool. Компания не нашла на рынке эффективной базы для хранения горячих данных и создала свою, которую вскоре выделила в отдельное продуктовое направление — и сейчас занимается ее развитием, предлагая сервисы Tarantool рынку.

Продуктовая разработка. О чём не рассказывают на собеседованиях

Еще один похожий кейс — аналитическая система управления базами данных ClickHouse. Изначально она создавалась для Яндекс.Метрики, но в какой-то момент продукт вышел из-под контроля — в хорошем смысле, — и его стали использовать в Директе, Маркете, Почте, AdFox, Вебмастере, а также в мониторингах и бизнес-аналитике. ClickHouse работал эффективнее аналогов, а в некоторых случаях решал задачи, с которыми другие инструменты не справлялись. В результате команда Яндекса открыла доступ к ClickHouse, опубликовав исходники на GitHub.

Впрочем, часто IT-гиганты находятся в своем информационном пузыре и начинают терять связь с рынком. Они могут тратить годы на создание технологии, которая решает задачи только самой компании, но не находит отклика у рынка. Например, Google в 2011 году свернула свой проект Labs, который занимался инновационными разработками, многие из которых закончились провалом. Изначально компания делала ставку на быстрые запуски продуктов, но потом поняла, что слишком часто «промахивается» — и поменяла модель. Другой пример — хостинг Google Code, который закрылся в 2016 году — спустя 8 лет после запуска GitHub, который оказался более успешным. На финансовых показателях Google это сказалось несущественно — IT-корпорация может переносить даже миллионные потери, но для компании меньшего масштаба это был бы огромный риск.

Чтобы этого не произошло, важно на определенном этапе подключать продуктовую логику — то есть перейти от разработки технологического решения к разработке готового продукта. Поэтому для развития, а главное, продвижения внутренних инноваций на внешние рынки нужно создавать не только сильную IT-команду, но и подразделение продуктовой разработки. Иногда «продакты» помогают понять, в каком направлении двигаться — и благодаря им внутренние проекты превращаются в успешный бизнес. Один из таких примеров — неожиданный успех игровой студии Tiny Speck, которая в начале 2010-х решила создать сервис для упрощения коммуникаций в команде. Так появился корпоративный мессенджер Linefeed, а через несколько лет он получил новое название — Slack. Первое время его использовали только четыре разработчика, но потом команда привлекла к тестированию своих друзей из других компаний — собрав фидбек, она улучшила продукт и смогла вывести его на рынок. Так появился сервис, который полностью изменил подход к корпоративным коммуникациям.

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