У каждого руководителя есть свой индвидуальный стиль. Различные подходы, идеи, взгляды и особенности формируют уникальный стиль менеджмента. Если разделить его на кусочки, то почти ничто нельзя назвать "плохим" и "хорошим", потому что все факторы взаимосвязаны.
Хотя...
Пожалуй, есть одна отличительная особенность в управлении, которая всегда, всегда, всегда плохая. По крайней мере, если мы говорим об управлении командой ИТ-шников.
Это - МИКРОМЕНЕДЖМЕНТ.
Микроменеджмент - это подход, при котором сотрудникам даются маленькие задачки. За их выполнением зачастую непрерывно следят на каждом этапе. Сотрудникам чётко определяют, КАК что сделать. За них всё разжёвывают, стоя за спиной и говоря: "Нажми сюда, теперь сюда, таааак, чуть левее..."
Финиш.
И знаете, что самое ужасное?
Микроменеджмент проявляется почти у всех!
Почему микроменеджмент - это плохо?
1. Потому что он отнимает рабочее время у руководителя.
Вместо того, чтобы делегировать сотруднику задачу, такой руководитель разжёвывает всё на кусочки, в труху. В итоге у руководителя аутлук похож на праздничную гирлянду из красных флажочков, и нет ни одной задачи, в которую он не должен засунуть свой нос.
2. Потому что он препятствует развитию сотрудников.
Вместо смелой команды, готовой к свершениям, микроменеджеры получают микросотрудников, решающих нанозадачи.
3. Потому что он демотивирует сотрудников.
Я Вам не скажу про всю Одессу, но инициативные и стремящиеся к развитию сотрудники ненавидят, когда им всё слишком строго определяют. Им нужно ТВОРЧЕСТВО. А вместо этого микроруководиль превращает работу своих сотрудников в РУТИНУ.
4. Потому что он приводит к концентрации на мелочах.
Глаза в глаза лица не увидеть. Микроменеджеры настолько сконцентрированы на нанолабуде, что у них нет времени трезво окинуть ситуацию взглядом, приоритезировать свою работу и увидеть наиболее важные задачи. Потому что они очень, очень заняты. Микрозадачами.
5. Потому что он вызывает bottleneck. В лице руководителя.
Потому что ему везде надо сунуть свой нос. Но он сконцентрирован на мелочах. И он очень занят. Ну, вы понимаете, результат неизбежен.
6. Потому что он препятствует развитию потенциала команды.
Если микроменеджер определяет, КАК решать задачу - то он задействует ресурс своих сотрудников на 5 процентов. 5 низкоквалифицированных процентов нажимателей на кнопки. Вместо того, чтобы задействовать остальные 95% творцов, исследователей и идеегенераторов.
Получается, микроменеджмент - это плохо. Это очевидно, неизбежно, однозначно плохо (я не уверена насчёт заводов и армии, и говорю лишь о тестировании). Но почему менеджеры, которые обладают достаточным уровнем интеллекта, продолжают, продолжают страдать этой фигнёй?
Почему?
1. Так привычнее.
Откуда появились менеджеры? Не из отдельной капустины и не из соседнего института. Менеджеры - бывшие исполнители. Им привычно, уютно и комфортно решать исполнительские задачи. А бремя ответственности эффективного менеджера, умеющего делегировать - некомфортно и неуютно.
2. Так круче.
Представьте, насколько обидно неуверенным в себе менеджерам, если их получасовое опаздание на работу не вызовет панику, потоп и пожар одновременно? Зато, если они сделают себя узким горлышком, они всегда, всегда, всегда будут самыми важными и незаменимыми. Хм, и вправду круто!
3. Им интересно.
"Давайте поиграем в решение задачки Х", думают микроменеджеры. И играют :) Забывая, что это НЕ ИХ игра.
4. Они никому не верят.
Ни себе, ни окружающим. А вдруг он не справится? Нет уж, лучше я ему помогу заранее. Тогда мы точно не успеем сделать самые главные проектные задачи, но вот эту нанохреновинку мы прикрутим как надо!!
5. Им страшно.
Они боятся второго вселенского потопа и зачитываются статьями о теории заговора. И естественно они боятся, что их сотрудники будут слишком круты и посягнут на Босса. Поэтому, они очень хотят, чтобы их сотрудники были всё менее и менее толковыми, свободными и развивающимися.
И всё равно просыпаются по ночам в холодном поту :)
Если мой босс - микроменеджер, ТО...
Надо валить. И побыстрее. Исправить это почти невозможно, развиваться и двигаться в такой ситуации - тоже.
Если я - микроменеджер, ТО...
Надо что-то исправлять. Потому что:
- карьерная планка микроменеджера, не умеещего развивать своих сотрудников, невысока
- работа - сплошной геморрой
- результаты всегда хуже чем хочется
- а вся команда состоит из несчатных, которые ещё в 17:00 начинают сверлить часы взглядом и умаляя стрелки двигаться быстрее.
p.s. При ответе на вопрос "Я микроменеджер?" важно быть честным с собой :)
суббота, 13 ноября 2010 г.
Подписаться на:
Комментарии к сообщению (Atom)
Отличная статья! Микроменджементо наверно все начальники грешат, вопрос только в том в какой степени :)
ОтветитьУдалитьВы говорите о микроменеджменте только с плохой стороны. Но, с другой стороны, микроменеджмент очень хорошо подходит для того, что бы ввести нового человека в комманду.
ОтветитьУдалитьОднозначно говорить, что это плохо, думаю нельзя. Например, подобный подход, может быть, применим при обучении начинающих специалистов. Они могут просто не знать, как нужно делать и подробные инструкции на начальном этапе обучения будут полезны.
ОтветитьУдалитьАбсолютно согласен с Taras Kucher.
ОтветитьУдалитьЕсть моменты, где микроменеджмент необходим, что бы получить результат.
Много раз наблюдал, когда задача дается так, что можно проявлять инициативу, творить и т.д.
А в результате руководитель получает не то что хочет. Выполнение задачи растягивается и т.д.
В людом случае есть люди эксперты, мозги.
А есть люди-руки (новички, старички, в конце концов не способные к творчеству).
Так зачастую, лучше эксперт конкретно распишет задачу и даст ее 5 человекам кодерам.
Валить!
ОтветитьУдалитьOverheat: упс...
ОтветитьУдалитьГде-то я это слышала :(
Taras Kucher, Вы говорите о так называемом инструктировании - стиле лидерства с начинающими сотрудниками. Конечно короткий период времени он применим и полезен.
ОтветитьУдалитьНо перебарщивать низззяя...
Добрый день, как раз хотел об этом (о проблеме микроменеджмента) написать , но теперь, боюсь тема почти Вами исчерпана ;) Статья хороша.
ОтветитьУдалитьМое мнение, микроменеджментом занимается:
либо тот, кто еще не освоился на более высоком уровне менеджмента (это естественно и исправляется со временем и опытом)
тот, кто реально не способен управлять на том уровне, на котором он сейчас находится..
или тот, кто не умеет или еще неуспел подобрать адекватную команду
...тут , как верно замечено, надо быть честным с собой.
Так что лозунг "даже кухарка может управлять страной" как раз об этом )
на вопрос "микроменеджмент" - это плохо или нет отвечу так: его надо избегать, но допускаю, что иногда без него не обойтись.
про "кухарку".. имел ввиду именно абсурдность этого лозунга :)
ОтветитьУдалитьwill, ИНОГДА сотрудникам (обычно начинающим) нужно чёткое и точное инструктирование. Это бесспорно. Но это должен быть осознанный выбор в текущих условиях и восприниматься как нечто ВРЕМЕННОЕ.
ОтветитьУдалитьА микроменеджмент - это такой стиль руководства, от которого руководители не могут избавиться и которому следуют ВСЕГДА, вне зависимости от контекста.
Чёткие инструкции, если они необходимы - это хорошо. Чёткие инструкции, если они не нужны - это микроменеджмент :)
Проблема большинства менеджеров в том, что они менеджеры, но зачастую хотят быть тим-лидами.
ОтветитьУдалитьМенеджер это связуещее звено между тим-лидом и командой и заказчиком(или руководством).
Тим-лид же это программист с большим опытом работы, который занимается самыми сложными задачами и координирует распределение остальных задач между подчиненными.
Суть здесь в том, что упралять ИТ командой может только человек хорошо знакомый с их областью работы и понимающий все нюансы. Следовательно человек без тех. образоваиня и опыта в ИТ управлять командой разработчиков не может.
Задача же менеджера не лесть в работу команды, и огрождать их от назойливых глаз и рученок руководства.
У вас же четко написано про управление командой ИТ менеджером. А поэтому данный подход изначально есть проблемой.
Что же касается работы ИТшников, так здесь все просто. ИТшник - это человек который может все. Суть работы программиста сводится к решению задачи, поиска ответа на заданный вопрос. И неважно какой вопрос, его работа найти решение и точка. Если же решение не найдено, то либо уровень не тот либо это не ИТшник, а идиот.
Для справки скажу, что ИТшник за год прочитывают литературы, статей и новостей в разы больше чем даже медики. А поэтому здесь крайне важно желание познавать новое и умение оперировать всей этим потоком знаний.
Как говорил мой учитель по физике. Каждый ученый может стать дворником, но ни дворник не сможет стать ученым.
А посему перед тем как строить грандиозные планы, структуры управления и прочее необходимо первое - читать книги и последние статьи, второе не думать что ты умнее других и уметь строить работу на основании предпочтений подчиненных и реалий среды.
Проблема большинства менеджеров в том, что они менеджеры, но зачастую хотят быть тим-лидами.
ОтветитьУдалитьМенеджер это связуещее звено между тим-лидом и командой и заказчиком(или руководством).
Тим-лид же это программист с большим опытом работы, который занимается самыми сложными задачами и координирует распределение остальных задач между подчиненными.
Суть здесь в том, что упралять ИТ командой может только человек хорошо знакомый с их областью работы и понимающий все нюансы. Следовательно человек без тех. образоваиня и опыта в ИТ управлять командой разработчиков не может.
Задача же менеджера не лесть в работу команды, и огрождать их от назойливых глаз и рученок руководства.
У вас же четко написано про управление командой ИТ менеджером. А поэтому данный подход изначально есть проблемой.
Что же касается работы ИТшников, так здесь все просто. ИТшник - это человек который может все. Суть работы программиста сводится к решению задачи, поиска ответа на заданный вопрос. И неважно какой вопрос, его работа найти решение и точка. Если же решение не найдено, то либо уровень не тот либо это не ИТшник, а идиот.
Для справки скажу, что ИТшник за год прочитывают литературы, статей и новостей в разы больше чем даже медики. А поэтому здесь крайне важно желание познавать новое и умение оперировать всей этим потоком знаний.
Как говорил мой учитель по физике. Каждый ученый может стать дворником, но ни дворник не сможет стать ученым.
А посему перед тем как строить грандиозные планы, структуры управления и прочее необходимо первое - читать книги и последние статьи, второе не думать что ты умнее других и уметь строить работу на основании предпочтений подчиненных и реалий среды.
Андрей Никишаев, в Ваших словах есть явные противоречия.
ОтветитьУдалитьТо управлять командой может только грамотный технарь, то любой грамотный технарь может найти решение любой проблемы сам. Зачем тогда управленец-технарь?
У меня есть свои проекты. На проектах работают разработчики, которыми я руковожу, тим-лида нет т.к. пока команда слишком маленькая. Моих технических навыков хватает на грамотное распараллеливание задач - не более того.
Но, как Вы верно заметили, грамотный технарь найдёт любое решение сам. А у меня они естественно грамотные :) Поэтому, команда работает слажено, проблем нет, и мне нет причин совать свой нос в их задачи.
При этом, у меня есть куча менеджерских задач, в которых обычно ни фига не разбираются выросшие из технарей "менеджеры": подбор, мотивация, развитие, обеспечение условий работы и т.д. Это - важные, важные, ОЧЕНЬ важные задачи менеджера, с которыми обычно серьёзные проблемы у руководителей, которые выросли из разработчиков.
Поэтому деление на менеджеров и тим-лидов я вижу достаточно условным. Оно требуется в больших командах, и кажется мне излишним при пяти ГРАМОТНЫХ разработчиках.
Пример , который я отношу (быть может, ошибочно) к рассматриваемой проблеме:
ОтветитьУдалитьесть отделы А, Б, В - в каждом есть свой тим-лид. Отделы решают свои частные задачи, ведущие к одной общей цели. Координировать работу этих отделов выделен человек Ч, который , к примеру неплохо разбирается в деятельности отдела Б и слабовато в деятельности отделов А и В. Тим лидам отделов А и В этот человек Ч говорит "ЧТО" делать и в какие сроки. Тим лиду отдела Б повезло меньше, часто ему приходится слышать и "КАК" надо делать, хотя на вопрос "КАК" он может и должен ответить сам... Кроме того, человек Ч иногда даже подменяет собой тим лидов А, Б и В в общении с их подчиненными - говорит им "ЧТО" "КАК" и "КОГДА".
Вопрос, в чем неправ Ч. и как это до него потактичнее довести?
:))
Возможно мы говорим с Вами о разный вещах. А может я и вправду злоупотребляю микроменеджментом.
ОтветитьУдалитьНо вот как Вы поступаете в такой ситуации:
Есть какая то технология разработки, принятая в Вашей фирме. Технология выверена в предыдущих проектах и работает. Что важно она учитывает особенности бизнеса Вашей компании.
Есть сотрудник, толковый парень.
Объяснили ему технологию. Прошли вместе с ним одну задачу. Т.е. ввели в курс дела. Вроде кивает головой, все понятно. Даем задачу на самостоятельную разработку. Твори...
Через некоторое время получаем результат. Вааще не то. Выясняем. Процесс велся так как он привык. Как делал в других конторах или как ему нравится (он же творец, эксперт и т.д.).
Вот что делать с таким экспертом?
Можно уволить, а можно достигать результата и с такими сотрудниками...
Я конечно же против микроменеджмента. Т.к. он является тормзом развития самого менеджера. Просто мне кажется, что вопрос сложнее чем описан в статье.
Вы тут на лихом коне да со знаменами против микроменеджмента, а я тут в окопах сижу с народом и вижу, что есть люди, с которыми надо реально долго и плотно работать, что бы получить результат.
Перефразирую Шевчука: "есть в микроменеджменте что-то такое до чего не приятно касаться рукою..."
ОтветитьУдалить>Есть какая то технология разработки, принятая в Вашей >фирме. Технология выверена в предыдущих проектах и >работает.
ОтветитьУдалитьЗа соблюдение технологий должны следить специальные люди, либо контроль соблюдения технологий должен быть автоматизирован. Это вполне реально. Трудился я как-то в одной конторе, где подобная автоматизация была реализована на 99%. Менеджерам и исполнителям оставалось только не закрывать глаза, на соответствующие почтовые информирования. Кроме того, обязательным условием прохождения испытательного срока было четкое знание технологий , в рамках которых новому сотруднику прийдется работать. А во время прохождения испытательного срока выделялось время и наставник для освоения этих технологий.
Все просто - либо тратите ресурсы на то, чтобы научить нового сотрудника, дисциплинировать его, либо потом все время носитесь с ним как дитем, взвешивая его минусы (систематическое нарушение технологий) и плюсы (талант, толковость, "красивые глаза" =)
"За соблюдение технологий должны следить специальные люди, либо контроль соблюдения технологий должен быть автоматизирован."
ОтветитьУдалитьВообще ничего не имею против. Классно если так у Вас есть. Могу сказать мы будем двигаться в этом направлении.
Итак, должны быть люди которые занимаются отслеживанием соблюдением технологии (при отсутствии автоматизации). Т.е. они и будут заниматься микроменеджментом?
Если да, то случай когда не надо заниматься микроменеджментом, это группа профи, давно работающая вместе.
Часто получается, что работать надо не с профи, а с тем кого дали. И тут выбор или увольнять или получать результат. Ну разве я не прав?
Это вполне реально. Трудился я как-то в одной конторе, где подобная автоматизация была реализована на 99%. Менеджерам и исполнителям оставалось только не закрывать глаза, на соответствующие почтовые информирования. Кроме того, обязательным условием прохождения испытательного срока было четкое знание технологий , в рамках которых новому сотруднику прийдется работать. А во время прохождения испытательного срока выделялось время и наставник для освоения этих технологий.
Все просто - либо тратите ресурсы на то, чтобы научить нового сотрудника, дисциплинировать его, либо потом все время носитесь с ним как дитем, взвешивая его минусы (систематическое нарушение технологий) и плюсы (талант, толковость, "красивые глаза" =)
Извините, часть сообщения will осталась
ОтветитьУдалить>Итак, должны быть люди которые занимаются отслеживанием >соблюдением технологии (при отсутствии автоматизации). >Т.е. они и будут заниматься микроменеджментом?
ОтветитьУдалитьКонтроль соблюдения технологий - это одна из составляющих системы менеджмента качества (совсем не обязательно , что речь идет о качетсве ПО) ,которая состоит далеко не только из тестирования . Это отдельная задача и очень важная. Она тем важнее, чем крупнее фирма.
>Часто получается, что работать надо не с профи, а с >тем кого дали. И тут выбор или увольнять или получать >результат. Ну разве я не прав?
Наличие этого выбора естественная штука... Но с другой стороны, можно стараться более качественно подбирать команду, развивать внутреннее обучение и так далее, вводитчтобы максимально избавить себя от роли "няньки". И , как мне кажется, мы оба будем правы если признаем, что использование "микроменеджмента" надо минимизировать )
"микроменеджмента" надо минимизировать!
ОтветитьУдалитьалилуя
"Трудился я как-то в одной конторе, где подобная автоматизация была реализована на 99%. "
ОтветитьУдалитьМожет расскажете как они это сделали?
Господа комментирующие, мне кажется, вы просто не уловили главный "message", который просматривается в статье. Наталья его даже вынесла отдельным комментарием:
ОтветитьУдалить"Чёткие инструкции, если они необходимы - это хорошо. Чёткие инструкции, если они не нужны - это микроменеджмент :)"
Возможно, следует добавить данную мысль в статью сразу после определения микроменеджмента, чтобы оставшаяся часть статьи воспринималась именно в таком контексте.
И ещё одно важное дополнение в свете моего предыдущего поста:
ОтветитьУдалить"p.s. При ответе на вопрос "Я микроменеджер?" важно быть честным с собой :)"
Вы можете задавать здесь любые вопросы и приводить любые примеры, но отвечать на главный вопрос всё равно Вам! Потому как некоторые посты выглядят следующим образом: "Ну скажите, что это не про меня?". Может и не про Вас...
Читая статью не покидало ощущение, что я что называется "в теме". Задумался, где мог сталкиваться в нашей компании с проявлением микроменеджмента? Проекты, задачи... И тут я обнаружил тонкую грань между "чёткие инструкции необходимы" и "чёткие инструкции не нужны". Поясню на примере.
ОтветитьУдалитьЕсть программный продукт и нужно провести нагрузочное тестирование. Встаёт вопрос входных параметров. Тимлид ходит на совещания по проекту, у него на руках спецификации, feedback'и от пользователей и разработчиков. Встаёт вопрос: проанализировать самому все данные и поставить тестировщику конкретную задачу - провести нагрузочное тестирование с такими входными данными? Или передать всё на откуп подчинённому, пусть сам анализирует? Имеет место быть микроменеджемнт в первом случае или нет?
Формально всё нормально - тестировщик не обладает необходимыми данными для решения задачи самостоятельно. И потом, на анализ ему потребуется больше времени и т.д. (оправданий можно придумать массу, и некоторые из них могут быть действительно значимыми, например, время выполнения задачи). С другой стороны ощущение микроменеджмента не покидает...
Вот такой интересный и, на мой взгляд, довольно сложный момент.