Разработка

Обработка запроса заказчика: как получить историю и собрать задачу;

Усложнение маршрута оценки в зависимости от сложности задачи;

Декомпозиция и параллельное выполнение;

Автоматизация тестирования и валидации качества;

Деплой;

Системы мониторинга состояния и статуса релиза.

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

- Эффективность лидера определяется способностью делегировать и сосредотачиваться на стратегии, а не на повседневных операциях.

- Достижение баланса между стратегическим развитием (80%) и управлением операциями (20%).

- Переосмысление роли лидера: важность доверия к команде и делегирования ответственности.

- Переход от микроуправления к макро-лидерству способствует созданию здоровой и инновационной организационной культуры.

- Осмысленный подбор. Рекомендации по онбордингу. Помощь или естественный отбор;

- Как общаться с сотрудниками о успехах и неудачах;

- С чего начинается мотивация;

- KPI и планы развития. Роль руководителя в этом процессе;

- Развитие руководителя. Почему всё плохо;

- Забавные истории неудачного руководства.

Все побежали и я побежал?

Поговорим о внедрении гибких методологий, осознанном подходе к управлению и разных типах компаний

Часть 0/интро: о коне и его вакууме: почему абсолютное большинство методологий выглядит отлично на бумаге, но оказываются сложно применимыми на практике, когда уже есть хоть и кривые, но процессы, люди, системы

Часть 1: Откуда у коня ноги растут

Как и когда появился Agile в России, но что-то пошло не так.

Ожидание VS реальность.

Кейс крупного банка: мы решили опрозрачить все, но только сильнее запутались

Часть 2:

Все еще работаете по вотерфоллу? Тогда мы идем к вам!

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

Часть 3:

Что было вначале — менеджер или «чтобы что»

Что делать, если очень хочется, но ноги коня растут пока из… из кондового бюрократа Ивана Иваныча (относится к ситуациям, когда менеджер/руководитель/гендир решил, что с завтра начинается новая жизнь, и жить все будут исключительно по аджайлу. Или вам сверху прилетела разнарядка срочно внедрить OKR. Или вы решили, что ваш стартап обязательно будет бирюзовым)

Ответ: задать вопрос «чтобы что»

Кейс: как одного менеджера взяли все изменить, но на самом деле изменения не планировались (и менеджер расстроился)

Часть 4:

Невероятная легкость бытия в бирюзовой компании

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

Заключительном слово

Дайте коням шансы в этот мир ворваться

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

Ты и работа

— Тайменеджмент: управляй своим временем, кто если не ты?

— Отвлекаться и делать параллельно что-то еще — это норма?

— Работа на дом или на выходных, как перерабатывать и не выгорать?

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

Работа в команде

— Тимлид отвечает не только за свой баланс, но и баланс в команде. Как управлять производительностью команды.

— Когда бить тревогу, что у спеца стало много лайфа, мало ворка. Депрессия или настало время расставаться.

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

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

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

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

Доклад подойдет как тем, кто интересуются PostgreSQL и мониторингом его, в частности, администратором СУБД PostgreSQL и разработчикам, использующие эту СУБД.

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

В докладе разберем базовые составляющие фреймворков и сравним их индивидуальные особенности.

Это поможет быстрее изучать новые технологии.

Видеть разницу и оптимально выбирать стэк.

А главное — аргументированно холиварить на тему “какой фреймворк лучший”!

В настоящий момент Микросервисная Архитектура является самый популярным подходом в Web-разработке. Но являются ли Микросервисы серебряной пулей, которая решит все ваши проблемы? В ходе доклада обсудим, действительно ли так нужны микросервисы в нашем проекте, и, если да, то с какими сложностями мы столкнемся. Мы сравним Микросервисную Архитектуру с Монолитным Приложением и разберемся, когда следует переходить на Микросервисы, а когда оставить все как есть.

Несколько лет назад мы в компании столкнулись с проблемами в управлении ожиданиями. Сроки размывались, результат инициатив не удовлетворял потребностям клиентов, а взаимодействие команд скатывалось в почтовый «футбол».

Расскажу о нашем опыте:

• как абстрактные аналитики разделились на бизнес- и системных аналитиков, solution- и системных архитекторов;

• почему мы отказались от fullstack-аналитиков и архитекторов;

• как внедрение С4-нотации и предоценки ИТ-инициатив изменило наш производственный цикл;

• почему мы проводим трассировку требований, и это нормально.

Подробно обсудим:

