Agile *

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

Существует несколько распространённых сценариев, но тот, о котором я хочу поговорить, касается ситуации, когда менеджеры формируются в организациях с жёстким централизованным планированием («роли, основанные на координации»), а затем оказываются на достаточно высокой позиции или в компании с организацией “снизу вверх”, где от них ожидают не координации, а именно лидерства («роли, основанные на лидерстве»).

Приветствую всех читателей! Меня зовут Игорь Конев и я техлид команды STaaS (Storage As A Service) в Авито. Сегодня я хотел бы в очередной раз поднять тему оценки задач, а конкретно оценки при помощи Story Points. Хотя мы давно применяем их в работе, оказалось, что команда по-разному трактует детали. Поэтому мы решили систематизировать и выровнять наши знания. Результатом работы стал этот материал, которым я с радостью делюсь с вами. Он не претендует на откровения, но удобно собирает терминологию, практические советы и наш опыт — возможно, это сэкономит вам пару-тройку Story Points.

Главная мысль статьи: Не подстраивайте Scrum под старую структуру компании. Меняйте структуру компании, используя Scrum как инструмент трансформации. Делайте это постепенно, маленькими шагами, постоянно учась и адаптируясь.

Статья является вольным переводом «Re.Imagine Your Scrum Firm up Your Agility» Гюнтера Верхейена.

Всем привет! Мы сотрудники отдела внедрения мультиязычных систем и сервисов из IT-компании SM Lab: отвечаем за обучение пользователей работе с информационными системами (ИС) группы компаний «Спортмастер». Проще говоря, мы те самые люди, которые находятся между разработчиками, выкатывающими новый функционал, и пользователями, которым с этим функционалом предстоит работать. Обучаем не только сотрудников офисов и магазинов, но и иностранных партнёров ГК «Спортмастер». 

Наша главная цель — помогать людям адаптироваться к новым системам и интерфейсам, будь то продавец Иван из Екатеринбурга или мистер Ли, упаковщик кроссовок на фабрике в Китае. Мы делаем всё, чтобы пользователи не терялись в новом интерфейсе, работали без проблем и ошибок, и всегда знали, на какую кнопку нужно нажать.

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

Сейчас agile-практиками никого не удивишь, все уже давно прочитали практическое руководство (или вы еще нет?:) ) и стремятся выполнять по методичке привычные функции: планировать, разрабатывать, тестировать и далее по циклу. «Но ведь все это мы делали всегда, зачем нам agile?» — с таким возражением пришлось работать больше всего, ведь сроки учитывались и раньше, ценность все понимают и так… При этом, меня не покидало тимлидское чувство что «что‑то не так», разобралась в этом для себя и делюсь с вами.

Гильдия VS воскресный приход: сообщество экспертов, которое решает, а не только играет в Манчкина

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

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

