Технологии
xpinjection
Технологии
24.03.202518:10
На фоне падающих общих показателей по количеству открытых вакансий в Украине, рад поделиться своими горячими вакансиями.
Начнем с сильного Middle+ PHP Developer. Требуется практический опыт реализации event-driven архитектуры с микросервисами на Symphony фреймворке, RabbitMq, Kafka, PostgreSQL, MongoDb. Обязательно наличие в арсенале ключевых инженерных практик и навыков DDD. Желательно иметь практический опыт с K8S.
Вторая позиция это привычный Senior Java Developer. Тут все по классике: микросервисы, Java 21+, Spring Boot, RabbitMq, Kafka, PostgreSQL, MongoDb, разворачивание и масштабирование в AWS и K8S. Ключевым навыком является умение быстро разбираться в сложном контексте и находить эффективные решения задач в режиме неопределенности. Приветствуется e-com и fintech опыт.
Ну и наконец, Senior Golang Developer. Требуется практический опыт работы с высоконагруженными сервисами и культура применения ключевых инженерных практик. Очень желательно иметь fintech или банковский опыт.
На вопросы по вакансиям буду рад ответить в комментариях или в личке. CV можно кидать сразу в личку @xpinjection.
Начнем с сильного Middle+ PHP Developer. Требуется практический опыт реализации event-driven архитектуры с микросервисами на Symphony фреймворке, RabbitMq, Kafka, PostgreSQL, MongoDb. Обязательно наличие в арсенале ключевых инженерных практик и навыков DDD. Желательно иметь практический опыт с K8S.
Вторая позиция это привычный Senior Java Developer. Тут все по классике: микросервисы, Java 21+, Spring Boot, RabbitMq, Kafka, PostgreSQL, MongoDb, разворачивание и масштабирование в AWS и K8S. Ключевым навыком является умение быстро разбираться в сложном контексте и находить эффективные решения задач в режиме неопределенности. Приветствуется e-com и fintech опыт.
Ну и наконец, Senior Golang Developer. Требуется практический опыт работы с высоконагруженными сервисами и культура применения ключевых инженерных практик. Очень желательно иметь fintech или банковский опыт.
На вопросы по вакансиям буду рад ответить в комментариях или в личке. CV можно кидать сразу в личку @xpinjection.
11.01.202512:48
Сегодня поговорим про интересные ловушки при переходе на должность следующего уровня влияния в организации. К примеру, переход из разработчика (операционный уровень) в техлида (тактический уровень) или из техлида в солюшен архитектора (стратегический уровень). Подобные переходы есть и по другим направлениям: QA инженер -> QA лид -> QA manager/Head of QA.
В чем сложность данного перехода помимо новых зон ответственности и требований к новым навыкам? На моем опыте, ключевая сложность в том, чтобы быстро обойти ключевые ловушки развития.
Первой ловушкой является операционная работа (операционка). Она натурально засасывает в себя. Ведь еще вчера ты мог делать что-то руками и очень тяжело подвинуть это по приоритетам вниз. У кого-то дополнительно добавляется страх перестать быть профессионалом своего дела или потерять уважение коллег. Операционка стремится занять все доступное время. Она обволакивает зоной комфорта.
Тут помогает контроль распределения времени и ежедневные цели. В идеале, % операционки должен быть на таком уровне, чтобы не терять связь с реальностью. Чаще всего речь о 10-20% времени. Если в новой роли получится все идеально организовать, то можно выйти на 30%. Если процент по факту выше, то почти наверняка человек попал в эту ловушку.
Вторая по значимости ловушка заключается в тяге к понятным задачам. Мозг любит понятные задачи, на них не нужно тратить много энергии или испытывать стресс. Но понятные задачи можно и нужно делегировать при переходе в новую роль. Потому что основная ценность в новой роли кроется в решении сложных и непонятных задач или декомпозиции их на понятные.
Тут помогает парочка вопросов к самому себе при выборе следующей задачи:
- Действительно ли это самая важная задача для наших ближайших целей?
- Почему эту задачу должен взять именно я? Какую ценность мое участие в задаче принесет остальным?
- Какая часть задачи должна быть решена с моим участием? Могу ли я делегировать на каком-то уровне данную задачу?
Третья ловушка сильно связана со второй и является ее продолжением. Она заключается в недоверии к качеству работы других людей. Включается формат эксперта с предыдущего уровня: «я точно знаю как сделать правильно, а они нет». И человек начинает погружаться глубоко в каждую задачу или процесс, пытаться поучаствовать в каждом принятии решений, чтобы не упустить «отклонений от правильного пути». А это быстро приводит к бутылочным горлышкам и замедлениям, когда все ждут одного человека чтобы продвигаться дальше по своей работе.
Самый простой способ проверить нахождение в этой ловушке - это взглянуть на % времени, который человек доступен для своей команды каждый день. Если для глубокого разговора по задаче нужно искать слот в календаре на 2-3 дня вперед, то человек уже по уши в этой ловушке.
Тут главным советом является отпустить морально желание «все сделать правильно» для зон с меньшим риском. Далеко не везде ошибка имеет одинаковую стоимость, а без ошибок люди плохо учатся. Еще помогает матрица с уровнями делегирования из Management 3.0 для членов своей команды. Нужно определить уровень делегирования для каждого из них и действовать соответственно текущим уровням. И иметь целью переход на хотя бы +1 уровень за 3-6 месяцев.
А какие ловушки вы встречали на своем карьерном пути при переходе в новую роль?
В чем сложность данного перехода помимо новых зон ответственности и требований к новым навыкам? На моем опыте, ключевая сложность в том, чтобы быстро обойти ключевые ловушки развития.
Первой ловушкой является операционная работа (операционка). Она натурально засасывает в себя. Ведь еще вчера ты мог делать что-то руками и очень тяжело подвинуть это по приоритетам вниз. У кого-то дополнительно добавляется страх перестать быть профессионалом своего дела или потерять уважение коллег. Операционка стремится занять все доступное время. Она обволакивает зоной комфорта.
Тут помогает контроль распределения времени и ежедневные цели. В идеале, % операционки должен быть на таком уровне, чтобы не терять связь с реальностью. Чаще всего речь о 10-20% времени. Если в новой роли получится все идеально организовать, то можно выйти на 30%. Если процент по факту выше, то почти наверняка человек попал в эту ловушку.
Вторая по значимости ловушка заключается в тяге к понятным задачам. Мозг любит понятные задачи, на них не нужно тратить много энергии или испытывать стресс. Но понятные задачи можно и нужно делегировать при переходе в новую роль. Потому что основная ценность в новой роли кроется в решении сложных и непонятных задач или декомпозиции их на понятные.
Тут помогает парочка вопросов к самому себе при выборе следующей задачи:
- Действительно ли это самая важная задача для наших ближайших целей?
- Почему эту задачу должен взять именно я? Какую ценность мое участие в задаче принесет остальным?
- Какая часть задачи должна быть решена с моим участием? Могу ли я делегировать на каком-то уровне данную задачу?
Третья ловушка сильно связана со второй и является ее продолжением. Она заключается в недоверии к качеству работы других людей. Включается формат эксперта с предыдущего уровня: «я точно знаю как сделать правильно, а они нет». И человек начинает погружаться глубоко в каждую задачу или процесс, пытаться поучаствовать в каждом принятии решений, чтобы не упустить «отклонений от правильного пути». А это быстро приводит к бутылочным горлышкам и замедлениям, когда все ждут одного человека чтобы продвигаться дальше по своей работе.
Самый простой способ проверить нахождение в этой ловушке - это взглянуть на % времени, который человек доступен для своей команды каждый день. Если для глубокого разговора по задаче нужно искать слот в календаре на 2-3 дня вперед, то человек уже по уши в этой ловушке.
Тут главным советом является отпустить морально желание «все сделать правильно» для зон с меньшим риском. Далеко не везде ошибка имеет одинаковую стоимость, а без ошибок люди плохо учатся. Еще помогает матрица с уровнями делегирования из Management 3.0 для членов своей команды. Нужно определить уровень делегирования для каждого из них и действовать соответственно текущим уровням. И иметь целью переход на хотя бы +1 уровень за 3-6 месяцев.
А какие ловушки вы встречали на своем карьерном пути при переходе в новую роль?
23.11.202413:33
Сегодня речь пойдет об архитектурных паттернах в высоконагруженных системах. Я часто слышу как люди связывают или даже отождествляют CQRS и Event-Driven Architecture. Хотя связь между ними весьма слабая.
CQRS про разделение потоков запросов на запись и чтение с фокусом их оптимизацию. Для реализации CQRS вовсе необязательно использовать Event-Driven Architecture или вообще использовать брокер сообщений/эвентов. Хотя такая реализация тоже возможна и помогает максимально разделить записывающий и читающий компоненты, принося новую боль в виде eventual consistency.
Про разные варианты реализации CQRS можно прочитать в этой статье.
Event-Driven Architecture (EDA), в свою очередь, является архитектурным подходом к построению адаптивных, устойчивых, масштабируемых распределенных систем за счет снижения уровня связанности компонентов. В его основе лежит генерация событий об изменениях в состоянии системы и построение бизнес процессов на реакции на эти события. В рамках EDA существует множество готовых дизайн паттернов под разные кейсы.
И что еще важнее, как CQRS так и EDA могут применяться не только в микросервисной архитектуре. :)
CQRS про разделение потоков запросов на запись и чтение с фокусом их оптимизацию. Для реализации CQRS вовсе необязательно использовать Event-Driven Architecture или вообще использовать брокер сообщений/эвентов. Хотя такая реализация тоже возможна и помогает максимально разделить записывающий и читающий компоненты, принося новую боль в виде eventual consistency.
Про разные варианты реализации CQRS можно прочитать в этой статье.
Event-Driven Architecture (EDA), в свою очередь, является архитектурным подходом к построению адаптивных, устойчивых, масштабируемых распределенных систем за счет снижения уровня связанности компонентов. В его основе лежит генерация событий об изменениях в состоянии системы и построение бизнес процессов на реакции на эти события. В рамках EDA существует множество готовых дизайн паттернов под разные кейсы.
И что еще важнее, как CQRS так и EDA могут применяться не только в микросервисной архитектуре. :)
30.10.202416:01
И хорошее продолжение предыдущей темы.
#kafka
https://youtu.be/2FNhKB3DK5Y?si=1NGsY8RVGlBiXjFU
#kafka
https://youtu.be/2FNhKB3DK5Y?si=1NGsY8RVGlBiXjFU
24.09.202413:00
Я давно в канале не рекомендовал книги. Но тут просто не могу пройти мимо. За $25 вы можете получить, на мой взгляд, лучший набор книг по теме software architecture. Тут есть фундаментальные книги по архитектуре от Нила Форда, набор книг по микросервисам от Сэма Ньюмана, покрыты дополнительные архитектурные направления как Domain-Driven Design, API, Event-Driven Architecture, Serverless и т.д.
С этим набором у желающих развиваться в роль архитектора не будет вопросов что бы еще прочитать полезного минимум на год вперед. :)
#architecture #books
https://www.humblebundle.com/books/software-architecture-2024-oreilly-books
С этим набором у желающих развиваться в роль архитектора не будет вопросов что бы еще прочитать полезного минимум на год вперед. :)
#architecture #books
https://www.humblebundle.com/books/software-architecture-2024-oreilly-books
24.08.202408:54
З Днем Народження, Україна! Найкраща і найрідніша країна для мільйонів людей. Така різноманітна і неповторна, незламна і незалежна!
Великий уклін усім тим, хто бореться і ризикує своїм життям заради нашої незалежності та нашого майбутнього!
Великий уклін усім тим, хто бореться і ризикує своїм життям заради нашої незалежності та нашого майбутнього!
20.03.202510:03
На днях появился торжественный анонс Apache Kafka 4.0. Из главных новостей финально отказались от использования ZooKeeper, выкатили ранний доступ к реализации очередей и новый улучшенный протокол консьюмер групп.
Давно не было таких существенных изменений в мире Kafka. Прямо не терпится пощупать на реальных кейсах.
Давно не было таких существенных изменений в мире Kafka. Прямо не терпится пощупать на реальных кейсах.
31.12.202417:13
Подошел к концу 2024 год. В IT он однозначно запомнился поразительно быстрым развитием AI. Всего за год мы получили широкое разнообразие моделей от разных провайдеров, огромные контекстные окна, новое поколение моделей с глубоким размышлением, побили все прогнозы по бенчмаркам, получили мощные AI инструменты на десктопных ОС, мобильных телефонах, в браузерах и большинстве привычных приложений… Нам сильно повезло жить в такое удивительное время.
Из негативного, этот год стал очередным годом ужасной войны, человеческих потерь и разрушений, политических манипуляций и разочарований. Печальнее всего то, что ежедневные ужасы войны стали повседневной нормой для людей. Жизнь продолжается, люди работают, воспитывают детей, ходят в отпуск, отмечают праздники, радуются жизни и строят планы на будущее. Все это возможно благодаря усилиям ЗСУ, волонтеров и других наших защитников. За что им низкий поклон!
Пусть 2025 год станет годом долгожданной победы Украины и мирного неба над головой, принесет нам еще больше инноваций, крутых идей и реализации самых амбициозных планов. Желаю каждому прожить наступающий год так, чтобы было чем гордиться! А также крепкого вам физического и ментального здоровья. С наступающим Новым Годом! 🎄🥂🍾
Из негативного, этот год стал очередным годом ужасной войны, человеческих потерь и разрушений, политических манипуляций и разочарований. Печальнее всего то, что ежедневные ужасы войны стали повседневной нормой для людей. Жизнь продолжается, люди работают, воспитывают детей, ходят в отпуск, отмечают праздники, радуются жизни и строят планы на будущее. Все это возможно благодаря усилиям ЗСУ, волонтеров и других наших защитников. За что им низкий поклон!
Пусть 2025 год станет годом долгожданной победы Украины и мирного неба над головой, принесет нам еще больше инноваций, крутых идей и реализации самых амбициозных планов. Желаю каждому прожить наступающий год так, чтобы было чем гордиться! А также крепкого вам физического и ментального здоровья. С наступающим Новым Годом! 🎄🥂🍾
11.11.202415:23
В ноябре 2024 года я праздную сразу 2 юбилея: 20 лет работы в IT и 15 лет XP Injection. Сложно поверить что я сколько лет провел в этой индустрии.
В далеком 2004 году на предпоследнем курсе универа я начал свой путь в IT как Java разработчик в маленькой компании и сразу попал в активный водоворот развития. Через полгода мне пришлось заменять единственного заболевшего техлида, а еще через полгода я уже сам работал техлидом.
Потом был переезд в Киев, работа по аутсорс и аутстаф моделям на клиентов в USA и UK как разработчик, техлид, архитектор и инженерный менеджер. А в 2009 году я решил начать учить других людей тому, что у меня неплохо получалось и организовать с единомышленниками инженерные конференции по Java, автоматизации тестирования и инженерным практикам. Так получился XP Injection.
С тех пор я начал развиваться в направлении консалтинга, появились первые клиенты из небольших продуктовых компаний. В 2015 году я решил попробовать себя в большой корпорации на синьор менеджерской позиции и присоединился к ЕПАМ. А уже в 2017 году я понял, что не хочу работать в корпорации и решил полностью уйти в консалтинг. Так начались мои самые насыщенные и интересные годы в IT. Разные клиенты, домены, проблемы, роли, задачи и вызовы…
Эти 20 лет стали настоящей проверкой на то, действительно ли я занимаюсь любимым делом и получаю от него удовольствие. Я все еще не выгорел и полон сил, поэтому show must go on! :)
В далеком 2004 году на предпоследнем курсе универа я начал свой путь в IT как Java разработчик в маленькой компании и сразу попал в активный водоворот развития. Через полгода мне пришлось заменять единственного заболевшего техлида, а еще через полгода я уже сам работал техлидом.
Потом был переезд в Киев, работа по аутсорс и аутстаф моделям на клиентов в USA и UK как разработчик, техлид, архитектор и инженерный менеджер. А в 2009 году я решил начать учить других людей тому, что у меня неплохо получалось и организовать с единомышленниками инженерные конференции по Java, автоматизации тестирования и инженерным практикам. Так получился XP Injection.
С тех пор я начал развиваться в направлении консалтинга, появились первые клиенты из небольших продуктовых компаний. В 2015 году я решил попробовать себя в большой корпорации на синьор менеджерской позиции и присоединился к ЕПАМ. А уже в 2017 году я понял, что не хочу работать в корпорации и решил полностью уйти в консалтинг. Так начались мои самые насыщенные и интересные годы в IT. Разные клиенты, домены, проблемы, роли, задачи и вызовы…
Эти 20 лет стали настоящей проверкой на то, действительно ли я занимаюсь любимым делом и получаю от него удовольствие. Я все еще не выгорел и полон сил, поэтому show must go on! :)
28.10.202418:53
Одни из моих любимых вопросов на собеседовании касаются неблокирующих протоколов коммуникации в распределенных системах. И когда речь заходит об инструментах, то я часто слышу ответ в стиле: «мы взяли Kafka в качестве брокера, потому что она проще и меньше заморочек».
Мне кажется такое мнение появляется благодаря фреймворкам, которые упрощают дефолтный опыт разработчика и позволяют быстро стартануть с новой для них технологией. И большинство даже не разбирается что там под капотом, о каких настройках стоит знать и явно установить. Для примера рекомендую посмотреть доклад с детальным разбором как Kafka работает по стороны продюсера. Думаю, многие откроют для себя что-то новое. :)
#kafka
https://youtu.be/eHWFHFQ8tKo?si=kV0ptwyJJHuNoS_4
Мне кажется такое мнение появляется благодаря фреймворкам, которые упрощают дефолтный опыт разработчика и позволяют быстро стартануть с новой для них технологией. И большинство даже не разбирается что там под капотом, о каких настройках стоит знать и явно установить. Для примера рекомендую посмотреть доклад с детальным разбором как Kafka работает по стороны продюсера. Думаю, многие откроют для себя что-то новое. :)
#kafka
https://youtu.be/eHWFHFQ8tKo?si=kV0ptwyJJHuNoS_4
17.09.202412:26
На прошлой неделе прокатилась волна обсуждений интересного документа. Опубликовали "утекшую" версию (я не уверен что такие утечки случаются без причин) описания внутренних принципов работы компании MrBeast YouTube Production. Их видео получают сотни миллионов просмотров на YouTube и можно уверенно называть чуть ли не самым успешным проектом на этой площадке. Поэтому принципы работы такой успешной организации однозначно вызывают интерес.
Сразу оговорюсь, неизвестно насколько всем этим принципам и паттернам следуют на практике. Вот ТОП-10, зацепивших меня во время прочтения документа:
1. Hands-on основатель, глубоко понимающий бизнес, который тесно интегрирован в работу организации на всех уровнях. Он ассоциирует себя и свою жизнь с продуктом и его успешностью.
2. На ключевых позициях A-players, на вырост B-players, отказ от C-players. Ставка на лидерство и проактивность.
3. Четкие и понятные принципы, которыми руководствуются сотрудники организации (креатив - основной двигатель, ответственность за результат, учиться на своих ошибках и т.д.).
4. Прозрачные цели и формализованные метрики, которыми можно измерять успешность, а не фантазировать на тему успеха.
5. Ответственность за результат, а не за процесс. Взятие ответственности за достижение результата, а не перекладывание ее на обстоятельства, подрядчиков и другие причины.
6. Признание своих ошибок и извлечение из них уроков как обязательный элемент культуры.
7. Постоянный рост зрелости организации по всем фронтам (иначе сложность работы просто захлестнет и не получится поддерживать качество).
8. Строгое управление приоритетами с фокусом на критичные элементы. Управление рисками от критичных элементов.
9. Экономия бюджета за счет креативности. Бюджет важен, но не должен становиться ограничением креативности на пути к цели, за счет креативности можно экономить.
10. Привлечение консультантов и внешней экспертизы в тех областях, где нет своей экспертизы или недостаточно опыта. За счет этого можно достичь большой экономии времени (критичный ресурс) и затрат на неверные решения.
В документе также отлично разобрана тема производства популярных видео на YouTube. Может помочь владельцам YouTube каналов улучшить свои показатели.
Сразу оговорюсь, неизвестно насколько всем этим принципам и паттернам следуют на практике. Вот ТОП-10, зацепивших меня во время прочтения документа:
1. Hands-on основатель, глубоко понимающий бизнес, который тесно интегрирован в работу организации на всех уровнях. Он ассоциирует себя и свою жизнь с продуктом и его успешностью.
2. На ключевых позициях A-players, на вырост B-players, отказ от C-players. Ставка на лидерство и проактивность.
3. Четкие и понятные принципы, которыми руководствуются сотрудники организации (креатив - основной двигатель, ответственность за результат, учиться на своих ошибках и т.д.).
4. Прозрачные цели и формализованные метрики, которыми можно измерять успешность, а не фантазировать на тему успеха.
5. Ответственность за результат, а не за процесс. Взятие ответственности за достижение результата, а не перекладывание ее на обстоятельства, подрядчиков и другие причины.
6. Признание своих ошибок и извлечение из них уроков как обязательный элемент культуры.
7. Постоянный рост зрелости организации по всем фронтам (иначе сложность работы просто захлестнет и не получится поддерживать качество).
8. Строгое управление приоритетами с фокусом на критичные элементы. Управление рисками от критичных элементов.
9. Экономия бюджета за счет креативности. Бюджет важен, но не должен становиться ограничением креативности на пути к цели, за счет креативности можно экономить.
10. Привлечение консультантов и внешней экспертизы в тех областях, где нет своей экспертизы или недостаточно опыта. За счет этого можно достичь большой экономии времени (критичный ресурс) и затрат на неверные решения.
В документе также отлично разобрана тема производства популярных видео на YouTube. Может помочь владельцам YouTube каналов улучшить свои показатели.
18.08.202412:35
Я взял паузу и некоторое время ничего не публиковал в канале. Нужно было «перезарядить батарейки» и немного разгрестись по работе. Теперь буду возвращаться к регулярным постам.
Сегодня хочу затронуть тему коммуникационных стилей в распределенных системах. С популяризацией микросервисов очень много команд перешли из мира локальных вызовов кода к сильно распределенным системам. И первым натуральным позывом было просто заменить локальные вызовы на синхронные stateless протоколы как HTTP или gRPC. Благо, тех же реализаций HTTP клиентов в любом стеке предостаточно. Просто, быстро и очень похоже на локальные вызовы.
Но синхронные stateless протоколы никак не решают проблемы распределенных систем, перекладывая их целиком на разработчиков. А если разработчики не заморачиваются подобными «мелочами», то очень быстро приходят к распределенным монолитам, каскадным падениям под нагрузкой и инцидентам с потерей консистентности данных. И приходит осознание, что так настоящие микросервисы не построить.
Тут на помощь приходят асинхронные протоколы коммуникации. Тем более, решений предостаточно: олдскульный JMS, RabbitMq с AMQP протоколом, Kafka и другие решения для евент стриминга… И снова многие попадают в ловушку надежды на то, что протокол закроет собой все проблемы и сложности распределенных систем. Поэтому они просто берут настройки по умолчанию и надеются что все будет хорошо.
Но чудес не бывает и проблемы распределенной коммуникации никуда не делись. Поэтому разработчики должны для каждого сценария коммуникации между сервисами выбрать какой формат доставки им подходит:
1. At-Least Once
2. At-Most Once
3. Exactly Once
Первые 2 покрываются практически всеми инструментами, но требуют разных настроек. Exactly Once может быть реализован только для определенных сценариев, далеко не во всех протоколах/реализациях и в универсальном смысле недостижим. Kafka дает разработчикам для использования все 3 семантики. Чтобы детально разобраться в теме, рекомендую почитать вот эту статью:
https://engineering.hellofresh.com/demystifying-kafka-exactly-once-semantics-eos-390ae1c32bba
#kafka #architecture
Сегодня хочу затронуть тему коммуникационных стилей в распределенных системах. С популяризацией микросервисов очень много команд перешли из мира локальных вызовов кода к сильно распределенным системам. И первым натуральным позывом было просто заменить локальные вызовы на синхронные stateless протоколы как HTTP или gRPC. Благо, тех же реализаций HTTP клиентов в любом стеке предостаточно. Просто, быстро и очень похоже на локальные вызовы.
Но синхронные stateless протоколы никак не решают проблемы распределенных систем, перекладывая их целиком на разработчиков. А если разработчики не заморачиваются подобными «мелочами», то очень быстро приходят к распределенным монолитам, каскадным падениям под нагрузкой и инцидентам с потерей консистентности данных. И приходит осознание, что так настоящие микросервисы не построить.
Тут на помощь приходят асинхронные протоколы коммуникации. Тем более, решений предостаточно: олдскульный JMS, RabbitMq с AMQP протоколом, Kafka и другие решения для евент стриминга… И снова многие попадают в ловушку надежды на то, что протокол закроет собой все проблемы и сложности распределенных систем. Поэтому они просто берут настройки по умолчанию и надеются что все будет хорошо.
Но чудес не бывает и проблемы распределенной коммуникации никуда не делись. Поэтому разработчики должны для каждого сценария коммуникации между сервисами выбрать какой формат доставки им подходит:
1. At-Least Once
2. At-Most Once
3. Exactly Once
Первые 2 покрываются практически всеми инструментами, но требуют разных настроек. Exactly Once может быть реализован только для определенных сценариев, далеко не во всех протоколах/реализациях и в универсальном смысле недостижим. Kafka дает разработчикам для использования все 3 семантики. Чтобы детально разобраться в теме, рекомендую почитать вот эту статью:
https://engineering.hellofresh.com/demystifying-kafka-exactly-once-semantics-eos-390ae1c32bba
#kafka #architecture
28.02.202510:20
Сегодня новостной пост. В мире AI новости несутся просто дикими темпами, очень сложно за ними успевать. Из интересного за последние 2 месяца:
- Появление китайского DeepSeek R1 сильно тряхнуло рынок LLM. Интересная альтернатива из класса open-source моделей, которая сильно дешевле в использовании и близка по качеству ответов топовым моделям. Сам же сервис DeepSeek используют разве что отважные и безрассудные люди. Там дыры и в безопасности, и в стабильности, и в присутствии контроля правительства Китая.
- Сразу 3 крупных игрока выпустили фичу Deep Research в своих продуктах с абсолютно одинаковым названием. Это автономный агент для глубокого анализа веб контента с генерацией отчета по задаче пользователя. Первый пример массово доступного агента, который может решать задачу долго (от минут до получаса) и обрабатывать на свое усмотрение дополнительные материалы.
- Из интервью с представителями Google, OpenAI и Microsoft выглядит так, что в 2025 году фокус и основная ставка будет на создание автономных агентов через Reinforced Learning from Human Feedback. Оказалось, что дообучение базовой модели для полного решения бизнес задачи дало лучше результат чем попытка оркестрировать работу с моделями из многочисленных агентских фреймворков.
- Размер контекста перестает быть значимым фактором. Большинство моделей от популярных провайдеров перешагнули лимит в 100К токенов и он уже считается чем-то привычным. Все больше моделей предлагают лимит в 1-2 млн токенов. Это просто огромные контексты, которые позволяют решать задачи наподобие взять весь код проекта или огромный кусок базы знаний и задать по нему вопрос в одном промпте.
- Основной вектор развития моделей направлен на deep reasoning. Тут просто огромное поле для экспериментов и улучшений, которые направлены на уменьшение галлюцинаций, повышение качества и глубины ответов. Есть ощущение, что на этой веточке развития задача написания кода должна быть решена близко к идеалу.
Из мелких новостей, OpenAI выпустил новую базовую модель GPT-4.5 и возвращается к адекватному именованию моделей. :) А Anthropic зарелизил свой Claude 3.7 Sonnet и объявил его лучшей моделью для задач разработки. В новой модели можно регулировать глубину размышлений в зависимости от задачи. И в бету от того же Anthropic вышел новый тул для разработчиков Claude Code. Тут ребята решили подойти к задаче создания ассистента разработки со стороны консоли. Любопытный выбор, не терпится попробовать на практике.
- Появление китайского DeepSeek R1 сильно тряхнуло рынок LLM. Интересная альтернатива из класса open-source моделей, которая сильно дешевле в использовании и близка по качеству ответов топовым моделям. Сам же сервис DeepSeek используют разве что отважные и безрассудные люди. Там дыры и в безопасности, и в стабильности, и в присутствии контроля правительства Китая.
- Сразу 3 крупных игрока выпустили фичу Deep Research в своих продуктах с абсолютно одинаковым названием. Это автономный агент для глубокого анализа веб контента с генерацией отчета по задаче пользователя. Первый пример массово доступного агента, который может решать задачу долго (от минут до получаса) и обрабатывать на свое усмотрение дополнительные материалы.
- Из интервью с представителями Google, OpenAI и Microsoft выглядит так, что в 2025 году фокус и основная ставка будет на создание автономных агентов через Reinforced Learning from Human Feedback. Оказалось, что дообучение базовой модели для полного решения бизнес задачи дало лучше результат чем попытка оркестрировать работу с моделями из многочисленных агентских фреймворков.
- Размер контекста перестает быть значимым фактором. Большинство моделей от популярных провайдеров перешагнули лимит в 100К токенов и он уже считается чем-то привычным. Все больше моделей предлагают лимит в 1-2 млн токенов. Это просто огромные контексты, которые позволяют решать задачи наподобие взять весь код проекта или огромный кусок базы знаний и задать по нему вопрос в одном промпте.
- Основной вектор развития моделей направлен на deep reasoning. Тут просто огромное поле для экспериментов и улучшений, которые направлены на уменьшение галлюцинаций, повышение качества и глубины ответов. Есть ощущение, что на этой веточке развития задача написания кода должна быть решена близко к идеалу.
Из мелких новостей, OpenAI выпустил новую базовую модель GPT-4.5 и возвращается к адекватному именованию моделей. :) А Anthropic зарелизил свой Claude 3.7 Sonnet и объявил его лучшей моделью для задач разработки. В новой модели можно регулировать глубину размышлений в зависимости от задачи. И в бету от того же Anthropic вышел новый тул для разработчиков Claude Code. Тут ребята решили подойти к задаче создания ассистента разработки со стороны консоли. Любопытный выбор, не терпится попробовать на практике.
14.12.202411:52
Судя по количеству откликов, у всех все хорошо с работой и поэтому я очень рад за подписчиков. 🤗
02.11.202409:54
Вчерашняя рабочая пятница прошла как на этой картинке. :)
19.10.202409:44
На прошлой неделе проходила очередная конференция Devoxx. В этом году основными выделяющимися трендами стали предсказуемо AI и современные фичи Java (виртуальные потоки, развитие новых проектов и т.д.). Но при этом данные темы не забили плотно расписание докладов и в этом году разнообразных тем было более чем достаточно.
Записи докладов публиковались прямо во время конференции, но теперь уже окончательно устаканились и можно смело рекомендовать к просмотру.
Хороших вам образовательных выходных!
#конференции
https://youtube.com/playlist?list=PLRsbF2sD7JVrNB1mKqklpc23hsKtvMAXm&si=ws07R8-Ttvwy-vjV
Записи докладов публиковались прямо во время конференции, но теперь уже окончательно устаканились и можно смело рекомендовать к просмотру.
Хороших вам образовательных выходных!
#конференции
https://youtube.com/playlist?list=PLRsbF2sD7JVrNB1mKqklpc23hsKtvMAXm&si=ws07R8-Ttvwy-vjV
13.09.202408:40
Многие ждали этой осенью очередного прорыва в мире 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. Планирую сделать это на следующей неделе. Обязательно поделюсь с вами результатами.
Серия моделей o1-preview ориентирована на решение сложных проблем в таких областях как наука, программирование и математика. Новая «фича» заключается в том, что модель будет тратить больше времени на «рассуждения» перед ответом. Это позволяет им решать задачи, требующие более глубокого размышления.
Например, модель o1-preview набрала 83% баллов по квалификационным задачам международной математической олимпиады по сравнению с 13% у GPT-4. Отличные новости для школьников и студентов, ведь делать домашку станет еще легче. ;)
А вот модель o1-mini должна вызвать большой интерес у представителей IT. По заявлениям OpenAI, эта модель таргетирована на работу с кодом и не уступает по качеству o1-preview. Но при этом на 80% дешевле. Больше деталей о моделях и сравнительный анализ можно найти тут.
Интересно будет прогнать через новые модели все промпты с моего тренинга по ChatGPT. Планирую сделать это на следующей неделе. Обязательно поделюсь с вами результатами.
01.07.202410:16
За последние несколько лет направление оптимизации старта и использования ресурсов Java приложений очень существенно продвинулось. В каждой версии Java и Spring Boot реализуются оптимизации производительности. Помимо native образов продолжают развиваться Crac, CDS и проект Leyden.
Теперь каждый может выбрать тот вариант или комбинацию вариантов, которые лучше подходят для его контекста. Однозначно рекомендую экспериментировать на своих сервисах, чтобы оценить потенциальную выгоду.
Для более глубокого погружения в тему рекомендую посмотреть обзорный доклад с доступными техниками оптимизации и более глубокий доклад по применению CDS.
P.S.: Что точно не рекомендую, так это использовать buildpacks для сборки образов. Более непрозрачного и специфичного подхода сложно придумать. Хотя его по какой-то непонятной причине очень активно продвигают в Spring Boot сообществе.
#Java #SpringBoot
Теперь каждый может выбрать тот вариант или комбинацию вариантов, которые лучше подходят для его контекста. Однозначно рекомендую экспериментировать на своих сервисах, чтобы оценить потенциальную выгоду.
Для более глубокого погружения в тему рекомендую посмотреть обзорный доклад с доступными техниками оптимизации и более глубокий доклад по применению CDS.
P.S.: Что точно не рекомендую, так это использовать buildpacks для сборки образов. Более непрозрачного и специфичного подхода сложно придумать. Хотя его по какой-то непонятной причине очень активно продвигают в Spring Boot сообществе.
#Java #SpringBoot
16.02.202511:31
Мне часто приходится нанимать разработчиков на синьор позиции и я раньше сильно удивлялся после провальных собеседований. Ведь мы по CV тщательно отбираем кандидатов, которые уже имеют значительный релевантный опыт работы на синьорной позиции. Как их тогда нанимали предыдущие работодатели и почему до сих пор с ними сотрудничают?
А потом я понял, что существуют разные виды синьорити и в разных организациях/контекстах/командах они востребованы в разной степени. Я для себя выделил такие виды:
1. Технологическая синьорити. Кандидат отлично понимает базовые технологические принципы, умеет быстро учиться и разбираться с любыми новыми для себя технологиями, в своем основном техническом стеке разбирается очень глубоко и постоянно следит за его развитием. Обычно таким людям в кайф работать в своей индустрии и они работают «по призванию». Это тот вид синьорити, который я обычно ищу для продуктовых команд.
2. Корпоративная синьорити. Кандидат имеет опыт работы с разного типа менеджментом, процессами и структурой команд, умеет играть по установленным корпоративным правилам и они не вызывают у него выгорания, может делать требуемую от него работу самостоятельно на приемлемом уровне качества. Такой вид зрелости очень востребован в аутсорс компаниях. Из таких людей можно построить костяк команды на любом проекте для любого заказчика.
3. Прикладная синьорити. Кандидат умеет быстро и достаточно качественно выполнять типовые задачи в своем технологическом стеке, с которым он уже давно работает. Он копает в глубину и по сторонам ровно настолько, чтобы решать типовые задачи от бизнеса. Переход на другой стек может быть для него очень болезненным и поэтому кандидат везде старается применять свой привычный стек, вне зависимости от контекста. Такие люди зачастую работают в IT потому что тут хорошо платят и синьорити для них ассоциируется с карьерным и зарплатным ростом.
4. Доменная синьорити. Кандидат долго работает в одном бизнес домене, отлично изучил его и знает как нужно решать бизнес задачи в этом домене. При этом, часто технологический стек может быть у кандидата весьма устаревший или специфический. Ведь его основная сила не в этом. Такие люди очень востребованы в энтерпрайз организациях со сложным бизнес доменом.
Как видите, это совершенно разные виды синьорити и все они нужны и важны в определенном контексте. Поэтому для эффективного найма нужно точно определить какой микс видов синьорити важен вам и как вы будете его определять на прескрине кандидатов и основном собеседовании.
К примеру, рассмотрим контекст найма в продуктовую фича-команду, работающую по Scrum в fintech домене. Для меня идеальным набором является сильная технологическая синьорити с кусочком корпоративной синьорити. Если в дополнение будет кусочек доменной синьорити, то это огромный плюс.
Если бы я нанимал в аутсорс компанию, то фокусировался бы на смесь прикладной и корпоративной синьорити. Технологическая и доменная синьорити несли бы в себе риск потерять сотрудника при переходе между проектами.
А потом я понял, что существуют разные виды синьорити и в разных организациях/контекстах/командах они востребованы в разной степени. Я для себя выделил такие виды:
1. Технологическая синьорити. Кандидат отлично понимает базовые технологические принципы, умеет быстро учиться и разбираться с любыми новыми для себя технологиями, в своем основном техническом стеке разбирается очень глубоко и постоянно следит за его развитием. Обычно таким людям в кайф работать в своей индустрии и они работают «по призванию». Это тот вид синьорити, который я обычно ищу для продуктовых команд.
2. Корпоративная синьорити. Кандидат имеет опыт работы с разного типа менеджментом, процессами и структурой команд, умеет играть по установленным корпоративным правилам и они не вызывают у него выгорания, может делать требуемую от него работу самостоятельно на приемлемом уровне качества. Такой вид зрелости очень востребован в аутсорс компаниях. Из таких людей можно построить костяк команды на любом проекте для любого заказчика.
3. Прикладная синьорити. Кандидат умеет быстро и достаточно качественно выполнять типовые задачи в своем технологическом стеке, с которым он уже давно работает. Он копает в глубину и по сторонам ровно настолько, чтобы решать типовые задачи от бизнеса. Переход на другой стек может быть для него очень болезненным и поэтому кандидат везде старается применять свой привычный стек, вне зависимости от контекста. Такие люди зачастую работают в IT потому что тут хорошо платят и синьорити для них ассоциируется с карьерным и зарплатным ростом.
4. Доменная синьорити. Кандидат долго работает в одном бизнес домене, отлично изучил его и знает как нужно решать бизнес задачи в этом домене. При этом, часто технологический стек может быть у кандидата весьма устаревший или специфический. Ведь его основная сила не в этом. Такие люди очень востребованы в энтерпрайз организациях со сложным бизнес доменом.
Как видите, это совершенно разные виды синьорити и все они нужны и важны в определенном контексте. Поэтому для эффективного найма нужно точно определить какой микс видов синьорити важен вам и как вы будете его определять на прескрине кандидатов и основном собеседовании.
К примеру, рассмотрим контекст найма в продуктовую фича-команду, работающую по Scrum в fintech домене. Для меня идеальным набором является сильная технологическая синьорити с кусочком корпоративной синьорити. Если в дополнение будет кусочек доменной синьорити, то это огромный плюс.
Если бы я нанимал в аутсорс компанию, то фокусировался бы на смесь прикладной и корпоративной синьорити. Технологическая и доменная синьорити несли бы в себе риск потерять сотрудника при переходе между проектами.
13.12.202417:05
На фоне общих сокращений и кризиса в 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.
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.
31.10.202419:27
OpenAI запустил новую фичу ChatGPT Search. Google должен активно начинать волноваться. :)
Ну и наконец появился поиск по истории чатов. Необъяснимый парадокс почему его не добавили до этого.
#chatgpt
https://openai.com/index/introducing-chatgpt-search/
Ну и наконец появился поиск по истории чатов. Необъяснимый парадокс почему его не добавили до этого.
#chatgpt
https://openai.com/index/introducing-chatgpt-search/
12.10.202409:50
Сегодня хочу поделиться с вами тремя интересными новостями из мира ChatGPT.
1. Я прогнал большую часть задач с тренинга и часть своих прикладных задач через новую модель o1-preview. Результаты разительно отличаются. В некоторых случаях прямо вау эффект. Главное неудобство в переключении режима работы в голове с привычных техник промптинга на базовые. Иначе результат может быть хуже чем с моделью 4o.
2. OpenAI начал наконец совершенствовать UI под специфические задачи. Первым шагом стало внедрение Canvas. В специальной панели можно редактировать результаты работы модели самому или выделять кусочки и просить сделать доработки с более детальным контекстом. Для работающих с кодом и статьями это очень полезный инструмент. Вполне сойдет для разработчиков пока в IDE не внедрят что-то революционного.
3. В Playground добавили функцию помощи в генерации системных промптов. Кто не знает, Playground - это веб-кабинет для разработчиков, которые собираются интегрировать или экспериментируют с OpenAI API. Но эту фичу можно использовать и для своих обычных бытовых нужд. Структура промптов там взята из популярного шаблона. Но если она подходит под вашу задачу, то можно сэкономить кучу времени на продумывание каркаса качественного промпта. А это значит что кастомные GPT-шки можно создавать быстрее и проще.
Всем классных креативных выходных!
1. Я прогнал большую часть задач с тренинга и часть своих прикладных задач через новую модель o1-preview. Результаты разительно отличаются. В некоторых случаях прямо вау эффект. Главное неудобство в переключении режима работы в голове с привычных техник промптинга на базовые. Иначе результат может быть хуже чем с моделью 4o.
2. OpenAI начал наконец совершенствовать UI под специфические задачи. Первым шагом стало внедрение Canvas. В специальной панели можно редактировать результаты работы модели самому или выделять кусочки и просить сделать доработки с более детальным контекстом. Для работающих с кодом и статьями это очень полезный инструмент. Вполне сойдет для разработчиков пока в IDE не внедрят что-то революционного.
3. В Playground добавили функцию помощи в генерации системных промптов. Кто не знает, Playground - это веб-кабинет для разработчиков, которые собираются интегрировать или экспериментируют с OpenAI API. Но эту фичу можно использовать и для своих обычных бытовых нужд. Структура промптов там взята из популярного шаблона. Но если она подходит под вашу задачу, то можно сэкономить кучу времени на продумывание каркаса качественного промпта. А это значит что кастомные GPT-шки можно создавать быстрее и проще.
Всем классных креативных выходных!
28.08.202410:48
Сегодня поговорим о плоских организациях и способах их построения. Многие из моих клиентов декларируют желание строить плоскую организацию без иерархии менеджмента внутри. Причины простые - плоская организация в индустрии противопоставляется бюрократизированной иерархичной энтерпрайз организации. Ну и любая большая организация выросла из маленькой, поэтому ностальгические воспоминания о драйве и скорости без всяких там менеджеров постоянно всплывают в памяти.
Давайте определим для начала что будем называть плоской организацией. Для простоты, пусть это будет организация с минимальным количеством управленческих слоев между руководителями (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 менеджер с инженерным бэкграундом.
Как видите, строить и масштабировать плоскую структуру в организации можно, НО сложно, долго и дорого. Зачем тогда это нужно? На выходе получается более устойчивая организация, без критических зависимостей от конкретных людей в каждой роли. Есть возможности принимать и отвечать за решения в рамках команд, большая адаптивность в рамках организации, возможности для развития и роста без карьерной иерархии.
Надо ли это всем организациям? Уверен что нет. А вы что думаете?
Давайте определим для начала что будем называть плоской организацией. Для простоты, пусть это будет организация с минимальным количеством управленческих слоев между руководителями (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 менеджер с инженерным бэкграундом.
Как видите, строить и масштабировать плоскую структуру в организации можно, НО сложно, долго и дорого. Зачем тогда это нужно? На выходе получается более устойчивая организация, без критических зависимостей от конкретных людей в каждой роли. Есть возможности принимать и отвечать за решения в рамках команд, большая адаптивность в рамках организации, возможности для развития и роста без карьерной иерархии.
Надо ли это всем организациям? Уверен что нет. А вы что думаете?
08.06.202410:45
Меня часто спрашивают как обезопасить себя от потери работы в IT в связи со стремительным развитием AI. Для ответа на этот вопрос нужно попробовать представить себе типовую разработку в будущем. Перспектива 2-3 года с текущей экспоненциальной скоростью изменений вполне подойдет.
Давайте начнем с того какие навыки будут максимально обесцениваться.
1. Знания. Это самый первый навык, который идет под нож. Раньше обладание знаниями в технологии, домене, проекте, организации и т.д. считалось очень ценным. Потому что получали их люди долго и дорого. Обучение новых сотрудников занимало годы. Многие люди оставались в организации только потому что они обладали нужными знаниями.
С приходом LLM и их развитием доступ к огромному объему знаний становится дешевым и обыденным. Знания можно будет использовать под разными ракурсами, нужными для конкретных работ. Это похоже на эволюцию от счетов к калькулятору и компьютерным программам.
Где знания все таки останутся ценными? В узких доменах, которые нигде не описаны и не могут быть использованы для обучения LLM. Но мне кажется, что даже эта область знаний будет в итоге обесценена. Автоматизируются процессы сбора знаний с людей и их формализации. Уже сейчас есть готовые технологии для выделения знаний из дискуссий, обсуждений и пользовательских интервью.
2. Написание кода. Эта область покрывается LLM проще всего, потому что языки программирования хорошо структурированы и написанного за долгие годы кода достаточно для тренировки моделей на любой вкус. Добавление инструментов для использования из LLM и цикл обратной связи для самообучения полностью закрывают вопрос. Еще 1-2 года максимум и тема будет закрыта. Как когда-то закрылась тема игры в шахматы с компьютером. :)
Что в этой области останется востребованным на какое-то время? Навыки архитектуры и технического дизайна. Эта область слишком слабо формализована и описана на текущий момент. В этом причина того, что не получается просто почитать книжек и стать классным архитектором. И кто-то должен будет на первое время драйвить работу AI по написанию кода для получения целостного решения.
3. Документация. В эту категорию попадает целая пачка активностей: описание требований, постановка задач, формализация приемочных критериев и тестовых сценариев, техническая документация, пользовательская документация и т.д. Работа большей части аналитиков, QA инженеров, прокси PO и менеджеров полностью заменится AI инструментами.
Где тут можно зацепиться и остаться подольше? Снова таки, узкие домены, узкопрофильные практические знания и опыт. Их автоматизация может не произойти хотя бы потому что проще и дешевле будет использовать людей чем обучать модели. :)
4. Менеджмент. Тут вообще интересная история. Менеджмент нужен тогда, когда работает множество людей и нужно организовать их работу. Если людей станет сильно меньше и зрелость оставшихся будет достаточно большой, то необходимость в менеджменте сильно сократиться. Задачи наподобие организовать процессы работы команды из 2 синьоров, 2 мидлов и 5 джунов уйдут в прошлое.
Определенная необходимость в менеджменте на уровне продукта или всей организации безусловно останется. Перспективное направление это продакт менеджеры, CTO, Head of Infastructure и т.д. Обязательно с практическими навыками в своей области и умением работать с AI-powered командами.
В интересное время мы с вами живем. ;) За что люблю и одновременно не люблю IT, так это за необходимость постоянно развиваться. Не выходит просто получить какой-то набор навыков и дальше просто плыть по течению. Хотя, отстающие от реальности энтерпрайзы с кучей легаси будут еще долгое время. :)
Кому интересно почитать еще мыслей на данную тему, рекомендую глянуть статью Agile in the Age of AI.
Давайте начнем с того какие навыки будут максимально обесцениваться.
1. Знания. Это самый первый навык, который идет под нож. Раньше обладание знаниями в технологии, домене, проекте, организации и т.д. считалось очень ценным. Потому что получали их люди долго и дорого. Обучение новых сотрудников занимало годы. Многие люди оставались в организации только потому что они обладали нужными знаниями.
С приходом LLM и их развитием доступ к огромному объему знаний становится дешевым и обыденным. Знания можно будет использовать под разными ракурсами, нужными для конкретных работ. Это похоже на эволюцию от счетов к калькулятору и компьютерным программам.
Где знания все таки останутся ценными? В узких доменах, которые нигде не описаны и не могут быть использованы для обучения LLM. Но мне кажется, что даже эта область знаний будет в итоге обесценена. Автоматизируются процессы сбора знаний с людей и их формализации. Уже сейчас есть готовые технологии для выделения знаний из дискуссий, обсуждений и пользовательских интервью.
2. Написание кода. Эта область покрывается LLM проще всего, потому что языки программирования хорошо структурированы и написанного за долгие годы кода достаточно для тренировки моделей на любой вкус. Добавление инструментов для использования из LLM и цикл обратной связи для самообучения полностью закрывают вопрос. Еще 1-2 года максимум и тема будет закрыта. Как когда-то закрылась тема игры в шахматы с компьютером. :)
Что в этой области останется востребованным на какое-то время? Навыки архитектуры и технического дизайна. Эта область слишком слабо формализована и описана на текущий момент. В этом причина того, что не получается просто почитать книжек и стать классным архитектором. И кто-то должен будет на первое время драйвить работу AI по написанию кода для получения целостного решения.
3. Документация. В эту категорию попадает целая пачка активностей: описание требований, постановка задач, формализация приемочных критериев и тестовых сценариев, техническая документация, пользовательская документация и т.д. Работа большей части аналитиков, QA инженеров, прокси PO и менеджеров полностью заменится AI инструментами.
Где тут можно зацепиться и остаться подольше? Снова таки, узкие домены, узкопрофильные практические знания и опыт. Их автоматизация может не произойти хотя бы потому что проще и дешевле будет использовать людей чем обучать модели. :)
4. Менеджмент. Тут вообще интересная история. Менеджмент нужен тогда, когда работает множество людей и нужно организовать их работу. Если людей станет сильно меньше и зрелость оставшихся будет достаточно большой, то необходимость в менеджменте сильно сократиться. Задачи наподобие организовать процессы работы команды из 2 синьоров, 2 мидлов и 5 джунов уйдут в прошлое.
Определенная необходимость в менеджменте на уровне продукта или всей организации безусловно останется. Перспективное направление это продакт менеджеры, CTO, Head of Infastructure и т.д. Обязательно с практическими навыками в своей области и умением работать с AI-powered командами.
В интересное время мы с вами живем. ;) За что люблю и одновременно не люблю IT, так это за необходимость постоянно развиваться. Не выходит просто получить какой-то набор навыков и дальше просто плыть по течению. Хотя, отстающие от реальности энтерпрайзы с кучей легаси будут еще долгое время. :)
Кому интересно почитать еще мыслей на данную тему, рекомендую глянуть статью Agile in the Age of AI.
Показано 1 - 24 из 677
Войдите, чтобы разблокировать больше функциональности.