Проект in house что это

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

Авторизуйтесь

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

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

Проект in house что это. Смотреть фото Проект in house что это. Смотреть картинку Проект in house что это. Картинка про Проект in house что это. Фото Проект 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 разработки. Можно выделить как минимум четыре недостатка технологических решений своими силами:

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

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

Построение отдельного бизнеса на базе технологического in-house — нормальная практика в IT. Часто гиганты рынка создают профильные решения под свои нужды, а потом масштабируют и выкладывают в открытый доступ. Так делают и Google, и Facebook, и Яндекс. Один из самых успешных кейсов — 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. Первое время его использовали только четыре разработчика, но потом команда привлекла к тестированию своих друзей из других компаний — собрав фидбек, она улучшила продукт и смогла вывести его на рынок. Так появился сервис, который полностью изменил подход к корпоративным коммуникациям.

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

Источник

Опыт работы in-house: что это такое и в чем преимущества такого опыта?

Проект in house что это. Смотреть фото Проект in house что это. Смотреть картинку Проект in house что это. Картинка про Проект in house что это. Фото Проект in house что это

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

Удаленная работа (remote job). Эт о та работа, которая выполняется дистанционно. Это может быть официальная работа в компании, а может быть и фриланс. Может быть один заказчик, а может быть несколько.

Инхаус — обычная работа в офисе.

Инхау с — что это?

Очень часто это т термин понимают дословно, то есть «in house» — значит «в доме». Поэтому думают, что инхау с — это работа из своего дома. Но это совсем не так, инхау с — это официальная работа в офисе.

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

Инхау с очень часто применяется в IT-индустрии. В основном такой вид деятельности используют крупный и средний бизнес. Но также инхау с пользуется популярностью у стартапов. Почему так происходит? Потому что инхау с обладает рядом преимуществ.

Преимущества инхау с

Когда IT-деятельность осуществляется в офисе, у этого есть ряд преимуществ:

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

Из недостатков такой модели можно выделить следующие :

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

в инхау с зарплата специалиста редко бывает «ниже рыночной», что не скажешь про удаленных сотрудников или фрилансеров;

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

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

Заключение

Инхау с — это быстрый опыт, стабильность, постоянная работа, а если компания успешная, то это еще и престиж. Удаленка или фриланс — это больше свободного времени, иногда вообще больше свободы и меньше зависимости от начальства, больше свободы творчества, практически нет ограничений. Поэтому это как весы: на одной чаше — опыт и стабильность, а на другой — свобода в разных ее проявлениях. Что для вас ценнее и какая чаша весов «перевесит» — к той модели организации своей деятельности и нужно стремиться!

Мы будем очень благодарны

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

Источник

Фрилансер, инхаус или студия: как выбрать исполнителя

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

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

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

Из предыдущих материалов вы узнаете:

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

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

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

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

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

Источник

Персонализированные (in-house) системы закупки рекламы в России и мире

Владимир Климонтович, СТО GetIntent, о развитии in-house programmatic

Проект in house что это. Смотреть фото Проект in house что это. Смотреть картинку Проект in house что это. Картинка про Проект in house что это. Фото Проект in house что это

В настоящее время на мировом рынке programmatic растет потребность в персонализированных системах закупки рекламы, то есть в создании in-house DSP-платформ. Такая тенденция наблюдается как у крупных рекламных агентств, ad tech компаний, так и заметно увеличивается спрос у рекламодателей – брендов с внушительными рекламными бюджетами или тех, бизнес которых сопряжен с работой с большими данными. На американском рынке такие компании представлены финансовым сектором и FMCG-индустрией. В пример можно привести кейсы таких брендов, как Netflix и Kellogg, Red Bull и GoPro. Сюда же можно отнести компании, бизнес которых сильно зависит от сезонных факторов, или, наоборот, очень непредсказуем.

