суббота, 13 ноября 2010 г.

Про микроменеджмент

У каждого руководителя есть свой индвидуальный стиль. Различные подходы, идеи, взгляды и особенности формируют уникальный стиль менеджмента. Если разделить его на кусочки, то почти ничто нельзя назвать "плохим" и "хорошим", потому что все факторы взаимосвязаны.

Хотя...

Пожалуй, есть одна отличительная особенность в управлении, которая всегда, всегда, всегда плохая. По крайней мере, если мы говорим об управлении командой ИТ-шников.

Это - МИКРОМЕНЕДЖМЕНТ.

Микроменеджмент - это подход, при котором сотрудникам даются маленькие задачки. За их выполнением зачастую непрерывно следят на каждом этапе. Сотрудникам чётко определяют, КАК что сделать. За них всё разжёвывают, стоя за спиной и говоря: "Нажми сюда, теперь сюда, таааак, чуть левее..."

Финиш.

И знаете, что самое ужасное?

Микроменеджмент проявляется почти у всех!

Почему микроменеджмент - это плохо?

1. Потому что он отнимает рабочее время у руководителя.
Вместо того, чтобы делегировать сотруднику задачу, такой руководитель разжёвывает всё на кусочки, в труху. В итоге у руководителя аутлук похож на праздничную гирлянду из красных флажочков, и нет ни одной задачи, в которую он не должен засунуть свой нос.

2. Потому что он препятствует развитию сотрудников.
Вместо смелой команды, готовой к свершениям, микроменеджеры получают микросотрудников, решающих нанозадачи.

3. Потому что он демотивирует сотрудников.
Я Вам не скажу про всю Одессу, но инициативные и стремящиеся к развитию сотрудники ненавидят, когда им всё слишком строго определяют. Им нужно ТВОРЧЕСТВО. А вместо этого микроруководиль превращает работу своих сотрудников в РУТИНУ.

4. Потому что он приводит к концентрации на мелочах.
Глаза в глаза лица не увидеть. Микроменеджеры настолько сконцентрированы на нанолабуде, что у них нет времени трезво окинуть ситуацию взглядом, приоритезировать свою работу и увидеть наиболее важные задачи. Потому что они очень, очень заняты. Микрозадачами.

5. Потому что он вызывает bottleneck. В лице руководителя.
Потому что ему везде надо сунуть свой нос. Но он сконцентрирован на мелочах. И он очень занят. Ну, вы понимаете, результат неизбежен.

6. Потому что он препятствует развитию потенциала команды.
Если микроменеджер определяет, КАК решать задачу - то он задействует ресурс своих сотрудников на 5 процентов. 5 низкоквалифицированных процентов нажимателей на кнопки. Вместо того, чтобы задействовать остальные 95% творцов, исследователей и идеегенераторов.


Получается, микроменеджмент - это плохо. Это очевидно, неизбежно, однозначно плохо (я не уверена насчёт заводов и армии, и говорю лишь о тестировании). Но почему менеджеры, которые обладают достаточным уровнем интеллекта, продолжают, продолжают страдать этой фигнёй?

Почему?

1. Так привычнее.
Откуда появились менеджеры? Не из отдельной капустины и не из соседнего института. Менеджеры - бывшие исполнители. Им привычно, уютно и комфортно решать исполнительские задачи. А бремя ответственности эффективного менеджера, умеющего делегировать - некомфортно и неуютно.

2. Так круче.
Представьте, насколько обидно неуверенным в себе менеджерам, если их получасовое опаздание на работу не вызовет панику, потоп и пожар одновременно? Зато, если они сделают себя узким горлышком, они всегда, всегда, всегда будут самыми важными и незаменимыми. Хм, и вправду круто!

3. Им интересно.
"Давайте поиграем в решение задачки Х", думают микроменеджеры. И играют :) Забывая, что это НЕ ИХ игра.

