«Смотрю на технологии через призму денег». Как молодой программист стал совладельцем студии разработки
Жаксылык Уалиев в 18 лет занимался созданием лендингов и корпоративных сайтов. Но быстро понял, что для профессионального роста этого недостаточно, и стал искать новые возможности. Так он присоединился к студии Esqadra (ранее Akhter Studios) – аутсорс-компании, которая разрабатывает софт для бизнеса под «ключ». Начав с позиции фронтенд-разработчика, к 25 годам Жаксалык стал техническим директором, а затем и совладельцем бизнеса.
Для конкурса лучших CTO стартапов, который Digital Business проводит совместно с Yandex Cloud, специалист рассказал, чем работа технического директора в Казахстане отличается от международной практики и почему именно ему предложили долю в компании.
«Занимаюсь больше стратегией и управлением»
— Жаксылык, ранее вы рассказывали, что, став СТО, пытались также одновременно быть и техлидом, и аналитиком. Почему так происходило?
— В начале думал как исполнитель и старался делать все сам. Из-за этого распылялся и недосыпал. Поэтому пришлось учиться делегировать, наняли новых разработчиков. Конечно, приходится переплачивать за экспертизу, но зато я сконцентрировался на решении текущих проблем компании и предотвращении их в будущем.
Теперь думаю не о том, как быстрее написать фичу, а о том, чтобы заранее согласовать цели, прописать ограничения и принять архитектурные решения. Это резко уменьшило переделки и снизило шум.
Плюс стал смотреть на технологии через призму денег и риска: насколько надежный инструмент, сколько стоит его поддержка и легко ли найти людей под стек.
— Как отвечаете себе на вопрос: кто такой СТО?
— CTO в стартапах Казахстана часто отличается от общепринятого понимания — что все они должны быть технарями. В Казахстане же есть СТО-техлид и стратегический СТО. В моем случае распределил технические обязанности между техлидами и чаптер-лидами, сам больше занимаюсь стратегией и управлением.
— Вы пришли в студию как фронтенд-разработчик и, прежде чем стать СТО, поработали на позиции solutions architect. Почему?
— Сначала выбрал фронтенд, стал лидом, воспитывал джунов и осваивал основы менеджмента. Однажды провел 56 часов за кодингом почти без сна, потому что за несколько дней до дедлайна джун подвел команду, и пришлось выполнять несколько задач в одиночку.
Но уперся в «потолок», потому что для следующего шага – стать СТО – нужно знать все сферы ИТ в идеале. Я выстроил систему, подготовил преемника и стал solutions architect (архитектором решений). Это специалист, который помогает «перевести» бизнес-задачи на язык технологий. Он анализирует, что именно нужно бизнесу, и как это лучше реализовать с технической точки зрения в этой компании.
Изучал архитектуру, бизнес-анализ, проектирование высоконагруженных систем и приложений, микросервисов. Когда предыдущий CTO ушел, в июле 2024 года предложили занять его место.
— Спустя год вы стали соучредителем студии. Почему вам предложили долю?
— Я работал с момента основания. Когда только открыли студию, собирались в SmartPoint (коворкинг в Алматы – прим. Digital Business), где у нас была маленькая душная комната на шесть человек, но сидело десять. Я даже свой монитор принес. Офис бесплатно предоставлял другой стартап, которому помогали с разработкой. Когда у них были совещания, нам приходилось освобождать помещение.
К счастью, компания начала быстро расти. Стали развивать новые услуги: discovery, технические и ИТ-аудиты.
Для развития технической части команды внедрял актуальные методологии вроде перфоманс-ревью, составлял индивидуальные пути развития для сотрудников. Новая система оценки сотрудников помогает людям расти в карьере и получать справедливую зарплату.
В 2025 году меня настигла апатия: хотел уйти, потому что не видел перспектив карьерного роста. Тогда предложили стать соучредителем, и я согласился.
«Галлюцинации ИИ могут быть опасны»
— Как подбираете ИТ-архитектуру для проектов?
— По «закону Конвея», любая система отражает структуру и ценности команды, которая ее создает. Архитектура зависит от организационного уклада. В основном проекты начинаются как модульный монолит: функционал разделен внутри одного приложения, чтобы в будущем его можно было масштабировать и дорабатывать. Простой проект может обходиться стандартной архитектурой.
— Помните самый сложный технологический кейс?
— Для одного из заказчиков разрабатывали Health-ассистента. ИИ должен был собирать информацию обо всех аспектах жизни и здоровья человека, чтобы давать рекомендации и оценивать риски. Проблема в том, что это огромный объем информации. Пользователю нужно загружать анализы, данные о заболеваниях, отвечать на 100–150 вопросов.
Одна ИИ-система не способна обрабатывать весь контекст диалога с человеком и одновременно загружать данные в базу. Самым сложным было создать около 50 ИИ-агентов, которые работали бы вместе. У каждого есть общий и локальный контекст. Логику этих связей нужно было синхронизировать между собой. К тому же, у ИИ бывают галлюцинации – это опасно, потому что он может придумать несуществующий факт или перепутать данные. Например, если у человека аллергия на банан, ИИ может забыть об этом и предложить съесть банановый пирог.
— Как решили проблему?
— Было довольно сложно. Проводили множество тестов. Ограничивали каждую ИИ-систему локально, прописывали системные промпты, чтобы она не путалась, и создавали маршрутизаторы, распределяющие запросы между ИИ. Так реализовали мультиагентную систему из 50 узлов.
— Все ли нюансы при разработке удалось учесть или возникали непредвиденные проблемы?
— Приложение должно было интегрироваться с Health App. На iOS использовался HealthKit, на Android – Android Health. На обеих платформах возникали баги: данные приходили с задержкой. Решили фильтровать нужную информацию сразу на фронте, чтобы не перегружать бэкенд.
«Эксперимент с работой по выходным провалился»
— Что для вас важнее при реализации проекта: уложиться в сроки и бюджет или сохранить качество?
— Наш бизнес связан с разными услугами, основное направление – аутсорсинг. Выполняем заказы «под ключ». У каждого заказа есть свои ограничения. Чаще всего это бюджет и сроки. В Казахстане, к сожалению, редко думают заранее: начинают торопиться только тогда, когда уже совсем прижмет. В таких случаях приходится жертвовать качеством.
Недавно проводили эксперимент, чтобы повысить скорость и эффективность разработки. Наняли людей, которые трудились бы по выходным, и сделали почасовую оплату. То есть, чем больше человек занят делом, тем больше получает. На практике оказалось, что если специалист гонится за объемом, страдает качество. Люди без отдыха работают хуже. Даже маленькую задачу выполняют долго, потому что мозг уже не воспринимает информацию. В итоге прекратили эксперимент. Даже после короткого отдыха сотрудники стали заметно продуктивнее и энергичнее.
— Какие еще факторы влияют на производительность команды?
— Коммуникация. Обязательно должна быть нетоксичная атмосфера. Каким бы суперинженером человек ни был, если у него софт-скиллы хромают, то он будет тянуть проект вниз.
Нужно уметь подбирать людей на проекты. Если поставишь слишком неопытного, то получишь низкое качество и переплатишь за переделки. Если поставить более квалифицированного сотрудника на маленький проект, ему будет неинтересно.
«Смогли сократить трудозатраты на 30–40%»
— Что вы внедрили недавно и какими результатами можете похвастаться?
— Системно внедряю ИИ-инструменты в инженерный и операционный контур, чтобы ускорить производство без потери качества и дисциплины. Перечислю некоторые.
- ИИ HR. Искусственный интеллект отбирает резюме, сравнивает профили кандидатов и ведет первичную переписку. Это снимает до 80% рутинной работы рекрутеров. HR-специалист теперь больше времени уделяет не бумажной работе, а оценке того, совпадают ли ценности человека с нашими, и проведению финальных интервью.
- ИИ-интервью для техсобеседований. Система задает стандартные вопросы для разных должностей и уровней, автоматически ведет протокол и дает первичную оценку. Качество собеседований стало стабильнее, а картина по кандидату складывается быстрее.
- Автопомощник для code review. Инструмент подсвечивает ошибки и сразу предлагает черновые комментарии для ревьюера.
- «Чат с кодовой базой» для онбординга. Подключили инструмент, который сканирует кодовую базу и позволяет инженерам буквально «спрашивать у кода» про бизнес-логику и зависимости. Это сильно упростило вход в проект: новые сотрудники быстрее понимают, как устроена система.
- IDE-ассистенты. Связали Cursor и Claude Code через специальный протокол MCP (Model Context Protocol), чтобы эти ИИ-помощники видели контекст проекта и наши правила. За помощью ассистента разработчики обращаются, чтобы разгрузиться от рутины – это помогает с шаблонами, тестами и мелким рефакторингом, при этом качество не страдает.
Вкупе смогли сократить трудозатраты на 30–40% там, где использование ИИ действительно уместно.
«Мне нужны люди, которые умеют брать ответственность»
— Что планируете изменить в ближайший год?
— Для меня важно, чтобы наши внутренние инструменты превратились в продукт по подписке. Сейчас это готовый набор функций для быстрого старта: регистрация пользователей, оплата, уведомления, рабочие кабинеты, журнал действий – все, что обычно нужно создавать с нуля. Хочу упаковать это в одну «коробку», чтобы ее можно было быстро установить в компании и настроить под их процессы. Цель на год – показать работающий продукт, провести несколько тестов и получить первых платящих клиентов. Хочу, чтобы заказчик видел ценность уже в первую неделю, а не через три месяца.
Рутинная работа все еще отвлекает от развития бизнеса. Поэтому планирую освободить как минимум треть времени для работы над продуктом, партнерствами и ростом. Текущие задачи передам лидам и проектным менеджерам.
Мы упорядочиваем работу: короткое планирование по понедельникам, демонстрация результатов раз в две недели, четкие правила общения. Важные решения фиксируем письменно, лишние встречи убираем. Новый сотрудник должен включаться в работу за неделю, а не за месяц.
Надеюсь, что команда будет работать эффективно без переработок по выходным. Мне нужны не просто хорошие разработчики, а люди, которые умеют брать ответственность, задавать стандарты и поддерживать коллег. В этом году выведу на роли руководителей направлений несколько сотрудников: фронтенд, бэкенд, мобайл, тестирование, инфраструктура, аналитика. Мы дадим им инструменты, наставничество и право принимать решения. К концу года хочу видеть пять уверенных лидеров, которые смогут вести команды без моего постоянного контроля.
