Почему инхаус-разработка кажется выгодной
Рассмотрим типичный сценарий: компания, не имеющая профильной экспертизы в IT, хочет построить хранилище данных. Для этого требуются специализированные решения, которые можно разработать самостоятельно или воспользоваться продуктами вендоров. Предварительная оценка затрат на собственное или готовое решение может не сильно отличаться. Поэтому на начальном этапе инхаус-разработка кажется привлекательной: отсутствие лицензионных платежей, контроль над процессом, гибкость решений и возможность тиражирования в собственной или дочерних компаниях без дополнительных затрат. Но помимо разработки есть множество сопутствующих процессов и особенностей, которые не всегда удаётся принять во внимание или оценить на первом этапе. Именно они становятся в дальнейшем причиной основных проблем.
«Надо понимать, что IT-подразделения в большинстве компаний — это сервисные подразделения, которые предоставляют IT-сервисы для поддержания основной деятельности бизнеса. Разработка серьёзного продукта в области управления данными требует значительных ресурсов: временных, кадровых, финансовых и научных».
Ключевые риски инхаус-разработки
Если компания решает пойти по пути разработки ПО собственными силами, то ей стоит внимательно изучить и оценить возможные риски и сложности, с которыми она может столкнуться. И речь не просто о трудностях, а о критичных проблемах, которые ведут к дополнительным расходам и даже остановке бизнес-процессов.
«Основные риски, с которыми мы сталкиваемся при инхаус-разработке, чаще связаны не столько с технологиями, сколько с организационными и управленческими аспектами. Поверхностное видение результатов у заказчика — одна из главных проблем. Если бизнес-цели не синхронизированы между отделами, разработка рискует превратиться в „решение ради решения“. Мы активно работаем над тем, чтобы избежать этого, выравнивая цели всех заинтересованных сторон и обеспечивая прозрачность процессов».
«В инхаус-разработке подводные камни часто скрываются в недооценке сложности интеграции новых решений друг с другом и с уже существующими системами. Другая проблема — инженерам интересны новые технологии, и, если их оставить без человека, который следит за движением продукта и понимает, какую задачу мы решаем, мы с высокой вероятностью получим классное технологическое решение, которое организации не нужно. Коммуникации — это задача, требующая постоянного внимания: если разные команды не общаются друг с другом, возникает изоляция, люди теряют общее видение проекта, результата просто не будет».
Расчёт полной стоимости владения продуктом
Главное заблуждение — экономия. Компании забывают, что разработка продукта с нуля требует значительных инвестиций в процессы и перестройку работы IT-команды. Развёртывание и поддержка технологического продукта принципиально отличаются от внедрения бизнес-решения. Нужно учесть не только зарплаты сотрудников, но и, например, расходы на инфраструктуру, сопровождение и поддержку продукта. «Подобно тому, как никто не пытается разработать свою уникальную операционную систему, дешевле и практичнее использовать готовое решение», — подчёркивает Дмитрий Новиков. Таким образом, если посчитать полную стоимость владения решением, станет понятно, что инхаус-разработка дешевле только на первый взгляд.
Сложности в найме специалистов, разбирающихся в технологиях
Формирование инхаус-команды сталкивается с ключевой проблемой — нехваткой квалифицированных специалистов, обладающих необходимыми техническими навыками. В условиях кадрового голода на рынке IT становится всё сложнее найти таких сотрудников. «Кадры и их квалификация влияют на процесс инхаус-разработки напрямую, причём не только IT-кадры. Очень много зависит от качественно выстроенных коммуникаций», — комментирует Дмитрий Новиков.
Компании, решившие создать собственные продукты, нередко сталкиваются с тем, что разработка требует серьёзной экспертизы, которой просто нет в доступном пуле кандидатов. Например, при разработке корпоративной платформы для управления данными наличие опытного системного архитектора критично: рассмотрим самый простой вариант, когда доработка open source кода не требуется, нужна только грамотная сборка кодовой базы в работающий продукт. Однако поиск такого специалиста может затянуться на длительный срок. Опрос «Сколько времени в вашей компании занимает закрытие вакансий дата-архитекторов в офисе CDO?», проведённый Arenadata, показал, что 29% компаний занимаются поиском подходящего кандидата 3–6 месяцев. 27% опрошенных тратят на эту задачу более года, 26% закрывают вакансию от 6 месяцев до 1 года. Речь идёт о достаточно актуальной профессии. Системный архитектор, который разбирается в потребностях бизнеса и является специалистом в системных технологиях, востребован прежде всего у компаний разработчиков. Их растят и берегут производители программного обеспечения. При этом без такого специалиста команда теряет время, разработка программного продукта невозможна, а проект фактически «замораживается» до момента найма. Кроме того, если проект уникален для компании, новому специалисту в системных технологиях потребуется время на погружение в бизнес-процессы, логику продукта и внутреннюю архитектуру системы. Это увеличивает временные и финансовые затраты, что делает инхаус-разработку менее гибкой в условиях меняющихся требований бизнеса.
«Квалификация команды — это, безусловно, критический фактор, но не менее важно учитывать риски, связанные с потерей экспертизы при уходе ключевых специалистов. Data Governance помогает смягчить эти риски благодаря нескольким ключевым механизмам. Во-первых, это документация и стандартизация процессов, которые позволяют новым сотрудникам быстрее включаться в работу. Во-вторых, это внедрение системы поиска данных, которая значительно ускоряет анализ и, как следствие, вывод задач в продуктив», — объясняет Николай Шевцов.
Специалисты-«многостаночники»
Даже если команда нашлась, её знаний может не хватить для решения всех задач. Разработка требует опыта в различных технологиях: от баз данных до облачных вычислений. В отличие от вендоров, которые могут задействовать широкий пул экспертов, компания вынуждена полагаться на ограниченный штат сотрудников. Как правило, бизнес старается нанять многопрофильных специалистов, которые обладают компетенциями во всех сферах. Но крайне редко бывает, что человек одинаково хорошо разбирается во всех технологиях разработки ПО. В итоге появляются «костыли» и компромиссные решения, которые могут сработать в моменте, но создадут технологический долг и снизят устойчивость системы в будущем. «Стремление быстро выпустить MVP с ограниченной командой может привести к накоплению проблем, которые при масштабировании проекта серьёзно тормозят его развитие. Мы осознаём этот риск и стараемся находить баланс между скоростью вывода продукта на рынок и качеством его реализации», — комментирует Николай Шевцов.
Удержание экспертов даже более сложно, чем их поиск
Даже если компании удалось собрать сильную команду, возникает новая проблема — удержание ключевых специалистов. Текучесть кадров в IT-сфере высока, особенно среди разработчиков, которые трудятся над долгосрочными проектами. При этом нужно учесть мотивацию сотрудников. Так, некоторые специалисты заинтересованы только в разработке и внедрении ПО. А затем им становится скучно заниматься поддержкой, и часто они покидают проект, несмотря на значительные предложения по росту компенсации. В этом случае компании придётся заново собирать команду, обучать её, то есть, по сути, всё начинать заново.
«Квалификация команды — это самое главное вообще в любой деятельности, не только для успешной инхаус-разработки. Если у специалистов не хватает опыта или навыков, то и результат будет, но несколько не тот, который вы ожидаете. Плюс возникает зависимость от команды, написавшей тот или иной компонент внутри. Потеряли команду — и в некоторых случаях начинай сначала», — говорит Александр Сабуров.
Если ведущий архитектор или разработчик покидает компанию, после него остаётся сложная архитектура и сложный код, в которых трудно разобраться. Почти во 100% случаев это отягощается устаревшей, неточной или вообще отсутствующей рабочей документацией. В результате новый IT-отдел может отказаться поддерживать существующую систему и предложить создать её с нуля, что потребует значительных затрат. На рынке есть множество примеров, когда проект буквально рассыпается из-за ухода ключевого сотрудника. В этот момент руководство компании сталкивается с дилеммой: либо срочно искать замену с негарантированным результатом (что в условиях дефицита кадров крайне сложно), либо внедрить стабильное решение от вендора.
Развитие продукта по остаточному принципу
Часто компании ошибочно полагают, что инхаус-разработка завершается на этапе развёртывания системы. Однако после установки только начинается самая сложная работа: поддержка, обновления и масштабирование. Здесь команде инхаус-разработки придётся в первую очередь решать задачи бизнеса: устранять технические сбои, адаптировать систему под изменяющиеся требования, обеспечивать бесперебойную работу. При таком подходе развитие продукта уходит на второй план.
Когда приоритет отдаётся исключительно оперативным нуждам бизнеса, продукт перестаёт эволюционировать, теряя конкурентные преимущества. Вместо внедрения новых функций команда тратит ресурсы на «тушение пожаров»: устранение технического долга, поддержку устаревших решений и экстренные исправления.
В итоге без стратегического видения и инвестиций продукт рискует остановиться в своём развитии, а бизнес — столкнуться с ограничениями, которые не позволят эффективно расти и адаптироваться к новым задачам.
Когда инхаус-разработка оправдана
Разумеется, есть случаи, когда инхаус-разработка имеет смысл. Например, если компания занимается IT-разработкой как своим основным бизнесом, обладает достаточным кадровым резервом и возможностью масштабировать продукт на внешний рынок. Примером могут служить крупные банки, которые создают собственные решения. Но такие сценарии — это скорее исключение, чем правило. «Задачи методологии работы с данными, продиктованные политикой компании и законодательством, должны оставаться внутри компании, остальное — должен быть оптимальный выбор по времени и стоимости», — считает Дмитрий Новиков.
Александр Сабуров считает: «В идеальной картине мира, конечно, хочется иметь у себя все компетенции, но это недостижимо. Поэтому задачи, которые ближе всего к нашим внутренним клиентам, к аналитику или DS из бизнеса, например дата-каталог или рабочее место DS, — их имеет смысл брать на свою сторону. А вот собирать 28-ю сборку известной СУБД самим не стоит — уже есть зрелые решения. Если говорить не про платформенные компоненты, то, например, миграцию данных, или реализацию потоков данных по уже сформированным гайдлайнам, или настройку специфичной инфраструктуры — это всё можно доверить внешним подрядчикам».
Если выбирать между собственной разработкой и тиражируемыми решениями от производителей, важно объективно оценивать свои ресурсы, стратегические цели и долгосрочные перспективы. «Я считаю, что анализ бизнес-логики, разработка алгоритмов управления данными, которые напрямую влияют на наши конкурентные преимущества, должны оставаться внутри команды. Это позволяет нам сохранять полный контроль над данными, обеспечивать их безопасность и соответствие бизнес-целям. Что касается типовых процессов, таких как миграция данных или настройка ETL, их можно передать на аутсорс. Однако важно, чтобы при этом соблюдались наши стандарты Data Governance, включая контроль качества данных. Это позволяет нам сосредоточиться на стратегически важных аспектах управления данными, не отвлекаясь на рутинные задачи», — подчёркивает Николай Шевцов.
Как показывает практика, в подавляющем большинстве случаев сотрудничество с производителем оказывается более рациональным вариантом: оно снижает риски, экономит время и деньги, а также обеспечивает доступ к передовым технологиям и экспертизе. Инхаус-разработка — это инвестиции не только в продукт, но и в людей, процессы, сертификацию и поддержку. Если компания не готова к таким вызовам, лучше доверить эту работу специалистам на стороне вендора.
Автор статьи:
Александр Тарасов
Архитектор департамента поддержки продаж Arenadata
Источник: Connect-Wit.