Agile *

Есть профессии, ценность которых определяется не только тем, что человек умеет делать, но и тем, насколько редким остается ресурс, которым он управляет.

В IT таким ресурсом много лет была разработка. Хороших инженеров не хватало, бэклог почти всегда был длиннее возможностей команды, а любое заметное изменение продукта стоило времени и денег. Поэтому вместе с хорошей идеей возникал вопрос: хватит ли у разработки людей, времени и бюджета?

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

Влияние тоже концентрируется там, где дефицит: если без вашей функции следующий шаг невозможен, ее мнение весит больше.

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

Что же изменилось на самом деле?

Самое простое объяснение обычно звучит так: AI теперь пишет код вместо людей.

От этой фразы у разработчиков часто дергается глаз, и это понятно. Сложные системы не стали простыми. Архитектура никуда не делась, legacy тоже, а прод по-прежнему умеет падать ночью.

Меняется другое. Само производство кода ускоряется, а весь путь от идеи до работающего продукта сокращается куда медленнее.

JetBrains весной 2026 года сформулировала это довольно приземленно: генерация кода становится дешевой и перестает быть главным бутылочным горлышком. Главная сложность смещается к вопросу, соответствует ли результат замыслу, и сколько вся система в итоге стоит.

Если спросить тимлида «сколько story points команда сделает в следующем спринте?», чаще всего ответ будет такой: «Ну, в прошлый раз было около 300, давай возьмём столько же». Потом выясняется, что двое уходят в отпуск, один новичок ещё не разогнался, а треть времени съедят баги. Спринт заканчивается авралом, задачи доделывают в последние два дня, и этот аврал попадает в статистику как «нормальная скорость команды». Следующий план строится уже на нём.

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

В начале сентября я провёл вканале интерактив: предложил подписчикам написать в комментариях свою профессию и пообещал каждому прислать эскиз системы в Obsidian под его работу. Эскиз — это буклет на 3 страницы: какие разделы нужны хранилищу юриста, психолога или инженера, как между ними ходит информация и какими плагинами это собирается. Профессию назвали 20 человек. Каждому ушёл буклет в личку, дальше пошли переписки и записи на консультации. Через неделю я уже не помнил, кому что отправил и кому обещал ответить. До этого лидов я не вёл никак, их было мало и все помещались в голове. Отдельный сервис заводить не хотелось: задачи, клиентские проекты и заметки по встречам у меня и так в Obsidian. В этой статье расскажу, как я собрал CRM на плагине Operon и что в нём допилил. Следующие раунды интерактива буду объявлять в канале.

«У вас недостаточно опыта работы с сопротивлением». Эту фразу я несколько раз слышал на собеседованиях.

Но что вообще считать сопротивлением?

Идеального руководителя не существует — и это хорошая новость. Четыре управленческие роли, четыре поведенческих стиля, одна матрица. Показываю, как PAEI и DISC прогнозируют, кто сорвёт ваши изменения, а кто их вытянет.

Открываешь рабочий чат — там новые вводные. Заходишь в Jira — на тебя упала еще одна срочная таска. До релиза остается все меньше времени, а в текущей задаче ты пока даже не разобрался. В какой-то момент к рабочим вопросам добавляется другой: «Может, я просто не справляюсь?»

Меня зовут Анастасия Позднякова, раньше я работала тестировщиком, а теперь я agile team leader в команде разработки в YADRO. Тема стресса интересует меня с разных сторон: как он проявляется в работе команды, как на него реагирует каждый человек (спойлер: сильно по-разному) и со стороны физиологических процессов в организме. 

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

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

У вас идёт цифровая трансформация? К вам пришёл Agile-коуч и рассказывает, как вам правильно работать? Вы разработчик и считаете Agile бредом, который придумали менеджеры? Тогда добро пожаловать под кат.

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

Я, Александр, автор телеграм-канала «Shulepov Code», поговорил с Александром Фридманом — экспертом и методологом по регулярному менеджменту, консультантом и автором книг об управлении, в том числе «Вы или вас? Профессиональная эксплуатация подчинённых», а также ведущим YouTube-канала «Александр Фридман & Регулярный менеджмент».

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

11:07 — разработчик пишет: «Готово, можно смотреть».
11:10 — менеджер уверен, что задача уже ушла в тестирование.
13:00 — выясняется, что проверка на стороне тестирования не начиналась.

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

Я работаю QA-инженером в Ozon Tech и часто вижу, как задачи переходят между разработкой, тестированием, менеджерами и другими командами. Статус в тикете может быть обновлён, договорённость в чате зафиксирована, но ни то ни другое не гарантирует, что следующий шаг кто-то действительно принял.

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

Знакома ли вам ситуация: задача оценена, данные собраны, все оценки сложены — и получилась вполне разумная цифра. А в реальности работа никак не помещается в дедлайн.

Или ещё интереснее: команда начинает работу и находит такой объём задач, которого на старте просто не было видно. В конце отчётного периода выясняется, что успели меньше половины.

Возникает логичный вопрос: почему так? Мы же всё посчитали заранее.

Проблема в том, что оценка трудоёмкости задачи и планирование — это не одно и то же.

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

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