Исследование американской компании Index Exchange показали, что категория расходов рекламодателей через in-house DSP уже сейчас самая быстрорастущая по сравнению с остальными способами работы с programmatic (через агентства, trading desks и т.д.). В 2013 году доля in-house закупок составляла 11%, а к концу 2014 года она достигла уже 15% (в 2012 году доля была равна всего 3%). Это единственная категория, которая показывает стабильный рост, доли других направлений programmatic закупок сокращаются. Однако все категории растут в долларовом выражении, что связано с общим ростом рекламных расходов, приходящимися на programmatic, отмечал эксперт Index Exchangeв в комментариях AdAge.

Выступая за создание in-house технологий, все участники рынка имеют ряд одинаковых мотивов: сделать programmatic закупки более прозрачными и понятными, экономичными и эффективными, самостоятельно контролировать все этапы, начиная от создания технологий под определенные нужды бизнеса и заканчивая возможностью быстро реагировать и управлять ходом рекламных кампаний. А также они стремятся к повышению конкурентоспособности, замыкая внутри компании основные данные и знания о клиентах (first-party data).

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

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

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

В случае агентств ситуация сложилась следующая. Традиционно рекламные агентства играли ведущую роль в закупках рекламы. С развитием технологий и новых возможностей, предлагаемых ad tech компаниями, у рекламодателей появилась возможность обходить агентства, сокращая расходы и при этом наиболее точно таргетируя свою целевую аудиторию. Конечно, нельзя сказать, что это конец эры digital-агентств: ведь их креативность, экспертиза и многолетний опыт не сопоставимы с технологическими компаниями. Однако, чтобы удерживать клиентов и оставаться конкурентоспособными на рынке, агентства должны научиться сочетать свои основные таланты и конкурентные преимущества с новыми технологиями в рекламе. Именно по этим причинам агентства начинают задумываться об инвестициях в создание собственной DSP-платформы.

Как считает CEO Index Exchange, топовые рекламодатели, в свою очередь, постепенно разочаровываются в подходе рекламных агентств к programmatic. Вместо того, чтобы просто вслепую доверять агентствам, компании хотят понимать, как именно расходуются их бюджеты, и действительно ли это настолько эффективно и удовлетворяет конкретным потребностям бизнеса. Другими словами, проблема непрозрачности programmatic-сервисов стала серьезным поводом для крупных брендов задуматься о создании in-house решений. Кроме этого, передача рекламных кампаний «на аутсорс» другим DSP-платформам (через агентства, ad tech компании или напрямую DSP-провайдеру) априори приводит к снижению конкурентных преимуществ крупных рекламодателей. Что это значит? Любая DSP-платформа – это уже готовое к использованию решение, и оно одинаково для всех. Конечно, набор функционала и различных наворотов будет незначительно отличаться и может немного «подкручиваться» в соответствие с потребностями клиента. Но в любом случае рекламные технологии остаются абсолютно некастомизированными, то есть рекламодатели по сути используют те же самые технологии, что и их конкуренты. Персонализированными могут становиться решения лишь тогда, когда они будут создаваться под конкретные кампании, с использованием уникальных моделей и сочетаний данных бренда, знаний о том, как себя вели потребители во время прошлых рекламных кампаний.

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

Инвестируя в создание собственной DSP, бренды получают ряд существенных преимуществ. Во-первых, это, конечно же, работа с данными. In-house решение позволяет максимально эффективно использовать свои собственные данные о клиентах (first-party data), не передавая информацию вовне. Также это возможность быстро реагировать на любые изменения рынка, поведения покупателей и т.д. Этому способствует сосредоточенность всех отделов, вовлеченных в процесс, внутри компании, когда programmatiс, social media команда, специалисты по контексту, маркетинг и продажи могут моментально делиться инсайтами и вносить необходимые корректировки в текущую кампанию.

Международные и российские продукты

В настоящее время созданием подобных продуктов занимаются международные компании GetIntent, IPONWEB, Datacratic, частично APPNexus.

