Наверняка вы за собой замечали, что иногда какую-то задачу настолько не хочется делать, что курсор мыши сам выпрыгивает из IDE, а пальцы отбивают на клавиатуре «YouTube — шортсы с котами». Возможно, вы пытались разобраться, почему же так?

 А вы точно пытались — на Хабре написано аж 39 (!) страниц статей по запросу «прокрастинация».

Меня зовут Арина, я работаю продуктовым аналитиком в Купере. Поделюсь тем, как сама боролась с прокрастинацией, а в результате узнала о СДВГ, получила диагноз, полюбила его и научилась с ним жить. Расскажу об СДВГ в целом и о своем опыте выживания в IT с таким мозгом.

С помощью поддержки и просвещения можно прийти к пониманию, что у СДВГ помимо минусов так же много и плюсов, и в мире много успешных людей с этим диагнозом. Например, чемпион мира по плаванию Майкл Фелпс, основатель IKEA Ингвар Кампрад, основатель корпорации Virgin Group Ричард Брэнсон, основатель JetBlue Девид Нилеман, режиссерка «Барби» Грета Гервиг, актеры Том Круз, Орландо Блум, Зоуи Дешанель, Эмма Уотсон и еще многие другие люди с этим диагнозом живут и строят успешные карьеры.

Многие из них, если речь заходила про СДВГ, говорили, что в конечном итоге это стало их сильной стороной. Ведь на самом деле это не про отсутствие самодисциплины или лень, а просто про другой механизм работы мозга. И если знать, что с этим делать, то все сложности можно нивелировать или даже обратить себе во благо.

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

Привет! Меня зовут Артём Коньков, я тимлид команды продуктовой разработки в Купере. У меня в команде шесть разработчиков, по два на каждый стек: мобилка, фронтенд, бекенд и два QA. В статье расскажу о том, как, став тимлидом в уже почти сложившейся команде, менял систему оценки задач и переводил абстрактные сторипоинты в конкретные.

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

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

Привет всем! Меня зовут Таня Конюшенко, и я — продуктовый дизайнер в Купере. В этой статье я рассказываю о том, как открыла для себя дизайн-Discovery и внедрила его в моей продуктовой команде. Мой опыт будет полезен дизайнерам, которые много слышали о Disco, но не понимают, в чём его смысл.

Ещё год назад я ничего не знала о Discovery, потому что работала в заказной разработке. О том, в чем разница между дизайнерами в агентстве и продукте, рассказывала в своей прошлой статье.

Когда я пришла в Купер (тогда он был ещё СберМаркетом), меня сразу познакомили с понятием Discovery, но смысла я в нем не увидела. Сейчас мое отношение кардинально другое. Discovery хорош, но нужно правильно его выстроить. Мой путь к идеальным процессам был тернистым…

Но давайте по порядку. Что входит в дизайн-Discovery и чем это отличается от общего Discovery команды?

Привет! Меня зовут Сергей Реусин и последние пять лет я занимаюсь эксплуатацией production-систем с непрерывной практикой инцидент-менеджмента. Каждый день, сталкиваясь с аномалиями и проблемами, невольно спрашиваешь себя: «Почему это происходит? А главное — как с этим дальше жить?». Три нелегких года работы в Купере ( ex СберМаркет), где мне доверили строить культуру инцидент-менеджмента, помогли мне утвердиться во мнении и подходах, которые действительно помогают справляться с подобными вызовами. О них и поговорим!

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

1. Определим, ради чего вся эта «доступность» и «стабильность» нужна

2. Попробуем устаканить терминологию, чтобы говорить на одном языке

3. Посмотрим на понятие системы с позиции устойчивости

4. Обратимся к историческому опыту

5. Изучим возможные паттерны отказов систем и способы их митигации

6. Визуализируем модель восприятия аномалий

7. Познакомимся с ключевыми личностями в подходах Resilience Engineering

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

Меня зовут Олег Федоткин, я программист и менеджер в ИТ. Я провел более сотни собеседований (мне HR даже толстовку «Hiring Hero» по такому случаю подарили) и нанял десятки человек: программистов, тим лидов, юнит лидов, архитекторов — да всех. После всех интервью я выделил три качества, которые неизменно определяют классного специалиста.

