«Компании сами ломают свои продукты»: почему дорогие IT-решения часто оказываются худшей ошибкой бизнеса

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

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

— Сегодня кажется, что цифровые сервисы становятся всё сложнее. Почему так происходит?

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

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

— То есть компании сами создают себе проблемы?

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

— Но ведь «лучшие практики» считаются правильным подходом. Почему они не работают?

— Потому что не существует решений, которые одинаково подходят всем. Есть очень важная вещь, которую редко объясняют молодым разработчикам: технология должна соответствовать масштабу бизнеса именно сейчас, а не через десять лет в фантазиях инвесторов. Я называю это подходом best fit – когда система проектируется под реальную задачу, а не под желание выглядеть «технологично». Например, можно сразу заложить фундамент под рост нагрузки в будущем. Но это не означает, что нужно немедленно строить огромную инфраструктуру, если продуктом пользуются несколько тысяч человек. Настоящая зрелость инженера не в том, чтобы знать все модные технологии, а  понимать, какие технологии сейчас принесут пользу, а какие станут дорогим балластом.

— При этом вы работаете в сферах, где ошибка недопустима: государство, финансы, промышленность. Как такой опыт влияет на мышление инженера?

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

— Сегодня в IT принято говорить о больших командах. Но многие ваши проекты вы создавали практически самостоятельно. Как это возможно?

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

— Вы говорите, что многие системы усложняются искусственно. Почему индустрия все равно продолжает идти по этому пути?

— Потому что сложность часто продается лучше простоты. Когда компания показывает огромную инфраструктуру, десятки технологий и сложные схемы, это производит впечатление «серьезности». Хотя для бизнеса гораздо важнее другое: скорость, стабильность и стоимость поддержки. Есть еще одна проблема: индустрия слишком часто учит инженеров технической правильности и слишком редко экономике технических решений. Можно создать технически идеальную систему, которая уничтожит бюджет компании. И наоборот: можно сделать архитектуру проще, но гораздо эффективнее для бизнеса. Каждое инженерное решение должно отвечать не только на вопрос «это правильно технически?», но и на вопрос «зачем бизнесу платить за это именно сейчас?».

— Как вы считаете, что сегодня отличает действительно сильного инженера?

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

Анна Попова