Всем привет! На связи Елизавета, я agile-коуч продуктовых стримов корпоративного бизнеса — транзакционных сервисов, продуктов для малого бизнеса, страхования. Внедряю Discovery и проверку гипотез, а ещё веду курс по CJM для топ-менеджмента и продуктовых лидеров. Отсюда и тема статьи: расскажу о том, как выстроить карту клиентского пути для ИТ-продуктов.

Свои процессы ИТ-команда знает хорошо: сколько занимает разработка, где стоит согласование, какой сервис отвечает за шаг, сколько проходит от постановки задачи до релиза. Мы считаем сроки и смотрим на продукт через метрики. Внутренние процессы не отвечают на один вопрос: что в этот момент происходит с клиентом?

На бумаге открытие счёта занимает 20 минут: регламент выполнен, сроки соблюдены. При этом клиент трижды приезжает в офис, потому что с первого раза ему не сказали, какие документы нужны. Потом несколько дней ждёт ответа, звонит в контактный центр и заново объясняет свою ситуацию. Банк считает такой процесс корректным. Клиент за это время потратил неделю и четыре обращения.

Команды берутся за CJM, чтобы посмотреть на продукт снаружи. Внутри процесс выглядит так:

заявка → проверка → согласование → решение → уведомление клиента.

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

узнал о продукте → попытался разобраться → не понял условия → написал в чат → получил один ответ → пришёл в офис → узнал о дополнительных документах → ушёл → вернулся через несколько дней → снова связался с банком.

Одна из наших крупных функциональностей ехала до пользователей 519 дней.

Мы провели ретроспективу, решили, что проблема в декомпозиции, поменяли процесс и попробовали снова.

Следующий большой кейс занял 666 дней.

То есть после осознанной попытки ускорить разработку мы получили ещё худший результат.

В статье разбираю, почему декомпозиция сначала не помогла, зачем мы постепенно переносили её с этапа разработки на аналитику и продуктовую проработку, как в эту историю вписались MVP и WIP-limit и что в итоге позволило сократить Lead Time похожих больших функциональностей до 90–120 дней.

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

Опыт управления командами у меня больше 10 лет. Начинала с нагрузочного тестирования в аутсорсе и там исполняла роль тимлида+проджекта. И в роли продакта я работала как с совсем маленькими, так и с командами по 20 человек. В маленьких командах получается быстро договориться, а вот в командах 15+ операционка может перетаскивать на себя огромный временной ресурс и отжирать то, чем я люблю заниматься. В этой статье расскажу, как я подхожу к управлению большими командами, как мы делили обязанности с проджектом и адаптировали Scrumban под наши потребности.

Привет! Меня зовут Маша, я Senior Product Manager и разбираю только те продукты, над которыми сама хотела бы поработать, так как ими пользуюсь, люблю и вижу, где есть потенциал роста. Мне драйвово искать для них решения, которые выводят продукт на новый уровень не только по деньгам, но и по UX и любви пользователей. Мои разборы: «Рейтинг ни на что не влияет»: Почему Яндекс.такси выбирает газлайтинг вместо честного UX и Кэшбек Шрёдингера и молчаливые проценты: Dark Patterns в банкинге. Сегодня я поделюсь как работаю с командой и какие лайфхаки нашла для себя для ускорения Time to Market.

Ретро умирают одинаково: жалобная книга вместо разговора, сорок минут на один спор, экшен-айтемы в никуда. Разбираю тайминг на 45 минут, четыре формата (Start Stop Continue, Mad Sad Glad, 4L, Sailboat) — что писать в каждую колонку и когда какой брать, — и правила, которые держат ретро живым. Во второй части — как устроена моя бесплатная доска для ретро: стек, где хостится, шифрование карточек и что происходит с данными.

Я больше десяти лет делаю рекламные платформы. Команды за это время были разные — по размеру, по составу, по зрелости. Но почти всегда был один загон — всем почему‑то было очень важно работать по спринтам.

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

Привет, Хабр! Меня зовут Лёша Савлев, я скрам-мастер продуктовых команд м2. За последние полгода мы изменили наш подход к дискавери — и я хочу поделиться тем, как мы этого достигли. 

В этой статье я расскажу, как мы собрали разрозненные Discovery-практики в единый процесс на уровне компании. Благодаря этому все команды стали говорить на одном языке.

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

Что происходит, когда команда оценивает задачу до знакомства с чужим кодом? В нашем случае это приводило к оптимистичным срокам, неожиданным A/B-реализациям, повторным итерациям ТЗ и багам, которые обнаруживались уже на тестировании.

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

На выборке из семи задач TTM средних и сложных проектов сместился с диапазона 1,5–3 месяца к 1–2 месяцам, а количество профильных багов на эпик — с 6–12 до 4–9.

У нас Scrum, доска Kanban, а скоро переходим на SAFe. Разбираемся, кто все эти люди: от Waterfall и XP до Lean Six Sigma, Team Topologies и AI. Простые объяснения, схемы и пять вопросов, которые стоит задать до смены процесса.

Карта подходов к разработке: от Waterfall и XP до Team Topologies и работы с AI. Что они решают, где помогают и как выбрать без посвящения в тайное общество.