Привет, Хабр! Меня зовут Капитолина Кузнецова, я Ruby-разработчик и на своём текущем месте работы в Купере (ex СберМаркет) доросла до роли тимлида. За 2,5 года я, так сказать, освоилась в этом статусе и, если верить моей команде, руководитель из меня получился неплохой, но вьетнамские флэшбэки о своих первых месяцах работы в новой роли ещё свежи.

Быть начинающим тимлидом — это...

- когда встречи занимают по семь, восемь, а то и девять часов подряд;

- когда ты целый день что-то делаешь, дико устаешь, а в конце не видишь никакого результата;

- когда о Jira знаешь больше, чем о собственной семье, а встречи с друзьями планируешь на новогодние праздники 2025 года.

Эта статья — попытка структурировать всё, что может помочь вам в новой роли. А также моя рефлексия о том, какие способы помочь себе, реально облегчат вам жизнь и помогут быстрее справиться с новым масштабом. Знаю, что такие проблемы были не только у меня, но и у многих других ребят, которые раньше просто писали код, а не вот это вот всё. В общем, надеюсь, мои заметки будут вам полезны :)

Всем привет! Меня зовут Аня Власова, я работаю ML-инженером в Купере (ex СберМаркет), а именно — в команде поиска. Сегодня я расскажу про нашу нейросетевую модель, которая стои́т на страже корректных поисковых запросов. Вы наверняка найдете пару инсайтов в этой статье, если тоже разрабатываете сервисы поиска или просто интересуетесь языковыми нейронками.

Привет, Хабр! Я Евгений Малышев, SRE-инженер в Купере (так теперь называется СберМаркет). Моя основная задача — это надежная работа сервисов фронтенда, и немалую роль в этом играют правильно построенные пайплайны CI/CD. В этом нам помогает Gitlab CI. В компании мы широко используем этот инструмент для создания общих шаблонов для сервисов на различных языках. На уровне отдельного репозитория легко расширить или настроить шаблонные джобы и добавить свои.

До этого у меня был опыт с Jenkins и Azure Devops, так что Gitlab CI мне показался довольно простым: есть стадии, есть правила запуска джоб с shell-подобным синтаксисом, да и скрипты джоб тоже используют bash-интерпретатор. Но в процессе близкого знакомства не раз возникали ситуации, когда поднимается то одна бровь, то обе, а то и руки в праведном гневе. Заходите посмотреть, какую коллекцию граблей собрал я.

Весь код с примерами граблей можно посмотреть в репозитории.

Всем привет. Меня зовут Нияз Кашапов, я AppSec Lead в СберМаркете. Улучшаю процессы безопасной разработки уже более 5 лет. Начинал карьеру в финтехе, где занимался безопасностью кода, фич и бизнес-процессов в онлайн-банкинге. А сейчас продолжаю начатое в одном из самых быстрорастущих игроков на рынке e-com.

Думаю, у многих в практике встречалась уязвимость, которую просто так не пофиксить — ведь она заложена глубоко внутри разрабатываемого решения, обвешана кучей зависимостей и требует полного ребилда самого решения. Чаще всего такие уязвимости остаются в проде навсегда и удерживаются от «падения» множеством костылей. Возникает резонный вопрос: «Как они возникли?» Чаще всего ответ — «Так исторически сложилось», а истоки проблемы давно забыты. Боролься с таким лучше превентивно, а как это сделать — попробую рассказать в этой статье.

Поговорим о том, как избегать ситуаций, когда уязвимость заложена на уровне архитектуры или бизнес-процесса и её исправление может стоить множество человеко-часов. Разберемся, когда фича становится багом и как прорабатывать архитектуру сервисов, не создавая дыры безопасности.

Привет, Хабр! На связи Кирилл Веркин. Вообще, я занимаю в СберМаркете должность Senior QA, но ради большей производительности команды стал немного кодером.

Эта статья может быть интересна тем, кто замечает, что задачи в команде часто теряются, и хочет автоматизировать процесс напоминалок. Я делюсь кодом, поясняя ключевые моменты для таких же новичков в Go. Мой код написан для сочетания GitLab, Jira и Mattermost (корпоративный мессенджер, которым мы пользуемся в СберМаркете), но подобное решение можно реализовать и с другими сервисами.

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

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