как выстроено управление ожиданиями в нашей текущей схеме проектирования: начиная с исследования до передачи системы или изменения в системе в поддержку релизной команды;

проверенные инструменты управления ожиданиями;

как мерить управление ожиданиями, и чем это может закончиться.

Как устроено API в Одноклассниках

- методы API на примере публичного API

- достоинства кастомного API клиента

- стек технологий проекта автотестов: Java, JUnit5, Maven, Hamcrest

Про покрытие

- Объем необходимого покрытия

- Приоритеты покрытия

- Учет параметров из сигнатур методов и другие критерии для приоритизации

- Цели по покрытию

- Решенные проблемы

- Фичи для развития покрытия

Измерение покрытия

- Как мы измеряем покрытие

- Приоритеты

- Степень покрытия метода автотестами, с учетом не только количества тестов, а также приватности, критичности сервиса, анонимности метода и прочих критериев

- Работа с druid

- Получение и обработка данных

- Визуализация через кастомный UI сервис, возможности и фичи

Автоматизация

- Автоматическое создание задач

- Автоматическая генерация автотестов

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

1. Знакомство с тех.стеком, изучение основ. Что важно знать.

2. Цели, задачи и контексты команды

3. Коммуникация с командой и заказчиком, регулярное получение обратной связи

4. Прозрачность процессов. Как обеспечить.

5. Участие в процессе разработки, свои решения и идеи, управление архитектурой

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

Я слушал много лекций, читал много книжек где учат что делать если ты стал тимлидом или каким-то руководителем впервые. Привет книге "Мама я тимлид" и тому подобное. И еще больше руководства и обучения как растить тимлидов правильно. Кого назначать, а кого нет. Окей, но допустим я разработчик и хочу стать лидом, что мне делать?

В своем докладе я хочу рассказать о своем пути в лиды, и о том что собрал общаясь с коллегами по цеху.

- Действительно ли ты хочешь быть лидом?

- Какой нужен уровень?

- Софты. Коммуникации, Делегирование, Командная работа, Работа со временем, управление стрессом и т. д. Что нужно и как качать.

- Рост внутри компании

- Рост через увольнение

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

Ученье — свет, а обучение — фонарь, солнце или сверхновая. Но как сделать из искры источник вечного света в ИТ?

Важно понять, что все мы можем быть учителями в той или иной области, но кто и как получает пользу от обучения?

Обсудим столпы devops: автоматизация, сотрудничество, коммуникация, близость, масштабирование в разрезе обучения.

Расскажу подходы к работе аналитика на основании моего опыта:

- Выстраивание работы в команде, когда какой-то роли не хватает

- Разберу типичные ситуации в реальных проектах.

Какие ошибки совершила и как можно было поступить удачнее

- Планирование своих задач и работа с ожиданиями

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

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

В своем докладе я хочу показать, как можно при помощи HTMX и пары строчек кода заменить тяжеловесные React и Vue.

Этот доклад можно рассматривать как продолжение прошлогодего доклада. Только теперь я полностью сосредоточусь на практике.

– Проблема props-drilling;

– Как не стоит решать проблему через контексты;

– Правила работы с контекстами;

– Фабрика провайдеров и хуков;

– Утилиты для безопасной работы с контекстами;

– Пример организации компонентов с разделением ответственности и использованием утилит;

– Преимущества: типобезопасность, разделение ответственности, легкая масштабируемость.

Доклад о том какие существуют популярные заблуждения есть в сообществе и что с собеседованиями по JS не так:

Мы с вами разберем, как JS существует сразу в нескольких реальностях и как это сказывается на нашем коде. Поймем, почему мы должны читать ECMAScript спецификацию, а так же, почему мы не должны этого делать. Почему аналогии того как работает JS зачастую далеки от реальности, а то и ведут к тому, что мы пишем код хуже чем может нам показаться. Как мы сами создали мифы которые потом требуем на собеседованиях от других? Поговорим об оптимизациях и байткодах в v8, а также как v8 игнорирует некоторые моменты в спецификации для повышения производительности.

О чём доклад:

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

Проблемы которые возникли при масштабировании команды

Чем занимаются платформенные команды, примеры задач

Зоны ответственности платформенных команд

Как подготовить проект к связке продукты + платформа

Что мы сделали в первую очередь

Работа с техдолгом и roadmap платформенной команды

Особенности найма и работы в платформенной команде.

Выводы

- что такое Agile зрелость
- какую ценность имеет регулярная диагностика Agile зрелости для организации
- разработка методологии и процесса проведения: опыт ВТБ