Менеджмент

Этот текст о применении ИИ-агентов для задач управления проектами.

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

Иными словами, ИИ-агент не просто отвечает, а формирует вашу картину проекта. А это уже совсем другой уровень управленческого риска.

Всем привет! Меня зовут Никита Гусев, я руковожу направлением EPM в компании «Инфосистемы Джет».

Если вы когда-нибудь видели, как финансист или аналитик ставит себе ТРЕТИЙ монитор, чтобы формулы помещались на экране, то сложности работы Excel в крупных компаниях примерно представляете. В статье расскажу, почему еще планирование в табличках — это больно, и по какому пути идут наши заказчики.

Как связаны ИТ и строительство? Очень тесно — через методологию управления.

Несколько лет назад я впервые столкнулся с методологией Scrum. Тогда она произвела на меня колоссальное впечатление. Позже, конечно, я нашёл и негативные стороны этого подхода, и понял, что в разных проектах лучше использовать разные подходы. Благо, что их придумано множество!

Привет. Меня зовут Настя и я мама сына, которому 2 года. А еще у меня своя практика психолога, проект, работа в фонде, учеба. И я живу в водовороте.

Порой он тесно связан с чувством вины — «а хорошая ли я мама?». Вина, конечно, не приговор, а важный сигнал, что нужно что‑то менять, на что‑то обратить внимание и взять фокус.

Здесь я собрала не «идеальные рецепты», которые сама так рада была бы найти, а инструменты, которые могут помочь.

И эту статью мы написали совместно с Еленой Забалуевой. Она многодетная мама (трое детей: 10, 6 и 2 года) и техлид в крупной ИТ‑компании. Ее история — живое доказательство, что совмещать можно, если перестать требовать от себя невозможного и начать выстраивать свою, удобную именно вам систему.

Почему команды регулярно «не укладываются», даже когда план выглядит разумно и согласован со всеми? Дело не только в сложности задач и неопределённости разработки. Существенную роль играет то, как формируются ожидания: где проходит граница между прогнозом, планом и обязательством, и какие сигналы команда считывает от руководителя.

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

$180 на Cursor за три дня. Три монитора. Пакет орешков. Ноль тестов. Бизнес в восторге. Команда в ужасе. Угадайте, кто победил.

Разработка высоконагруженных систем — типовая инженерная задача. Для неё есть паттерны, инструменты и понятные подходы. Но что делать, когда нагрузке подвергаются не приложения, а люди? Когда одновременно растут сроки, количество задач и неопределённость — и сбой даёт уже не система, а команда?

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

Мнение. Предложение к обсуждению, а не новая догма.

Story points долго были удобным способом оценивать сложность задач в разработке. Но в 2026 году всё больше работы делается не только инженером, но и в связке с LLM: генерация кода, тестов, документации, рефакторинг, разбор ошибок. Возникает вопрос: может ли рядом со story points появиться новая метрика — neuro points, отражающая AI-итеративность решения задачи? В статье предлагаю этот подход как гипотезу для обсуждения и разбираю, зачем он вообще может понадобиться командам, которые уже активно используют нейросети в рабочих процессах.

Каждый раз, когда какой‑то продакт с гордостью говорит: «Я сам собрал прототип за вечер на AI/no‑code», я не вижу в этом геройства. Я вижу главу продукта, который превратился в ещё одну пару рук для дешёвого билдинга. Вижу человека, который перестал быть «мозгами продукта» и стал универсальным солдатом, которого удобно использовать, но невозможно уважать как продуктового специалиста.

Данные перенесены, workflow настроен, всех обучили. А через неделю — саботаж, снова задачи в Excel и бунтующий разработчик, у которого «вообще-то в Jira все нормально было»

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

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

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

Привет! Меня зовут Света и я — project manager. Или, по мнению разработчиков, человек, который превращает «надо подумать» в «обещали к пятнице».

За время работы я успела побывать в самых разных контекстах. Через меня проходило всё подряд: от историй уровня «давайте аккуратно распилим монолит банка и никого не убьём по дороге» до вполне безобидных, на первый взгляд, продуктовых изменений, и вот что я заметила.

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

То есть уже понятно, что:

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

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

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

Я Ирина, в Блоке ИТ-развития инвестиционного бизнеса РСХБ.Цифра помогаю ИТ-командам доставлять ценность бизнесу, содействую оптимизации процессов, повышению эффективности и сплоченности команд, продвигаю Agile-практики.

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

Управлять тимлидами — это не раздавать задачи и проверять сроки. Это выстраивать среду, где сильные технические лидеры могут проявить себя без микроменеджмента. В статье разберем какие ошибки совершают 90% руководителей, почему контроль убивает инициативу, и как перейти к системному лидерству с помощью OKR, DORA-метрик и роли Delivery Manager. Без воды, с конкретными кейсами и схемами!

Есть такой опасный момент в инфраструктуре: когда все вроде бы работает, но трогать это лишний раз не хочется. Не потому что идеально. А потому что есть ощущение — если полезешь, станет хуже. В какой-то момент мы поймали себя на этом с MinIO.

Последние годы в IT‑командах регулярно встречаю один и тот же паттерн — у техлидов и различных руководителей самого среднего звена.

Назову его Геннадий. Техлид. В команде за глаза зовут «Ещё Подумаем». Восьмой год в роли. Выбор фреймворка — две недели. Приоритеты спринта — три встречи. Даже «куда идём обедать командой» превращается в опрос в чате.

Геннадий — человек, который всегда знал, как надо. Уверенный. С позицией. Решал сам — это было его.

Перестало работать.

HR считает его выгоревшим, отправляет в отпуск. Он возвращается посвежевшим — ничего не меняется. Вопросы продолжают висеть.

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

Слово есть — в нейробиологии.

Говорят: “выстраивать процессы”. А откуда они берутся, как это обычно происходит, и вообще, зачем это всё?

Что такое процесс? Это то, как организована повторяющаяся работа, взаимодействие между участниками, ради какого-то общего результата.

Процесс никогда не должен быть самоцелью. И нет никакого универсального процесса на все случаи жизни.

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

Сегодня мы с вами поговорим о вещи, на первый взгляд, простой до банальности: почему важно хвалить сотрудников и проявлять к ним внимание. Тема, кажется, даже не заслуживает отдельного разговора - ну кто же не знает, что доброе слово приятно? Но вот парадокс: по моим личным наблюдениям (статистику я, конечно, не публикую, все взято из моей головы), компании редко хвалят коллег за сделанную работу. Я не о том, чтобы каждые две-три недели гладить человека по головке за сам факт его существования - разумеется, нет. Речь о другом - о простом, почти забытом искусстве замечать усилия.

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

За месяц в одиночку написал production-систему анализа цен и продуктов конкурентов с Claude Code. До этого пятнадцать лет управлял командами и бизнесами, код руками открывал раз в три года. Главный вывод: Claude Code это инициативный junior с памятью золотой рыбки. 5 правил контроля, без которых он разваливает любую систему сложнее MVP за две сессии.