Nokia: компания, которую чуть не утопили бюрократы
Nvidia: «удачливый» маленький стартап, который умело ловит волны
IBM: бери, все что можешь, или как адаптироваться к любым кризисам 

Привет, Хабр! Меня зовут Николай и уже 17 лет я работаю сетевым инженером. Обычный вопрос для моей профессии: «Доходит ли трафик куда нужно?». И десятки лет на него отвечают одним словом — tcpdump.  А теперь зададим другой вопрос: «Как поймать трафик, если доступных путей много? Неужели вариант один: открывать десятки консолей?»

 В СберМаркете я работаю с начала 2022 года и занимаюсь автоматизацией рабочих процессов. Одной из моих задач и стало найти решение на вопросы, рассмотренные выше. 

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

Всем привет, меня зовут Антон Малафеев, я руководитель группы инженеров IT‑инфраструктуры в СберМаркете. Моя команда вот уже больше 3-х лет занимается разработкой деплоя для PaaS и сопутствующих инструментов.

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

Но сначала немного цифр. Ниже на рисунке — наша статистика использования канареечного деплоя. На момент написания статьи у нас в проде 200+ сервисов, 5300 подов PaaS, ежемесячно мы делаем 2 тысячи деплоев в продакшн и 11 тысяч деплоев в стейдж, которые проходят через канарейку.

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

Я сама 10 лет работала в разных агентствах, а в прошлом году перешла в продукт. И мне есть, что рассказать).

Привет, Хабр! Меня зовут Салахутдинов Дмитрий, я принципал инженер в СберМаркете. Занимаюсь развитием Ruby-платформы и масштабированием системы через декомпозицию монолита на сервисы.

В статье хочу поделится опытом внедрения аутентификации на базе монолита. Это первая проблема, с котором мы столкнулись в попытке реализации новой бизнес-логики автономно (за пределами монолитной системы). Будет полезно, если перед вами стоит задача сделать первые шаги от монолитной к микросервисной архтитектуре.

Привет, Хабр ?! Меня зовут Александр, я занимаюсь разработкой ПО. В этом посте я расскажу про свой опыт, как желание улучшить свой рабочий процесс CI, помогло ускорить все golang пайплайны в PaaS в СберМаркета.

Привет, Хабр! Меня зовут Вадим, я мобильный разработчик в СберМаркете. В этой статье расскажу, как провести профилирование (оно же измерение производительности или оценка перформанса) в react native приложениях: как выявить источник проблем и решить их. В русскоязычных источниках не так много информации по данной теме. Я потратил немало времени, чтобы со всем разобраться, поэтому попытаюсь восполнить этот пробел и для вас :)

Привет, Хабр! Меня зовут Кирилл Веркин, я Senior QA в СберМаркете. Эта статья о том, как за 1,5 года моя команда прокачала уровень инженерной культуры с нуля до самого высокого среднего балла в компании среди 105 команд. 

(Да, у нас есть уровни инженерной культуры!) Хочу рассказать, как мы их оцениваем и повышаем, почему это круто бустит развитие и как соревновательный аспект делает жизнь инженера гораздо интереснее. А ещё это история о том, как у меня получилось повлиять на командный результат будучи тестировщиком — на заметку тем, кто хочет не только расти сам, но и «менять мир».

Привет! Меня зовут Юля Шамина, я руководитель IT-проектов в СберМаркете. Хочу поделиться нестандартным по всем меркам кейсом, как мы подготовили наши сервисы к высоким предновогодним нагрузкам за 3 месяца благодаря челленджу внутренней команды нагрузочного тестирования. 

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

Если бы можно было описать этот проект одной цитатой — «Это было смело, чертовски смело!»

А теперь по порядку. Расскажу,  как мы пришли к тому, что нам понадобился подрядчик, и что вообще это за проект.

Если у вас есть большая система, состоящая из множества микросервисов, то вы наверняка задавались вопросом: «Что сделать, чтобы архитектурная схема всей системы была всегда на 100% актуальной?».

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

Чтобы решить проблему мы автоматизировали отрисовку схем опираясь на метаданные IT-систем. Мы создали отдельный микросервис, который этим занимается и назвали его «Architect». О том как это происходит и как работает Architect я расскажу в этой статье, а также дам несколько советов, которые помогут внедрить то же самое у вас в компании.