Да и концепция давно получила подтверждение, есть очень интересные современные исследования (MIT 2018, Placci 2019, Banca d'Italia 2022).

Формулировка принципа звучит так:

«В иерархической системе каждый работник поднимается до уровня своей некомпетентности».

Когда человек решает идти по пути менеджера в разработке, например, в начале карьеры или, особенно, уже работая в команде разработки, то приходится фокусироваться на знаниях, которые порой трудно классифицировать и уложить в своей голове. В отличие от разработчика, чей фокус часто сужен до решения конкретных технических задач, менеджеру приходится иметь дело с менее осязаемыми инструментами: процессами, коммуникацией и людьми. В основе своей они имеют другую природу, потому что здесь больше неопределенности и различных инструментов, которые должны помогать в работе. Часто менеджер фокусируется на выполнении правил фреймворка, на механике какого‑нибудь инструмента или метода, забывая, что в конечном итоге пользователь должен получить ценность. Вполне возможна ситуация, при которой все условия фреймворка выполнены, процесс разработки «настроен», на доске сотни выполненных задач, но пользы от них не так много, как кажется. И заказчики, и конечные пользователи могут не оценить вклад команды разработки и самого менеджера. Ситуация, увы, частая и очень обидная. Главная сложность заключается не в изучении теории, а в её применении на практике, где ключевую роль также играет и «социальный фактор». 

Попытки внедрить новые практики, такие как Scrum или Kanban, часто наталкиваются на сопротивление команды, которой комфортно работать в существующем workflow. Иногда проблема усиливается часто меняющимися менеджерами, каждый из которых приносит «волшебную таблетку», оставляя после себя след из никому не понятных артефактов. В результате процессы внедряются поверхностно, лишь создавая видимость изменений. Команда двигает тикеты на Kanban‑доске — значит, у нас «Kanban». Проводятся спринты — значит, у нас «Scrum». Но настоящей ценности такие формальные преобразования не приносят.

Как за год перезапустить онлайн-банк для бизнеса, влюбить в него клиентов и повысить продажи. Опыт продакт-лида 

Привет! Меня зовут Альберт Геворкян, я Product Lead в МТС Финтех. Здесь поделюсь опытом, как за время моей работы радикально обновился онлайн‑банк для бизнеса, доля продаж через платформу выросла на 25 п.п., а удовлетворённость клиентов — на 50%.

Агентные ИИ-системы обещают ускорить разработку, но ускоряют только там, где уже налажен быстрый поток поставки: автономные продуктовые команды, короткие циклы, непрерывная обратная связь. Реальность же прозаична: по DORA многие организации релизят реже раза в неделю, у четверти change failure rate доходит до 40%, а инциденты чинятся неделями.

В статье разбираемся, почему без «взрослого» Agile и DevOps ИИ-агенты всего лишь делают узкие места заметнее, и как организационная агентность (право и способность команд действовать) становится предпосылкой для реальной выгоды от ИИ.

Привет! Меня зовут Мария Белых, я занимаюсь управлением изменениями более 10 лет.

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

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

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

Agile-методологии, основанные на манифесте 2001 года, стали краеугольным камнем современной разработки программного обеспечения (ПО) благодаря своей гибкости, ориентации на клиента и способности адаптироваться к изменениям. В России, где IT-сектор демонстрирует устойчивый рост Agile остается доминирующей парадигмой. Однако экономические вызовы, включая санкции, импортозамещение и нестабильность (инфляция 6,2% в апреле 2025), а также технологические сдвиги, такие как интеграция искусственного интеллекта (AI) и DevOps, порождают вопросы о будущем Agile. Действительно ли принципы Agile теряют популярность в российской разработке ПО? Если да, то что приходит на замену?

Российский IT-сектор уникален: он сочетает стремительный рост (CAGR 12% в разработке ПО) с ограничениями. Это стимулирует переход к локальным аналогам и гибридным методологиям. В то же время глобальные тренды, такие как автоматизация через AI и рост DevOps влияют на локальную практику. В этом контексте важно понять, сохраняет ли Agile свою актуальность или уступает место новым подходам, и как российские компании адаптируются к этим изменениям.

В этой статье я делюсь своим решением оптимизации подготовки к ежедневным командным встречам Daily Scrum. Я рассказываю о практических подходах к систематизации задач и автоматизации процессов с помощью собственного плагина для Obsidian.

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

Если вам важно сделать процесс Agile-встреч удобным и результативным, моя статья предложит простой и проверенный путь к этому.

Продуктовые роли не появились из воздуха. Их не придумали с нуля бородатые дядьки в Долине или выглаженные воротнички из Купертино. Профессии Product/Project Owner/Manager выстраивались на протяжении почти столетия — и всё ради того, чтобы сейчас мы с вами плевались, читая вакансии на хедхантере. Кто главнее: PM или PO? Что должен делать проджект? И что ещё за AI PM и Data PM?

Давайте разбираться. И копнём аж до начала прошлого века.

Настало время покопаться в шедеврах мировой классики, и выискать там Agile. Мой взгляд сразу упал на любимицу дам Джейн Остин и её «Гордость и предубеждение», потому что это идеальная иллюстрация Agile, как «из книжек», в котором есть и непрерывная обратная связь, итеративность, ретроспектива, реагирование на изменения, и успешное завершение трудного проекта. Всё как мы любим.

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

Как у пилота, у нас есть разные показатели: одни помогают удерживать курс, например lead time и cycle time, другие вовремя указывают на критические отклонения, а третьи позволяют заранее увидеть «турбулентность» и предсказать риски срыва сроков.

Привет, Хабр!

Частенько тимлидов беспокоит одна ситуация: команда из кросс-функциональных специалистов собирается решить важный вопрос, а процесс превращается в бесконечный спор. Каждый тянет одеяло на себя, вето любого участника способно затормозить прогресс, и в итоге решение либо принимается слишком долго, либо вообще откладывается. В поисках способа ускорить принятие решений и при этом учитывать мнение каждого, естьподход под названием Sociocracy 3.0 (S3). Сегодня я расскажу, что это за методика, как она помогает командам принимать решения на основе согласия без бесконечных обсуждений и вето, и как её можно пилотно опробовать в проекте.

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

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

Привет, Хабр! Меня зовут Сергей Филатов и я работают в R‑Style Softlab. Сегодня расскажу о разработке с помощью Jmix удобного коннектора для HR‑подразделения, который поможет менеджерам работать с наймом сотрудников.

Мы проанализировали типовой процесс найма сотрудников, который происходит в управлениях по работе с персоналом в разных компаниях и предложили свое решение для автоматизации: простой внутренний инструмент для распознавания и заполнения карточек в «1С. Зарплата и Управление персоналом» и дальнейшей работы с этими сведениями.

Модуль умеет распознавать массив скан‑документов от группы соискателей, подгружать их в 1С, автоматически заполнять карточки соискателей и предоставлять возможность проверки заполненных сведений сотруднику Службы безопасности. Звучит просто, но это помогает экономить множество часов рабочего времени сотрудников HR и сотрудников СБ, которые заняты проверкой кандидатов, убирает рутину и позволяет вести подбор кандидатов быстрее (и эффективнее!).

Еще несколько преимуществ: