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

Инхаус-команда vs внешнее агентство. Что выбрать?

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

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

3.2K открытий
3 комментария

Хех, ну это не «vs», это перечисление перечня из 2 пунктов.

Развернуть ветку
№ 4. Экономия на программном обеспечении.

Вот про это не понял. Вы про лицензионные шрифты и фотошоп?

Развернуть ветку

При нормальной организации работы пункты 1-3 вполне реальны и реализуемы. Никто не мешает погрузить проектного специалиста в детали и стратегию, ну а говорить о простоте коммуникации, когда весь мир второй год сидит на удаленке вообще смысла нет. Пункт 4 зависит от проекта, агентства, уровня специалистов. Скажу по своему опыту. 95% моих клиенты — студии и команды разработчиков, которые предпочитают нанимать меня на проект, а не брать дизайнера в штат.

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

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

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

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

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

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

Ушел на 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 разработка в компаниях — как технологических, так и финтех- и банках — существует на двух уровнях:

1. продуктовая разработка — технологию рассматривают как готовый продукт, являющийся драйвером для бизнеса, и в процессе участвуют продуктовые команды;
2. технологический 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: как определиться

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

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

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

Битва за разработку: инвестировать в решение вендора или собрать

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

В этом материале Юлия Пивоварова, операционный директор Just AI, расскажет об особенностях каждого из подходов — in-house-разработки и работы с вендором, а также прольет свет на третью концепцию, которая сейчас набирает популярность на рынке.

In-house-разработка vs вендор

Для начала разберемся в понятиях.

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

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

Рассмотрим несколько критериев между привлечением вендора и in-house-разработкой.

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

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

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

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

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

Если компания активно занимается цифровизацией бизнеса, она часто приходит к тому, что сроки разработки и доработок под каждый департамент сильно увеличиваются и со временем роадмап превращается в гигантский объем тикетов и задач. Преимущество вендора в том, что часть разработок может быть уже выполнена для другого заказчика и их можно переиспользовать в другом проекте. К тому же зачастую у вендора есть партнерская сеть — он может делегировать часть задач и сократить time-to-market.

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

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

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

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

На что опираться при выборе вендора?

Я выделяю восемь критериев:

• реализованные кейсы;
• сравнение с конкурентами;
• набор уникальных фич/инструментов;
• предложенные KPI от внедрения решения;
• гибкость и адаптация решений вендора под уже существующие инструменты;
• возможность кастомных доработок по мере развития продукта;
• техническая поддержка 24/7, а также обучение сотрудников для дальнейшей работы с продуктом;
• возможность проведения пилотного проекта.

Гибридное решение

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

Под более простыми инструментами подразумеваются no-code-платформы. Они становятся все более распространенными благодаря тому, что позволяют людям, не имеющим навыков программирования, создавать приложения. Эти платформы обычно используют интерфейсы drag-and-drop (способ оперирования элементами интерфейса при помощи мыши или сенсорного экрана) и готовые компоненты, позволяющие быстро и легко «собирать» решения.

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

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

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

Многие платформы no-code интегрируются с другими инструментами и сервисами, такими как CRM-системы, платформы автоматизации маркетинга и инструменты аналитики.

Минусы no-code-платформ. Ограниченная кастомизация. Некоторые специфичные или сложные требования к продукту не могут быть удовлетворены с помощью готовых компонентов платформы.

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

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

Примеры задач, для которых no-code станет эффективным инструментом

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

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

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

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

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

Хотите написать статью?

В рубрике «Блоги компаний» вы становитесь автором и делитесь личным опытом работы с клиентами, партнерами, рынком.

О чем можно рассказать?

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

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

Все подробности о формате, оформлении и возможных темах статей — в телеграм-боте @bs_community_bot.