Как мы в Koronatech, сами того не ведая, попали в поток эволюции роли Project Manager. Поговорим о Delivery Manager как об одном из путей эволюции PM на сегодняшний день. Чем эта эволюция обоснована, какие эволюционные кризисы новой роли предстоит преодолеть в ближайшее время.

Посмотрим практическое внедрение роли на примере Koronatech, с чем мы столкнулись и что получили. Затронем триггеры, которые помогут решить, нужна ли вам выделенная роль DM и в каком виде.

Всем знакома установка, что надо всё успевать, ведь это признак профессионализма. Но задач становится больше, а рук и времени в сутках почему-то больше не становится. А ведь нашим заказчикам всё это неинтересно — им «просто» нужен результат.

Значит, главная задача не в том, чтобы всё успевать, а в том, чтобы заказчики получали то, что ожидают, и оставались довольны, а команда при этом работала в адекватном режиме и не выгорала.

В докладе немного раскрою сторону и потребности заказчиков, что важно им. А также поделюсь инструментами и правилами, которыми пользуюсь сам.

Часто задумываетесь о своём дальнейшем развитии?
Являются ли желаемые цели реальными и достижимыми?
Как обычно, хочется всё и сразу, а за что взяться в первую очередь, непонятно…

Поможет декомпозированный подход! Расскажу, как применить его к собственному апгрейду на примере нашей компании.
Спойлер: идеи для вдохновения тоже будут.

За фасадом силы и лидерства руководители часто скрывают тревогу, усталость и ощущение ловушки: исследования показывают, что более 70% топ-менеджеров и руководителей среднего звена сталкиваются с депрессией и выгоранием.

В докладе мы поговорим о том, какие чувства переживает руководитель, откуда они берутся, как проявляются во внешнем поведении и какое влияние оказывают на самого руководителя, команду и бизнес.

Мы часто думаем, что эффективная команда — это просто набор сильных специалистов.
Но на практике даже «звёзды IT» могут буксовать, а бизнес-цели достигаются с трудом, когда команда не работает как единое целое.

Мы поговорим о том, как организовать работу так, чтобы эффективность стала устойчивым результатом, а не разовой вспышкой.
Разберём ключевые принципы: прозрачные роли, доверие, баланс компетенций и фокус на результат.

И, конечно, поделюсь опытом Koronatech:
как мы выстраиваем команды в условиях стремительного роста, повышаем Bus Factor и используем инструменты, которые превращают таланты в слаженный механизм.

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

В своём докладе я расскажу, как за последние несколько лет у нас в компании преобразился процесс оценки задач. Поделюсь опытом: что оказалось рабочим, что не прижилось и какие идеи мы, возможно, попробуем в будущем.

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

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

В докладе я расскажу о среде JetBrains MPS, которая помогла нам быстро и несложно создать свой язык и теперь используется как среда разработки на нём. Покажу на примерах, как создаётся сам язык и реализация его элементов на Java.

Скорость поставки и качество продукта — главные конкурентные преимущества в разработке ПО. Поэтому важно использовать лучшие практики сообщества для обеспечения этих двух пунктов. Одной из таких практик является CI/CD — Continuous Integration и Continuous Delivery — непрерывная интеграция и непрерывная доставка. Она помогает свести ошибки к минимуму, повысить качество разрабатываемого продукта и увеличить скорость его поставки клиенту. Без непрерывной интеграции сотрудничество разработчиков превращается в утомительный ручной процесс координации обновлений и слияний кода.

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

В докладе разберём на примере, чем это полезно не только с точки зрения конкурентных преимуществ для бизнеса, но и для самих разработчиков. Посмотрим, в чём преимущества и недостатки этой концепции. И разберём пример реализации с помощью инструмента Jenkins.

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

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

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

В мире enterprise-разработки на Java один из ключевых вопросов при проектировании — как будут взаимодействовать компоненты системы: синхронно или асинхронно? За этим выбором стоит компромисс между производительностью, сложностью, отказоустойчивостью и временем на разработку.

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

Ключевые темы выступления:
— История и контекст: От RPC и REST-сервисов до реактивных потоков и микросервисов. Почему асинхронность стала трендом?
— Особенности построения систем: сравним синхронный и асинхронный подходы на реальных примерах. Обсудим их влияние на код, отладку, мониторинг и потребление ресурсов.
— Паттерны асинхронного взаимодействия: Рассмотрим готовые рецепты для построения надежных систем, такие как Event Sourcing, CQRS, SAGA.

После этого доклада вы сможете более осознанно подходить к выбору типа взаимодействия в своих проектах, понимая не только «как это сделать», но и «почему именно так».

Давно присматриваетесь к kotlin, но у вас видавший виды проект на java? Боитесь, что граблей при переходе будет больше, чем вы можете себе позволить? У вас каждый раз горят глаза и чешутся руки, когда смотрите очередной доклад про kotlin, но, приходя на работу, только грустно вздыхаете, понимая тщетность попыток убедить коллег попробовать что-то новое? Тогда этот доклад для вас!

