Apache Kafka в интеграционных задачах КРУПНОГО бизнеса: какие плюсы и слабые стороны у такого подхода? И какие дополнительные инструменты стоит подключить, чтобы избавиться от всех проблем в интеграциях?
Андрей Путин @utandr
Пользователь
Почему оценка разработчиков должна быть про доверие, а не про поведение
3 min
Opinion
или разбор карты от Авито с точки зрения бизнеса, DORA и инженерной практики
Если ты релизнул фичу на 500K₽/мес выручки, но получил «3» за ретро и фассилитацию — это не шутка, это реальность многих крупных команд.
Сегодня хочу поговорить про систему оценки разработчиков. Не формально, а по существу. Разберём публичную карту Авито — без токсичности, но критически. И покажу, как строить модель, которая работает.
Отчет DORA–2024: как ведущие команды достигают успеха в разработке ПО
7 min
Translation
При создании этого материала были использованы данные отчета DORA Accelerate State of DevOps 2024
В конце октября 2024 DORA выпустила очередной отчет Accelerate State of DevOps — результаты масштабного ежегодного исследования об эффективности разработки. В этой статье команда KT.Team суммировала выводы исследователей DORA о том, как работают эффективные команды разработки. Здесь же вы найдете ключевые советы DORA: какие подходы внедрить, чтобы повысить результативность команды и оправдать ожидания бизнеса.
Статья будет полезна руководителям ИТ любого уровня — от проектных менеджеров до ИТ-директоров.
ИИ в разработке: выводы DORA о доверии и продуктивности
7 min
Review
Материал является саммари на основе отчета DORA 2024 Trust in AI Report
Согласно отчету DORA, почти 40% разработчиков не доверяют решениям, которые предлагает ИИ. Это происходит потому, что многие инструменты недостаточно прозрачны, а разработчики сомневаются в их надежности.
При этом ИИ-инструменты уже помогают ускорять работу и повышать эффективность разработки. В условиях растущих требований бизнеса ИИ может стать незаменимым помощником разработчика. Для этого, конечно, надо правильно его внедрить и использовать.
Всем привет, я Андрей Путин, управляющий партнёр ИТ-компании KT.Team. В нашей компании широко используется ИИ — как в разработке, так и в сервисных подразделениях. Например, мы для себя создали ИИ-помощников в HR-процессах, в написании протоколов по итогам видеовстреч, в поиске договоренностей по этим встречам и т. д. А ещё мы внедряем ИИ-инструменты в работу своих клиентов.
Я слышал совершенно разные мнения: от «ИИ убьет профессию разработчика» до «без ИИ разработчик отстаёт от требований рынка». DORA достаточно доверенный и экспертный источник, чтобы вывести эту дискуссию на новый уровень.
Low-code с точки зрения разработчиков — есть ли плюсы для инженеров?
11 min
В комментариях к прошлой статье о low-code в enterprise-решениях я увидел резонное количество типичных возражений по LCDP. Этим постом я постараюсь ответить на них. Разберём то, как устроен пул задач разработчика сегодня и как его можно трансформировать с low-cod, и пофантазируем на тему будущего IT-отрасли.
Правда ли, что low-code нельзя применять в enterprise-решениях: разбираемся с основными возражениями
8 min
Привет. Я Андрей Путин, управляющий партнёр ИТ-интегратора kt.team. В последнее время мы всё чаще предлагаем своим крупным клиентам использовать в ИТ-архитектуре low-code решения. Их функционал позволяет быстро вносить изменения в интеграции и бизнес-процессы. Это критично для бизнеса, учитывая динамику изменений на рынке.
Несмотря на это, бизнес масштаба enterprise с осторожностью и даже недоверием относится к парадигме low-code. Сегодня мы разберём основные возражения по использованию low-code систем у бизнеса масштаба enterprise и выясним, насколько они справедливы.
Микросервисы или модульные системы? Как заказчику выбрать подход к IT-архитектуре продукта
13 min
Микросервисная и модульная системы — это типы архитектуры IT-решений.
При работе с модулями мы дорабатываем коробочную версию существующего IT-продукта.
Под коробочной версией имеем в виду монолит, готовую систему с ядром, которая поставляется всем заказчикам одинаково, «как есть».
Доработка состоит в создании модулей с недостающим функционалом.
Новые модули получаем путём переиспользования частей монолита (ядра или других модулей).
Бизнес-логика прописывается внутри монолита: для программы (приложения, сайта, портала) есть одна точка входа и одна точка выхода.
При работе с микросервисами мы создаём IT-продукт с нуля, составляя его из «кирпичиков» — атомарных микросервисов, отвечающих за отдельный небольшой процесс (отправить письмо, получить данные по заказу, сменить статус заказа, создать клиента и т. п.).
Набор таких блоков объединяется бизнес-логикой в общую систему (например с помощью BPMS). Несмотря на наличие связей, каждый блок автономен и имеет свои точки входа и выхода.
Большинство IT-продуктов для наших заказчиков начинаются с модульной разработки. Часть из них со временем эволюционируют до микросервисов. Для другой части микросервисы не нужны. В этой статье мы рассмотрим, почему это именно так и какие критерии помогают определиться, нужно ли внедрять микросервисы или стоит придерживаться работы с модулями.
