HRTech: причины разочарования в собственной разработке

Материал входит в серию статей о build vs buy в HRTech.

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

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

В начале 2020‑х этот поворот окончательно закрепился: многие компании реального сектора стали трансформироваться в tech‑компании и создавать ИТ‑дочки для развития собственных платформенных решений. После шока начала 2022 года и ухода западных вендоров с опустевшего рынка эта тенденция только усилилась.

Моё мнение: сейчас рынок снова находится на распутье. С одной стороны, накапливается разочарование в собственной разработке, а на рынке появляются новые игроки с громкими обещаниями непревзойдённого качества. С другой стороны, AI и low-code, которые, вероятно, радикально изменят индустрию разработки, смещают фокус выбора от прикладного продукта к среде разработки.

Ваши ожидания — ваши проблемы, и в этом плане мало что изменилось со времён матча на Евро‑2012. Бизнес часто ждёт от tech «серебряной пули», способной решить все проблемы. Сначала эти надежды возлагались на коробочные решения с набором лучших практик, затем — на собственные разработки.

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

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

Не стоит недооценивать и другой источник разочарования: романтизацию собственной разработки. Многие компании с энтузиазмом открывают tech‑офисы, покупают кофемашины, выстраивают модный внешний контур и на какое-то время начинают чувствовать себя чем-то средним между Apple и Google. Но довольно быстро выясняется, что собственная разработка — это не только эстетика технологичности, но и тяжёлая производственная рутина. Это не разовый проект, а постоянный цикл найма, приоритизации, конфликтов между бизнесом и ИТ, накопления техдолга, сопровождения legacy, интеграций, инцидентов и бесконечных доработок. И когда первая волна энтузиазма проходит, многие обнаруживают, что построили не «ИТ своей мечты», а дорогое и трудноуправляемое производство, которое требует всё больше ресурсов. В этот момент разговоры о технологической независимости часто сменяются разговорами о сокращении костов и переосмыслении роли ИТ.

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

Изменились и сами ресурсы. Если раньше программистами, как правило, становились выпускники профильных технических вузов с сильной инженерной базой, заложенной ещё советской технической школой, то теперь у многих за плечами ускоренные курсы по востребованным языкам программирования. AI и low-code могут стать одним из ответов на эти вызовы: они способны сократить потребность в технических ресурсах и сместить фокус на компетенции в более прикладных областях.

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

Сегодня бизнесу в tech нужны не просто люди, умеющие писать код, защищать архитектурную чистоту и выбирать между build и buy. Нужны те, кто способен понимать сам бизнес, переводить его потребности в продуктовые решения и не просто говорить с заказчиком на одном языке, а в каком-то смысле мыслить как он. Те, кто умеет принимать осмысленные компромиссы между скоростью, устойчивостью, стоимостью изменений и итоговым результатом.

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

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