Теперь пришел черед поговорить и о развитии. Мы можем себе его позволить только после того, как запланировали и прошили в календарь:

• поддерживающие дела;

• мероприятия из управленческого цикла;

• «окна хаоса».

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

Но прежде чем у нас появятся развивающие проекты, мы должны принять развивающие же решения, для чего запланировать время для анализа информации и уже потом – для синтеза. Анализ и синтез можно совместить в одно мероприятие, обеспечив к этому времени поступление нужной информации. Я рекомендую планировать и прошивать в календарь мероприятия для разработки развивающих решений еженедельно (минимум одно) и ежемесячно (минимум два), лучше одним блоком в половину дня, через перерыв.

Разрабатывать развивающие проекты с помощью процедур «формулировка целей – декомпозиция – расстановка приоритетов» можно в любом интересующем и возможном с точки зрения человеческих и временны́х ресурсов режиме, вовлекая в эту разработку подчиненных или внешние ресурсы. Планируя выполнение развивающих проектов, мы должны учитывать приоритет поддерживающих дел. Прошивать мероприятия развивающих проектов мы можем только после прошивки поддерживающих мероприятий. И не забудьте: мы решили отказаться от столь любимых на «нашей» территории заклинаний вроде «Делайте что хотите, но…»

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

Поэтому, увеличивая ресурс для разработки всяческих новаций, нужно учитывать и то, какими силами эту разработку будет необходимо реализовывать – чтобы оценить целесообразность ускорения разработки при невозможности, к примеру, ускорить реализацию. А что будет делать закончившая разработку команда? Если у нас есть разумно долгосрочная стратегия, то развивающих проектов для загрузки этой команды у нас хватит. Но насколько разумно разрабатывать проекты быстрее, чем они могут внедряться? Кроме того, в случае создания специальных команд для развивающих проектов возникает отдельный вопрос о психологии их взаимодействия с теми, кто занимается делами поддерживающими. Проблема, конечно, решаемая, но к ней лучше быть готовым и не рассчитывать на объединяющую всех «сплоченность». Я обозначаю все эти далеко не исчерпывающие вопросы, чтобы удержать вас от простых на первый взгляд решений для весьма сложной, хотя и вполне решаемой задачи. Но теперь вы «предупреждены и вооружены».

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

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