У каждого из нас есть факторы в работе, которые очень сильно раздражают и демотивируют. Я недавно задумался над своим личным ТОП-3 таких факторов. Оказалось, что они даже связаны между собой. Итак, встречайте!

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

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

2. На втором месте идёт отсутсвие ценности проделанной работы. Сильно перекликается с первым фактором, но обычно имеет другие первопричины. Например, желание реализовать во что бы то ни стало весь изначальный объём задач проекта, хотя контекст давно поменялся и половина уже неактуальна. Или наличие бессмысленных и беспощадных бюрократических правил, заставляющих делать много бесполезной работы на ровном месте. Или нежелание четко расставить приоритеты задам с точки зрения ценности, ведь «все это важно». Или игнорирование обратной связи от конечных пользователей с формулировкой «они просто не понимают»…

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

3. Замыкает список «легаси мышление». Не технологии или подходы, а именно мышление. Такой себе упорный консерватизм, граничащий с маразмом. Когда люди даже шанса не дают чему-то новому. Например, использование до сих пор Java 8, потому что это «надежный релиз и ничего стоящего дальше не выходило». Или отказ от использования контейнеров, потому что «там все тормозит». Или запихивание всего в Oracle, потому что «это надежное и быстрое транзакционное хранилище данных». Или полное отрицание идей Lean/Agile, потому что «мы умеем делать проекты и у нас есть опытный проектный офис».

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

Вот такие факторы в работе меня больше всего раздражают и демотивируют. А вас? Поделитесь в комментариях!

​​#реклама #java #jobs

🔥 У нас тут пропозиція, від якої неможливо відмовитись 😎

🔹 з нуля писатимемо продукт (так-так, ніякого легасі)
🔹 $545 мільйонів інвестицій
🔹 суть продукту — зробити крутезний Digital Bank
🔹 лише свіжі технології
🔹 команда — тільки middle та senior спеціалісти
🔹 можливість взяти участь у всіх етапах розробки продукту
🔹 зарплатна вилка $3000–7000

Інтригує, правда? Тоді скоріше читай повний опис вакансії ➡️ https://bit.ly/3AYvf4G і подавайся 🚀

📩 Або пиши @bozhenazvarych за усіма деталями 💜

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

23 октября сообщество JUG.ru возвращается с новым онлайн-митапом - «JUG.ru: JPA Buddy – краткая история одного плагина для IntelliJ IDEA».

Алексей Стукалов и Андрей Оганесян выступят с большим докладом о проекте, над которым они работают в HAULMONT — плагине JPA Buddy. Они расскажут, как дошли до создания JPA Buddy и какие принципы берут за основу при создании инструментов для широкой аудитории. Плюс, Алексей и Андрей покажут, что у них получилось и даже анонсируют еще одного Buddy-ка.

Начало в 15:00, участие бесплатное!
⠀
30 октября состоится конференция Tech Ground: Java Edition.
⠀
В программе спикеры из Revolut, Luxoft, JUG UA и не только. А еще Fireside Chat с Адамом Бином, Java Champion, Top Java Ambassador и JavaOne Rock Star!
Также будет возможность поучаствовать в open space discussion - это виртуальные комнаты, где ты можешь обсудить актуальные вопросы и поделиться опытом с коллегами!
⠀
🇬🇧 Доклады будут на английском языке.
⠀
Начало в 12:00. 🧑💻Участие бесплатное!

#java #конференции

​​Пятница - обычное время ретроспектив в командах. :)

Sprint Planning VS Retrospective

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

К чему приводит такой подход все знают:

- чисто проектный подход к разработке;
- всюду локальные оптимизации по использованию ресурсов;
- водопадная модель работы с длинным циклом обратной связи;
- бесконечная игра в пятнашки с приоритетами;
- отсутствие долгосрочной вовлечённости и фокуса на value stream со стороны разработки…

А какие альтернативы? Мне кажется, до определенного размера (100-150 человек) нужно строить достаточно плоскую организацию на основе команд по 7-10 человек. Желательно кросс-функциональных, но не обязательно. Они работают над единым бэклогом, объединяя свои усилия в каждой итерации для работы над наиболее приоритетным элементом бэклога в качестве цели.

