Управление проектами *

Слушай, друг, давай без лишних церемоний. Знаю, что заголовок звучит как очередная паникёрская статейка про то, как ИИ всех уничтожит. И да, понимаю — скорее всего, ты сюда зашёл с лёгким холодком в животе. Мол, блин, а что если правда? Что если завтра утром мне скажут: «Спасибо, Вася, но у нас теперь есть ChatGPT-менеджер»?

Расслабься. Налей себе чай (или что покрепче, если уже вечер), и давай поговорим по душам.

Страх — это нормально, но паника — нет

Я тоже проектный менеджер. За плечами больше 15 лет в проектах и бизнесе, видел взлёты и падения десятков проектов, руководил командами от 5 до 50 человек. И знаешь что? Когда десяток лет назад все начали кричать про ИИ, у меня тоже ёкнуло сердце. Думаю: «А что, если эти алгоритмы действительно умнее меня?»

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

Вот тут-то я и понял: заголовок этой статьи — полная чушь.

Почему ИИ не заменит проектных менеджеров

Человеческий фактор доверия

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

Ветеранам Хабра пора напрячься: время летит слишком быстро... В этом году нашему корпоративному блогу стукнуло 10 лет! За это время мы исследовали мир айтишки через самые разные сферы: от киберспорта и «фантазий о будущем» до классических технических «заглядываний под капот» с сотнями строк кода.

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

Вы часто слышите на конференциях: «Нужно быть продуктовой компанией!», «Проводите CustDev!», «Замеряйте метрики!». А на совещании звучит: «Почему мы не проводим A/B-тесты?», «Давайте сделаем CustDev с 100 пользователями!». Вы видите, что команда уходит в бессмысленную активность, а руководство требует «быть как Яндекс». В суровой реальности B2B-сделок, кастомных внедрений и длинных циклов продаж "продуктовые советы" часто разбиваются о необходимость сделать сложную интеграцию, соблюсти нефункциональные требования и договориться с комитетом из десяти человек.

Эта статья для CPO/PM и руководителей B2B, у кого сделки длятся 6–12 месяцев, решение покупает комитет, а 70% усилий уходят в интеграции и надёжность. Разбираем, где продуктовые практики дают отдачу, а где решают доменная экспертиза и безупречный delivery. Короче для тех, кто разрывается между «давайте сделаем продукт» и суровой реальностью проектов, кастома и длинных B2B-сделок. Разберёмся, когда CustDev и «быстрые эксперименты» дают ценность, а когда решает именно контекст и предметная экспертиза, чем полезна продуктовая функция, где PM не обязателен, и как управлять в циклах 6–12 месяцев без самообмана и продуктового фетишизма.

Ну и традиционно подписывайтесь на канал StrategicMove, там будет оповещение о новых вебинарах и полезностях.

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

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

Запись встречи можно посмотреть здесь. Отвечу на любые вопросы. Ниже кратко резюме:
Scrum — фреймворк из группы гибких подходов (Agile). Может быть в комбинации с другими гибкими фреймворками. Немного о терминологии:
🕊️ Методология - система принципов, практик, процессов и правил для управления проектами на уровне всей компании. Правила организации процесса готовки с набором кулинарных книг и требованиям к кухне.
🕊️ Фреймворк - гибкая структура с набором рекомендаций, но без строгих правил. Позволяет адаптироваться под контекст. Рецепт конкретного блюда, где, вместо молока, если у вас аллергия, вы не можете добавить воду. Приготовьте другое блюдо.
🕊️ Подход - общая стратегия или философия управления проектами. Будете ли вы пользовать книгой рецептов при готовке или нет? Концептуально. Если да - европейская кухня или русская?
🕊️ Метод - конкретный способ решения задачи в рамках методологии или фреймворка. Обжаривать на открытом огне или с крышкой?
🕊️ Инструмент - инструмент. Не знаю, какое ему дать определение) Ложка, масло.
Итак:
🕊️ Подход: проектный
🕊️ Методология: Agile
🕊️ Фреймворк: Scrum
🕊️ Метод: Спринт, бэклог, ретроспектива и т.д.
🕊️ Инструмент: Agile poker planning, диаграмма сгорания спринта, kanban-board и т.д.

Если вы хоть раз работали в стартапе или команде с неопытным менеджером, то знаете этот особый вид утреннего кофе. Ты садишься за рабочий стол, открываешь чат, и ещё до первого глотка узнаёшь: "Всё отменяем! Срочно делаем вот это!"

На Хабре, как и в любом живом техническом сообществе, время от времени вспыхивают споры: «Зачем программисту гуманитарные науки?», «Философия — это пустословие», «От неё ни пользы, ни кода». Я не раз слышал подобные комментарии под своими статьями — и каждый раз они вызывали у меня не раздражение, а скорее грусть.
Потому что за этими словами стоит не просто непонимание, а потеря масштаба.
А масштаб — это как раз то, что отличает инженера от квалифицированного исполнителя, учёного — от техника.

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

Agile-проекты проваливаются на 268% чаще. Исследование

Исследование, в котором приняли участие 600 инженеров-программистов из Великобритании и США, показало, что проекты, в которых применяются методы Agile Manifesto, на 268% чаще заканчиваются неудачей, чем проекты, в которых используются другие методы.

Исследования показывают, что с помощью новой методологии Impact Engineering можно снизить количество неудачных проектов по разработке программного обеспечения в 6,5 раз.

Внедрение Impact Engineering может сэкономить 115 млрд долларов США в год на бесполезных расходах на исследования и разработки в США, а британские налогоплательщики могут сэкономить около 7 млрд фунтов стерлингов в год на неудачных государственных проектах по цифровой трансформации.

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

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

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

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

И со временем я заметил: в неопределённости мы не выбираем, кем быть. Мы возвращаемся к «заводским настройкам» — к тем автоматизмам, которые и формируют паттерны поведения. Я назвал их метафорически — «социопат», «дохристианин», «кантианец», «христианин», «буддист» — не как вероисповедание, а как архетипы отношения к миру, к другому человеку, к несправедливости.

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

В этой статье мы рассмотрим несколько основных направлений ведения бизнеса, на которые стоит обратить внимание при оптимизации бизнес процессов.

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

Делегирование в IT — штука тонкая. Руководитель не должен превращаться в «узкое горлышко», через которое проходят все решения и проверка каждой задачи. Можно нанять нового сотрудника, передать ему часть дел, а потом понять, что вы снова в ручном режиме ведете каждую мелочь. Знакомо? Меня зовут Владимир Лукашенко, и я автор —медиа «вАЙТИ».

Привет, Хабр! Я Роман Путилов, руковожу техническими менеджерами в Cloud.ru. Встреч у меня много, а времени на постмиты мало. Поэтому я отдал рутину искусственному интеллекту: он собирает черновик, а я за 3–5 минут довожу его до финала.

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

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

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

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

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

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

В этой статье мы поговорим о том, кто такой DevOps lead, какие навыки ему требуются и какие проблемы должен уметь решать данный специалист.

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

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

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