4. Они никому не верят.
Ни себе, ни окружающим. А вдруг он не справится? Нет уж, лучше я ему помогу заранее. Тогда мы точно не успеем сделать самые главные проектные задачи, но вот эту нанохреновинку мы прикрутим как надо!!

5. Им страшно.
Они боятся второго вселенского потопа и зачитываются статьями о теории заговора. И естественно они боятся, что их сотрудники будут слишком круты и посягнут на Босса. Поэтому, они очень хотят, чтобы их сотрудники были всё менее и менее толковыми, свободными и развивающимися.
И всё равно просыпаются по ночам в холодном поту :)


Если мой босс - микроменеджер, ТО...

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


Если я - микроменеджер, ТО...

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


p.s. При ответе на вопрос "Я микроменеджер?" важно быть честным с собой :)

25 комментариев:

  1. Отличная статья! Микроменджементо наверно все начальники грешат, вопрос только в том в какой степени :)

    ОтветитьУдалить
  2. Вы говорите о микроменеджменте только с плохой стороны. Но, с другой стороны, микроменеджмент очень хорошо подходит для того, что бы ввести нового человека в комманду.

    ОтветитьУдалить
  3. Однозначно говорить, что это плохо, думаю нельзя. Например, подобный подход, может быть, применим при обучении начинающих специалистов. Они могут просто не знать, как нужно делать и подробные инструкции на начальном этапе обучения будут полезны.

    ОтветитьУдалить
  4. Абсолютно согласен с Taras Kucher.
    Есть моменты, где микроменеджмент необходим, что бы получить результат.

    Много раз наблюдал, когда задача дается так, что можно проявлять инициативу, творить и т.д.
    А в результате руководитель получает не то что хочет. Выполнение задачи растягивается и т.д.

    В людом случае есть люди эксперты, мозги.
    А есть люди-руки (новички, старички, в конце концов не способные к творчеству).
    Так зачастую, лучше эксперт конкретно распишет задачу и даст ее 5 человекам кодерам.

    ОтветитьУдалить
  5. Overheat: упс...

    Где-то я это слышала :(

    ОтветитьУдалить
  6. Taras Kucher, Вы говорите о так называемом инструктировании - стиле лидерства с начинающими сотрудниками. Конечно короткий период времени он применим и полезен.

    Но перебарщивать низззяя...

    ОтветитьУдалить
  7. Добрый день, как раз хотел об этом (о проблеме микроменеджмента) написать , но теперь, боюсь тема почти Вами исчерпана ;) Статья хороша.
    Мое мнение, микроменеджментом занимается:
    либо тот, кто еще не освоился на более высоком уровне менеджмента (это естественно и исправляется со временем и опытом)
    тот, кто реально не способен управлять на том уровне, на котором он сейчас находится..
    или тот, кто не умеет или еще неуспел подобрать адекватную команду
    ...тут , как верно замечено, надо быть честным с собой.
    Так что лозунг "даже кухарка может управлять страной" как раз об этом )
    на вопрос "микроменеджмент" - это плохо или нет отвечу так: его надо избегать, но допускаю, что иногда без него не обойтись.

    ОтветитьУдалить
  8. про "кухарку".. имел ввиду именно абсурдность этого лозунга :)

    ОтветитьУдалить
  9. will, ИНОГДА сотрудникам (обычно начинающим) нужно чёткое и точное инструктирование. Это бесспорно. Но это должен быть осознанный выбор в текущих условиях и восприниматься как нечто ВРЕМЕННОЕ.

    А микроменеджмент - это такой стиль руководства, от которого руководители не могут избавиться и которому следуют ВСЕГДА, вне зависимости от контекста.

    Чёткие инструкции, если они необходимы - это хорошо. Чёткие инструкции, если они не нужны - это микроменеджмент :)

    ОтветитьУдалить
  10. Проблема большинства менеджеров в том, что они менеджеры, но зачастую хотят быть тим-лидами.
    Менеджер это связуещее звено между тим-лидом и командой и заказчиком(или руководством).
    Тим-лид же это программист с большим опытом работы, который занимается самыми сложными задачами и координирует распределение остальных задач между подчиненными.

    Суть здесь в том, что упралять ИТ командой может только человек хорошо знакомый с их областью работы и понимающий все нюансы. Следовательно человек без тех. образоваиня и опыта в ИТ управлять командой разработчиков не может.

    Задача же менеджера не лесть в работу команды, и огрождать их от назойливых глаз и рученок руководства.

    У вас же четко написано про управление командой ИТ менеджером. А поэтому данный подход изначально есть проблемой.

    Что же касается работы ИТшников, так здесь все просто. ИТшник - это человек который может все. Суть работы программиста сводится к решению задачи, поиска ответа на заданный вопрос. И неважно какой вопрос, его работа найти решение и точка. Если же решение не найдено, то либо уровень не тот либо это не ИТшник, а идиот.

    Для справки скажу, что ИТшник за год прочитывают литературы, статей и новостей в разы больше чем даже медики. А поэтому здесь крайне важно желание познавать новое и умение оперировать всей этим потоком знаний.

    Как говорил мой учитель по физике. Каждый ученый может стать дворником, но ни дворник не сможет стать ученым.

    А посему перед тем как строить грандиозные планы, структуры управления и прочее необходимо первое - читать книги и последние статьи, второе не думать что ты умнее других и уметь строить работу на основании предпочтений подчиненных и реалий среды.

    ОтветитьУдалить
  11. Проблема большинства менеджеров в том, что они менеджеры, но зачастую хотят быть тим-лидами.
    Менеджер это связуещее звено между тим-лидом и командой и заказчиком(или руководством).
    Тим-лид же это программист с большим опытом работы, который занимается самыми сложными задачами и координирует распределение остальных задач между подчиненными.

    Суть здесь в том, что упралять ИТ командой может только человек хорошо знакомый с их областью работы и понимающий все нюансы. Следовательно человек без тех. образоваиня и опыта в ИТ управлять командой разработчиков не может.

    Задача же менеджера не лесть в работу команды, и огрождать их от назойливых глаз и рученок руководства.

    У вас же четко написано про управление командой ИТ менеджером. А поэтому данный подход изначально есть проблемой.

    Что же касается работы ИТшников, так здесь все просто. ИТшник - это человек который может все. Суть работы программиста сводится к решению задачи, поиска ответа на заданный вопрос. И неважно какой вопрос, его работа найти решение и точка. Если же решение не найдено, то либо уровень не тот либо это не ИТшник, а идиот.

    Для справки скажу, что ИТшник за год прочитывают литературы, статей и новостей в разы больше чем даже медики. А поэтому здесь крайне важно желание познавать новое и умение оперировать всей этим потоком знаний.

    Как говорил мой учитель по физике. Каждый ученый может стать дворником, но ни дворник не сможет стать ученым.

    А посему перед тем как строить грандиозные планы, структуры управления и прочее необходимо первое - читать книги и последние статьи, второе не думать что ты умнее других и уметь строить работу на основании предпочтений подчиненных и реалий среды.

    ОтветитьУдалить
  12. Андрей Никишаев, в Ваших словах есть явные противоречия.

    То управлять командой может только грамотный технарь, то любой грамотный технарь может найти решение любой проблемы сам. Зачем тогда управленец-технарь?

    У меня есть свои проекты. На проектах работают разработчики, которыми я руковожу, тим-лида нет т.к. пока команда слишком маленькая. Моих технических навыков хватает на грамотное распараллеливание задач - не более того.

    Но, как Вы верно заметили, грамотный технарь найдёт любое решение сам. А у меня они естественно грамотные :) Поэтому, команда работает слажено, проблем нет, и мне нет причин совать свой нос в их задачи.

    При этом, у меня есть куча менеджерских задач, в которых обычно ни фига не разбираются выросшие из технарей "менеджеры": подбор, мотивация, развитие, обеспечение условий работы и т.д. Это - важные, важные, ОЧЕНЬ важные задачи менеджера, с которыми обычно серьёзные проблемы у руководителей, которые выросли из разработчиков.

    Поэтому деление на менеджеров и тим-лидов я вижу достаточно условным. Оно требуется в больших командах, и кажется мне излишним при пяти ГРАМОТНЫХ разработчиках.

    ОтветитьУдалить
  13. Пример , который я отношу (быть может, ошибочно) к рассматриваемой проблеме:

    есть отделы А, Б, В - в каждом есть свой тим-лид. Отделы решают свои частные задачи, ведущие к одной общей цели. Координировать работу этих отделов выделен человек Ч, который , к примеру неплохо разбирается в деятельности отдела Б и слабовато в деятельности отделов А и В. Тим лидам отделов А и В этот человек Ч говорит "ЧТО" делать и в какие сроки. Тим лиду отдела Б повезло меньше, часто ему приходится слышать и "КАК" надо делать, хотя на вопрос "КАК" он может и должен ответить сам... Кроме того, человек Ч иногда даже подменяет собой тим лидов А, Б и В в общении с их подчиненными - говорит им "ЧТО" "КАК" и "КОГДА".
    Вопрос, в чем неправ Ч. и как это до него потактичнее довести?
    :))

    ОтветитьУдалить
  14. Возможно мы говорим с Вами о разный вещах. А может я и вправду злоупотребляю микроменеджментом.

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

    Есть сотрудник, толковый парень.
    Объяснили ему технологию. Прошли вместе с ним одну задачу. Т.е. ввели в курс дела. Вроде кивает головой, все понятно. Даем задачу на самостоятельную разработку. Твори...

    Через некоторое время получаем результат. Вааще не то. Выясняем. Процесс велся так как он привык. Как делал в других конторах или как ему нравится (он же творец, эксперт и т.д.).
    Вот что делать с таким экспертом?

    Можно уволить, а можно достигать результата и с такими сотрудниками...

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

    ОтветитьУдалить
  15. Перефразирую Шевчука: "есть в микроменеджменте что-то такое до чего не приятно касаться рукою..."

    ОтветитьУдалить
  16. >Есть какая то технология разработки, принятая в Вашей >фирме. Технология выверена в предыдущих проектах и >работает.

    За соблюдение технологий должны следить специальные люди, либо контроль соблюдения технологий должен быть автоматизирован. Это вполне реально. Трудился я как-то в одной конторе, где подобная автоматизация была реализована на 99%. Менеджерам и исполнителям оставалось только не закрывать глаза, на соответствующие почтовые информирования. Кроме того, обязательным условием прохождения испытательного срока было четкое знание технологий , в рамках которых новому сотруднику прийдется работать. А во время прохождения испытательного срока выделялось время и наставник для освоения этих технологий.
    Все просто - либо тратите ресурсы на то, чтобы научить нового сотрудника, дисциплинировать его, либо потом все время носитесь с ним как дитем, взвешивая его минусы (систематическое нарушение технологий) и плюсы (талант, толковость, "красивые глаза" =)

    ОтветитьУдалить
  17. "За соблюдение технологий должны следить специальные люди, либо контроль соблюдения технологий должен быть автоматизирован."

    Вообще ничего не имею против. Классно если так у Вас есть. Могу сказать мы будем двигаться в этом направлении.

    Итак, должны быть люди которые занимаются отслеживанием соблюдением технологии (при отсутствии автоматизации). Т.е. они и будут заниматься микроменеджментом?

    Если да, то случай когда не надо заниматься микроменеджментом, это группа профи, давно работающая вместе.

    Часто получается, что работать надо не с профи, а с тем кого дали. И тут выбор или увольнять или получать результат. Ну разве я не прав?



    Это вполне реально. Трудился я как-то в одной конторе, где подобная автоматизация была реализована на 99%. Менеджерам и исполнителям оставалось только не закрывать глаза, на соответствующие почтовые информирования. Кроме того, обязательным условием прохождения испытательного срока было четкое знание технологий , в рамках которых новому сотруднику прийдется работать. А во время прохождения испытательного срока выделялось время и наставник для освоения этих технологий.
    Все просто - либо тратите ресурсы на то, чтобы научить нового сотрудника, дисциплинировать его, либо потом все время носитесь с ним как дитем, взвешивая его минусы (систематическое нарушение технологий) и плюсы (талант, толковость, "красивые глаза" =)

    ОтветитьУдалить
  18. Извините, часть сообщения will осталась

    ОтветитьУдалить
  19. >Итак, должны быть люди которые занимаются отслеживанием >соблюдением технологии (при отсутствии автоматизации). >Т.е. они и будут заниматься микроменеджментом?

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

    >Часто получается, что работать надо не с профи, а с >тем кого дали. И тут выбор или увольнять или получать >результат. Ну разве я не прав?

    Наличие этого выбора естественная штука... Но с другой стороны, можно стараться более качественно подбирать команду, развивать внутреннее обучение и так далее, вводитчтобы максимально избавить себя от роли "няньки". И , как мне кажется, мы оба будем правы если признаем, что использование "микроменеджмента" надо минимизировать )

    ОтветитьУдалить
  20. "микроменеджмента" надо минимизировать!
    алилуя

    ОтветитьУдалить
  21. "Трудился я как-то в одной конторе, где подобная автоматизация была реализована на 99%. "

    Может расскажете как они это сделали?

    ОтветитьУдалить
  22. Господа комментирующие, мне кажется, вы просто не уловили главный "message", который просматривается в статье. Наталья его даже вынесла отдельным комментарием:

    "Чёткие инструкции, если они необходимы - это хорошо. Чёткие инструкции, если они не нужны - это микроменеджмент :)"

    Возможно, следует добавить данную мысль в статью сразу после определения микроменеджмента, чтобы оставшаяся часть статьи воспринималась именно в таком контексте.

    ОтветитьУдалить
  23. И ещё одно важное дополнение в свете моего предыдущего поста:

    "p.s. При ответе на вопрос "Я микроменеджер?" важно быть честным с собой :)"

    Вы можете задавать здесь любые вопросы и приводить любые примеры, но отвечать на главный вопрос всё равно Вам! Потому как некоторые посты выглядят следующим образом: "Ну скажите, что это не про меня?". Может и не про Вас...

    ОтветитьУдалить
  24. Читая статью не покидало ощущение, что я что называется "в теме". Задумался, где мог сталкиваться в нашей компании с проявлением микроменеджмента? Проекты, задачи... И тут я обнаружил тонкую грань между "чёткие инструкции необходимы" и "чёткие инструкции не нужны". Поясню на примере.

    Есть программный продукт и нужно провести нагрузочное тестирование. Встаёт вопрос входных параметров. Тимлид ходит на совещания по проекту, у него на руках спецификации, feedback'и от пользователей и разработчиков. Встаёт вопрос: проанализировать самому все данные и поставить тестировщику конкретную задачу - провести нагрузочное тестирование с такими входными данными? Или передать всё на откуп подчинённому, пусть сам анализирует? Имеет место быть микроменеджемнт в первом случае или нет?
    Формально всё нормально - тестировщик не обладает необходимыми данными для решения задачи самостоятельно. И потом, на анализ ему потребуется больше времени и т.д. (оправданий можно придумать массу, и некоторые из них могут быть действительно значимыми, например, время выполнения задачи). С другой стороны ощущение микроменеджмента не покидает...

    Вот такой интересный и, на мой взгляд, довольно сложный момент.

    ОтветитьУдалить