Недавно один мой приятель после релокации переехал из дома в квартиру. Места стало меньше — и в приглашении на день рождения дочери появилась фраза:
“No more physical toys.”
Не потому что он стал «строгим родителем».
А потому что складывать уже некуда, игрушек слишком много и каждая новая мгновенно обесценивает предыдущие.
В бизнесе мы ведём себя точно так же. Мы обожаем новые «игрушки»:
Вы проводите daily stand-ups? Делаете ретроспективы каждые две недели? Следите за velocity? Поздравляю, вы делаете Scrum. Но понимаете ли вы философию? Или ваш Scrum превратился в набор встреч, которые все ненавидят, но ходят, потому что «так надо»?
Большинство методик управления проектами отвечают на вопрос «что делать», но значительно хуже — на вопрос «в каком состоянии находится проект прямо сейчас». Мы измеряем сроки, бюджеты, проценты готовности, количество выполненных задач — и при этом нередко упускаем момент, когда проект перестаёт быть управляемым, хотя формально всё ещё «идёт по плану».
Проблема в том, что управление обычно рассматривается как последовательность действий: поставить задачу, выполнить, проверить, скорректировать. Такой взгляд удобен, но он скрывает главное — проект развивается не по шагам, а по состояниям. Между «всё под контролем» и «проект провален» лежит широкий спектр промежуточных состояний. Именно в них и накапливается риск.
В этой статье предлагается посмотреть на управление задачами под другим углом — не как на контроль выполнения, а как на работу с пространством возможных состояний, в которых может находиться задача. В таком подходе неопределённость становится не побочным эффектом, а центральной характеристикой процесса, а управление — способом перераспределять её так, чтобы цель оставалась достижимой.
В 2026 продакт-менеджеру важнее всего скорость: из заметок, созвонов или исследований быстро получать PRD и понятный план работ.
В статье как раз практический гайд по Claude Code: зачем он Product-менеджеру, как настроить CLAUDE.md, как автоматизировать конкурентный анализ, использовать параллельных агентов и skills, плюс роадмэп - карта обучения Claude Code для Product-менеджеров и разбор типовых ошибок.
Если вы ищете «аналог Jira», скорее всего, вы уже поняли главное: это не просто таск-трекер. Это центр управления разработкой — бэклог, релизы, интеграции с Git, отчётность, автоматизация, Service Desk.
В этой подборке мы не будем перечислять функции из лендингов. Мы разберём, какие системы действительно подходят для продуктовой разработки, какие — только для базового управления задачами, а какие вообще не стоит рассматривать как полноценную альтернативу.
Если вам важно выбрать инструмент не на квартал, а на 3–5 лет вперёд — читайте дальше.
Начну с конца. Вывод или рабочая гипотеза, к которой я пришел после того, что описано ниже звучит следующим образом:
Наличие проблем с самоорганизацией не мешает более-менее адекватно справляться с работой. Но вот личная жизнь есть только у организованных!
Внутри компании отделы и подразделения живут в параллельных вселенных. У каждого — свои способы планирования и исполнения задач.
ИТ-отдел восстанавливает сервер, но не знает, что продавцы до сих пор ждут подтверждения сделки на 200 млн. HR не закрывает вакансии, не понимая, что реальная проблема — в отсутствии ноутбуков. Закупки ждут согласования договоров, а директор уже решил отложить эту задачу. Маркетинг пытается утвердить баннер на мероприятие более 10 дней, не осознавая, что он «завис» у юристов из-за изменений в законодательстве.
Как выстроить работу разных подразделений и сделать процессы полностью прозрачными?
<...> причина, почему все эти скрам-атрибуты теоретически могут появиться в командах, — это если сами команды нуждались в этом и ввели все осознанно. Но это какая-то фантастика, такого не бывает. – Из статьи «Я убрал оценки задач, спринты, планирование и ретроспективы — и ничего не сломалось»
Или все-таки бывает?
Привет, меня зовут Рома. Я разработчик и последние 4 года я руковожу командами разработки в бигтехе и в пет проектах. Сегодня я хочу рассказать, как в моих командах появляются атрибуты Agile-методологий и почему часть из них я считаю необходимыми.
Как зайти в проект, где до тебя за год "сгорели" три менеджера и все перестроить внутри? В августе 2024 года я принял вызов и возглавил один из крупных проектов компании.
Крошка Макс ко мне пришел,
И спросила кроха:
«Если всё решаю сам —
Это, значит, плохо?»
Макс — это project manager, который живет свою лучшую жизнь. Каждую пятницу после обеда он берет латте на банановом молоке, приходит на 1-1 к своему лиду — ко мне, — и мы разбираем какие-то на первый взгляд типовые кейсы, но смотрим на них с нестандартной стороны.
Цель Макса — повысить эффективность своей команды, чтобы она могла переваривать более сложные проекты, не теряя в скорости и гибкости. При этом не изменяя своего состава, а только за счет личностного роста.
Вызов принят.
Меня зовут Епифанова Наташа, я Lead Project Manager на сайте alfabank.ru, и моя команда — это команда платформы сайта. Хочется рассказать вам о том, как мы с командой пришли к самостоятельности. Под самостоятельностью я понимаю в том числе автономность от менеджеров с сохранением ответственности за свои решения.
Всем привет! Я Светлана Давыдова, работаю менеджером проектов в команде Поиска. В моём отделе поисковых интерфейсов работает 24 команды. За 5 лет мы выстроили множество процессов, но перед нами всё ещё стоят вызовы: разный уровень развития команд, специфичные задачи и нехватка времени на улучшения. Из-за этого не все команды могут одинаково эффективно развиваться и повышать качество своих продуктов.
Чтобы избежать стагнации и обеспечить более высокий уровень работы всех команд, мы разработали модель зрелости команд. Это инструмент, который помогает определить направления развития, внедрить необходимые процессы и ускорить адаптацию новых команд. Модель позволяет выявлять слабые места в рабочих процессах, улучшать качество разрабатываемых продуктов и, как следствие, повышать удовлетворённость пользователей.
В статье расскажу, как мы отбирали ключевые критерии для модели, проводили оценку текущего состояния команд, составляли планы развития и что из этого получилось.
Сокращение бюджета — это почти всегда момент истины для руководителя: будь то руководитель проекта, тимлид, архитектор или ответственный за внутреннюю IT-службу. В такие моменты лучше всего работают прозрачность и честный диалог, а не директивы и «приказы сверху». Меня зовут Александр Якунчев, я руковожу отделом внедрений и развития 1С и пишу статьи для медиа «вАЙТИ». На примере проектной команды IT-интегратора расскажу, как пройти этот сложный период, сохранив клиента, команду и эффективность.
Привет, Хабр! Как часто вы встречаете термин «Agile»? Лично я — с завидной регулярностью: в заголовках статей, на конференциях и в повседневных разговорах. Особенно активно это понятие используется в сфере ИТ.
Несмотря на большое количество информации, многие всё еще не понимают, что это такое, потому что концепция допускает различные трактовки. В этой статье я расскажу об истории возникновения гибкого подхода и его ключевых методах — Scram и Kanban. Попробуем вместе разобраться, почему методология стала популярной и актуальной в наше время.
Про SAFe и масштабирование Agile на десятки команд есть много статей. Но про визуализацию этого процесса материалов не так много. В итоге остается вопрос, как организовать работу так, чтобы сотни людей видели и общую картину, и свою часть задач? Покажем в этой статье — с канбан-досками для каждого этапа внедрения.
Шаблоны всех досок есть в статье.
Меня зовут Александр Бунтов. Я разработчик, который однажды внезапно стал тимлидом: сначала пришел как старший/ведущий инженер, через несколько месяцев прежний лид ушел — и я взял роль на себя. Сейчас работаю в Ви.Tech — IT‑дочке ВсеИнструменты.ру
В статье расскажу, как за первые 100 дней перевел команду в более устойчивый режим: без «реформ с порога», но с понятными договорённостями, нормальными ритуалами, фиксом оценки задач и делегированием так, чтобы команда меньше дергалась и больше делала.
Будет полезно новым тимлидам и сеньорам перед промо. Если у вас сейчас ощущение «все горит, люди устают, планирование не работает» — тут для вас.
Начнем с фреймворков, а ведь так много определений, касаемо того, что это за такое. Хотя, пожалуй, формат работы уже более простым языком, а вот способ организации взаимодействия близок как никак.
Заставить профессионала работать? Да тут весь Agile построен на том, да и практика подсказывает, что все манифесты и принципы разработки дают как раз базис для того, чтобы ты развивался "без потолка" и имел свой профессионализм и никто тебя не заставлял работать.
Это как внутренний движок, который, верстая своими шестеренками опыта, дает новый глоток пользы своего существования в командной работе.
А вот тут мы сейчас затронули интересный момент. Кто видел хоть раз, как работает команда профессионалов? Вот они и задают фреймворки, ну, или точнее, фреймворки писались с них.
НЛП говорит нам, что ничего не создается просто так, а успешные кейсы создаются как раз из эмпирического наблюдения за успешными кейсами и их оцифровки.
Для создания Scrum, SAFe и прочих фреймворков брались успешные команды внутри компаний и описывался процесс, вычленялись церемонии в духе - "что было важного, без каких встреч не обойтись и наделялась их ценность.
Ну вроде бы, окрестили встречи, возвели значимость, дабы коварный зверь бизнеса понимал что,для,чего и зачем и не снес тебе встречу, поставив свою с девизом "я сейчас сам всем скажу как надо работать"-опс, даже корпоративную культуру внутри компании можно задвинуть, ведь даже ценности Agile есть, а от них можно, в интеграции с HR даже цифровизацию профилей задвинуть и тогда мы можем наложить примерно 2 картинки для того, чтобы понять, как и чем должен обладать кандидат (конкретно, что развивать и как связать с обучением в корп.академии и у провайдеров).
Scrum стал священной коровой индустрии. Его преподают на курсах, под него заточены целые карьеры, а сертификация Scrum Master стала отдельным бизнесом на миллиарды долларов. Но давайте честно: когда вы в последний раз выходили со стендапа с мыслью «вот это было полезно», а не «ещё пятнадцать минут жизни, которые я не верну»?
Я предлагаю признать очевидное: мир разработки изменился настолько, что процессы, придуманные в начале двухтысячных, стали тормозом. И если профессия программиста еще поживет какое-то время, то Scrum должен умереть сейчас.
Да что он такое несёт?
Сейчас же большинство менеджеров останутся без работы.
Разбираемся: а точно ли нужно всё это скрам-добро?
Количество участников в команде влияет на статистику, но не определяет эффективность процесса. Ключевой фактор успеха — не численность, а чёткое распределение зон ответственности и поддержка траектории профессионального роста каждого коллеги.
В разработке сложного программного обеспечения и систем одной из постоянных проблем является формулировка требований, ориентированных на пользователя, которые одновременно должны быть технически реализуемыми.
В этой статье представлена новая методология, сочетающая пользовательские истории с JTBD в контексте сложных проектов.
