Почему ваши сотрудники перегружены
причины, последствия и что с этим делать
Перегрузка на проектах — это как ремонт: все знают, что он затянется, но делают вид, что уложатся в срок. Давайте честно разберём, откуда берётся вечный аврал, чем он грозит и как из него выбираться.
Причины авралов (спойлер: дело не в «ленивых сотрудниках»)
- Плохое планирование. Оценки «на глазок», заниженные длительности, отсутствие резервов. Классика: «Ну мы же в прошлый раз как-то успели».
- Игнорирование рисков. Риск-реестр есть, но он — как огнетушитель: висит для красоты. Все знают про отпуск ключевого разработчика, но «как-нибудь решим».
- Оптимизм на старте. Руководство хочет верить, что проект выйдет в срок. Если не верить — придётся что-то менять. Проще поверить.
- «Расползание» границ. Объём проекта тихо растёт, а сроки и бюджет — нет. «Это же маленькая доработка», — говорит заказчик. В пятый раз.
- Культ героизма. Если в компании хвалят тех, кто «спасал проект ночами», будьте уверены: ночные подвиги будут регулярными. Героев у нас любят, а планировать — нет.
- Мультипроектность. Один сотрудник сидит на трёх проектах одновременно, и все три считают, что он занят только ими. Спойлер: он не занят ни одним полноценно.
- Продали то, чего нет. Обещания клиенту, которые кто-то (даже знаю кто) дал без консультации с командой. Сюрприз.
Что делать, чтобы не доводить до аврала
1. Реалистичные оценки и буферы. Буфер — не слабость, а страховка. Проект без резерва — это не оптимизм, а вера в чудо.
2. Ограничивайте параллельные назначения. Один человек — один проект в единицу времени, где это возможно. Мультипроектность выглядит эффективно только в отчётах.
3. Следите за загрузкой, а не за штатным расписанием. Ресурсный план должен отражать реальную доступность, а не «в штате 10 человек — значит, 10 человеко-единиц». Отпуска вы учитываете при планировании?
4. Риски — в работу, а не в реестр. Каждый риск — с владельцем, противорисковым мероприятием и сроком реализации. Иначе он не управляется, а лежит.
5. Учитесь говорить «нет». Иногда — заказчику, иногда — руководству, иногда — коллеге, который «на минутку». Только не грубо, особенно в конце проекта.
6. Считайте скрытые потери. Переработки, больничные, отгулы, текучка, исправление брака — всё это стоимость «сэкономили на планировании».
7. Следите за признаками выгорания. Авралы повторяются вторую неделю — у вас серьезные проблемы.
Если перегрузка неизбежна
- Попробуйте сократить объём, а не качество. Лучше меньше функций, но работающих. У вас ведь есть приоритет функций?
- Сделайте переработки явными. Не «как обычно», а с лимитом, компенсацией и сроком. Без «когда-нибудь потом отдохнёте».
- Усильте команду точечно. Не «добавим людей, станет быстрее» (см. закон Брукса), а точечно — на критический путь, с наставником.
- Уберите всё лишнее. Временный стоп-лист на необязательные задачи: совещания, отчёты, «улучшения процесса». Потом вернёте.
- Разберитесь после. Пост-мортем: почему случился аврал и что меняем, чтобы он не повторился. Иначе через полгода — тот же сюжет с новыми лицами.
Перегрузка бывает на любом проекте, но, если хотите предсказуемый результат — планируйте честно, не "подгоняйте" даты под обещанные дедлайны, учитывайте риски и не делайте героизм нормой.
#ProjectManagement #PMO #ResourceManagement #RiskManagement #УправлениеПроектами
Канал «Управление проектами» подключен к сервису MaxGate. Контент автоматически синхронизируется между Telegram и мессенджером MAX.
«Управление проектами» - канал из категории «Бизнес», подключенный к сервису кросспостинга MaxGate. Публикации канала синхронизируются между Telegram и мессенджером MAX, а на этой странице собраны ссылки на обе версии канала.
Сейчас у канала 140 подписчиков суммарно в Telegram и MAX. За последние 30 дней в истории MaxGate учтено 45 публикаций, поэтому перед подпиской можно оценить не только размер аудитории, но и регулярность обновлений.
Чтобы подписаться, используйте кнопки «Открыть в MAX» и «Открыть в Telegram» в верхней части страницы. У отдельных постов ссылка может быть доступна в обоих мессенджерах или только в одном из них, если MaxGate получил такой URL из истории обработки.
Критерий DCMA №9:
Некорректные даты — недопустимы.
Продолжаем разбор методики DCMA. Девятый пункт устанавливает: в плане не должно быть задач, у которых фактическое начало или фактическое завершение заданы в будущем по отношению к текущей дате.
Что это значит: если сегодня 16 сентября, а в плане у задачи стоит фактическое начало 20 сентября — это ошибка. Факт — это то, что уже произошло. Будущее может быть только планом, но не фактом.
Почему это важно:
- Некорректные даты искажают реальную картину проекта. Руководитель видит «факт», которого ещё не было, и принимает решения на основе недостоверных данных.
- Это сигнал о некачественном обновлении плана: либо даты проставлены «на автомате», либо план не синхронизирован с реальностью.
- Критерий напрямую связан с достоверностью отчётности. Если факт в будущем — отчёт не отражает реальное состояние проекта.
Как проверять в MS Project с помощью VBA:
Можно сделать ручную проверку путем установки фильтра. Но удобнее при помощи VBA, в нем можно закодировать проверку сразу 14 критериев. Макрос перебирает все задачи активного проекта, сравнивает поля «Фактическое начало» и «Фактическое окончание» с текущей датой и помечает нарушителей в текстовых полях (например, Text1 и Text2). Дальше достаточно поставить фильтр по этим полям — и все проблемные строки перед вами. Такую проверку можно запускать перед каждым формированием отчётности.
Внедрение такой проверки в регламент контроля качества планов позволяет:
· Автоматически выявлять задачи с некорректными фактическими датами до формирования отчётности.
· Снижать риски принятия решений на основе недостоверных данных.
Факт в будущем — это не «почти сделано». Это ошибка в данных. А VBA в MS Project делает проверку быстрой и регулярной.
#DCMA #ProjectManagement #Scheduling #MSProject #VBA #PMO #УправлениеПроектами
Atlassian решила: пусть агенты работают
Atlassian анонсировала новые возможности в Jira и DX для управления агентной разработкой. И вот главная цифра: 94% инженерных руководителей используют ИИ, но только 6% имеют системы, чтобы масштабировать его на весь жизненный цикл разработки.
Что теперь умеет Jira:
- Code Context. Агенты получают доступ к знаниям о многопозиционных кодовых базах через Teamwork Graph.
- Agent Context Controls. Платформенные команды решают, к каким пространствам Jira и Confluence агенты имеют доступ.
- Agent loops in Jira. Агенты сканируют бэклог, берут нераспределённые задачи, генерируют код и создают pull-запросы прямо в Jira.
- DX for Agentic Development. Измеряет влияние ИИ на пропускную способность, качество, адоптацию и стоимость.
64% прирост производительности получили команды, чьи ИИ-инструменты использовали больше контекста Atlassian. То есть если дать агенту правильный контекст — он работает. Не дать — получаете код, который «вроде работает, но не так».
https://www.itpro.com/software/development/atlassian-introduces-always-on-capabilities-for-agentic-development-workflows
Atlassian — австралийская компания-разработчик программного обеспечения для командной работы и управления проектами, основанная в 2002 году в Сиднее Майком Кэннон-Бруксом и Скоттом Фаркуаром. Её флагманские продукты — трекер задач Jira и корпоративная вики Confluence — используются более чем 20 000 организаций по всему миру, включая Microsoft, Oracle, Amazon и NASA. Штаб-квартира компании находится в Сан-Франциско, а сама она является публичной (NASDAQ: TEAM) с рыночной капитализацией около $42,5 млрд.
#Atlassian #Jira #AI #AgenticEngineering #ProjectManagement #PMO
Критерий DCMA №8
Длительность задачи — не более 44 рабочих дней.
Продолжаем разбор методики DCMA.
Восьмой пункт устанавливает: длительность задачи не должна превышать 44 рабочих дней (около 2 месяцев). Задачи большей длительности требуют декомпозиции.
Почему это критично:
Длительная задача скрывает реальный прогресс, контроль такой задачи становится малоэффективным. DCMA прямо указывает: длинные задачи скрывают детали реальной работы. Аналогичный подход описан в документации Microsoft по работе с длительностью задач.
Кроме того, длительные задачи искажают расчёт критического пути и резервов. Система не может корректно оценить, где именно возникает отклонение, пока задача не завершится.
Как проверять в MS Project с помощью VBA:
Вместо ручного просмотра сотен строк плана можно написать макрос, который автоматически выявит задачи с длительностью более 44 рабочих дней и пометит их для декомпозиции.
Код проходит по всем задачам активного проекта, сравнивает длительность с порогом (44 рабочих дня) и помечает нарушителей в текстовом поле для последующего анализа.
Можно заменить код установкой соответствующего фильтра, но если вы проверяете другие критерии DCMA, то вам придется ставить как минимум 14 разных фильтров.
Практический результат:
Внедрение такой проверки в регламент контроля качества планов позволяет:
- Автоматически выявлять задачи, требующие декомпозиции, до утверждения базового плана.
- Снижать риски срыва сроков за счёт более детального контроля.
- Формировать отчётность по критерию DCMA №8 без ручного труда.
44 дня — разумный порог. Если задача длится дольше, её нужно разбить на подзадачи. А VBA в MS Project делает эту проверку рутинной и безошибочной.
#DCMA #ProjectManagement #Scheduling #MSProject #VBA #PMO #УправлениеПроектами
