MS Project в 2026 году превратился в токсичный актив: блокировки, замороженные лицензии, серые схемы оплаты. Но прежде чем бежать, честно: если лицензия бессрочная и проекты не выходят за периметр, можно не дёргаться. А если риски перевесили привычку, разбираем 10 аналогов по классам задач (PPM, SDLC, трекеры), с реальной ценой миграции .mpp и честными минусами каждого, включая наш.
Рассмотрим методологию организации рабочих процессов, основанную на ответственности за результат, в противовес понятиям «рабочего времени», «ритуалов» и прочих весёлых забав
В команде могут быть спринты, дейли и ретроспективы, а работа при этом годами оставаться обычным водопадом под вывеской Agile. В 2026 году такую подмену стало проще заметить: ИИ быстро забирает рутинные церемонии и показывает, где процесс действительно помогает команде, а где лишь производит отчёты и артефакты. В этой статье разберём семь признаков Agile-театра и способы вернуть практикам смысл.
Задача делегирована, исполнитель назначен, сроки согласованы — но через несколько дней работа снова оказывается у вас. Одни приходят за решением каждой проблемы, другие останавливаются на первой развилке, третьи ждут подтверждения каждого шага.
Разберём, почему делегирование часто превращается в иллюзию передачи ответственности и что нужно отдавать вместе с задачей, чтобы она действительно перестала быть вашей.
Redmine до сих пор делает своё дело — бесплатно, стабильно, на вашем железе. Если у вас 15 человек и настроенный процесс, возможно, менять ничего и не надо. А если упёрлись в плагины и человеко-часы — разбираем 10 альтернатив: с честными минусами, реальной ценой миграции и советом, как не перевезти в новую систему свои 25 кастомных статусов.
За последние несколько лет AI у меня, как и у многих моих коллег, стал одним из основных рабочих инструментов. И речь не только о том, чтобы иногда задать пару вопросов ChatGPT. AI инструменты сегодня способы приносить пользу продакт менеджеру и команде на каждом этапе жизненного цикла продукта — от появления идеи до его релиза в продакшн.
Недавно я завершила исследование, в рамках которого сравнивались два проекта по разработке продукта в сфере кибербезопасности. Один проект создавался без использования AI, второй — с активным использованием AI-инструментов на протяжении всего жизненного цикла продукта. Результат был следующий: суммарные трудозатраты (а, как следствие, и бюджет проекта) по второму проекту по сравнению с первым снизились на 36%.
Самый интересный вывод, который я сделала для себя из этого исследования - AI все еще не способен заменить специалистов полностью, но он позволяет усиливать команду, ускорять процесс получения результата, заставляет команду взаимодействовать по-другому.
Где именно AI может быть полезен в работе продакта сегодня?
Этап 1. Проверка гипотез и исследование рынка
Работа над любым продуктом начинается с формулирования гипотез. Раньше значительная часть моего рабочего времени уходила на изучение рынка, поиск нужной информации, анализ конкурентов, чтение обзоров, отзывов пользователей и аналитических материалов. Сейчас первую итерацию исследования мне помогают делать AI-инструменты: ChatGPT и Claude.
Обычно я прошу AI собрать информацию по рынку, выделить основные тренды, сравнить конкурентов, найти сильные и слабые стороны существующих решений. Важно понимать, что я не принимаю решения исключительно основываясь на ответах, полученных от AI. Но вместо нескольких часов поиска информации я получаю хорошую отправную точку за несколько минут. Особенно это полезно, когда необходимо быстро разобраться в новой предметной области.
В начале 2024 года я устроилась Senior Software Test Automation Engineer в финтех-стартап. После работы в большой стабильной корпорации это был настоящий вызов ― попасть в живой дышащий мир молодой продуктовой компании, пытающейся занять своё место на рынке. Мне понравился продукт и привлекала возможность влиять на процессы, даже устанавливать новые.
Сперва я изучала как всё работало на тот момент, особенно меня интересовал вопрос обеспечения качества. В жизни я стремлюсь к эффективности: получать больше, а тратить меньше. В бизнесе такой подход приветствуется, особенно в стартапе. Причем стартап банально не выживет если он неэффективен. Я чувствовала себя на месте.
Так вот, в этой компании я встретила подход automation first. Это означало, что весь разрабатываемый функционал сразу же покрывался автотестами. В добавок к этому были задействованы многие продвинутые инженерные практики, к которым, как я знала из опыта, компании и проекты приходили через боль, страдания, унижения и годы беспросветного мануального регрессионного тестирования.
Однако не всё было идеально, проблем тоже хватало, даже при том, что скорости релизов мы достигли прямо таки нереальной, обеспечивая при этом отличное качество. В этой компании существовала доселе не встречавшаяся мне структура ― инженерное комьюнити. В каждой дисциплине было своё. У инженеров по качеству ― QA Community. Польза его для процветания компании неочевидна при первом взгляде. Как человеку, который любит докопаться до причин всего на свете, мне было любопытно как это работает и почему. В том числе влекомая этом любопытством я спустя некоторое время выдвинула свою кандидатуру на должность очередного QA Community Lead. Да, должность выборная, как президенство, срок правления ― год, потом смена власти. Немного ранее выборов у нас сменился СТО и объявил, что теперь теперь избранный кандидат должен получить также апрув от него, а также он может оставаться на должности дольше, если нет возражений от комьюнити и/или СТО. Или пока не настанет импичмент, а такое тоже было в истории компании.
Меня зовут Пелых Виталий, я корпоративный архитектор в «БКС Финтех». Разберу тему, которая звучит просто, но в крупных организациях регулярно «выстреливает» в неожиданных местах: как позиционировать архитектуру так, чтобы она помогала бизнесу и командам, а не превращалась в формальность или «бутылочное горлышко».
Сразу зафиксирую рамку. Под «позиционированием» я понимаю не место на оргсхеме, а то, как устроены правила принятия решений, кто за что отвечает и как мы удерживаем целостность ландшафта, не превращая архитектуру в узкое горлышко. По сути это про архитектурную способность (architecture capability) и архитектурное управление (architecture governance), встроенные в повседневный delivery.
Финтех — среда, где изменения идут непрерывно: продукты, регуляторка, каналы, интеграции. Поэтому архитектура здесь либо помогает меняться быстро и управляемо, либо становится тормозом и источником рисков. Дальше — как это устроено у нас: continuous architecture, около 75% архитектурных решений в командах, корпоративная архитектура как ограничение и контроль. И где у такого подхода границы и риски.
Многие знают Agile по ежедневным стендапам, спринтам и доскам в Jira. Но мало кто задумывается, почему Agile вообще появился. Если вам интересен ответ на этот вопрос, очень рекомендую книгу Роберта Мартина «Clean Agile. Back to Basics». Для меня это одна из лучших книг об Agile, которую стоит прочитать каждому Project Manager.
Для многих специалистов в IT имя автора не нуждается в представлении. Именно Роберт Мартин, известный также как Uncle Bob, был одним из авторов Agile Manifesto, опубликованного в 2001 году и навсегда изменившего подход к разработке программного обеспечения.
Книга получилась интересной не только для разработчиков, но и для руководителей проектов. Это не очередной учебник по Scrum или набор модных практик. Скорее, это попытка вернуться к истокам Agile и объяснить, зачем он вообще появился.
Мартин начинает с простой мысли: современный мир полностью зависит от программного обеспечения. Софт управляет практически всеми аспектами нашей жизни. Программное обеспечение стало кровеносной системой современной цивилизации. Без него привычный нам мир просто не смог бы существовать. Поэтому неудивительно, что люди, создающие программное обеспечение, постоянно ищут способы делать это быстрее, качественнее и эффективнее.
Большая часть книги посвящена истории возникновения Agile. Автор подробно рассказывает, какие проблемы существовали в индустрии до появления Agile-подходов и почему традиционные методы управления проектами перестали справляться с задачами быстро меняющегося мира разработки.
У большинства трекеров задачи по умолчанию показываются списком. Этого хватает, пока работа линейная: статус, исполнитель, приоритет. Как только появляются зависимости, иерархия и сроки, нужны другие представления. Ниже — короткий обзор того, что есть на рынке и для каких задач это подходит.
Привет, Хабр! Меня зовут Кристина, скрам-мастер в МТС Web Services. Два года назад я попала в трайб, который резко начал масштабироваться и быстро вырос с двух до девяти команд — продуктовых и сервисных. Процессы за этим ростом не успевали: коммуникации начали сыпаться, терялись зависимости и регулярно ехали сроки. Кроме того, конфликты между командами приходилось лично разруливать C-level. А главной сложностью было то, что каждое планирование начиналось с чистого листа.
Мне предстояло во всем разобраться и наладить процессы. Вот только для команд я выглядела как засланец от бизнеса, который просто наблюдает, как все работают, а затем доложит руководству. А для топ-менеджмента — как сомнительная инвестиция, которая еще должна доказать свою полезность.
Но несмотря на все сложности, за год мы выстроили квартальное планирование на базе адаптированного SAFe: специалисты научились проводить его сами, зависимости сократились до минимума, а руководители перестали тратить управленческое время на выяснение, кто за что отвечает. Расскажу, как мы к этому шли, какие подходы сработали и какие уроки я для себя вынесла.
Месяц назад я выложил здесь статью про то, почему хорошие специалисты делают работу качественно — и не растут. Под ней появился комментарий, который оказался точнее самой статьи.
Его оставил пользователь Alexey_Kangin: Не исключено, что ответ на поставленный вопрос гораздо проще. Менеджер хакнул систему. Он понял, что решения можно просто не принимать, и это не оказывает существенного влияния на его позицию и доход. А в таком случае, зачем напрягаться? Думать больно, установленный нейронаукой факт.
Алексей описал не лень и не цинизм. Он описал рабочую стратегию — и описал её точнее, чем я в статье. В стабильной системе она правда работает: доход не падает, позиция не под угрозой.
Дальше — развёрнутый ответ. Ты прав в каждом пункте. Но в систему зашёл фактор, который многие считывают как угрозу, а он открывает дверь — в том числе тому самому менеджеру. Расскажу, какую.
Рудольф
Назову этого менеджера Рудольфом. Восьмой год в роли. Решения не форсирует — даёт ситуации дозреть, и к моменту, когда «решение» оформилось, обстоятельства уже выбрали за него. Доход индексируется, позиция стабильна, с руководителем ровно.
Сразу договоримся: Рудольф — это диагноз, а не приговор. Не «плохой работник». Человек, который точно определил среду и выбрал под неё разумную стратегию. Среда восемь лет за это и платила. Узнали себя — отлично, с этого начинается разговор. Дальше увидим: у этой стратегии открывается продолжение.
Почему это работало
Две причины, и обе про устройство среды.
Первая — насиженное место. Руководитель сидит на месте годами, структура меняется раз в пятилетку. В такой среде предсказуемость дороже инициативы. Рудольф предсказуем, на него можно опереться — и это ценное свойство, а не дефект.
Больше всего мне не нравятся короткие созвоны. Когда мне говорят: «У меня есть окно завтра в 11:30, давай созвонимся на 10 минут». Для собеседника это просто очередной созвон, которых у него десятки за день. А для меня событие, вокруг которого начинает строиться весь день.
За годы работы в project и product management мне довелось работать с проектами самых разных типов: от государственных и образовательных инициатив до сложных IT-продуктов и создания SaaS-платформ.
И один из интересных профессиональных выводов, который я сделала за это время, касается выбора подхода к управлению проектами.
Waterfall и Agile уже много лет остаются двумя основными методологиями в индустрии. О них написаны сотни книг и статей.
Однако на практике вопрос обычно не в том, “какая методология лучше”, а в том, насколько она соответствует типу продукта, уровню неопределенности внутри проекта, задачам бизнеса.
Когда Waterfall действительно работает
Традиционная Waterfall-модель строится вокруг последовательных этапов: сбор требований → проектирование → разработка → тестирование → внедрение.
Такой подход дает бизнесу несколько важных преимуществ:
Меня зовут Николай Лямин. В IT я уже 25 лет, в SOFROS - с 2023 года. За это время успел поработать с системной интеграцией, электронным документооборотом, построением крупных команд поддержки и мониторинга для высоконагруженных продуктов ЭДО и электронного факторинга. Работал как с российским, так и с европейским рынком, а также участвовал в развитии решений для электронной коммерции в сегментах FMCG и DIY.
Придя в SOFROS, мне поручили строить направление поддержки. На берегу казалось, что логика будет классической: у клиента есть закрытый проект в промышленной эксплуатации, пользователи, инциденты и проблемы. У нас же есть линии поддержки. Остается только построить процессы и научиться с ними жить.
Реальность оказалась другой – модель начала ломаться почти сразу.
Интеграционный проект - это не монолитный программный продукт, который можно поддерживать изолированно. После внедрения клиент получает не просто «интеграционную шину», а живой интеграционный контур, в котором десятки систем начинают зависеть друг от друга. У каждой системы свой владелец, свои доработки, свои регламенты обмена и особенности эксплуатации, а самое важное, что проблемы почти никогда не живут внутри одной системы.
Если вы используете GPT в работе, вы уже могли поймать странный эффект: задачи стали делаться быстрее, но свободнее не стало. Более того — иногда кажется, что стало тяжелее.
Раньше ты писал отчёт два часа. Теперь собираешь его за двадцать минут. Но вместо того чтобы получить обратно эти полтора часа, ты начинаешь делать отчёт глубже: добавляешь аналитику, проверяешь гипотезы, готовишь несколько сценариев, аккуратнее формулируешь выводы.
И в какой-то момент возникает неприятный вопрос: если ИИ действительно экономит мне время, почему я не чувствую себя менее загруженной?
Где-то с 2021 года программистам обещают, что: ИИ оставит их без работы, 30% мест исчезнут, дипломы обесценятся и вообще все станут бесполезными. В декабре 2025 это уже стало походить на правду, теперь, какой-нибудь Claude, действительно, выдает рыночный результат. А если сравнить стоимость генерации за ноль рублей с любой оплатой труда, то тут победить ИИ - крайне сложно.
Что касается профессий уровня аналитиков, то джуны не нужны, по моим ощущениям, с 2023 года, а на текущий момент вообще аналитики не особо нужны. Тут уже, к сожалению, так как в моей профессии присутствует слово аналитик.
Про замену управленческих кадров и уровня С, пошли прогнозы на конец 2026 года. Это уже касается лично меня и моей текущей работы. Но начиная с того самого 2021 года, я сменил 3 компании, пережил два кризиса в найме и как итог два ребрендинга собственной карьеры.
Сразу спойлер: без работы я не остался, но пришлось перестать "играть в шахматы" и переключиться на режим игры в настольный теннис.
В шахматах побеждает тот, кто видит стратегию на 10 ходов, а в теннисе - у кого лучше реакция и способность адаптироваться под противника.
Вот как раз эпоха ИИ - это теннис. Мы уже явно в зоне турбулентности, которая по прогнозам в 2027 году достигнет пика. Есть сложный момент с тем, что происходит в странах с развитой экономикой и у нас, скажем мягко, имеет некий рассинхрон. Поэтому пока ориентируюсь на международные практики и институты, а как их адаптировать под наши практики, как раз возвращаемся к метафоре с теннисом.
Всем привет, это команда продукта SimpleOne SDLC. Поговорим о вещи, которую в командах обычно не обсуждают вслух — о бэклоге дефектов, который никто не разгребает.
Почти в каждом проекте есть момент, когда кто-то говорит: «Ну мы же предупреждали». И это, пожалуй, самая неприятная фраза в проектном управлении. Так как она означает, что проблема была не в том, что команда не знала о рисках. Проблема была в том, что знание о рисках никак не повлияло на решения.
Реестр рисков в таком случае превращается не в инструмент управления проектом, а в кладбище тревожных мыслей. А что вообще такое Риск?
Почему Agile‑команды скатываются в неконтролируемый хаос, а проекты на Waterfall годами пилят никому не нужный продукт? Спойлер: проблема не в методологиях, а в нас самих. Вы узнаете, как сильные команды совмещают лучшие практики обоих миров, почему Contract‑First и Trunk‑based Development спасают даже в Agile.
