Предположение прошлого поста - управляют не люди или боты в играх , управляют цели этих ботов или людей. Например в мозге человека могут быть немного противоречащие друг другу цели - безопасность и размножение (или любопытство). Если раскрывать эту мысль , то с точки зрения логики можно легко создавать цепочки целей . Например "нужно заработать деньги" чтобы "купить остров и жить там счастливо". Такие цепочки могут быть длинными и могут образовываться через логический вывод. Очевидно что промежуточная цель "нужно заработать деньги" тоже управляет средой. Но между этими двумя целями , промежуточной и основной существует логическая зависимость и некое отношение иерархии.
Вообще управление целями интересно рассматривать в таком контексте. Пусть в игре майнкрафт есть множество ботов с одной и той же целью - построить пирамиду в определенном месте. Цель определяет их целостность как системы или нет. Для примера - муравейник как система
В предыдущих постах я задумывался о том что с точки зрения математики термин "управление" довольно прост но с точки зрения того чтобы определить "кто кем управляет" в алгоритме игры которую играют боты или ии - это уже сложно и двусмысленно
Мы можем задуматься об этой теме с другой стороны. Вот есть например руководитель фирмы который открыл книгу Конфуция и прочитал "Не делай другим того, чего не желаешь себе" и решил использовать этот прицип в своем управлении подчинеными. Можно ли сказать что именно Конфуций управляет этим человеком? Скорее всего нет. Потому что правило «Не делай другим того, чего не желаешь себе» на самом деле это "золотое правило нравственности" смысловое повторение которой есть во многих религиях. Например в индуизме - "Пусть не причиняет другому того, что неприятно ему самому." . С точки зрения наших рассуждений данное правило не связано с конкретным человеком, оно связано с конкретной уникальной целью которую и должна достичь математическая теория управления. То есть руководитель фирмы возможные пути достижения цели "максимзация прибыли" фильтрует целью "Не делай другим того, чего не желаешь себе" , после применения которой у него остается какой-то список возможных действий. Мы можем сделать вывод что возможно вопрос "кто кем управляет" не имеет смысла , имеют смысл вопросы "какая цель управляет внутри алгоритма (возможно обьединенная из подцелей)" и "какая из целей действительно реализовалась и достигнута в реальности".
Это можно проиллюстрировать на другом примере тоже. С точки зрения желаний человека у него есть цель "безопасность" и есть цель "размножение". Эти цели часто конфликуют между собой , потому что женщины например бывает боятся рожать а мужчины бывает боятся соревноваться за женщину. И та и другая цель управляет интеллектом человека. Однако по факту в реальности выгрывает одна из целей в конкретные моменты времени или они просто блокируют друг друга.
В массовом сознании стройка — это шум, пыль, краны и «крепкое словцо» прораба. Считается, что проект выигрывается на площадке. Я же уверен в обратном: 80% успеха проекта закладывается в кабинете, а оставшиеся 20% — это лишь качественная исполнительность.
За годы работы в строительном менеджменте я вывел одну формулу: любой срыв срока или перерасход бюджета — это не проблема «плохого бетона», это проблема потери информации.
В чем реальная беда отрасли?
Большинство компаний сегодня живут в режиме «ручного управления» и «тушения пожаров».
Проектировщики выдают чертежи, которые не бьются с реальностью.
ПТО тонет в бумажках, не успевая за темпами работ.
ГПР (график производства работ) превращается в красивую картинку на стене, которую никто не соблюдает, потому что финансирование «подвисло», а материалы не заказаны вовремя.
Результат: Директор превращается в самого дорогого прораба, который лично «дожимает» каждый болт, вместо того чтобы управлять системой.
Мой подход: Архитектура вместо хаоса
Я начинаю этот блог (и книгу), чтобы показать другую сторону медали. Управление строительством — это в первую очередь организация бизнес-процессов.
Информация превыше всего: Если данные от геодезиста доходят до директора через три дня — проект уже в зоне риска.
Юридическая и цифровая гигиена: Каждое решение должно быть обосновано и зафиксировано. «Договорились на словах» — на стройке не работает.
Автономия: Правильно выстроенная структура компании должна работать эффективно даже в отсутствие первого лица.
Что дальше?
В «Кабинете Директора» я буду разбирать жесткие кейсы: как мы перекраивали структуру в Компании, как боролись с проектными ошибками и почему современный менеджер в строительстве обязан быть немного юристом и ИТ-архитектором.
Коллеги, а какой процент вашего времени занимает «тушение пожаров» вместо плановой работы? Пишите в комментариях, разберем, где в вашей системе происходит утечка данных.
Дела копятся, сроки двигаются, а в коллективе растёт напряжение. Как отличить перегрузку сотрудников от ошибок в управлении и взять ситуацию под контроль
Это команда сервиса управления проектами и задачами WEEEK Мы пишем о том, как навести порядок в работе и жизни — планировать, организовывать, отслеживать дела и процессы, чтобы добиваться результата без лишнего стресса.
Вот частый сценарий: сделать нужно много, дедлайны постоянно переносятся, коллеги жалуются на загруженность. Что предпринять руководителю? Правда ли имеет смысл снизить темп работы? И как понять реальную занятость команды? Сейчас расскажем.
Симптомы перегрузки
Мы ещё поговорим о способах, которые помогут сделать точные выводы про занятость команды. Но перед тем, как перейти к цифрам, предлагаем оценить общее состояние коллектива. Обрати внимание на эти признаки:
Постоянные переработки. Иногда нормально задержаться из-за срочного релиза или сложного проекта. Но если сотрудники регулярно остаются допоздна и двигают работу на выходные — это тревожный звоночек.
Участившиеся ошибки. Усталость и спешка неизбежно влияют на качество. Часть дел приходится отправлять на доработку — со временем всё большую. В какой-то момент даже начинает казаться, что команда занята только исправлениями.
Снижение скорости. Когда нагрузка высокая, становится сложно сфокусироваться на одном деле — ведь нужно было успеть ещё вчера. Внимание прыгает между задачами, и ничего не доводится до конца вовремя.
Сдвиг сроков. Задачи перетекают из спринта в спринт, а иногда команда не успевает закрыть даже базу. Перегруженные коллеги работают в режиме тушения пожаров и не находят времени взяться за плановые дела.
Снижение вовлечённости. Уставшие сотрудники перестают проявлять инициативу и сосредотачивают все усилия на том, чтобы справиться с основной работой. Здесь есть риск эмоционального выгорания — тогда человек совсем выключается из процессов.
Рост недопониманий. Из-за перегрузки копится раздражение — на работу, друг друга, клиентов. Оно выливается в конфликты, где очень сложно найти общий язык. Потому что устали абсолютно все.
Если такая картина складывается систематически, а не только во время пика нагрузки — это повод сопоставить количество задач, рабочих рук и сроки. Скорее всего, коллеги правда делают слишком много
Управленческие ошибки
Бывает и по-другому — объём работы адекватный, но есть ощущение, что команда не справляется. Тогда дело может быть в управлении. Проверь, нет ли чего похожего:
Неравномерное распределение задач. Пока одни ждут следующих поручений, дела вторых расписаны на недели вперёд. Объединившись, команда могла бы справиться с объёмом задач — но из-за перекоса некоторые коллеги работают на пределе.
Узкие места. Ключевые сотрудники становятся точкой, через которую проходит всё — они перепроверяют работу коллег, согласовывают результат, закрывают сложные дела. Нагрузка на таких людей сильно возрастает, а процессы тормозятся.
Задачи без оценки. Работа попадает в спринт без указания предполагаемого времени выполнения, сложности и сроков. Если мы не знаем, сколько «весит» конкретное дело, можно запросто перегрузить своих подчинённых.
Частая смена приоритетов. Вчера была важной задача Х, сегодня — переключаемся на Y. Завтра придётся бросить всё и начать вникать в дело Z. Часть работы зависает, хаос разрастается, а нагрузка ощущается сильнее.
Нет прозрачности. Задачи для коллег распределяются в переписках или на встречах и не фиксируются в общей системе. Руководитель не видит полную картину процессов, а команда рискует принять в работу больше дел, чем способна выполнить.
Как оценить объём работы
Если сомнения о перегрузке всё-таки закрались, их можно подтвердить или развеять. Для этого достаточно обратиться к анализу — он покажет, правда ли у коллег много работы или проблема в распределении задач. Попробуй оценить:
Количество задач. Простой способ проверить уровень занятости — посмотреть на число дел каждого подчинённого. О системной перегрузке говорит одинаково высокий объём работы для всех членов команды. Другое дело, если перерабатывают единицы.
Количество параллельных задач. Сколько задач у команды в работе? Возможно ли справиться с ними за отведённое количество времени? Если нет, стоит убрать лишнее.
Время выполнения задач. Учитывай не только количество задач, но и «вес». Пусть у сотрудника восемь пятичасовых задач — это полноценная рабочая неделя. Коллеге же назначили сразу десять дел, равных по сложности. Второй человек взял много.
Загрузка по спринтам. Сравни, какой объём работы планировался на определённый промежуток — и какой на самом деле получается выполнить. Большой разрыв между двумя показателями может говорить о нереалистичных ожиданиях.
Сколько задач зависает. Если большое количество дел долго остаётся без движения — это сигнал, что в процессе появился сбой. Часто он бывает причиной перегрузки.
Где зависают задачи. Например, поток работы айти-команды состоит из разработки, тестирования, ревью, релиза. Процесс идёт гладко до тех пор, пока дела не попадают на оценку. Важно выяснить, что происходит на этом этапе и куда уходит время.
Как контролировать занятость
Чтобы не пришлось собирать и анализировать данные по загрузке вручную, используй специальные инструменты. Они облегчают управление ресурсами команды и делают процессы прозрачным. Три главных помощника:
Трекеры задач. Системы управления задачами собирают всю работу в одном месте: видно, кто за что отвечает, какие дела выполняются, а какие ждут очереди. Снижается риск скрытой нагрузки, как когда поручения нигде не фиксируют.
Канбан-доски. Визуализируют процесс с помощью колонок и карточек. По умолчанию столбцов три: «К работе», «В работе» и «Готово». В первом — запланированные дела, во второй перемещают карточки задач, которыми уже занимаются. С третьим просто!
Колонки настраиваются в соответствии с процессами команды. Например, в редакции они могут быть такими: «Идеи», «В работе», «Редактура», «Дизайн», «Согласование», «Вёрстка», «Публикация».
Карточки задач передвигаются по этапам работы и упрощают контроль нагрузки. Доска поможет заметить узкие места, когда в какой-то колонке накопится много дел.
Диаграмма Ганта. Способ посмотреть на процессы во времени: оценить фронт работ, продолжительность, последовательность и зависимость задач друг от друга. Выглядит как столбчатая диаграмма, где на вертикальной оси — задачи, а на горизонтальной — время выполнения:
Команда перегружена: что делать
Итак, итоги аналитики натолкнули на мысль, что сегодняшний объём задач превышает возможности команды. Несколько шагов, чтобы сбалансировать рабочий ритм:
Пересмотри приоритеты. Не все задачи важны одинаково — второстепенные дела могут отнимать время и фокус команды у действительно значимых проектов. Проверь, что принесёт больше пользы сейчас, и актуализируй список приоритетов.
Ограничь количество задач в работе. Когда коллеги ведут слишком много дел сразу, нагрузка становится неподъёмной. Установи правило: например, не брать более пяти задач одновременно. Если используешь Канбан-доски, настрой лимиты для колонок.
Автоматизируй процессы. Часть нагрузки приходится на операционку: сбор данных, обновление статусов, создание повторяющихся задач. Автоматизация освобождает время команды для более ответственной работы.
Привлеки ресурсы. Если объём работы регулярно превышает количество рук, имеет смысл задуматься о расширении: подключить новых коллег, подрядчиков, сотрудников на фрилансе.
Проблема в процессах: что делать
Средний уровень занятости в пределах нормы — но команда всё равно жалуется на перегрузку. Вот что поможет выстроить более надёжную систему управления:
Прозрачное планирование. Все задачи должны находиться в одном пространстве — например, в таск-трекере. Тогда получится лучше оценивать нагрузку и распределять дела.
Оценка задач. Чтобы нагрузка была равномерной, важно понимать трудоёмкость каждой задачи — насколько она сложная и какое займёт время. Не забывай учитывать это.
Балансировка нагрузки. Посмотри, как разделены задачи между коллегами — может быть, кто-то очевидно перерабатывает, а у кого-то полно пустых слотов. Тогда нужно перераспределить дела.
Устранение узких мест. Иногда затык возникает на конкретных этапах работы. Важно проанализировать, почему задачи застревают именно там. Бывает, ответственность сосредоточена на одном сотруднике или коллегам не хватает ресурсов.
Короче говоря
Если команда не успевает закрывать задачи в срок, дело может быть не в нагрузке — иногда проблема в том, как распределены задачи, выстроены процессы или выбраны приоритеты. Понять ситуацию помогут характерные приметы и, конечно, данные.
Как определишь причину, действуй — настрой единую систему управления, «взвесь» задачи, проконтролируй загруженность и узкие места. Всё это поможет поддерживать в команде баланс и замечать сбои вовремя.
Многие управленцы стремятся выжать максимум из ресурсов: загрузить команду на 100%, распределить бюджет до копейки, занять всё время. Кажется, что это эффективность. Но опыт многих лет в управлении показывает: без резерва такая «оптимизация» обманчива. Когда в «оптимизированный» до упора коллектив приходят новые задачи или кто-то из него выбывает, система рушится.
Классика: команда работает на пределе, каждый сотрудник занят, свободных рук нет. Руководитель считает себя самым эффективным в мире. Внезапно появляется срочный проект. Откуда взять ресурсы? Коллектив заходит в стресс, сроки срываются, проект проваливается. Тоже самое происходит, когда сотрудник уходит на больничный. Отдел перегружен, потому что заменить его некем. Такие сценарии — прямое следствие отсутствия резерва.
Если управленец не держит резерв, он не выполняет свою работу. Стресс, в который попадает команда при внезапных задачах, — результат его ошибки.
Резерв — это не «простой ресурсов», а страховка от коллапса.
Как создать резерв? Во-первых, не загружайте команду на 100%. Оставляйте 20% мощности на непредвиденное. Это позволяет быстро реагировать на новые задачи. Во-вторых, всегда имейте план Б: список фрилансеров, подрядчиков или коллег, готовых подхватить. В-третьих, сохраняйте финансовый буфер — хотя бы 10% бюджета на внезапные нужды.
А вы создаёте резерв в своей работе? Расскажите в комментариях.
Если вам близка тема управления, в моем телеграм-канале «Лайфхаки управленца» я делюсь опытом и советами, которые накопились за 20 лет работы на руководящих позициях. Можете заглянуть — уверен, что найдете что-то полезное для себя.
В прошлом посте мы говорили о важности сообщать команде о выполнении задач. Сегодня — о другой стороне коммуникации: умении вовремя задавать вопросы.
Периодически в проектах происходит одно и то же: кто-то что-то недопонял, но стесняется уточнить. Вроде бы мелочь, но дальше начинается цепочка «додумываний» и интерпретаций. Итог предсказуем — либо задача выполнена не так, как ожидалось, либо сроки срываются. Какую эмоцию у вас вызывает фраза собеседника «А я думал, что…»?
Здоровая наглость — один из нужнейших навыков менеджера.
Не понял или сомневаешься — спроси!
Если есть сомнение в деталях, уточняйте. Лучше задать «глупый» вопрос в начале, чем получить «глупый» результат в конце.
Типичный пример.
Как-то раз попросил оперативно провести экспресс-анализ рынка одной услуги. Проходит день — результата нет. Спрашиваю, почему так долго? «А мы разослали запросы компаниям и ждём ответов». Говорю, что для экспресс-анализа достаточно было изучить открытые источники, зачем запросы? «А я подумал, что этого недостаточно и нужно всех опросить». Небольшое уточнение — «можно ограничиться открытыми источниками или запросить цены?» — позволило бы сделать работу точнее и быстрее.
Чем больше вопросов — тем меньше ошибок. В управлении молчание редко украшает.
А вы на какой позиции — здоровой наглости или излишней скромности?
Если вам близка тема управления, в моем телеграм-канале «Лайфхаки управленца» я делюсь опытом и советами, которые накопились за 20 лет работы на руководящих позициях. Можете заглянуть — уверен, что найдете что-то полезное для себя.
С точки зрения математической теории управления термин «управление» довольно прост: это поиск последовательности действий, которая приведет динамическую систему в нужное состояние. Однако при анализе того, кто именно управляет и как эта агентность реализуется в игре или алгоритме, возникает множество вопросов.
Прежде всего, следует разделить понятия «влияние» и «управление». Предположим, у нас есть дискретная динамическая система с набором переменных. По мере их эволюции во времени они либо воздействуют друг на друга, либо нет. Возможны ситуации, когда одна переменная влияет на состояние других, но обратного воздействия не существует. В программировании аналогом является использование константной переменной в цикле. Очевидно, что в динамической системе можно построить направленный граф влияния значения переменной в момент времени t на состояние переменных в будущем. Аналогично это работает и в алгоритме: можно определить, как переменная в начале программы влияет на все последующие. Постройка такого графа в некоторых случаях возможна без «проигрывания» системы во времени — если существует закрытая форма рекуррентной функции, — а в других случаях это возможно только путем выполнения алгоритма, что наталкивает на проблему остановки. Мы можем выделять временные компоненты сильной связности: если одна группа переменных в течение определенного времени никак не влияет на другую (и наоборот), то они причинно-следственно изолированы.
Мы видим, что в алгоритме есть переменные, обладающие бóльшим влиянием на систему, чем другие. Однако попытка подсчитать силу этого влияния — задача эвристическая. Мы можем создать метрику, подсчитывая, как изменится состояние памяти программы на каждом шаге, если изменить значение конкретной переменной. По сути, это характеристика того, насколько состояние выхода алгоритма зависит от состояния его входа. Интересно, можно ли выйти за пределы такой эвристики, используя теорию информации Колмогорова.
Если же анализировать термин «управление» в контексте игры, то мы подразумеваем наличие подалгоритма моделирования и поиска путей (классический пример — два бота, играющих в шахматы). Проблема возникает, когда мы пытаемся определить, кто кем управляет. Интуитивное понятие «управления» рассыпается на логические загадки.
Существует проблема иерархии: управляет ли игрой программист, создавший бота? А кто создал самого программиста и его алгоритм поведения? Мы упираемся в парадокс Фомы Аквинского о том, что у всего должна быть причина, что порождает вопрос о возможности бесконечно-иерархического управления. Также существует проблема масштаба планирования: один бот просчитал ходы на 10 шагов вперед, а второй — на 15. Первый бот считает, что управляет, но в действительности его стратегия поглощается логикой второго. Кроме того, есть феномен управления без присутствия: программист может создать игру и вычислить, что для достижения цели ему не нужно вмешиваться в процесс в течение часа. Означает ли это, что «пустое управление» — это тоже форма управления, происходящая даже без признаков существования управляющего?
Важным аспектом является привязка управления ко времени: функция управления зависит от момента игры, и в разные периоды один бот может влиять на другого сильнее, чем наоборот. Не менее сложна проблема цикличности: если бот A управляет ботом B, B — ботом C, а C может переписывать цели A, то можно ли сказать, что A управляет C? Возникает замкнутый контур. Существует также состояние «не-управления»: если два бота только что встретились в игре, не зная правил, то первое время никто никем не управляет, пока не выработается подкрепление от среды. Наконец, есть проблема абсолютной предсказуемости: из-за проблемы остановки программист не может предсказать поведение системы через тысячу лет. Возможно, боты разовьются настолько за это время, что выйдут за пределы программы и начнут управлять самим программистом, что доказывает принципиальную невозможность абсолютного управления на бесконечном интервале времени для каких-то типов алгоритмов, особенно с учетом внешних факторов вроде отказа оборудования.
