55 систем управления проектами: самый полный обзор рынка 2025

Два года назад я разбирала , как планируют расти разные системы управления проектами. За это время рынок перетряхнуло: многие игроки ушли из России, кто-то разорился, кто-то вырос, а кто-то выбрал новую стратегию. В этом материале — главное, что произошло с каждой системой к марту 2025 году: что изменилось, сколько заработала (беру последние открытые данные из Rusprofile) и какая стратегия. Пока это самый полный обзор российского и зарубежного рынка на 60 страниц. Для удобства в конце сделала сводную таблицу. Итак, поехали.

https://habr.com/ru/articles/890684/

Управление проектами: дайджест публикаций #27

Устаревший скрам, парадоксальная оценка трудозатрат, мифы о канбане, карта-процесса-опыта, шляпы, убийственные дедлайны, деградация тимлидов и всё интересное, что писали на этой неделе про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

https://habr.com/ru/articles/889262/

Скрам — не работает, плак-плак? Или почему нытики в IT не понимают Agile

Скрам не работает. Скрам не бывает в чистом виде. Скрам - это для корпораций. Скрам душит разработку. Если вы хоть раз видели такие комментарии, то знайте: перед вами либо человек, который не понял Agile, либо тот, кому однажды внедрили скрам через одно место, и теперь гибкого тут только его растяжка. Но давайте разберёмся: а в чём вообще смысл скрама и почему он "не работает" у некоторых?

https://habr.com/ru/articles/887866/

Канбан Метод: не магия, а логика. Наводим порядок в хаосе

Вы думаете, что Канбан – это просто доска с карточками? Ошибаетесь! Сегодня мы работаем головой больше, чем руками. Современный бизнес – это управление задачами, информацией, креативными процессами. Но вот беда: старые методы управления, пришедшие из заводов и фабрик, в мире интеллектуального труда часто не работают. И тут на сцену выходит Канбан Метод – инструмент, который помогает навести порядок в работе, улучшить процессы и сделать их прозрачными. Не путайте его с обычной доской задач – Канбан Метод гораздо глубже. Это не жёсткая методология и не пошаговая инструкция, а гибкий подход к организации труда, который адаптируется под ваши задачи. Алексей Пименов — тренер, эксперт и практик по Канбан Методу, Гибкости Бизнеса и Стратегическому Маркетингу. Более 10 лет помогает компаниям разного уровня с построением адаптивных процессов. Организатор, продюсер, постоянный спикер и кейноут крупнейших профессиональных конференций FlowDays, Kanban Eurasia, AgileDays, TeamLead Conf, Merge, IT Nights, SECON, SECR, CodeFest, Стачка и пр. Специально для комьюнити Skillbox Code Experts рассказал про мифы о Канбан Метода. Публикую статью по мотивам этого эфира. Важно понимать разницу между методикой, методом и методологией. Если методика – это готовый алгоритм (делай раз, делай два, получи результат), то метод – это способ создавать такие алгоритмы. Канбан Метод именно такой: он не даёт вам готовых решений, а учит выстраивать процессы, подходящие именно для вашей команды, компании или проекта.

https://habr.com/ru/articles/887714/

[Перевод] Карго-культ Scrum: почему команды копируют форму, но теряют суть

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

https://habr.com/ru/companies/otus/articles/885656/

[Перевод] Data Engineering — это не Software Engineering

Это мой вольный перевод статьи "Data Engineering is Not Software Engineering", с рядом моих правок, дополнений, а так же сокращений (так как автор склонен повторять одно и то же, но иными словами или излишне "разжевывать" очевидные вещи). Мне кажется, автор действительно поднял очень важную тему, которую я "чувствовал" по своей практике, но не мог сформулировать так точно, как это сделал он. Мало кто задумывается, что дата-инженерия и разработка ПО имеют значительные различия. Поэтому распространено мнение, что некое отставание дата-инженерии в части внедрения современных методов разработки, таких как Agile, Test Driving Development и т.д. обусловлено лишь отставанием в освоении этих передовых практик. На самом деле этот взгляд ошибочен. Хотя дата-инженерия и разработка ПО действительно имеют много общего, между ними существуют значительные различия. Игнорирование этих различий и управление командой дата-инженеров по тем же принципам, что и командой разработчиков ПО, является ошибкой. Особенно этим грешат относительно молодые менеджеры, или те, кто никогда не работал с "датой". Собственно, этим зачастую и вызваны ошибки в пименении "в лоб" соврмененых методой разработки. Дата-инженерия — как томат: технически это фрукт, но это не значит, что его стоит добавлять в фруктовый салат.

https://habr.com/ru/articles/883026/

[Перевод] Апокриф Agile