Дополнительно понадобятся несколько архитекторов или техлидов (зависит от технологической сложности продукта и опыта команд). Чтобы была плотная hands-on вовлечённость, один архитектор или техлид может работать с 1-3 командами.

На каждые 1-3 команды обычно выделяется ScrumMaster или инженерный менеджер в зависимости от зрелости команд и специфики процесса разработки. Бывает, что параллельно есть и тот и другой, но тут нужно быть очень аккуратным с распределением зон отвественности между ними.

Product Owner в такой схеме отвечает за видение продукта, управление бэклогом и его приоритезацию. Чем больше команд, тем больше PO понадобится помощи со стороны SME или аналитиков для детальной проработки элементов бэклога и подготовки их к разработке. Тут могут появиться роли Stream Owner или Feature Owner для распределения ответсвенности.

Дополнительно, наверняка будут существовать сервисные команды, как инфраструктурная, поддержки и т.д. Тут модель может сильно разниться в зависимости от специфики инфраструктуры и продукта.

В итоге, такая моделька может отлично работать на масштабе до 100-150 человек. Можно дотянуть и до 200-300, если наложить дополнительные условия на культуру организации и критерии найма новых сотрудников. А что если организация сильно больше? И продуктов не один а много?

Об этом мы поговорим в следующем посте. Stay tuned!

#менеджмент #разработка #масштабирование

Продолжаем обсуждать вопрос масштабирования организаций, начатый в прошлом посте. Итак, что делать, если размер команды разработки в разы превышает допустимый для линейного масштабирования или организация занимается разработкой различных продуктов? Нужно делить организацию на части. Эти части называют по-разному: трайбы, стримы, департаменты, продуктовые группы… Давайте остановимся на коротком названии трайб для удобства.

Выделение трайбов - очень непростая задача, особенно в больших и запутанных организациях. Начать стоит с формализации основных потоков ценности (value streams) для клиентов организации. Фактически, вся разработка должна существовать для доставки ценности по этим потокам. Конкретные приложения, системы и сервисы - это лишь каналы для доставки.

Вот ключевые критерии для выделения трайбов:

- Каждый трайб должен покрывать целиком (end to end) один или несколько потоков ценности. Это позволяет бизнесу максимально эффективно экспериментировать и управлять приоритетами.

- В трайбе должны быть специалисты по всему задействованному технологическому стеку. Для legacy систем возможны исключения, но необходимо реализовывать специальные подходы для использования internal open source стратегии.

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

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

Давайте рассмотрим пример не очень удачного разделения на трайбы и к чему оно приводит. Представим, что у большой финтех компании выделили такие трайбы: Cards для карточных продуктов, Payments для платежей и Mobile для клиентских мобильных приложений. И вот, у бизнеса из Cards трайба возникает идея нового карточного продукта, частью которого являются льготные платежи. Для реализации им нужно поставить задачу в Payments трайб, а также в Mobile трайб для добавления поддержки нового продукта в мобильном клиенте. И начинаются все те же игры с приоритетами, ведь у Payments и Mobile трайбов наверняка есть свои бэклоги с не менее приоритетными задачами и целями.

Вдобавок, в Cards трайбе нет специалистов по мобильной разработке, поэтому они полагаются на решения Mobile трайба, который не так сильно погружён в домен карточных продуктов. Это может привести к плохому UX для пользователей. От бизнеса будет требоваться точная постановка задач для оценок и включения в бэклог. А это, в свою очередь, закрывает возможность для экспериментов для бизнеса. В результате, снова страдают конечные пользователи.

Через некоторое время находится кто-то, предлагающий попробовать SAFe для управления всем этим бардаком зависимостей. Ведь в соседней энтерпрайз организации «внедрили SAFe и все довольны». Это лишь вопрос времени. Вуаля, и организация снова вернулась в мир водопадной разработки, только с Agile привкусом…

В следующем посте я отвечу на ваши вопросы и набросы по данной теме. :)

#менеджмент #разработка #масштабирование

