Откуда взялся «долби-менеджмент»

Мне не первый раз объясняют, что менеджмент работает примерно так: поставил человеку задачу, назначил срок, а дальше «долбишь», пока он ее не выполнит.

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

Я прочитал немало бизнес-литературы, но «долби-менеджмент» как отдельный метод нигде не встречал. Поэтому у меня периодически возникает вопрос: откуда люди это берут? Кто этому учит и где первоисточник?

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

Я совершенно не против сроков, тем более, в нашем бизнесе они очень конкретные. Конечный заказчик задает срок в договоре. К определенной дате мы должны поставить оборудование, провести работы и выполнить свои обязательства. За нарушение сроков бывают вполне реальные пени. То есть общий дедлайн никто не отменял. Вопрос в другом: обязательно ли для достижения этого результата назначать дедлайн каждому промежуточному действию, а потом ставить отдельного человека, который будет следить за всеми остальными?

Если задача – выкопать яму два на два метра глубиной один метр, такой подход вполне может работать. Результат понятен, объем работы понятен, технология тоже. Но попробуйте перенести ту же модель на инженерную или исследовательскую задачу и система перестанет функционировать! Можно сказать инженеру: «Мне нужен результат к пятнице» – он, вероятно, принесет его к пятнице, но вполне может получиться так: ты хотел в срок? Вот, на тебе в срок. Формально задача закрыта и галочка поставлена, только мне от этой галочки никакой пользы, потому что оборудование в итоге должно работать, измерять и решать задачу заказчика, а не формально “быть”, и в таком случае работа часто не укладывается в «делай раз, делай два».

Мы занимаемся наукоемким мелкосерийным производством полного цикла. У нас около 20 человек, при этом конкурировать приходится в том числе с компаниями, где работают сотни сотрудников. Мы сами разрабатываем оборудование, производим его, пишем программное обеспечение, занимаемся методикой, внедрением и сервисом. В такой работе невозможно один раз расписать все в формате «делай раз, делай два» и дальше просто следить за сроками. Сегодня ты занимаешься разработкой, а завтра приходит сообщение с объекта: из семи точек измерения работают только три. После изменения программы часть оборудования перестала запускаться, где-то не включается датчик, где-то нет измерения. И это не та ситуация, где помогает сообщение: «Напоминаю, срок устранения проблемы – завтра до 15:00». Нужно понять, почему не работает. Найти причину, проверить гипотезы, иногда подключить нескольких специалистов и в конечном итоге восстановить работу оборудования…

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

Для корпорации на 30 тысяч человек такая система, скорее всего, необходима. Без регламентов и формализованных процессов организация просто перестанет быть управляемой. Но когда у тебя небольшая команда, ситуация другая.

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

Но «не долбить» не значит «не управлять» – я не сторонник управления в стиле: «Вы все взрослые люди, делайте что хотите, увидимся через полгода», потому что так тоже не работает. У нас есть обязательства перед заказчиками. Есть задачи, которые зависят друг от друга. Есть качество, деньги и репутация компании. Поэтому система нужна. Просто я вижу ее несколько иначе. Для нормальной осознанной работы человеку, на мой взгляд, нужны три вещи:

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

Вторая – понятный результат. Что означает «задача выполнена»? Не «я отправил письмо». Не «я сделал чертеж». Не «программа написана»… Что в итоге должно произойти? Для меня это принципиальная разница.

Третья – открытость. Если что-то пошло не так, об этом нужно говорить сразу. Не в день дедлайна сообщать: «Мы не успели, потому что три недели назад возникла проблема». Возникла проблема – давайте разбираться. И вот здесь сроки действительно нужны – только срок конкретной инженерной работы, на мой взгляд, в первую очередь должен оценивать тот, кто эту работу выполняет. Общий срок задает договор с заказчиком. Дальше специалист понимает свое место в общей цепочке и говорит: мне на эту работу нужно столько-то времени.

Это уже его профессиональная оценка и его обязательство перед командой. А если он понимает, что не успевает, не нужно ждать пятницы, чтобы торжественно зафиксировать просрочку. Нужно прийти в среду и сказать: возникла такая-то проблема, первоначальная оценка не срабатывает, нужно искать решение.

Для меня это и есть взрослая работа. У любого инструмента есть границы применимости!
Наверное, больше всего в некоторых управленческих рекомендациях меня раздражает их универсальность: «Нужно делать только так». Почему? Для какой компании? Какого размера? Для какого типа задач? Для серийного производства или R&D? Для 20 сотрудников или для 30 тысяч? Для меня это примерно как с техническим оборудованием. Нельзя сказать, что какой-то анализатор вообще «самый лучший». Можно сказать, что он оптимален для конкретной задачи и конкретных условий. С менеджментом, думаю, происходит то же самое. Есть инструмент. Есть область его применения. Есть ограничения. Поэтому, когда мне говорят, что единственный способ получить результат от сотрудника – поставить ему срок и потом регулярно его пинать, мне хочется увидеть первоисточник. Кто разработал этот подход? Где применял? На каких компаниях? Какой результат получил? Потому что уверенность консультанта сама по себе для меня доказательством не является.

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

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

Возможно, я в чем-то ошибаюсь. Поэтому мне действительно интересен опыт людей, которые управляют небольшими производственными, инженерными и R&D-командами. Где у вас проходит граница между нормальной координацией и «долби-менеджментом»? И если вы используете систему жестких дедлайнов и постоянного контроля – на какие книги, исследования или собственный практический опыт вы опираетесь?