В последнее время я стал замечать, что применение подходов Agile в отдельных проектных коллективах стало носить характер религиозного культа. Иногда понимание целей знание названий основных терминов Scrum для некоторых эффективных перспективных руководителей успешно заменяет здравый смысл. Они гордо заявляют о якобы успешном применении методов Scrum в условиях, в которых эти методы в принципе неприменимы. При этом в обоснование своих решений адепты Scrum как догму декламируют положения книги Джеффа Сазерленда «SCRUM: революционный метод управления проектами». Однако кроме основных догматов в некоторых конфессиях существуют другие древние артефакты, посвящённые ключевым заповедям. Вместе с тем эти артефакты не признаются церковью и не включены в канон. Несмотря на то, что авторство этих скрижалей также приписывается основателям церкви, эти документы противоречат основным положениям религии и являются запрещенными для адептов культа. Такие документы называются апокрифами .

https://habr.com/ru/companies/lanit/articles/882642/

Как избавиться от фоллоуимитаторов? Топ систем управления проектами для здоровой команды

Фоллоуимитация (от слов follow и «имитация») — болезнь, поражающая команды любого размера. Полгода назад я работал в крупном агентстве недвижимости. Входит в ТОП-5 по России, несколько тысяч сотрудников, которые общаются… в Telegram. Там было два типа чатов. Те, что лично просматривал гендир. И чаты, в которых можно было работать. Чаты с гендиром на 80 % состояли из бодрых «фоллоуапов» — договоренностей по итогам встреч. Выполнять их, конечно же, никто не собирался… Читать дальше

https://habr.com/ru/articles/883064/

Фасилитация: превращаем разговоры в решения

Или почему я считаю, что про фасилитацию нужно знать всем. Курс по фасилитации я прошла еще в далеком 2020 году благодаря тому, что мой менеджер убедила меня в том, что это точно пригодится. Валя, если ты это читаешь, спасибо тебе! Фасилитация — это процесс, в ходе которого нейтральный или не найтральный фасилитатор помогает группе работать эффективно, обсуждать идеи и принимать решения. Фасилитатор не участвует в обсуждениях и не высказывает своего мнения, но управляет процессом общения. Он помогает участникам сосредоточиться на цели встречи, направляет обсуждения, обеспечивает, чтобы каждый мог высказаться и предотвращает отклонение от темы. Роль фасилитатора — создать конструктивную атмосферу и помочь группе прийти к общему результату, будь то решение проблемы или принятие важного решения. В нашем неидеальном мире фасилитатор может участвовать во встречах, но это, конечно, не всегда просто. Я предлагаю взять полезные практики и сразу же начать использовать их в работе. Фасилитация значительно упростила мою работу сначала как QA, затем как QA Lead и Engineering Manager. Давайте сразу перейдем от теории к практике, где я использую фасилитацию.

https://habr.com/ru/articles/883744/

Фасилитация: превращаем разговоры в решения

Или почему я считаю, что про фасилитацию нужно знать всем. Курс по фасилитации я прошла еще в далеком 2020 году благодаря тому, что мой менеджер убедила меня в том, что это точно пригодится. Валя, если ты это читаешь, спасибо тебе! Фасилитация — это процесс, в ходе которого нейтральный или не найтральный фасилитатор помогает группе работать эффективно, обсуждать идеи и принимать решения. Фасилитатор не участвует в обсуждениях и не высказывает своего мнения, но управляет процессом общения. Он помогает участникам сосредоточиться на цели встречи, направляет обсуждения, обеспечивает, чтобы каждый мог высказаться и предотвращает отклонение от темы. Роль фасилитатора — создать конструктивную атмосферу и помочь группе прийти к общему результату, будь то решение проблемы или принятие важного решения. В нашем неидеальном мире фасилитатор может участвовать во встречах, но это, конечно, не всегда просто. Я предлагаю взять полезные практики и сразу же начать использовать их в работе. Фасилитация значительно упростила мою работу сначала как QA, затем как QA Lead и Engineering Manager. Давайте сразу перейдем от теории к практике, где я использую фасилитацию.

https://habr.com/ru/articles/883742/

Скрам-мастер: право имею?

Привет! Меня зовут Маша Резниченко, и я работаю Agile-коучем в Страховом Доме ВСК. До этого 4 года я была скрам-мастером, и за это время сталкивалась с разными мнениями о моей профессии: от сомнений в её необходимости до откровенных насмешек и язвительных комментариев о том, что скрам-мастера — это «паразиты» в мире IT. Конечно, такие слова задевают. Ведь скрам-мастера — это агенты изменений, которые помогают командам и компаниям внедрять культуру Agile и Scrum. Их влияние выходит далеко за рамки проведения встреч или составления графиков. На Хабре можно найти множество обсуждений на эту тему, и я решила внести свой вклад, развенчав популярные мифы о скрам-мастерах.

https://habr.com/ru/companies/vsk_insurance/articles/882500/

12 принципов управления проектами: что не работает в Agile

Недавно я прошла Agile-тренинг Certified Agile Professional вместе с такими же ребятами, которым, как и мне, пришлось или захотелось самостоятельно столкнуться с этим явлением. В первый же день у нас возник спор о том, что принципы гибкой разработки из Agile-манифеста устарели. Agile-манифест был подписан аж в 2001 году, и неужели за прошедшие 25 лет, никто не захотел в нём что-то поменять? Я предлагаю посмотреть на «12 принципов» с точки зрения того, как гибкие подходы могут адаптироваться к управлению проектами в зависимости от масштаба задач и стадии готовности продукта. Это не просто моё мнение — 3 дня обучения бок о бок с другими руководителями проектов из разных сфер только убедили меня в том, насколько важна эта тема.