Мы уже перевели пачку микросервисов на kotlin, станцевали фламенко по граблям, убедили менеджеров, что нам нужен другой язык для реализации их желаний, и готовы поведать, что сделали бы иначе, будь у нас такая возможность… ведь такая возможность есть у вас!

Поговорим о том, почему стримы «на каждый случай» могут приносить больше вреда, чем пользы. Разберём проблему N+1, посмотрим, как корректно сокращать транзакции, и обсудим, чем опасны слишком «тяжёлые» объекты в коде.

К вам приходит новый человек, и вы не знаете что с ним делать? Посмотрим на ситуацию с двух сторон: руководителя и специалиста.

Обсудим
— Как организовать эффективный онбординг, чтобы сотрудник не выгорел в первый месяц работы, потому что его «кинули» читать 2 млн страниц документации, а потом ждут перфоманса в выполнении задач.
— Что стоит изучать в первую очередь, если информации много, а ты джун, изучающий java с нуля. Разберёмся, куда расти.
— Что чаще всего становится причиной отказа кандидатам в нашей команде — возможно, ты сможешь узнать в этих причинах себя, и изменишь подход к собеседованиям.
Постараюсь на основе личного опыта онбординга / менторинга / проведения собеседований поделиться полезными фишками и рекомендациями, вместе обсудим актуальные и тяжёлые вопросы в максимально открытом диалоге.

Как запускали проект мобильной автоматизации на Android и какие решения приходилось принимать по ходу. Начнём с Espresso и дойдём до реорганизации проекта на Kaspresso. Разберём, как адаптировали Kaspresso/Kakao под кастомные элементы приложения, где в процесс подключались разработчики и какие приёмы помогли сократить количество шагов в тестах.

Поговорим о том, как CI/CD и Allure встроились в процесс и позволили запускать тесты удалённо, сохраняя прозрачность и контроль качества.

Тематика unit-тестов и процесса их написания стара как мир, но до сих пор вызывает проблемы у разработчиков. Существует множество команд, в которых процесс написания unit-тестов организован неэффективно или вовсе отсутствует. Многие разработчики пренебрегают помощью извне, когда дело касается unit-тестов. А что, если за помощью далеко ходить не надо?

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

Автотестов много, а баги всё равно попадают в прод. Вложений в QA — миллионы, а бизнес не видит возврата. Почему так происходит?
Этот доклад — не про CI/CD и не про селениум. Это — разговор о ценности:
— как измерять эффективность автотестов;
— как посчитать ROI от автоматизации;
— где автоматизация реально теряет деньги;
— как превратить тестирование в стратегический актив, а не в зону «вечного коста».

Разберём
— почему мифы про «дешевле и быстрее» вредят автоматизации;
— какие метрики действительно волнуют бизнес (и почему code coverage — не одна из них);
— где рождаются анти-паттерны (пример из финтеха: DRY против KISS);
— как презентовать QA-результаты языком продукта и Time-to-Market.

Для инженеров это повод по-новому взглянуть на свою стратегию автоматизации.
Для менеджеров — инструменты, чтобы защитить бюджеты, говорить с бизнесом на одном языке и продавать эффективность QA внутри команды.

Рассмотрим эволюцию баз данных и их ключевые особенности, в том числе модели согласованности и возникновение deadlock. Поймём, как различные типы СУБД влияют на тестирование.

В любом проекте каждая проблема — это потери для бизнеса. Это могут быть финансовые, репутационные либо вовсе критичные риски, связанные с несоблюдением требований регуляторов и потерей лицензии. Дежурство предназначено для оперативного устранения этих потерь. А тестировщик, безусловно, один из участников данного мероприятия.

Но что, если тестировщик становится не только одним из тех, кто помогает решать проблемы на проекте, но и в параллель готовит стенды к регрессу, принимает активное участие в выносе версии на бой? А ещё ведь задачи не прекращаются…

Поделюсь с вами, как мы облегчили жизнь рядового дежурного backend-тестировщика.

Тестирование безопасности обычно воспринимается как что-то специфичное и очень сложное. На самом деле это не так — тестировщик в рамках своих рутинных проверок может безболезненно добавлять такие кейсы.

Расскажу:
— как составить универсальный чек-лист проверок безопасности практически для любой платформы;
— как обогатить его кейсами, актуальными для конкретного продукта;
— почему эти кейсы действительно важны.

Поделюсь нашим опытом в построении этого процесса.

Будет полезно тестировщикам веб-, мобильных, бэкенд-приложений, а также тем, кто хочет заняться тестированием безопасности, но не знает с чего начать.

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

О том, насколько важно регрессионное тестирование, говорить не приходится. А вот как сделать эту рутину легковесной с точки зрения работы инженеров? Как при разрастании кодовой базы оставить регрессионное тестирование в тех же временных рамках, не исключая важные проверки?

У меня есть ответы! Подход, который мы используем в команде, доказал свою эффективность как в отношении больших продуктов, так и отдельных компонентов. Поделюсь идеями, опытом, наработками.

Приходите, будет полезно!