Продолжаем тему масштабирования организаций и сегодня поговорим о платформенных командах. Это популярное название, которое дают выделенной команде, занимающейся разработкой единой платформы или ядра продукта. Очевидно, что эта команда является компонентной и очень редко может реализовывать end-to-end ценность в одном из потоков. Обычно она делает что-то для других команд. В результате, для данной команды актуальны стандартные проблемы компонентных команд. Когда же это оправдано?

1. Команда состоит из очень узкопрофильных специалистов, которым важно работать вместе для максимальной эффективности. Например, это могут быть data science эксперты, лингвисты или специалисты по высокопроизводительному коду. Разделять их по продуктовым командам не имеет смысла.

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

3. Поддержка одной из сложных legacy систем. Многие legacy системы разработаны в очень специфичном технологическом стеке и требуют узких доменных знаний. Например, огромная core banking system на Cobol.

Что можно сделать, чтобы минимизировать негативные аспекты для таких команд?

1. Минимизировать количество таких команд в организации. Тогда будет проще упорядочить ее работу и построить подходящий процесс разработки.

2. Команда должна иметь стратегическую цель максимально перейти на self-service модель работы с другими командами. Это значит, что продуктовые команды должны иметь возможность большую часть типовых задач решать самостоятельно по проработанным и детально описанным подходам. Принцип internal open source в действии.

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

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

5. Если большая часть задач этой командой делается для определенной продуктовой команды, то можно присоединить ее туда. Это поможет интегрироваться плотнее в бизнес цели и приоритеты, а также избежать дублирования командных функций и ролей как people management, ScrumMaster, HR, поддержка и т.д.

Компонентные команды явно не идеальны, но имеют место быть во многих контекстах. Ведь теория и реальная жизнь всегда расходятся. :)

#менеджмент #масштабирование #разработка

​​Пятничный пост на злобу дня! :)))

В отпуске было время посмотреть видео с последних конференций. Одна из них Tinkoff Agile Conference 2021. Вот доклады, которые мне понравились.

«Как сохранить все хорошее при масштабировании». Классный обзор подходов и практик в масштабировании разработки. Позволяет не пустить все на самотёк и при этом наращивать команду весьма интенсивно. Надежный онбординг, хорошая документация, максимальная автоматизация на уровне инфраструктуры и тестирования, поддержание health метрик команд на уровне и т.д.

«Ускоряем движение задач в 2.5 раза за 2+1 шага». Доклад о том, как можно простыми методами сфокусировать команды разработки на нужном результате. Визуализация, четкие метрики поставки ценности, фокус через WIP лимиты…

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

«Практика управления безопасностью ПО в масштабных продуктах». Доклад про современные подходы к безопасности и о чем важно не забыть. Своеобразный чеклист для самопроверки.

«Гибкое управление ML проектами». Доклад о том, как обеспечить нужную гибкость, прозрачность и предсказуемость в ML проектах. Много полезных советов как ставить задачи, отслеживать прогресс, устанавливать цели, оценивать результаты.

Все доклады выложены на YouTube, ссылка ⬇️

#конференции #agile

​​Чуть не забыл сделать ещё один анонс интересной конференции, в этот раз на DevOps тематику.

С 8 по 11 ноября на конференции DevOops 2021 спикеры расскажут о лучших DevOps-практиках, которые помогли им наладить процессы в команде:

✔ Олег Ненашев, «REvolution of open source CI/CD tools»;
✔ Павел Селиванов, «Повышаем отказоустойчивость и снижаем расходы в Kubernetes»;
✔ Алина Власова, «Как сделать стабильно, когда тысячи разработчиков могут всё сломать, или как организован CI в монорепозитории "Лаборатории Касперского"»;
✔ Владимир Гурьянов, Андрей Колаштов, Дмитрий Столяров, «TSDB – взгляд изнутри. Миграция на Prometheus и Cortex. Опыт Okmeter»;
✔ Kerim Satirli, «Building Trustable Infrastructure».

Посмотреть полностью готовую программу и билеты можно на сайте.

А промокод xpinjection2021JRGpc поможет приобрести Personal Standard билет со скидкой 2000₽.

#конференции #devops