https://habr.com/ru/articles/881906/

Scrum-то какой! За что критикуют спринты

Гибкая разработка и сопутствующие методологии уже лет двадцать как стали новой нормой. Но если копнуть поглубже, немало инженеров считают, что появление в компании консультантов по Scrum — повод срочно обновить резюме. Разбираемся, за что не любят спринты, кто виноват и можно ли с этим что-то сделать.

https://habr.com/ru/companies/beeline_cloud/articles/881848/

Какие бывают менеджеры в IT

Сколько же развелось разных видов менеджеров в компаниях! И IT, конечно, не исключение. Я бы сказал, особенно IT не исключение. Великие IT-спецы и эксперты сразу скажут, что это всё бесполезные люди в команде, которые только и делают, что пушат всех по срокам, но как только такие скептики попадают в команду без менеджера, то сразу начинают жаловаться, мол, как же так, подавайте хорошего управленца, работать невозможно. Так что давайте с вами разберёмся, какие же есть в IT виды менеджеров , чем они занимаются, зачем они нужны , чем отличаются друг от друга , и какие навыки требуются каждому из них. **мем про попугая, который спрашивает статус задачи, вставлять не буду, обещаю

https://habr.com/ru/articles/881260/

Управление проектами: дайджест публикаций #26

Как оценивать задачи, ABCDE для РП, эффективные разборы полетов, умирающий и вечно живой Agile, любовь и работа, идеальное собеседование, гору от ума и всё интересное, что писали на этой неделе про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

https://habr.com/ru/articles/880764/

Не торопитесь со Скрамом! Действительно полезные книги для менеджеров проектов. 5 функций Файоля

Когда я начинал свой путь junior PM, мне казалось, что ключ к успеху — это найти ту самую «волшебную» методологию. Scrum там, Kanban или, симпатичный, p3express. Но потом я понял одну штуку (спойлер: я еще в процессе понимания) — пока не разберёшься в пяти классических функциях менеджмента, любые модные фреймворки/методы/методологии будут лишь «пляской с бубном». При том что ты еще не стал шаманом.

https://habr.com/ru/articles/878300/

Как выбрать формат внедрения BPM-платформы

Когда компании начинают планировать внедрение информационной системы или автоматизацию нового процесса, перед ними встает важный вопрос – как это реализовать? Выбор подходов зависит от многих факторов: есть ли сформулированные цели, объем неопределенности в бизнес-процессах, принятые в компании стандарты и ряд других факторов. Чтобы внедрение прошло максимально эффективно, и результат проекта удовлетворил заказчика можно, и даже нужно, выбирать разный подход, методологию, свой набор необходимых шагов. В этой статье мы на основе своего опыта реализации проектов расскажем о вариантах и шагах для достижения цели на примере внедрения решений на платформе ELMA365.

https://habr.com/ru/companies/korus_consulting/articles/877900/

Как мы адаптируем Agile в Ozon?

Привет, Хабр! Меня зовут Антон, я — тимлид в Ozon. За более чем 20 лет работы в IT, где свыше 15 из них выпало на управленческие должности, меня покидало по разным проектам разработки ПО. Познавая управленческое мастерство, я нередко замечал, как на проектах игнорировали самую важную часть — ориентированность на Клиентов, то есть для кого мы, собственно, эти проекты и продукты реализуем. Методология Agile как раз и была призвана решить проблему фокуса на Клиенте, где в тесном сотрудничестве с ним создаётся первоклассный продукт. Люди и коммуникации выведены в Agile на первый план, а технологии, можно сказать, не упомянуты вообще. Проблемы Agile отмечают не только рядовые пользователи, но и такие мастера, как Роберт С. Мартин и Кент Бек — двое из тех, кто составил Agile Manifesto. Как отмечает Ален Холуб, Agile в последнее время стал означать: делать половину задач (активностей) из Scrum плохо с использованием Jira. В целом все знают плюсы использования данной методологии, но за годы работы я выделил для себя ряд негативных моментов. В данной статье я предлагаю рассмотреть 4 негативных последствия плохого использования Agile, которые, собственно, и подрывают эффективность применения, а также рекомендации, как встроить Agile в понятные бизнесу процессы. Проблемы я стараюсь рассматривать равнозначно как со стороны бизнеса, так и со стороны IT, поэтому надеюсь, что данная статья будет полезна не только техническим менеджерам, но и представителям бизнес-подразделений. Итак, подслушано в баре об Agile: некомедия в пяти актах... Третий звонок. Занавес поднимается...

https://habr.com/ru/companies/ozontech/articles/877244/

Кто-нибудь переживал процесс перехода на Agile? Как вы справились?

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

https://habr.com/ru/articles/877296/