В России такое решение есть только у компании GetIntent. RTBSuite – это софт Enterprise-класса для создания собственной DSP и DMP в срок от месяца. Клиент получает решение, которое включает в себя биддер, алгоритмы предиктивной аналитики и работы с большими данными, отчетность, а также пользовательский интерфейс. Все модули могут быть установлены как на сервера клиента и интегрироваться в его действующую инфраструктуру, так и на сервера дата-центра GetIntent с операционной поддержкой по системному администрированию. Платформа поддерживает все форматы рекламы: десктоп, видео, мобильной и нативной. Модель оплаты может быть выгодней для клиента: вместо процента от выручки компании RTBSuite имеет более гибкую систему оплаты за годовое обслуживание сервиса. Кроме того Getintent дает клиенту возможность самостоятельно кастомизировать систему, если у клиента есть свои Java-разработчики.

IPONWEB предлагает персонализированные programmatic технологии в виде SaaS (software as a service) DSP. Если не брать во внимание достаточно высокую стоимость этих продуктов, SaaS формат – это отличное решение для стартапа или небольшого бизнеса. Нет необходимости тратить время и огромные деньги на создание собственной технологии. Однако по мере роста компании, SaaS DSP только препятствует ее дальнейшему развитию и сильно ограничивает гибкость. Это проявляется, например, в сложности интеграции любого нового функционального инструмента, который разработан внутри компании на ее сервере, с сервером SaaS провайдера. Любая доработка будет производиться специалистами IPONWEB, и нет возможности самостоятельно кастомизировать.

Datacratic предлагает довольно простой open-source софт RTBKit, поверх которого клиент может писать доработки самостоятельно или приобретать RTB Optimizer уже за деньги.

AppNexus дает очень гибкий доступ к своему облачному хранилищу API (Application Programming Interface). Клиент может не только использовать свой интерфейс поверх их биддера, но и разработать свою модель или логику показов, которая через API будет в реальном времени «общаться» с биддером AppNexus. При этом никакой кастомизации, и оплата идет в процентах от media cost.

Как внедрять inhouse технологии

Теперь, когда мы рассмотрели все причины возросшего спроса на in-house programmatic решения, возникает вопрос, каким образом лучше внедрять in-house технологии: создавать DSP собственными силами c нуля или лицензировать решение?

Создавая DSP c нуля, агентства и бренды могут потерять в экспертизе и квалифицированной поддержке, которые обычно предоставляют DSP-вендоры, и что можно получить, лицензируя технологию. Также собственная разработка потребует слишком больших финансовых вложений, как на создание, так и на дальнейшую поддержку решения, поиск и/или обучение соответствующих технических специалистов, которые смогут работать с системой и обслуживать ее. Ad tech компании уже имеют квалифицированную команду специалистов, обладают необходимыми технологическими мощностями и опытом. В этом случае самостоятельная разработка все равно будет стоить довольно дорого и понадобится около года времени, иногда даже без достижения гарантированного положительного результата.

Еще один вариант – лицензирование технологий, как в случае с RTBSuite. Оно в первую очередь подойдет ad tech компаниям, которые уже имеют какие-либо рекламные технологии (SSP, DMP и т.д.), и им нужна еще и DSP. Также агентствам и компаниям, готовым инвестировать в технологии, и в штате которых есть соответствующие технические специалисты. И, наконец, брендам, которые располагают значительными бюджетами на programmatic-рекламу.

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

In-house programmatic решения можно назвать новой эрой в развитии индустрии. Пока данный тренд достаточно сильно заметен на американском и европейском рынках. В России постепенно начинают говорить об этом – реальный интерес к in-house технологиям заметен пока только у ad tech компаний. В перспективе же потребность в таких продуктах может возникнуть у всех участников рынка. Единственным препятствием может стать цена решения: бюджеты российских компаний, которые они готовы использовать на развитие технологий в рекламе, не сопоставимы, например, с американскими. Других принципиальных ограничений нет.

Автор: Владимир Климонтович,
СТО и сооснователь GetIntent

Источник

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *