Судя по количеству откликов, у всех все хорошо с работой и поэтому я очень рад за подписчиков. 🤗

На фоне общих сокращений и кризиса в IT, у меня есть для вас целый пучок горячих вакансий в продуктовые fintech и ecom:

1. Java Tech Lead. Нужен опыт с нагруженными распределенными системами, продвижение инженерных практик в команде, понимание микросервисных паттернов, глубокие знания в Spring Boot, архитектурные навыки и умение строить эффективные команды разработки.

2. Senior Java Developer. Требуются глубокие знания Spring Boot, автоматизация тестирования на уровне своих сервисов, навыки проектирования API, опыт поддержки нагруженных сервисов в продакшен среде и траблшутинга проблем, практический опыт с PostgreSQL, Kafka, RabbitMq, MongoDb.

3. Senior PHP Developer. Большой практический опыт с Symfony, автоматизация тестирования своих сервисов, опыт применения event-driven архитектурных решений, желательно иметь опыт в ecom домене.

Если чувствуете в себе силы и подходите под требования, не стесняйтесь стучаться в личку на @xpinjection.

В ноябре 2024 года я праздную сразу 2 юбилея: 20 лет работы в IT и 15 лет XP Injection. Сложно поверить что я сколько лет провел в этой индустрии.

В далеком 2004 году на предпоследнем курсе универа я начал свой путь в IT как Java разработчик в маленькой компании и сразу попал в активный водоворот развития. Через полгода мне пришлось заменять единственного заболевшего техлида, а еще через полгода я уже сам работал техлидом.

Потом был переезд в Киев, работа по аутсорс и аутстаф моделям на клиентов в USA и UK как разработчик, техлид, архитектор и инженерный менеджер. А в 2009 году я решил начать учить других людей тому, что у меня неплохо получалось и организовать с единомышленниками инженерные конференции по Java, автоматизации тестирования и инженерным практикам. Так получился XP Injection.

С тех пор я начал развиваться в направлении консалтинга, появились первые клиенты из небольших продуктовых компаний. В 2015 году я решил попробовать себя в большой корпорации на синьор менеджерской позиции и присоединился к ЕПАМ. А уже в 2017 году я понял, что не хочу работать в корпорации и решил полностью уйти в консалтинг. Так начались мои самые насыщенные и интересные годы в IT. Разные клиенты, домены, проблемы, роли, задачи и вызовы…

Эти 20 лет стали настоящей проверкой на то, действительно ли я занимаюсь любимым делом и получаю от него удовольствие. Я все еще не выгорел и полон сил, поэтому show must go on! :)

Многие ждали этой осенью очередного прорыва в мире AI в виде GPT-5 от OpenAI. На эту тему было много рассуждений и сплетен. Но пока OpenAI порадовал нас только новыми моделями o1-preview и o1-mini.

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

Например, модель o1-preview набрала 83% баллов по квалификационным задачам международной математической олимпиады по сравнению с 13% у GPT-4. Отличные новости для школьников и студентов, ведь делать домашку станет еще легче. ;)

А вот модель o1-mini должна вызвать большой интерес у представителей IT. По заявлениям OpenAI, эта модель таргетирована на работу с кодом и не уступает по качеству o1-preview. Но при этом на 80% дешевле. Больше деталей о моделях и сравнительный анализ можно найти тут.

Интересно будет прогнать через новые модели все промпты с моего тренинга по ChatGPT. Планирую сделать это на следующей неделе. Обязательно поделюсь с вами результатами.

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

Давайте определим для начала что будем называть плоской организацией. Для простоты, пусть это будет организация с минимальным количеством управленческих слоев между руководителями (C level) и рядовыми сотрудниками. Для маленькой организации количество таких слоев может быть 0. Это и будет наша идеально плоская организация.

Что мешает ей такой и оставаться с ростом числа сотрудников? Необходимость масштабировать следующие направления без построения иерархии менеджмента:

1. Работа со стейкхолдерами.
2. Управление требованиями и приоритетами.
3. Управление процессами разработки и поддержки.
4. Развитие инженерной культуры и архитектурных решений.
5. Работа с сотрудниками (найм, развитие, увольнение и т.д.).

1 и 2 можно отдать на роль Product Owner или Product Manager и масштабировать горизонтально по количеству продуктов или независимых продуктовых областей в организации. Если оставить чисто бизнесовую роль, то иерархия не возникает. За PnL в этом случае продолжает отвечать C level.

Пункт 3 можно попытаться построить на балансе готовых фреймворков и самоорганизации команд разработки. Для этого понадобится больший уровень зрелости членов команды и кто-то помогающий адаптировать выбранный фреймворк под потребности организации. Например, ScrumMaster или Agile Coach. Если организация не может позволить себе нанимать в команды только зрелых инженеров, то появляется потребность в роли Tech Lead (не путать с Team Lead) на уровне команд. Так как роль сугубо инженерная, то она не влияет на уровни иерархии.

Пункт 4 сложнее всего реализовать на базе самоорганизации. Тут требуется большой уровень инженерной зрелости от членов команды. Нанимать таких дорого и долго. Поэтому чаще всего организации возвращаются снова к роли Tech Lead на уровне команд. Инженерные решения на уровне всей организации можно принимать и внедрять группой техлидов во главе с CTO. Дополняют картину сильные лидеры инженерных направлений (QA, iOS, Android, Web и т.д.).

Пункт 5 самый сложный в реализации без иерархий. Напрашивается вариант отдать все эти функции HR как сервису в рамках организации. Часть потребностей это покрывает при высоком уровне квалификации HR команды. Но остаются вопросы с увольнением, ростом и развитием. Развитие можно переложить частично в формате менторства на техлида и синьор инженеров в командах. А вот увольнение и рост снова упираются в зрелость инженеров в командах. При высоком уровне зрелости можно построить процесс 360 ревью на базе сбалансированной системы оценки сотрудников.

В качестве хака некоторые компании закрывают пункт 5 «инженерными менеджерами», которые на самом деле к инженерии не имеют отношения. Их задача фактически заниматься инженерами, помогать им развиваться в организации и становиться более эффективными. Такой себе people менеджер с инженерным бэкграундом.

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

Надо ли это всем организациям? Уверен что нет. А вы что думаете?

За последние несколько лет направление оптимизации старта и использования ресурсов Java приложений очень существенно продвинулось. В каждой версии Java и Spring Boot реализуются оптимизации производительности. Помимо native образов продолжают развиваться Crac, CDS и проект Leyden.

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

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

P.S.: Что точно не рекомендую, так это использовать buildpacks для сборки образов. Более непрозрачного и специфичного подхода сложно придумать. Хотя его по какой-то непонятной причине очень активно продвигают в Spring Boot сообществе.

#Java #SpringBoot

Меня часто спрашивают как обезопасить себя от потери работы в IT в связи со стремительным развитием AI. Для ответа на этот вопрос нужно попробовать представить себе типовую разработку в будущем. Перспектива 2-3 года с текущей экспоненциальной скоростью изменений вполне подойдет.

Давайте начнем с того какие навыки будут максимально обесцениваться.

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

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

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

1. Написание кода. Эта область покрывается LLM проще всего, потому что языки программирования хорошо структурированы и написанного за долгие годы кода достаточно для тренировки моделей на любой вкус. Добавление инструментов для использования из LLM и цикл обратной связи для самообучения полностью закрывают вопрос. Еще 1-2 года максимум и тема будет закрыта. Как когда-то закрылась тема игры в шахматы с компьютером. :)

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

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

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

1. Менеджмент. Тут вообще интересная история. Менеджмент нужен тогда, когда работает множество людей и нужно организовать их работу. Если людей станет сильно меньше и зрелость оставшихся будет достаточно большой, то необходимость в менеджменте сильно сократиться. Задачи наподобие организовать процессы работы команды из 2 синьоров, 2 мидлов и 5 джунов уйдут в прошлое.

Определенная необходимость в менеджменте на уровне продукта или всей организации безусловно останется. Перспективное направление это продакт менеджеры, CTO, Head of Infastructure и т.д. Обязательно с практическими навыками в своей области и умением работать с AI-powered командами.

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

Кому интересно почитать еще мыслей на данную тему, рекомендую глянуть статью Agile in the Age of AI.