В 2021 году Мартин Одерски представил Scala 3. С тех пор экосистема адаптируется, а интерес к ней растет: Scala 3 становится стандартом для новых проектов, в то же время Scala 2 постепенно сворачивается.
В этой статье — наш опыт миграции проекта на Scala 3. Рассказываем, как справлялись с типовыми ограничениями и совместимостью, переписывали макросы и адаптировали популярные библиотеки, и почему архитектура модульного монолита помогла нам пройти этот путь безболезненно.
Привет, Хабр!
Если вы тимлид или архитектор, и в команде всё чаще звучит «давай сделаем CQRS» — стоит остановиться. Этот паттерн мощный, но далеко не беспроблемный.
Почему 90% рабочего времени уходит на мессенджеры, а не на главное?
Чувство постоянной занятости часто маскирует отсутствие реальной продуктивности. Проблема в том, как мы распределяем самое ценное время, поддаваясь потоку реактивных задач вместо сфокусированной работы.
Осознав 4 ключевых типа профессионального времени и внедрив таймбоксинг, можно вернуть контроль над календарем и направить энергию на достижение значимых целей.
Привет! Меня зовут Артем Валевич, я тимлид в AGIMA. Одна из важнейших моих обязанностей — код-ревью, то есть проверка кода на качество, надежность и соответствие требованиям проекта. Этот процесс может ощутимо улучшить продукт, а может превратить жизнь всей команды в ад. Ключ к этому процессу — в умении не перегибать палку. Давайте посмотрим, как может выглядеть токсичный и нетоксичной фидбек, а заодно на то, как можно оптимизировать сам процесс ревью.
В digital-разработке, как и в любом другом деле, ошибки неизбежны. Но именно они часто становятся катализатором полезных изменений. Мы собрали несколько честных примеров из нашей практики, когда факапы привели к появлению новых рабочих процессов, фич и регламентов, которые теперь помогают нам избегать проблем и работать эффективнее.
Всем привет! Я старший специалист по тестированию в ITFB Group. Сегодня хочу поделиться с вами практическим опытом нашей команды — как нам удалось достичь нулевого количества инцидентов в продакшене за отчётный период.
Это не теория, а реальная история из проекта крупного банка, где мы внедрили систему процессов, позволившую минимизировать риски. Если вам интересен практический подход к предотвращению сбоев, давайте разберём его вместе.
Эпиграф:
Приходит чувак к музыкантам, в группу просится. Те у него и спрашивают:
- А ты на гитаре играть умеешь?
- Нет.
- А на барабанах?
- Тоже не умею.
- Может ты поешь?
- Не пою.
- Зачем ты нам тогда нужен?
- Знаете, я просто офигенный друг!
Рано или поздно любой хороший продакт начинает покрывать метриками свою команду. В одной из продуктовых групп так и случилось: продакт ввел метрики, постепенно вычислил самого неэффективного сотрудника — назовем его Петя — и уже готовил бумаги на увольнение. Но во время этого веселого процесса вдруг выяснилось, что общие высокие показатели команды, это заслуга совсем не продакта (опаньки!), а именно «неэффективного» Пети. Потому что Петя оказался «человек-клей». Тот самый парень (или девушка), ради общения с которым собирается команда, который умеет поддержать, вдохновить, снять негатив и вообще настроить команду на продуктивный лад. При этом он вполне может быть распоследним раздолбаем.
Генеральный директор Microsoft заявил, что до 30% кода компании было написано ИИ*
Ожидание стейкхолдеров от внедрения LLM расходится с обозреваемой реальностью. Именно поэтому реальность приходится постоянно модифицировать. Так делают политики, так делают и менеджеры.
Похоже, мы попали в стадию, когда корпорация готова рискнуть экосистемой с несколькими языками и утащить на дно всех, кто её использует.
SP создали, чтобы уйти от тирании часовых оценок, но в итоге без понимания принципов превратились в бессмысленный ритуал. Команды тратят рабочее время на пересчет баллов в дни, менеджеры требуют «увеличить velocity на 20%», а разработчики — тихо ненавидят планирование.
Разбираемся, что такое Story Points, как их считают, в чем их проблема и как их используют разные команды.
Вот вам страшная правда: проблемы в проектах происходят не из-за того, что люди делают плохо, а из-за того, что никто не проверяет, что они делают. И как же быть, если задачи считаются выполненными, а на самом деле не проверены, не согласованы и не готовы?
«Дорогие коллеги! С понедельника мы переходим на новую CRM-систему. Ваши учётные записи уже созданы. Обучающий вебинар — в пятницу после работы. Успехов!» — кто получал такие письма от руководства, знает, что после этого не будет ничего хорошего.
Привет, Хабр! Меня зовут Мария Киселева, я тимлид команды разработки мобильных приложений для KvadraOS. В своей команде я развиваю здоровую культуру отношения к ошибкам. В статье поделюсь, зачем она нам нужна и чем грозит ее отсутствие. Расскажу, как руководитель может помочь команде научиться принимать ошибки, извлекать из них максимальную пользу и не бояться творить и рисковать в разумных пределах.
Описала свой подход в виде блок-схемы, а для удобного представления данных об ошибке использовала data-класс из Kotlin.
Будучи подростком, я часто выступал парламентёром, который на школьных «стрелках» первым выходил и пытался разобраться, за что мы вообще пытаемся сейчас бить друг другу лица. Переговоры составляли большую часть моей жизни. Хочу поделиться с вами мотивацией и мудростью, почему переговоры — это классно и здорово. Всё, о чём я буду рассказывать, основано на моём личном опыте.
Цель статьи — помочь понять, нужен ли вам на проекте системный аналитик или нет.
А также предостеречь тех, кто только собирается стать системным аналитиком.
Последние восемь лет я работаю системным аналитиком и до сих пор не перестаю удивляться тому, насколько противоположные мнения об этой роли встречаются даже среди опытных специалистов. Ещё в далёком 2008 году был доклад на близкую тему — «Аналитик в Agile: архаизм или необходимость?». С тех пор прошло семнадцать лет, а ситуация принципиально не изменилась — тема по-прежнему вызывает ожесточённые споры.
Привет! Меня зовут Алексей Стратонов, я экс-техлид Авито Недвижимости. До Авито я 8 лет проработал в аутсорсе: управлял четырьмя отделами, успел нанять и уволить многих, в том числе руководителей. В аутсорсе есть специфика — зарплаты тут ниже, а задачи те же, что и в продукте. Поэтому тимлид должен уметь собирать команды под определенный проект и качественно собеседовать.
В статье рассказываю, какие моменты напрягают меня в кандидатах, а какие, наоборот, подкупают. Этот текст будет полезно прочитать молодым лидам, которые только начинают нанимать самостоятельно. Если вы уже уверенно чувствуете себя на собеседованиях, то все, что я упомянул, покажется вам знакомым. Но проверить свои знания не помешает :-)
Привет, Хабр! Меня зовут Катя, я лидирую Gramax, open-source платформу для управления технической документацией. Однажды мы с коллегами утонули в хаосе рабочих документов: без версий, без согласований, без истории принятых решений. Это подтолкнуло нас к созданию Gramax — инструмента, который интегрирует документацию в процесс разработки, делая его прозрачным и управляемым.
В этой статье расскажу, как Gramax помогает на каждом этапе разработки ПО. Как перейти к документированию в подходе Docs as Code и шагнуть дальше — к Everything as Code.
Привет, я Настя, редактор системы управления задачами YouGile. Мы делаем работу команд простой и удобной. Мы развиваем систему на основе обратной связи пользователей, и запросов получаем очень много. В этом материале я расскажу, что же чаще всего хотят пользователи от системы управления проектами, а также поделюсь логикой продуктовых решений команды и раскрою, к каким обновлениям мы придем.
До появления современных методик компании управляли задачами разными способами: вели таблицы в Excel, перекидывали просьбы по почте, составляли общие списки. Но пришёл канбан — инструмент, который позволяет визуализировать рабочий процесс. Задачи отображаются на доске и перемещаются по колонкам по мере выполнения.
Этот инструмент решает сразу несколько задач: делает процесс проще и прозрачнее, объединяет в одной среде исполнителей, смежников и топов, сокращает издержки. Исследования показывают, что команды, внедрившие канбан-доски, ускоряют выполнение задач на 40% и повышают производительность на 20%.
В этой статье я разберу практические сценарии использования канбан-досок в ключевых отделах компании и покажу, как адаптировать этот инструмент под разные задачи.
Это статья не про тех менеджеров, кто таски в джире двигает и статусы собирает. И не про тех, кто просто ретранслирует запросы сверху вниз и держит в поле только календарь. Здесь пойдёт речь о людях, которые по-настоящему держат на себе команду, бизнес и продукт. О тех, кто в небольших компаниях или стартапах становится точкой сборки: принимает решения, управляет продуктом, координирует разработку, тащит финансы и договаривается со стейкхолдерами. И всё это одновременно.
Если ты был в такой роли - ты знаешь, о чём речь. Если нет - добро пожаловать в экскурсию по состоянию, где выгорание не приходит по расписанию, а подкрадывается тихо и исподтишка. Здесь нет оценки сверху, нет зрелых коллег, которые скажут «ты молодец» или «пора свернуть». Ты - сам себе барометр. Ты - точка принятия решений. Ты - ресурс, который должен работать без сбоев. А потом внезапно ловишь себя в состоянии, когда больше не можешь.
И вот эта статья - не гайд. Это скорее проживание. Разговор. Попытка систематизировать опыт, ощущения, тупики и возможные выходы. Без универсальных решений, но с попыткой назвать то, что обычно замалчивается.
