Для начала вопрос: а много ли кто использует знания, полученные в умных книгах по управлению на практике? Почему-то сильно сомневаюсь (разубедите меня, буду только рад!). Уж по крайней мере таких людей будет меньше (в процентом отношении, конечно), чем тех, кто прочитав Страуструпа использует его на практике. Почему так происходит – вопрос отдельный, но рискну предположить, что во многом это происходит из-за того, что руководство, в первую очередь, это общение (взаимодействие) с другими людьми, а людей, которые могут под воздействием умных книжек изменить свой стиль общения с другими – единицы (если таковые вообще имеются; для ответа на этот вопрос отсылаю к трудам Фрейда, Юнга, Хелингера и т.д.). И возникает вопрос – а нужно ли вообще учиться управлять и управлять кем-то? Нет, я не хочу доводить до абсурда и не имею ввиду, что не нужно раздавать задания и как-то контролировать результаты. Под управлением сейчас я имею ввиду какие-то специальные мероприятия для повышения производительности и улучшения качества. И рискну высказать предположение, что управлять то особо и не надо. Большая часть мотивировки людей – это восполнение скрытых потребностей. Не денег, не славы, а чего-то такого, что неумолимо диктует подсознание (а диктует оно, обычно, вещи вроде родительской любви или неудовлетворённой сексуальной жизни ). Как результат люди прибиваются к той иерархии в которой им по той или иной причине комфортно. Кому-то «нравится» деспотизм, кому-то – демократия. Вот вы посмотрите – все ругают CBOSS…Но при этом сколько народу там работает и компания то процветает! Та же Евросеть – тоже отличный пример (да и вообще все конторы с herovajob). Как бы сотрудники CBOSS и иже с ними не говорили как им плохо – они там продолжают работать находя для себя какие-то причины. А теперь, вдумаемся, в чём смысл управления людьми. В том, что бы они были счастливы? Возможно, для кого-то это и так, но для работодателя этого руководителя, всё-таки, первичная цель – это получение прибыли. А прибыль можно получать при совершенно разном стиле управления и Евросеть тому пример. Отсюда и вытекает, что для получения прибыли управление не так важно, раз прибыль можно делать и без всего этого. Далее, я думаю не открою Америку, если скажу что большая (ударение ставьте куда хотите) управленцев в софтверных компаниях – это бывшие программисты или другие компьютерные специалисты, которые склонны к шизоидному типу личности и, как следствие, вообще предпочитают (как минимум – предпочитали) ни с кем особо кроме компьютера не общаться. О каком же управлении может идти речь? Как ни странно – о самом обыкновенном – о политике невмешательства, т.е. как раз о том, о чём, в частности, говорится в Peopleware — программистам надо дать задания и не мешать, а они всё сделают. И наверняка это правильно для тех иерархий, в котором руководитель придерживается такой стратегии управления, т.к. к нему прибились именно те люди, которые нуждаются именно в таком стиле руководства. И я сам и мой непосредственный начальник, и мой коллега в той же должности, что и я придерживаемся преимущественно (каждый, наверное, силу своих внутренних причин) именно такого поведения (странное совпадение, правда?). Но посмотрим на соседний отдел (в моей же компании). Там дисциплина, штрафы и т.д. А результат точно такой же. Продукты выпускаются, с тем же качеством, с теми же задержками что и у нас, текучка тоже не выше (в моей компании она вообще достаточно низкая). И это отлично вписывается в сказанное выше — в каждом из этих отделов работают люди которые нуждаются именно в таком стиле управления. Те, кто по каким-то причинам попадают не в свою иерархию увольняются и как раз и составляют текучку кадров.
Какие выводы из этого можно сделать? Как минимум — не получится изменить стиль руководства под воздействием книг о том, как «надо» руководить. Нужны инструменты посерьезнее (психоаналитик, видимо). Но, второй вывод – не нужно менять стиль, это не изменит ровным счётом ничего. Более того, последствия могут быть произвольными, вплоть до того, что разбежится вся команда, т.к. скрытые потребности этих людей перестанут удовлетворяться. Придут другие, может быть лучше (а может и нет).
Поэтому, коли уж занесло на руководящую должность (тоже не просто так, кстати), то можно сидеть, особо не рыпаться и рулить так, как «подсказывает сердце». Можно, конечно, внедрять разные технические новинки или какие-то методологии вроде XP – в общем продолжать искать разного рода серебренные пули. Но что это даст? Видимо ничего, кроме удовлетворения потребностей. Мне, например, просто иногда приятно козырнуть цитатой кого-то из великих. Каждый из нас, наверняка, сам сможет привести не один пример провалившихся проектов в которых использовались самые модные технологии и наоборот, успешные проекты в котором ничего подобного не было (например, давайте посмотрим на Линукс). Одни и те же методы в разных руках дают совершенно разные результаты. Это не мой тезис, кстати, а Ларри Константина . Кстати, тот же Константин писал что в MS (по крайней мере на тот момент – девяностые годы) в управлении был приличный бардак. И ничего, выжили.
Такие мысли посещают людей, которые сидят в конторах, где всё более менее благополучно и процессы устоялись — притом плюс-минус работают и их результаты устараивают руководство и владельцев.
Книги же пишут для тех ситуаций — когда эти процессы нужно организовавать или реорганизовавать. В эпоху перемен естественно может наблюдаться повышенная текучка кадров, да и вообще перемены могут обойтись дорого и не всегда себя оправдывают, что впрочем с лихвой окупается теми случаями, когда они таки приводят к лучшим результатам, чем были бы без них.
Здравствуйте, AndreyFedotov, Вы писали:
AF>Такие мысли посещают людей, которые сидят в конторах, где всё более менее благополучно и процессы устоялись — притом плюс-минус работают и их результаты устараивают руководство и владельцев. AF>Книги же пишут для тех ситуаций — когда эти процессы нужно организовавать или реорганизовавать. В эпоху перемен естественно может наблюдаться повышенная текучка кадров, да и вообще перемены могут обойтись дорого и не всегда себя оправдывают, что впрочем с лихвой окупается теми случаями, когда они таки приводят к лучшим результатам, чем были бы без них.
Ну, тогда можно переформулировать первое предложение — кто использовал эти знания при организации/реорганизации . Остальной текст оставить можно оставить тем же.
Да и я сам тут не вечно работал....Сравнительно недавно я работал в конторе где уууххххх как всё было, процессом каким-то и не пахло....И ничего — работали. Гораздо веселее было, чем там, где я сейчас
Здравствуйте, trial, Вы писали:
T>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Такие мысли посещают людей, которые сидят в конторах, где всё более менее благополучно и процессы устоялись — притом плюс-минус работают и их результаты устараивают руководство и владельцев.
Хотя, конечно, что-то (какая-то истина) в этом есть....
Здравствуйте, trial, Вы писали:
T>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Такие мысли посещают людей, которые сидят в конторах, где всё более менее благополучно и процессы устоялись — притом плюс-минус работают и их результаты устараивают руководство и владельцев. AF>>Книги же пишут для тех ситуаций — когда эти процессы нужно организовавать или реорганизовавать. В эпоху перемен естественно может наблюдаться повышенная текучка кадров, да и вообще перемены могут обойтись дорого и не всегда себя оправдывают, что впрочем с лихвой окупается теми случаями, когда они таки приводят к лучшим результатам, чем были бы без них.
T>Ну, тогда можно переформулировать первое предложение — кто использовал эти знания при организации/реорганизации . Остальной текст оставить можно оставить тем же.
Использовал. И пока все живы, всё работает и проекты идут.
T>Да и я сам тут не вечно работал....Сравнительно недавно я работал в конторе где уууххххх как всё было, процессом каким-то и не пахло....И ничего — работали. Гораздо веселее было, чем там, где я сейчас
Веселее кому — вам или владельцу бизнеса?
[...] T>Вот такие мысли меня посетили в понедельник.
ИМХО менять иногда нужно. Если возникает проблема — вы её пытаетесь решить. Одна половина решения — локализовать проблему. Вторая — найти решение. Так вот литература может в первую очередь помочь понять, в чём проблема и каковы принципиальные пути решения.
Например, система начала расширяться и команда перестала успевать реализовывать новые пожелания заказчика. В данном случае, на основании прочитанной литературы об ИТ проектах, можно предположить, что, с большой долей вероятности, возникла проблема с управлением требованиями. Предположить можно по тем ситуациям, которые описаны в литературе. Далее из той же литературы можно почерпнуть теоретические пути решения данной проблемы. А вот само решение уже подбирается "по месту".
А то, что команда может развалится — это, конечно, проблема (в конце концов, правда, решаемая), но если команда всё равно в текущем состоянии не справляется с задачей, то зачем она тогда нужна?
Другой вопрос, что КПД данной литературы, к сожалению, оставляет желать лучшего из-за слишком высокого уровня абстракции.
Здравствуйте, AndreyFedotov, Вы писали:
T>>Да и я сам тут не вечно работал....Сравнительно недавно я работал в конторе где уууххххх как всё было, процессом каким-то и не пахло....И ничего — работали. Гораздо веселее было, чем там, где я сейчас AF> Веселее кому — вам или владельцу бизнеса?
Естественно нам
Я, кстати, отчасти это в хорошем смысле. Да, бардак был приличный, зато и бюрократии минимум....
Здравствуйте, Spidola, Вы писали:
S>Например, система начала расширяться и команда перестала успевать реализовывать новые пожелания заказчика. В данном случае, на основании прочитанной литературы об ИТ проектах, можно предположить, что, с большой долей вероятности, возникла проблема с управлением требованиями. Предположить можно по тем ситуациям, которые описаны в литературе. Далее из той же литературы можно почерпнуть теоретические пути решения данной проблемы. А вот само решение уже подбирается "по месту".
А вот не уверен, что соглашусь. Как раз в случае управления требованиями — литература не нужна (имхо, естественно) — в смысле, можно и так понять, что происходит, если посмотреть на происходящее....Но мне кажется, что большая (ударение по вкусу) часть проблем с требованиями происходит не из-за того, что нет соответствующей методологии, а из-за того, что человек общающийся с заказчиком недостаточно уверен в себе и боится отказа, что бы настаивать на своём...Когда заказчик (от которого зависит очень многое!) начинает давить, ему ооочень трудно объяснить, что это невозможно сделать, особенно когда тот уверен в обратном. К сожалению, оценка сроков в IT отличается изрядной примерностью, и поэтому аргумент "это не сделать, потому что на это надо 6 месяцев" может не прокатить; скажут просто — "не гони, на это хватит пары месяцев". И нужно обладать достаточно крепкими нервами, что бы с таком споре устоять....Но это умной книжкой точно не воспитать...
S>А то, что команда может развалится — это, конечно, проблема (в конце концов, правда, решаемая), но если команда всё равно в текущем состоянии не справляется с задачей, то зачем она тогда нужна?
Кстати, как вариант — можно уволить руководителя. В футболе, например, я никогда не слышал, что бы разгоняли всю команду — всегда меняют тренера, когда что-то идёт не так.
S>Другой вопрос, что КПД данной литературы, к сожалению, оставляет желать лучшего из-за слишком высокого уровня абстракции.
Зато иногда её интерестно почитать . Просто как беллетристику.
Здравствуйте, trial, Вы писали:
T>Здравствуйте, Spidola, Вы писали:
S>>Например, система начала расширяться и команда перестала успевать реализовывать новые пожелания заказчика. В данном случае, на основании прочитанной литературы об ИТ проектах, можно предположить, что, с большой долей вероятности, возникла проблема с управлением требованиями. Предположить можно по тем ситуациям, которые описаны в литературе. Далее из той же литературы можно почерпнуть теоретические пути решения данной проблемы. А вот само решение уже подбирается "по месту".
T>А вот не уверен, что соглашусь. Как раз в случае управления требованиями — литература не нужна (имхо, естественно) — в смысле, можно и так понять, что происходит, если посмотреть на происходящее....Но мне кажется, что большая (ударение по вкусу) часть проблем с требованиями происходит не из-за того, что нет соответствующей методологии, а из-за того, что человек общающийся с заказчиком недостаточно уверен в себе и боится отказа, что бы настаивать на своём...Когда заказчик (от которого зависит очень многое!) начинает давить, ему ооочень трудно объяснить, что это невозможно сделать, особенно когда тот уверен в обратном. К сожалению, оценка сроков в IT отличается изрядной примерностью, и поэтому аргумент "это не сделать, потому что на это надо 6 месяцев" может не прокатить; скажут просто — "не гони, на это хватит пары месяцев". И нужно обладать достаточно крепкими нервами, что бы с таком споре устоять....Но это умной книжкой точно не воспитать...
О! А вот давление заказчика нивелировать очень помогает литература, когда говоришь ему, что вот там-то и там-то уважаемые люди и солидные компании пишут, что ваша задача не сделается за одну неделю, а потребуется месяца два... Типа, можете сами посмотреть
S>>А то, что команда может развалится — это, конечно, проблема (в конце концов, правда, решаемая), но если команда всё равно в текущем состоянии не справляется с задачей, то зачем она тогда нужна?
T>Кстати, как вариант — можно уволить руководителя. В футболе, например, я никогда не слышал, что бы разгоняли всю команду — всегда меняют тренера, когда что-то идёт не так.
Ох — аналогии такая непрочная штука ... Например, думу принято разгонять... Импичмент президенту я в России не помню, хотя теоретически возможен...
T>PS: в общем, человеческий фактор рулит!!
Ну, без него, естественно, никуда..
Здравствуйте, Spidola, Вы писали:
S>Другой вопрос, что КПД данной литературы, к сожалению, оставляет желать лучшего из-за слишком высокого уровня абстракции.
Описывать каждый конкретный случай -- тоже не пойдет -- по 2-м причинам -- случаев разных много. книги получаться толстыми очень ... и все равно можно не найти там своего случая .
T>А вот не уверен, что соглашусь. Как раз в случае управления требованиями — литература не нужна (имхо, естественно) — в смысле, можно и так понять, что происходит, если посмотреть на происходящее....Но мне кажется, что большая (ударение по вкусу) часть проблем с требованиями происходит не из-за того, что нет соответствующей методологии, а из-за того, что человек общающийся с заказчиком недостаточно уверен в себе и боится отказа, что бы настаивать на своём...Когда заказчик (от которого зависит очень многое!) начинает давить, ему ооочень трудно объяснить, что это невозможно сделать, особенно когда тот уверен в обратном. К сожалению, оценка сроков в IT отличается изрядной примерностью, и поэтому аргумент "это не сделать, потому что на это надо 6 месяцев" может не прокатить; скажут просто — "не гони, на это хватит пары месяцев". И нужно обладать достаточно крепкими нервами, что бы с таком споре устоять....Но это умной книжкой точно не воспитать...
Тут есть один момент, связанный с тем, что для того чтобы сказать что на "это нужно 6 месяцев" нужно это чем-то аргуменировать ... иначе нечем возразить тем, кто говорит, "что пару месяцев достаточно". Иначе это будет спор ощущений а не фактов . А факты как раз можно брать из статистики (метрик) работы, которые без управления (их же нужно получить!) врядли нарисуются ...
Здравствуйте, trial, Вы писали:
T>Здравствуйте, AndreyFedotov, Вы писали:
T>>>Да и я сам тут не вечно работал....Сравнительно недавно я работал в конторе где уууххххх как всё было, процессом каким-то и не пахло....И ничего — работали. Гораздо веселее было, чем там, где я сейчас AF>> Веселее кому — вам или владельцу бизнеса?
T>Естественно нам
T>Я, кстати, отчасти это в хорошем смысле. Да, бардак был приличный, зато и бюрократии минимум....
Работал я как то в подобной фирме. Через пару месяцов, как я оттуда ушёл — они таки развалились.
Вообще моё личное мнение, женьщина крайне вменяемая, и дельные статьи пишет.
У каждого есть свои заскоки, если не считать меня и тебя, Читатель. Хотя насчет тебя я уже не так уверен.
— Фуллер Томас, 1608-1661, английский богослов и историк
> Под управлением сейчас я имею ввиду какие-то специальные мероприятия для повышения производительности и улучшения качества. И рискну высказать предположение, что управлять то особо и не надо. Большая часть мотивировки людей – это восполнение скрытых потребностей.
Управлять надо проектами. Управление людьми на 90% сводится к тому чтобы
1) Самому не мешать тем кто может работать, и убирать другие препятствия которые могут мешать.
2) Увольнять(в идеале отсеивать еще на собеседовании) тех кто не может(и таким образом сам является препятствием для других).
3) Помогать определиться тем кто еще не понял может он или нет.
Это все касается IT где люди по дизайну вменяемые. В макдональдсе совершенно нормальная ситуация когда когда менеджер зала пальцем показывает уборщице где мыть.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, byur, Вы писали:
B>Здравствуйте, trial, Вы писали:
T>>А вот не уверен, что соглашусь. Как раз в случае управления требованиями — литература не нужна (имхо, естественно) — в смысле, можно и так понять, что происходит, если посмотреть на происходящее....Но мне кажется, что большая (ударение по вкусу) часть проблем с
B>Тут есть один момент, связанный с тем, что для того чтобы сказать что на "это нужно 6 месяцев" нужно это чем-то аргуменировать ... иначе нечем возразить тем, кто говорит, "что пару месяцев достаточно". Иначе это будет спор ощущений а не фактов . А факты как раз можно брать из статистики (метрик) работы, которые без управления (их же нужно получить!) врядли нарисуются ...
Это конечно да. Но как быть, если задача сравнительно уникальна? Статистики не будет в этом случае.
Здравствуйте, Spidola, Вы писали:
S>О! А вот давление заказчика нивелировать очень помогает литература, когда говоришь ему, что вот там-то и там-то уважаемые люди и солидные компании пишут, что ваша задача не сделается за одну неделю, а потребуется месяца два... Типа, можете сами посмотреть
Это так, для типовых задач....А для достаточно уникальных — возникнут проблемы.
T>>Кстати, как вариант — можно уволить руководителя. В футболе, например, я никогда не слышал, что бы разгоняли всю команду — всегда меняют тренера, когда что-то идёт не так.
S>Ох — аналогии такая непрочная штука ... Например, думу принято разгонять... Импичмент президенту я в России не помню, хотя теоретически возможен...
>> Под управлением сейчас я имею ввиду какие-то специальные мероприятия для повышения производительности и улучшения качества. И рискну высказать предположение, что управлять то особо и не надо. Большая часть мотивировки людей – это восполнение скрытых потребностей.
A>Управлять надо проектами. Управление людьми на 90% сводится к тому чтобы A>1) Самому не мешать тем кто может работать, и убирать другие препятствия которые могут мешать. A>2) Увольнять(в идеале отсеивать еще на собеседовании) тех кто не может(и таким образом сам является препятствием для других). A>3) Помогать определиться тем кто еще не понял может он или нет.
A>Это все касается IT где люди по дизайну вменяемые. В макдональдсе совершенно нормальная ситуация когда когда менеджер зала пальцем показывает уборщице где мыть.
В IT тоже ничего не мешает так делать. Я сам видел такое не раз, когда тимлид или даже ПМ указывает что, где и как писать. И ничего особо страшного не происходило.
T>Это конечно да. Но как быть, если задача сравнительно уникальна? Статистики не будет в этом случае.
Проект пилотируемого полете на Марс ? ... По части уникальных проектов в СССР был большой опыт (сказано без тени иронии) ... правда в основном они делались истинными энтузиастами своего дела. Если у вас случай -- когда люди присполнены энтузиазма и проект имеет сильную идею ... то это в совокупности может может служить причиной успеха проекта без всякого управляющего воздействия . Но таких проектов -- очеееень мало ...
Однозначно могу сказать, что управлять нужно.
Нужно изучать модели производственных процессов и менять стихийно сложившийся процесс в компании.
По своему опыту управления могу сказать, что отказ от стихийного процесса и внедрение
процессов, почерпнутых из литературы, делает прозводство намного более предсказуемым и управляемым.
Дело это, конечно, не быстрое. Самое главное препятствие на пути внедрения новых
производственных процессов — это люди, которые привыкли работать по старинке, которым кажется,
что за ними будет слишком много контроля, которым спокойней, когда ничего не меняется.
Но если подходить к вопросу с точки зрения бизнес-приоритетов (а именно так и нужно делать), то становиться ясно,
что важнее не спокойствие сотрудников, а качество продукта.
Для примера приведу несколько, что называется, "земных" примеров, что лично мы сделали в нашей кампании,
как обстояли дела при стихийном процессе, и как они обстоят сейчас —
1. Итерирование
Раньше разработка продукта шла постоянно, непрерывно, не разбиваясь на этапы, в течении нескольких лет (специфика проектов такова, что мы не никогда не закрываем их, а работаем над их расширением и улучшением).
Соответственно, невозможно было спланировать сколько-нибудь осмысленные логические этапы разработки.
Теперь этого нет. Длительность итерации не превышает 4-х недель. В конце итерации мы имеем новую версию нашей системы.
Мы знаем, сколько продлится итерация и какие работы мы выполним.
2. Управление ошибками
Полностью автоматизарован рабочий цикл управления ошибками:
Обнаружение — Приоретизация — Назначение ответственного — Устранение — Верификация
Раньше об ошибках сообщалось устно, по мере их возникновения. Теперь, благодаря автоматизированному тестированию,
множество ошибок обнаруживается автоматически. Ни одна из ошибок не устраняется, не попав в базу ошибок.
Всегда можно посмотреть сколько ошибок у нас возникает, кто за них ответственнен и т.п.
3. Управление требованиями.
Раньше как такого управления требованиями не существовало — в любой момент мог поступить запрос, который кто-то бросался
устранять. Теперь все требования проходят приоретизацию, заносятся в базу, разбиваются по итерациям. Мы всегда знаем, какой набор требованяй мы реализуем в текущей итерации и какие у нас запланирваны на последующие.
4. TimeTracking
Контроль времени, затраченный разработчиками на решение любых задач позволил решить несколько проблем —
— Проблема планирования — теперь, давая оценку времени в момент планирования итерации, сотрудники подходят к этому более ответственно, так как знают, что потом будет подсчитано, сколько они времени прогнозировали на решение каждой задачи и сколько в действительности пришлось им потратить. Таким образом, с опытом, повышается качество прогнозов.
— Проблема контроля — теперь известно, кто чем занимался в течении дня и сколько времени на это потратил.
— Проблема оценок — теперь мы можем оценить, сколько времени и денег мы потратили на различные задачи, подсистемы, требования и ошибки в пределах каждой итерации.
— Проблема рабочего времени — удалось избавиться из ситуации, когда кто-то работает днем, кто-то с обеда и до полуночи.
Эта ситуация существенно снижала эффективность работы.
5. Ежедневные билды.
Замечательная идея, позволяющая нам теперь оперативно находить ошибки и оценивать ход работ.
Прекрасное письмо!
M_E>Однозначно могу сказать, что управлять нужно. M_E>Нужно изучать модели производственных процессов и менять стихийно сложившийся процесс в компании.
M_E>По своему опыту управления могу сказать, что отказ от стихийного процесса и внедрение M_E>процессов, почерпнутых из литературы, делает прозводство намного более предсказуемым и управляемым.
M_E>Дело это, конечно, не быстрое. Самое главное препятствие на пути внедрения новых M_E>производственных процессов — это люди, которые привыкли работать по старинке, которым кажется, M_E>что за ними будет слишком много контроля, которым спокойней, когда ничего не меняется.
M_E>Но если подходить к вопросу с точки зрения бизнес-приоритетов (а именно так и нужно делать), то становиться ясно, M_E>что важнее не спокойствие сотрудников, а качество продукта.
Полностью согласен. Есть правда одно существенное дополнение.
Процессы, описанные выше, можно вводить искуссно — тогда это действительно приводит к прекрасным результатам. Но бывает ситуация, когда эти процессы вводятся неумело, для галочки. То есть во главу угла ставится не суть процессов — более эффективная организация работы, а внешняя форма. Или другой вариант — реальные процессы подменяются жёстким, авторитарным стилем управления. Оба этих подхода приводят к идеентичным результатам — обычно даже худшим чем тот стихийный порядок который был до них. Вот так действительно врядли стоит управлять.
Однако если процессы организовавать умело, вводить их поэтапно, с постепенной подготовкой людей к их применению — то это может не только принести бизнесу пользу (так как вы это описали), но и поднять активность людей, участвующих в них.
Потому, главным препятствием являются не столько люди, работающие по старинке (их можно рассматривать как часть задачи), а мастерство управляющих, организующих данные процессы.
). Как результат люди прибиваются к той иерархии в которой им по той или иной причине комфортно. Кому-то «нравится» деспотизм, кому-то – демократия. Вот вы посмотрите – все ругают CBOSS…Но при этом сколько народу там работает и компания то процветает! Та же Евросеть – тоже отличный пример (да и вообще все конторы с herovajob). Как бы сотрудники CBOSS и иже с ними не говорили как им плохо – они там продолжают работать находя для себя какие-то причины. А теперь, вдумаемся, в чём смысл управления людьми. В том, что бы они были счастливы? Возможно, для кого-то это и так, но для работодателя этого руководителя, всё-таки, первичная цель – это получение прибыли. А прибыль можно получать при совершенно разном стиле управления и Евросеть тому пример. Отсюда и вытекает, что для получения прибыли управление не так важно, раз прибыль можно делать и без всего этого. Далее, я думаю не открою Америку, если скажу что большая (ударение ставьте куда хотите) управленцев в софтверных компаниях – это бывшие программисты или другие компьютерные специалисты, которые склонны к шизоидному типу личности и, как следствие, вообще предпочитают (как минимум – предпочитали) ни с кем особо кроме компьютера не общаться. О каком же управлении может идти речь? Как ни странно – о самом обыкновенном – о политике невмешательства, т.е. как раз о том, о чём, в частности, говорится в Peopleware — программистам надо дать задания и не мешать, а они всё сделают. И наверняка это правильно для тех иерархий, в котором руководитель придерживается такой стратегии управления, т.к. к нему прибились именно те люди, которые нуждаются именно в таком стиле руководства. И я сам и мой непосредственный начальник, и мой коллега в той же должности, что и я придерживаемся преимущественно (каждый, наверное, силу своих внутренних причин) именно такого поведения (странное совпадение, правда?). Но посмотрим на соседний отдел (в моей же компании). Там дисциплина, штрафы и т.д. А результат точно такой же. Продукты выпускаются, с тем же качеством, с теми же задержками что и у нас, текучка тоже не выше (в моей компании она вообще достаточно низкая). И это отлично вписывается в сказанное выше — в каждом из этих отделов работают люди которые нуждаются именно в таком стиле управления. Те, кто по каким-то причинам попадают не в свою иерархию увольняются и как раз и составляют текучку кадров.
. Кстати, тот же Константин писал что в MS (по крайней мере на тот момент – девяностые годы) в управлении был приличный бардак. И ничего, выжили. 
