Но, допустим, один и тот же человек должен и смету разрабатывать, и тендер для подрядчиков проводить. И, допустим, затраты на эти работы в часах таковы, что он может успеть выполнить либо одно дело, либо другое. Тогда связь между этими делами была бы ресурсная. Или, например, для того, чтобы вовремя согласовать смету, необходимо согласовать время встречи. Тогда в сетевом графике появилось бы мероприятие «направить приглашение на встречу для согласования сметы», и выполнить это мероприятие было бы правильно одновременно с началом разработки сметы – на всякий случай, чтобы не рисковать тем, что у контрагента в этот день все уже будет расписано, когда вы, завершив разработку сметы, захотите ее как можно быстрее согласовать. Программа дает возможность прямо в сетевом графике отметить характер связи (причинно-следственная либо ресурсная) путем введения в файл колонки, в которой это можно указать.

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

Очень важно обращать внимание на степень загрузки ресурсов. В рамках увеличения производительности системы у нас может возникнуть похвальное на первый взгляд стремление к максимальной загрузке всех ресурсов. Однако загрузка оборудования более чем на 75 процентов времени (в среднем, конечно) приводит… к уменьшению производительности (производственные нормы обычно учитывают этот эффект). Это связано с тем, что возрастает напряженность работы и требуется уже не оптимизация, а идеализация буквально всех основных и поддерживающих процессов, что невозможно на практике. Поэтому малейший сбой или просто естественное для процессов, в которых участвуют люди, отклонение от жесткого графика приводит к эффекту домино и буквально сносит всю цепочку.

Мы выходим на странную, казалось бы, идею: система будет работать лучше, производительнее, если у каждой ее «единицы» будут резервы. Элияху Моше Голдратт сформулировал это так: «Максимальная загрузка всех элементов системы вовсе не приводит к максимальной производительности системы». Это справедливо как для станков, так и для людей. Стремление (часто неосознанное) загрузить подчиненных «по максимуму» часто приводит к непрерывному «сбрасыванию» на их головы недостаточно проработанных идей, поручению задач с низким приоритетом, а иногда и к выполнению вообще ненужных работ, ибо главное – чтобы подчиненные вкалывали. Иногда такой подход становится следствием «синдрома собственника»: мол, эти люди «едят» мои деньги, стремятся отлынивать от работы, поэтому чтобы деньги выплачивались не зря, пусть пашут. Дополнительным катализатором может служить и то, что стоимость рабочей силы у нас растет быстрее, чем ее квалификация и производительность. В общем, на то вроде бы есть объективные причины, но такой подход приводит вовсе не к увеличению производительности труда, а, наоборот, к снижению общей эффективности системы, так как делается, может быть, и больше, но не то, что надо, не так, как надо и не тогда, когда надо. А иногда делается и меньше, так как в итоге, после всех пролитых ведер пота и ажиотажной суеты с выпученными глазами, оказывается, что до конца и в нужном качестве не сделано вообще ничего, а все работы находятся «в процессе».

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

Одной из ошибок при планировании развивающих проектов является попытка оптимизировать их сразу. Давайте порассуждаем: можно ли спланировать все точно? И насколько точно? Ведь если речь идет о новом проекте, рассчитать необходимые ресурсы мы можем только ориентировочно. Мы не знаем, сколько часов понадобится на выполнение работы; пусть по предварительным прикидкам мы пришли к цифре в 8–11 часов. Сколько закладывать в план? На первый взгляд, 8 или даже 7 часов: пусть сотрудники покрутятся, будут стараться – глядишь, и справятся, а если что – разрешим опоздать.

Такой подход кажется мне неправильным. Я бы заложил максимальное время, 11 часов, выделив ресурс на контроль качества планирования. Это не самый легкий путь, но, на мой взгляд, самый правильный. Постоянные «обрезающие» ограничения приводят к избыточной нервозности, а, значит, и к низкой производительности сотрудников при параллельном развитии иждивенческих настроений и встречном «раздувании» смет.

Мы предполагаем, что первые результаты будут не совсем оптимальны по временны́м и прочим издержкам. Это не страшно. Мы учимся производить нужные результаты, а уже потом, при переходе от развития к рутине, оптимизируем все нужные показатели. Эти этапы развития могут быть дополнительно «проиллюстрированы» и сменой приоритетов в «дереве целей». Кстати, такой подход не несет в себе ничего нового: еще в СССР существовали «экспериментальные» расценки на запуск в серию нового изделия. Об «экспериментальности» планируемого времени мы можем предупредить всех участников.

Конечно, 75 процентов – условная цифра, которая иллюстрирует сам принцип, а не является обязательным показателем загрузки каждого ресурса. Степень реальной загрузки должна учитывать следующие факторы:

• «Отработанность» заданий: чем более рутинные, привычные работы и соединяющие отдельные работы процессы выполняются, тем большая загрузка ресурса допустима.

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

• Вариативность задач: чем более однородна работа подчиненных, тем более высокую их загрузку мы можем планировать. И, наоборот, чем более разнообразны повседневные задачи, тем больший резерв нужно оставлять. Вариативность может зависеть от разных факторов: функционала, определяющего набор рутинных работ, количества одновременно выполняемых проектов по развитию и «турбулентности» внешней среды, а также от уровня владения… хаос-менеджментом, так как эта компетенция позволяет компенсировать высокую вариативность (независимо от вызвавших ее причин).