Представим себе, что есть корпорация с достаточно длинной вертикалью менеджмента. Ну уж не знаю… скажем 5+ слоев. И пусть где-то на верху есть некоторое количество людей (в топ менеджменте или в совете директоров), которые владеют какой-то частью компании (читай заинтересованы в достаточно долгосрочном успехе компании).
Есть одна особенность «потоков» информации в такой компании. Обычно тех самых владельцев кормят из ложечки говном информацией, которая ну скажем имеет очень слабое отношение к реальности. Кормят их те самые 4+ слоев, которые находятся под ними.
Происходит это по той простой причине, что в своем уме, очень небольшое количество менеджеров хотят признавать свои ошибки (особенно, если это может сказаться на их ЗП, бонусах, должности). Ну и логично, что на верх подается несколько искаженная информация и пройдя через N слоев искажения — она уже содержит истину в гомеопатических объемах.
Например классика такой ситуации — это когда в корпорации делается большой IT проект и собираются его выкатить через два года и что проект будет нереально крутым. Весь топ менеджмент (включая совладельцев) продолжают верить в это и инвестировать деньги, до тех пор пока 2 года спустя оказывается, что деньги просраны, а проект не просто далек от выпуска, а за это время стал жутким монстром, который проще выбросить, чем довести до ума. При этом достаточно большее количество рядового состава из опоков (QA, программисты и иже с ними) вполне таки подозревали чем это все закончится еще год, до того, как это дойдет до менеджмента.
Так вот, появилась у меня забавная идея. Удивлен, что ее не слишком практикуют. Позволять впрямую контактировать через несколько слоев менеджмента. Чаще всего люди, максимум знают (и общаются) с боссом своего босса. Редко кто общается через 2, а тем более через 3+ уровня.
Так вот — идея, позволить это делать раз в некоторое время. Например, раз в неделю можно пообщаться через 1 уровень, раз в месяц — через 3, раз в квартал — через 5, раз в пол года — через 7 уровней. Не думаю, что будет так много людей, которые захотят этот делать, так что беспокоиться о том, что CEO вдруг засыплют письмами.
С другой стороны, это даст возможность менеджменту (а в идеале владельцам) получать информацию с разным уровнем искажения и делать выводы на ее основе.
Кажется, в Pixar существует такая система.
Есть иной вариант:
если томменеджмент и директора будут иметь постоянный доступ к текущей ситуации, то никогда не произойдет краха, для этого можно использовать систему багтрекинга, для обмена заданиями/багами. + к этой системе будет иметь доступ и всякие верхние слои (в любой момент времени), как вам такая идея?
Мне кажется, это — суть те же отчеты, которые и так сейчас готовят менеджеры для вышестоящего руководства. Руководство всегда смотрит на цифры. Если в компании существует практика приукрашивания чисел для руководства, то совсем не важно, в каком виде эти цифры поданы — на бумажке или в репорте багтрекера ))
Скорее, лучше руководству компании созывать митинги, куда приглашать менеджеров разного уровня. Сразу можно получить картинку по всему процессу.
не факт что на миттинге раскроются все проблемы, а если для раздачи задачь использовать 1 механизм с указанием дедлайнов, то картина будет более явной, + в таком случае миттинги будут очень даже продуктивными 🙂
Я согласен, цифры можно оттрактовать по разному.
Митинги — это не решение. Так как, если присутствует твой прямой менеджер — то ты явно не будешь рассказывать о том, как он приукрашает цифры и принимает дурацкие решения.
Проблема состоит в том, что для трактовки багов (их количества) и графика нужно знать контекст (размер подсистемы, сколько людей над ней работают, в каком она сейчас состоянии, насколько она критична и т.п.)
Контекста, естественно CEO не знает, а board of directors и о проекте может и не знать.
А вот, когда снизу приходит email, который говорит — вот я тут учавствую в проекте на 100 человек, который мы уже два года тянем и весь менеджмент заявляет, что мы его через 6 месяцев закончим, а на самом деле наш отдел делает самую важную часть и нам еще лет 5 нужно все добивать. И так, между прочим, с самого начала проект делался неправильно, так что сейчас больше уходит на переделку.
Вот такая информация уже идет с трактовкой. То есть мы не просто интересуемся в подачи информации, но и в ее трактовке (альтернативной той которую делают менеджмеры).
Получается что более верхние слои менеджмента (или владельцы) будут делать работу от которой они ушли путем делегирования полномочий, зачем тогда вся эта система нужна? Мне кажется если получившаяся иерархия не может нормально работать, значит она хреново построена и этим ей вряд ли можно помочь.
Делегирование полномочий без серьезного контроля как раз и приводит к разрыву описанному в посте.
Спасибо 😉 Только что написал фактически тоже самое.
Не согласен. Никто же не говорит делать 100% работы подчиненных. Плюс, после делегирования, есть еще одна важная часть — проверка исполнения.
Так вот, это и есть проверка исполнения.
Это работает, когда высший менеджемент сам себе способен признаваться в своих ошибках. А то так поговорят через пол-года с парой простых программистов, а они топ-менеджеру скажут, что вся вертикаль менджемента уже постепенно и давно прогнила и проекты движутся в опу. А топ-менеджер и подумает, да откуда этот простой программист может все знать? Да я ж менеджеров не с улицы набирал, у них куча опыта в управлении. что я и мои подчиненные, которым я доверял эти пол-года все делали зазря? Что может этот программист знать вообще со своего места? нам с высоты виднее все таки. Не мог я ошибаться столько времени. И если он так подумает (а очень большая вероятность, что так оно и будет в большинстве случаев), то просто проигнорирует все что сказал этот программист. И смысл тогда прямых контактов?
Пару важных замечаний.
а) Топ менеджер может так и подумает. Владелец тоже может подумать, но все таки, когда есть возможность потерять много __СВОИХ__ денег, то человек думает дважды.
б) Если программист напишет что-то типа «да у нас все фигово и все прогнило» — то пожалуй, я тоже отбросил бы как спам (нету данных, нету обоснований и т.п). Если программист приведет некоторое количество обоснований. А-ля
— наш отдел занимается написанием ядра системы, без которой она не сможет работать
— за прошлый год ушли все профессиональные работники и на их место были набраны неумелые студенты
— качество системы упало под стол и там валяется (данные проверяемы из багтрекера)
— планируемое окончание проекта через 6 месяцев, при этом в 4 отделах, которые работают над проектом у работников единоглассное мнение, что займет это не меньше чем 18 месяцев.
Вот на такое письмо, еще как бы откликнулись.
Поддерживаю Ягуара.
Ну предположим пообщался ты не со своим менеджером, а менеджером на ступеньку выше. Дальнейшие действия менеджера на уровень выше? Я бы вызвал нижестоящего менеджера и возможно задал бы твои «скользкие» вопросы. И получил бы в ответ, что ситуацию маленький менеджер все же видит в более радужном свете, нежели программист. Результат общения следующий:
1. Главный менеджер — на фуя я потратил свое драгоценное время на программиста. Только настроение испортил. И вообще к этому программисту надо присмотреться он не умеет работать в команде
2. Маленький менеджер — эта сволочь пыталась лишить наш отдел премий
3. Ты с чувством выполненного долга и подпорченными отношениями со своим менеджером. И … ничего не поменялось…
Я бы действовал немного по-другому. Сама по себе негативная инфа ничего не даст. Предлагать надо методы улучшения ситуации. А давайте это попробуем поменять. Это может дать прирост кода 🙂 (уменьшение багов) и тд. И действовать через вышестоящего и не прыгать через головы. Глядишь и на ступеньку выше поднимешься сам. И уже самому можно будет общаться с менеджером на уровень выше и ситуацию возможно удасться поменять к лучшему…
+1
нужно уметь работать в команде, а не разрушать ее, созидание всегда лучше дестроя 🙂
главное чтобы вышестоящий менеджер не прыгал выше своего и чтобы не 5 манагеров раздавали задачи одновременно, а то может получиться: один с сошкой, да семеро с ложкой.. сами понимаете
>нужно уметь работать в команде, а не разрушать ее, созидание всегда лучше дестроя
Кто же спорит. Только вот, если компания идет саморазрушительным курсом, как по мне созидание тут — не работа опустив голову, а наоборот попытки изменения этого курса.
Вот тут список крупных провалов. Бьюсь об заклад, те люди которые все это исполняли знали гооораздо раньше о том, куда все катится.
http://pcworld.about.com/od/softwareservices/Lessons-Learned-IT-s-Biggest.htm
>главное чтобы вышестоящий менеджер не прыгал выше своего
В обычной плановой ситуации — согласен. В ситуации, когда все идет к одному большому сливу — не согласен.
>и чтобы не 5 манагеров раздавали задачи одновременно
С этим согласен полностью. Если топ менеджер вдруг осознает, как все плохо, он не должен начинать выдавать задачи напрямую. Он должен начинать вправлять мозги менеджменту находящемуся прямо под ним.
В целом согласен (насчет резульататов контакта через пару ступенек), только вывод бы сделал другой. Пожалуй действительно контакт должен быть ТОЛЬКО напрямую с совладельцами компании. Выход на середину менеджерской вертикали не актуален.
Естественно, предложение улучшения ситуации — это еще лучше, чем просто констатация плохих фактов. Но даже констатация фактов, важна, так как разрыв с реальной в больших компаниях ну просто огромный.
Контрреволюционные идеи толкаешь, товарищ! 🙂 Ты что, против
советскогокорпоративного уклада взбунтоваться решил? А если серьезно, я бы внес несколько замечаний.1. Очень часто (почти всегда) главный менеджер, aka CEO, от разработки софта так же далек, как программисты от биржевых котировок. Так что рассказывать ему о проблемах архитектуры и тыкать в багтрекер — это то же самое, что показывать девелоперам графики NASDAQ. Ну да, линия ползет куда-то то вверх, то вниз, а что это, о чем это говорит — хз.
2. У executive staff такой вагон своей работы, что понимать оперативную ситуацию в деталях они не могут. Для этого они нанимают себе менеджеров и делегируют им полномочия. Менеджер без полномочий и своего уровня ответственности — это самый бесполезный работник любой компании. Хуже уборщика. И у executives нет другого выхода, кроме как доверять своим менеджерам. Если им не доверять, значит их нужно микроменеджить и перепроверять, а нахера тогда такой менеджер? Поэтому я не вижу ничего удивительного в том, что C-level и прочие сильные мира сего слушают то, что им приносят их подчиненные менеджеры. И не потому, что они не умеют признавать свои ошибки. Они как раз умеют и они в основном люди далеко не глупые — просто так CEO не становятся (мы здесь не говорим о стартапах «Рога и Копыта»). Просто у них НЕТ другого инструмента оценки ситуации в компании и они физически не в состоянии перелопатить тучу отчетов снизу, чтобы получить свое представление.
3. По поводу прямых общений через несколько уровней. Это делается. Даже у нас в компании это как бы существует. Но как мне кажется, цели тут несколько иные. Это скорее мотивационная штука, иллюзия демократии. Типа вот какой у нас тут дух свободы, можно со всеми обо всем открыто болтать. Нифига. С одной стороны, для руководства организация таких вот общений «через голову» — это де-факто признание своего менеджмента ненадежным. А может там проблем и нет? Может все в проекте хорошо и здорово? И как тогда будет чувствовать себя менеджерский состав, который действительно делает свою работу хорошо, но все равно someone is looking up their asses. Это можно делать изредка, раз в полгода, как бы для повышения боевого духа, но тогда это не позволит держать руку на пульсе. Что касается прыжков через голову снизу — это вообще как ссать против ветра. Это может прокатить в компании на 15 человек, где CEO сидит через два стола и пишет acceptance criteria в перерывах между телефонными звонками. В компаниях с 5 уровнями иерархии менеджеры среднего звена уже тоже слегка потерлись в политических игрищах. Первый раз намекнут, что лучше так не делать, второй раз дадут по ушам как минимум, потому что их это выставляет в глазах их начальства теми самыми бесполезными паразитами. Так что, извините, не верю я в глобальные изменения снизу. Точнее, верю, но при условии их прохождения через иерархическкую цепочку. Я не говорю, что это правильно и хорошо, это наоборот усложняет систему и лишает ее гибкости, но так уж оно работает.
Что делать — не знаю 🙂 Снизу — как минимум делать свою работу хорошо, и как заметил Олег, предлагать улучшения, а не просто паниковать. Идти и долбать своего менеджера, пока он не услышит. Если совсем непробиваемый, можно попробовать сходить через голову, но я бы посоветовал иметь предложение из другой компании, прежде чем делать это. Сверху — наверное, по мере возможностей, знать детали и задавать как можно больше неудобных вопросов своим прямым подчиненным. Уж точно не запираться в кабинете и онанировать на финансовые планы и графики estimated revenue 🙂 А владельцам бизнесов, как вариант, нанимать весь топ менеджемент по принципу официантов — $7.25 в час федеральный минимум, а остальное все в бонусах по факту хороших результатов 🙂 Боюсь только, никто не пойдет
>1) …CEO, от разработки софта так же далек, как программисты от биржевых котировок….
Да, тыкать в багтрекер — фигня, да и про архитектуру — тоже в целом херня. Что не херня — это сроки и деньги. CEO в этих вещах прекрасно понимает и именно с них надо начинать.
А остальное можно подкидывать, в виде добавки (в том случае, если он таки захочет вдаться в детали).
2) … И у executives нет другого выхода, кроме как доверять своим менеджерам …
Почему-то все вспоминают о делегирование полномочий, а потом о святой вере в непогрешимость менеджеров. Но, почему-то все забывают о том, что после делегирования полномочий всегда идет оценка результатов сделанной работы, отчетность и проверка.
Предложенный алгоритм является методом альтернативной отчетности и проверки.
3) …По поводу прямых общений через несколько уровней. Это делается. Даже у нас в компании это как бы существует….
Чаще всего есть очень рудиментарное общение. Плюс оно зачастую организовано так, что нижестоящие не слишком спешат делиться своими мыслями.
3) … Может все в проекте хорошо и здорово? И как тогда будет чувствовать себя менеджерский состав, который действительно делает свою работу хорошо, но все равно someone is looking up their asses. …
Боязнь и неприязнь критики — как раз первый звоночек того, что не ладно в королевстве датском. Это значит либо то, что есть таки скелеты в шкафу или то, что в компании присутствует культура рубление голов с плеча не разбираясь.
3) … то касается прыжков через голову снизу – это вообще как ссать против ветра. …
Именно поэтому и просираются зачастую 100M проекты. Так как никому не хочется это делать. Собственно говоря, я чуть выше таки сказал, что линия «связи» таки должна идти на самый верх. Чтобы если ты уж решил против ветра, то в случае если ты прав, чтобы хоть всех замочило, а не тебя одного. ;))
Ну и по последнему абзацу «что делать»?
>делать свою работу хорошо, и как заметил Олег, предлагать улучшения, а не просто >паниковать.
согласен. до тех пор пока работает.
>Если совсем непробиваемый, можно попробовать сходить через голову, но я бы посоветовал >иметь предложение из другой компании, прежде чем делать это.
На самом деле, возникает вопрос зачем это человеку снизу? Если в компании полная херня творится и у него есть предложение от другой фирмы, какого черта ему парить мозги, не имея от этого никакой выгоды? Пробиваться через слои менеджмента, доказывать, что проект съест еще 5 лет, а не 6 месяцев? И в крайнем случае, получить кислое «спасибо» от своего прямого менеджера?
Именно поэтому я и предлагаю, то что описал. У человека появляется реальный шанс что-то изменить (и вероятно еще и получить хорошее повышение), если он таки спас компании X миллонов баксов. Да, если человек написал полную херню, то ничего не изменится (а может его и попросят). Но по крайней мере, становится понятно, зачем это нужно людям снизу.
> Сверху – наверное, по мере возможностей, знать детали и задавать как можно больше неудобных вопросов своим прямым подчиненным.
В этом то и проблема, что при наличие многих слоев менеджмента очень сложно задать такие вопросы, которые доставили бы НЕ искаженную информацию снизу вверх.
Ну, вот что можно спросить по вот такому потенциально провальному проекту?
Мне повезло — я работала в компании, где такое практикуют:)
Вы правы — решаются на это немногие, в моём офисе, например только 2 из 50 решились написать письмо напрямую зам президента корпорации.
Кстати, мой вопрос по проекту был решён в течение дня именно благодаря тому, что я таки написала это письмо. Хотя вокруг все стращали: Ты что? Напрямую? да он…да тебя… и т.д.
Кстати, наоборот это тоже оч хорошо работает. Особенно что касается корпоративных задач. Ибо если большинство подчиненных и в лицо-то Великого и Ужастного ни разу не видели, о решении каких общих задач может идти речь?
Это как раз один из моих расчетов. Что дай бог пару процентов будут писать — остальные все равно или бояться или считаю не нужным.
И получается, что на компанию в 5000 человек, на самом деле кто-то там вверху будет получать письмо раз в два дня от кого-то (что в целом не слишком большая загрузка).
Не совсем понял, что значит «Кстати, наоборот это тоже оч хорошо работает» В смысле когда кто-то из топ менеджмента идет в народ?
Именно.
Ибо пока инфа до низу дойдёт — тоже вся покарёжется — что ни есть хорошо:) да и вообще — полезное это дело — в народ ходить. иногда:)
понял.
хотя тут неравновесная ситуация. Когда кто-то идет на верх, то это чаще всего тот у кого душа болит за дело.
А когда кто-то идет вниз это скорее воспринимается как «барин приехал».
Увы.
Не могу не согласиться.
Да можно придумать 1000+1 способов управления, красиво обозвать каждый *.менеджмент, но при ленивом, зажранном, некомпетентном руководстве ничего не будет работать.
Как говорится, «если бордель не даёт доходу, то надобно б*ядей менять, а не вывеску.»
Все проблемы упираются в человеческий фактор.
Думаю тут проблема фундаментальная, причем фундамент ее находиться в самой схеме пирамидального управления, которое является одним из основных почти во всех сферах. Причем мы можем ее масштабировать как угодно, от меленькой фирмы из двух человек до корпорации.
Идеальная пирамида подразумевает собой неукоснительное соблюдение требований которые идут сверху, и если решения правильные и выполняются хорошо и быстро то все идеально работает. Но это только поверхностный взгляд ))
Вот некоторые проблемы пирамиды:
Такая система крайне неустойчива к возмущениям, недостаткам и ошибкам, причем на всех уровнях. Плохое решение на самом верху, разумеется, неотвратимо приводит к полному краху, так как не может быть отменено или изменено никем внизу, и продолжает исполняться, до тех пор пока этот самый верх его не пересмотрит, что обычно случается, когда здец уже пришел во всей красе.
Но и ошибки и недочеты внизу точно так же развиваются без немедленного исправления и реагирования до размеров, когда их уже замечают на том же самом верху. Ибо все промежуточные звенья управления не способны реагировать на проблемы, а только и исключительно на прямо указанные отклонения реальности от спущенной сверху картины. И любой проеб внизу имеет время и возможности разрастаться достаточно долго, и исправляется часто тогда, когда уже поздно.
Корень проблем в самой системе.
Согласен.
Хотя в целом, коммерческая компания — это не армия. Так, что за неисполнение или не точно исполнение не расстреливают.
Ключевая проблема, что множеству людей с точки зрения персональной выгоды проще исполнять полную херню (та что приходит сверху) и скрывать херню (та которая творится внизу).
Так, что я сказал бы, что основа проблемы не просто в пирамидальной организации, а в том, что такая организация усиливает недостатки присущие среднестатистическому человеку.
Да, это не армия, расстреливать не будут, но и терпеть того кто слишком много выпендривается со своим виденьем проблемы и способами ее решения, тоже не будут, просто уволят от греха подальше ))
А обратная связь пита «политика открытых дверей» весьма теоретична, поэтому я и говорю что корень проблемы в самой системе, а на сколько ее проблемы проявляются это уже зависит от конкретной ситуации.
Согласен. Хотя, вон, как пишут — Pixal реализовал таки политику.
Ну конечно система системой но ее делают люди, я читал про Пиксар статью, но там пишется что это не так просто и требует очень много усилий, всегда надо держать руку на пульсе )
Ну это вполне логично. Для получения хорошего результата обычно требуется гораздо больше усилий, чем для получения плохого.
Хотел написать про то, что такие контакты мало реальны, но меня опередили 🙂
А тут вот случайно набрел на выступление президента Pixar, у них вроде как работают такие контакты.
http://alenacpp.blogspot.com/2010/02/blog-post_16.html
Поглядел выступление.
Смысл мне понравился (умные вещи говорит), а вот стиль изложения у него как-то подкачал.
Странно, что никто не упомянул про PMO (Project Management Office). Этот офис (люди в нем состоящие или достаточно Head of PMO) имеет выход на руководство. PMO контроллирует выполнение всех проектов компании (контрольные точки проектов, наличие и качество артефактов проектов и прочее). Т.о. прекрасно решается проблема коммуникации низы-верхи.
Проблема этого PMO в том, что в самом проекте они ничего не понимают. Единственную вещь, которую они могут проверить — это наличие/отсутствие артифактов.
PMO не может проверить
а) продуманность архитектуры
б) полезность проекта
в) качество проекта (все что они смогут сделать — глядеть на количество открытых багов, которое является только отдаленным показателем качества).
и т.п.
> PMO не может проверить
Какое-то странное PMO…
В топикстарте описана проблема:
—
Есть одна особенность “потоков” информации в такой компании. Обычно тех самых владельцев кормят из ложечки говном информацией, которая ну скажем имеет очень слабое отношение к реальности. Кормят их те самые 4+ слоев, которые находятся под ними.
—
Наличие правильного(!) PMO эту проблему решает влет.
Лично с PMO никогда не сталкивался.
Прочел, то что написано в wikipedia
http://en.wikipedia.org/wiki/Project_management_office
По большему счету они занимаются стандартизацией процессов и слежением, чтобы процессы шли по стандарту.
Проблема состоит в том, что человек всегда может переиграть систему. Те самые X слоев менеджмента, которым интересно прикрыть свою задницу вполне смогут генерировать все нужные артефакты (при том, что проект будет двигаться в противоположную сторону).
Возьмем простой пример. Сидит программист. Процесс говорит
а) Программист должен прислать каждый день timesheet
б) Программист должен каждое изменение отсылать на review
в) Программист должен сообщаться о каждом изменение в QA.
Программист, пишет говенный код, при этом заполняет timesheet и отсылает на ревью другому программисту, которому лень все это смотреть и который мгновенно помечает весь код как пройденный review. Аналогично, QA удаляет все email’ы из почтового ящика о изменения и отчитывается, что проглядел изменения, протестировал и проанализировал их.
Я конечно, утрирую. Но с точки зрения процессов, придраться будет не к чему — все идет отлично. Но вот, какой-нибудь программист, который работает в этом отделе и видит все это безобразие будет прекрасно понимать, что все идет не так уж хорошо.