Comments 276
UFO just landed and posted this here
Статья несет негативный оттенок по отношению к менеджерам. Существуют плохие программисты, плохие менеджеры, плохие дворники, плохие врачи и т.д.
Возьмите «эффективного сеньора» и через год, ваш проект будет представлять из себя постоянно падающую мешанину самых современных технологий с никому непонятной архитектурой из которой абсолютно также побегут программисты.
Возьмите «эффективного сеньора» и через год, ваш проект будет представлять из себя постоянно падающую мешанину самых современных технологий с никому непонятной архитектурой из которой абсолютно также побегут программисты.
UFO just landed and posted this here
Эффективный менеджер — это одна из разновидностей плохого менеджера, когда новаторство и современные технологии зашкаливают и приносят больше вреда, чем пользы.
Блокчейн не напоминает вам эффективного менеджера? ТОже какая-то сложная непонятная ненужная ерунда, которая может быть полезна в каком-то одном месте, но суется всюду.
Будем честными, грех чрезмерного новаторства более свойственнен как раз более программистам, а не менеджерам. Когда примитивный лендинг, который можно сделать на html, пишут на реакт+редаксе+вебхуках+бабеле+тайпскрипте+галпе далее до бесконечнести ни разу не встречали?
Блокчейн не напоминает вам эффективного менеджера? ТОже какая-то сложная непонятная ненужная ерунда, которая может быть полезна в каком-то одном месте, но суется всюду.
Будем честными, грех чрезмерного новаторства более свойственнен как раз более программистам, а не менеджерам. Когда примитивный лендинг, который можно сделать на html, пишут на реакт+редаксе+вебхуках+бабеле+тайпскрипте+галпе далее до бесконечнести ни разу не встречали?
UFO just landed and posted this here
Ага, приходит после МБА и начинает всем выносить мозг метриками, кпи, ебидтой и прочими умными словами, а у тебя шаурмяной ларек и ты себя сразу таким умным чувствуешь. Ебидта по беляшам упала в первом квартале)))
И сеньор приходит, так все переводим на nosql, реакт и пишем в функицональном стиле. А через год смотришь, никакой функциональности не добавилось, только тормозить стало и падать чаще.
И сеньор приходит, так все переводим на nosql, реакт и пишем в функицональном стиле. А через год смотришь, никакой функциональности не добавилось, только тормозить стало и падать чаще.
ЕбиТДа вроде бы https://ru.wikipedia.org/wiki/EBITDA
UFO just landed and posted this here
UFO just landed and posted this here
Имеет, имеет. Это у бухов все в одну кучу свалено. А в упр.учете, если компания реально хочет прибыльно работать, приходится все по продуктам делить.
Есть конечно вопросы по целесообразности распределять админрасходы по продуктам. Но если цель посчитать ебеду по продуктам поставлена и это помогает в анализе и упралении — то все там считается на раз.
Есть конечно вопросы по целесообразности распределять админрасходы по продуктам. Но если цель посчитать ебеду по продуктам поставлена и это помогает в анализе и упралении — то все там считается на раз.
From 2020 about MBA: https://www.youtube.com/watch?v=Y6P8qdanszw
В США и Китае давно уже (лет 20) главные в любой организации технические инженеры и учёные. Менеджерам которые организуют больше нужны только для организации - зарплаты у них маленькие, но работа не пыльная.
В РФ они считали себя более главными, где между 2005-2015, но реально в Хайтеке у них власти вообще никакой нет.
UFO just landed and posted this here
А давайте я объясню вам в лоб, почему словосочетание «эффективный менеджер» я всегда заключал в кавычки. Хотите?
Ага.
«Снизить издержки...» Основная издержка — это зарплата. А давай уволим всех нафиг!
«Увеличить прибыль...» У нас освободилась аппаратура. А давай её продадим!
А потом увольняешься и пишешь в резюме: «под моим руководством снижены издержки и получена прибыль». И становишься ещё более эффективным менеджером.
«Снизить издержки...» Основная издержка — это зарплата. А давай уволим всех нафиг!
«Увеличить прибыль...» У нас освободилась аппаратура. А давай её продадим!
А потом увольняешься и пишешь в резюме: «под моим руководством снижены издержки и получена прибыль». И становишься ещё более эффективным менеджером.
это мне напоминает бородатый анекдот про пловцов
сабж
Однажды русская и немецкая компании договорились провести совместные соревнования по гребле на восьмиместных байдарках.
Обе команды долго и упорно тренировались и когда обе были на пике формы устроили соревнования, но…
Немцы победили с преимуществом в 1 км.
После поражения русская команда была деморализована.
Топ-менеджмент решил выяснить причину провала.
Была создана рабочая группа для подготовки предложений по изменению и реструктуризации в команде.
После многих недель изысканий было установлено, что в немецкой команде гребли семеро и один рулевой…
а в русской – один на веслах и семеро рулевых!
Топ-менеджментом русской компании была привлечена консалтинговая компания для подготовки и проведения реструктуризации команды.
Получив солидный гонорар и внедрив показатели KPI, ССП и ISO 9001 и проведя маркетинговые исследования, консалтинговая фирма пришла к выводу:
Слишком много сотрудников в русской команде подает команды и слишком мало гребет….
После реструктуризации русская команда выглядела так:
– четыре рулевых…
– два старших рулевых,
– один рулевой директор,
– и один гребец.
Кроме того для гребца была введена персональная система оценки показателей эффективности и расширен круг обязанностей, чтобы повысить его ответственность.
На следующий год немецкая команда опять убедительно победила с отрывом в 2 км.
В результате очередного поражения, топ менеджментом русской компании была нанята консалтинговая компания по аудиту и оценке эффективности команды. Было принято решение расформировать гребную команду…
Гребец, как основной виновник неэффективности команды был уволен, все плановые инвестиции на ближайшие годы в новую лодку и весла были отменены.
Рулевым была объявлена благодарность, а сэкономленные деньги были выплачены топ-менеджменту в качестве премии.
Обе команды долго и упорно тренировались и когда обе были на пике формы устроили соревнования, но…
Немцы победили с преимуществом в 1 км.
После поражения русская команда была деморализована.
Топ-менеджмент решил выяснить причину провала.
Была создана рабочая группа для подготовки предложений по изменению и реструктуризации в команде.
После многих недель изысканий было установлено, что в немецкой команде гребли семеро и один рулевой…
а в русской – один на веслах и семеро рулевых!
Топ-менеджментом русской компании была привлечена консалтинговая компания для подготовки и проведения реструктуризации команды.
Получив солидный гонорар и внедрив показатели KPI, ССП и ISO 9001 и проведя маркетинговые исследования, консалтинговая фирма пришла к выводу:
Слишком много сотрудников в русской команде подает команды и слишком мало гребет….
После реструктуризации русская команда выглядела так:
– четыре рулевых…
– два старших рулевых,
– один рулевой директор,
– и один гребец.
Кроме того для гребца была введена персональная система оценки показателей эффективности и расширен круг обязанностей, чтобы повысить его ответственность.
На следующий год немецкая команда опять убедительно победила с отрывом в 2 км.
В результате очередного поражения, топ менеджментом русской компании была нанята консалтинговая компания по аудиту и оценке эффективности команды. Было принято решение расформировать гребную команду…
Гребец, как основной виновник неэффективности команды был уволен, все плановые инвестиции на ближайшие годы в новую лодку и весла были отменены.
Рулевым была объявлена благодарность, а сэкономленные деньги были выплачены топ-менеджменту в качестве премии.
А мне скорее напоминает анекдот про три конверта:
сабж
На некоем заводе меняется руководство в лице генерального директора, и старый, уходящий в отставку директор, говорит своему преемнику, мол вот, оставляю тебе в сейфе три конверта с указаниями, что делать в случает наступления ж*пы. Конверты пронумерованы, поэтому открывать последовательно.
Ну, новый директор работает-работает, подступает пушной зверёк, он вскрывает конверт №1, там написано «Вали всё на меня». Тот недолго думая, махнул шашкой, мол во всём виноват предыдущий генеральный, его неумная политика и привела к существующему писецу и т.д.
Вроде проканало, ситуация нормализовалась, всё защуршало-заработало, но… проходит время, наступает срок очередного пизеца, он вскрывает конверт №2, там написано «Готовь сокращения». Сказано-сделано. Началась подготовка к сокращениям, оптимизациям и прочим умным словам, и, внезапно, всё опять пришло в норму — завод заработал, как часы.
Долго ли, коротко ли, приходит время вскрывать третий конверт. Там указание «Готовь три конверта».
Ну, новый директор работает-работает, подступает пушной зверёк, он вскрывает конверт №1, там написано «Вали всё на меня». Тот недолго думая, махнул шашкой, мол во всём виноват предыдущий генеральный, его неумная политика и привела к существующему писецу и т.д.
Вроде проканало, ситуация нормализовалась, всё защуршало-заработало, но… проходит время, наступает срок очередного пизеца, он вскрывает конверт №2, там написано «Готовь сокращения». Сказано-сделано. Началась подготовка к сокращениям, оптимизациям и прочим умным словам, и, внезапно, всё опять пришло в норму — завод заработал, как часы.
Долго ли, коротко ли, приходит время вскрывать третий конверт. Там указание «Готовь три конверта».
ну общем так и делают, и это не анекдот
>Если прибыль выросла, продажи растут, издержки снижаются — это эффективный менеджер.
Эффективный менеджер — это тот, кто умеет видеть не только абсолютные значения, но и первую, вторую производные как минимум. Если прибыли растут, а эффективный потенциал компании снижается — это значит, что при другом сценарии (например, не уволили якобы неэффективных высокооплачиваемых профессионалов из компании и не наняли быстро набивающих произвольный текст мартышек) — компания могла бы достигнуть в 10 раз большей прибыли, но не сейчас, а через 2 года. А при выбранном нанятым варягом сценарии «прибыль здесь и сейчас» — через 2 года компания уже уйдёт в глубокий минус и прекратит своё бездарное существование.
Менеджмент — это прежде всего управление ресурсами компании, и сотрудники — это тоже ресурс, только на порядки более сложный, нежели серверы в стойках или купленное ПО. И если менеджер не умеет и не желает понимать собственно людей, которые и есть та самая производящая сила компании — то он никак не может быть эффективным. А управление людьми на основании попугайских баллов с полной самоизоляцией от якобы легко взаимозаменяемых «чёрных рабов» в стенах комфортабельных кабинетов — это как раз и есть классический подход тех управленцев, о которых пишет автор статьи.
Эффективный менеджер — это тот, кто умеет видеть не только абсолютные значения, но и первую, вторую производные как минимум. Если прибыли растут, а эффективный потенциал компании снижается — это значит, что при другом сценарии (например, не уволили якобы неэффективных высокооплачиваемых профессионалов из компании и не наняли быстро набивающих произвольный текст мартышек) — компания могла бы достигнуть в 10 раз большей прибыли, но не сейчас, а через 2 года. А при выбранном нанятым варягом сценарии «прибыль здесь и сейчас» — через 2 года компания уже уйдёт в глубокий минус и прекратит своё бездарное существование.
Менеджмент — это прежде всего управление ресурсами компании, и сотрудники — это тоже ресурс, только на порядки более сложный, нежели серверы в стойках или купленное ПО. И если менеджер не умеет и не желает понимать собственно людей, которые и есть та самая производящая сила компании — то он никак не может быть эффективным. А управление людьми на основании попугайских баллов с полной самоизоляцией от якобы легко взаимозаменяемых «чёрных рабов» в стенах комфортабельных кабинетов — это как раз и есть классический подход тех управленцев, о которых пишет автор статьи.
Если прибыль выросла, продажи растут, издержки снижаются — это эффективный менеджер.
О да. Давайте на itшном бюджете экономить. Они же не приносят прибыль этих их серверы, ленты, резервное оборудование так вообще стоит и не используется, вот пусть за счёт этого оборудования и расширят мощности. Начальство в ответ отличная идея (им то невдомек что оно есть гарант от простоев). Ставим резолюцию отказать. Приказ использовать существующие резервные мощности. Проходит время ложится сервис, резервного оборудования нет. Кто виноват — itшник, почему — ну это ж у него сломалось, чего это он весь день кофе пьет, не предусмотренок него ничего, какой-то оннеэффективный — лишить премии. Нувыпонели...
UFO just landed and posted this here
если CIO не может объяснить, как связана эта ленточка с показателями бизнеса, грош ему цена. Ну в если вдруг эта ленточка никак не влияет на показатели бизнеса, или убытки бизнеса от простоя куда меньше стоимости этой ленточки, значит она на самом деле лишняя.
Ладно, про грош ему цена я погорячился, но это на самом деле чудовищная проблема. Айтишники говорят на своём птичьем языке серверов, ленточек, RPO и RTO, но эти слова не понятны бизнесу. Бизнес не понимает этого языка, не понимает, как новый сервер, который хочет ИТ-департамент, скажется на делах компании.
Ладно, про грош ему цена я погорячился, но это на самом деле чудовищная проблема. Айтишники говорят на своём птичьем языке серверов, ленточек, RPO и RTO, но эти слова не понятны бизнесу. Бизнес не понимает этого языка, не понимает, как новый сервер, который хочет ИТ-департамент, скажется на делах компании.
Бизнес прекрасно понимает, как скажется на делах компании новый сервер. Но понимание это продолжается ровно до тех пор, пока между бизнесом, которому нужно понимание, и IT-департаментом не сформируется достаточно толстый слой менеджеров-медиаторов. Как только медиаторов становится больше двух — приехали.
В испорченный телефон играли в детстве? Вот то-то.
Но это, строго говоря, касается далеко не только IT. Слой в три медиатора вполне надежно блокирует практически любую обратную связь от низов к верхам, будь то айтишники, продажники или кладовщики.
В испорченный телефон играли в детстве? Вот то-то.
Но это, строго говоря, касается далеко не только IT. Слой в три медиатора вполне надежно блокирует практически любую обратную связь от низов к верхам, будь то айтишники, продажники или кладовщики.
На моей уже теперь прошлой работе структура была такова: я (ведущий специалист) — начальник отдела (мне с ним повезло) — начальник управления — 1 зам главного — главный (подпишет документы если 1 зам поддержал).
Так вот если связь я-мой_начальник все прекрасно, в некоторых случаях я мог запросто выйти на связи я-начальник_управления, но вот начальник_управления и дальше, когда речь шла о чем-то глобальном чаще никуда не поднималось, выйти на связь я-1зам или мой_начальник-1зам практически нереально. Так что порой слой в 1 медиатор уже останавливал дальнейшее возможное обсуждение проблемы на уровне, где могут выделить финансирование. А мой выход за пределы связи я-начальник_управления считался бы «предательством», попыткой показать несостоятельность оного и пр.
Так вот если связь я-мой_начальник все прекрасно, в некоторых случаях я мог запросто выйти на связи я-начальник_управления, но вот начальник_управления и дальше, когда речь шла о чем-то глобальном чаще никуда не поднималось, выйти на связь я-1зам или мой_начальник-1зам практически нереально. Так что порой слой в 1 медиатор уже останавливал дальнейшее возможное обсуждение проблемы на уровне, где могут выделить финансирование. А мой выход за пределы связи я-начальник_управления считался бы «предательством», попыткой показать несостоятельность оного и пр.
В некоторых (впрочем чаще, чем хотелось бы, встречающихся) случаях для блокировки любого разумного обсуждения вполне хватает связи начальник-подчиненный. Просто с моей кочки зрения три медиатора эффективно блокируют любую связь всегда. Кроме, возможно, случаев принятия очень специальных мер, направленных на недопущение подобного.
Гмм…
Ну вот скажем, флотская традиция (уж не знаю, есть ли она на самом деле, но в фольклоре есть, а значит, для примера годится) устраивать общие советы, и на них сначала выслушивать младших по званию. Ее, разумеется, тоже можно выхолостить десятком способов.
Гмм…
Ну вот скажем, флотская традиция (уж не знаю, есть ли она на самом деле, но в фольклоре есть, а значит, для примера годится) устраивать общие советы, и на них сначала выслушивать младших по званию. Ее, разумеется, тоже можно выхолостить десятком способов.
Именно так, своими глазами наблюдал как чуть не умерли два проекта, во главе которых был поставлен прекрасный, очень талантливый и деятельный, опытнейший «сеньор», который всё губил техническим перфекционизмом и тщательным огораживанием разработчиков от всякого давления извне. Создавал, вроде как, чудесный мир, где кодеры делают идеальный продукт (веки вечные).
Да, хотя полагаю, посыл тут несколько иной. «Эффективный сеньор» хотя бы какие-то прикладные задачи выполнит, иначе его низкая производительность будет наглядна и его уволят. А как оценить производительность сотрудника, задача которого — придумать попугаи и оценивать в них других сотрудников?
Плюсую. Видел эффективных разработчиков, из разряда — нужны новые технологии: модно, молодежно, современно с результатом… а как теперь все это поддерживать…
Ну хорошо, «эффективных менеджеров» обсмеяли, но как быть с эффективными менеджерами, они существуют? Они нужны компании? И как их отличить от «эффективных менеджеров», где их найти?
По статье создалось впечатление, что на роль менеджеров нужно брать хороших тимлидов, буквально переводить инженера в чистые руководители. Тут тоже вопросы, во-первых, на кой чёрт человеку с большим опытом и налаженной работой уходить в управление, менять сферу деятельности? Во-вторых, кто вам сказал, что он будет с этим хорошо справляться?
Для правильного понимания современных подходов к управлению разработкой и управлению вообще нужно в первую очередь избавляться от комплекса «подчинённый-начальник». Так, например, не надо все менеджерские позиции считать «начальственными». Не надо требовать от хорошего администратора навыков разработки. Тимлид, и даже рядовой разработчик, ВСЕГДА должен быть более квалифицированным инженером, чем, к примеру, менеджер проекта, потому что каждый должен быть на своём месте и хорошо делать именно свою работу. (И влияние в компании он тоже может иметь значительно большее.)
Вот метрики, взятые с потолка, или разрыв горизонтальных связей в компании — это просто плохо сделанная управленческая работа. Плохой сотрудник он и в Африке плохой, будь он менеджер или инженер.
По статье создалось впечатление, что на роль менеджеров нужно брать хороших тимлидов, буквально переводить инженера в чистые руководители. Тут тоже вопросы, во-первых, на кой чёрт человеку с большим опытом и налаженной работой уходить в управление, менять сферу деятельности? Во-вторых, кто вам сказал, что он будет с этим хорошо справляться?
Для правильного понимания современных подходов к управлению разработкой и управлению вообще нужно в первую очередь избавляться от комплекса «подчинённый-начальник». Так, например, не надо все менеджерские позиции считать «начальственными». Не надо требовать от хорошего администратора навыков разработки. Тимлид, и даже рядовой разработчик, ВСЕГДА должен быть более квалифицированным инженером, чем, к примеру, менеджер проекта, потому что каждый должен быть на своём месте и хорошо делать именно свою работу. (И влияние в компании он тоже может иметь значительно большее.)
Вот метрики, взятые с потолка, или разрыв горизонтальных связей в компании — это просто плохо сделанная управленческая работа. Плохой сотрудник он и в Африке плохой, будь он менеджер или инженер.
Разница между «эффективным менеджером» и эффективным менеджером в том, что первые знают и делают только то, что полезно для них самих, а вторые — то что полезно для продукта и команды. Это более чем очевидно.
Таким образом, статья сводится к тезису: «Не нанимайте плохих сотрудников — это плохо скажется на вашем бизнесе. Мы в компании Crossover советуем вам нанимать хороших сотрудников».
Статья сводится к тому, что найм людей из вне на руководящие позиции — щекотливый и крайне сложный процесс и «чудес» в этой сфере не бывает. Потому что как только HR или владелец начинает верить в чудеса и в спешке затыкать кадровые дыры, в коллектив просачивается «эффективный менеджмент» (делаю акцент на кавычках).
Лично я видел, как подобным образом была, фактически, разрушена одна крупная и известная компания (за полгода административный аппарат был увеличен на порядок с подачи нескольких новых «топов» со стороны), а еще одна — парализована. Ну и плюс в разных стадиях находится половина организаций, с которыми я соприкасался.
Лично я видел, как подобным образом была, фактически, разрушена одна крупная и известная компания (за полгода административный аппарат был увеличен на порядок с подачи нескольких новых «топов» со стороны), а еще одна — парализована. Ну и плюс в разных стадиях находится половина организаций, с которыми я соприкасался.
в разных стадиях находится половина организаций, с которыми я соприкасался.{sarcasm} Звучит весьма зловеще… {/sarcasm}
В текущей конторе, начальником сделали челрвека весьма шустрого и работящего.
Но через полгода он мутировал в обсуждаемое… и начал повсюду хвастаться что первое образование у него — экономическое.
Основной принцип: ' рпботает, не трожь'. Поэтому станки третий год без внятного ТО и капиталки. Вспомогательные инструменты покупаются по году-два. Люди ищутся в последний момент, когда они нужны 'вчера'. Планирование смен от балды. И т.д.
Лично я работал в трёх конторах и наблюдал работу (д)эффективных менеджеров в различных вариациях.
Но через полгода он мутировал в обсуждаемое… и начал повсюду хвастаться что первое образование у него — экономическое.
Основной принцип: ' рпботает, не трожь'. Поэтому станки третий год без внятного ТО и капиталки. Вспомогательные инструменты покупаются по году-два. Люди ищутся в последний момент, когда они нужны 'вчера'. Планирование смен от балды. И т.д.
Лично я работал в трёх конторах и наблюдал работу (д)эффективных менеджеров в различных вариациях.
«Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по-своему.»
Вы описали только одно несчастье и сделали из него кликбейтный заголовок.
Вы описали только одно несчастье и сделали из него кликбейтный заголовок.
Но ведь «эффективные менеджеры», развалившие эти крупные компании, были наняты каким-то руководителем? Может быть это говорит о том, что самое топ-руководство плохое, если они допустили, что назначенные ими люди развалили компанию? И такая компания в любом случае обречена.
Вы же пишете, что «начальник отвечает головой за косяки своих подчиненных». Так значит фактически виноваты не «эффективные менеджеры», а их начальник?
Вы же пишете, что «начальник отвечает головой за косяки своих подчиненных». Так значит фактически виноваты не «эффективные менеджеры», а их начальник?
И как их отличить от «эффективных менеджеров», где их найти?
Очень просто — эффективный менеджер, в отличии от "эффективного менеджера", четко понимает, что сам по себе не является непосредственным участником производственного процесса и, т.о., является обслуживающим персоналом. "Эффективный менеджер" же считает строго наоборот — полагает главным себя, а обслуживающим персоналом считает тех людей, которые непосредственно производят продукт.
Это примерно как "власть — слуга народа". Та власть, которая это понимает — это хорошая, годная власть. Эффективный менеджер. А которая не понимает — плохая, негодная власть. "Эффективный менеджер". Для такой власти народ — слуги
По-моему как раз с «начальственностью» у разного рода варягов нет проблем: они считают себя исполнительным механизмом, работающим по какому-то «платиновому» алгоритму, описанному в толстых учебниках. В действительности и среди разработчиков полно тех, кто пишет код, руководствуясь не условиями задачи и реальными сроками, а некими околорелигиозными представлениями о «лучших практиках». При этом разработчик боится быть непонятым и неооцененным гипотетическими виртуальными коллегами, которые когда нибудь «будут править его код», но не боится не выполнить работу в срок или выполнить не все требования заказчика или выполнить их неверно, скорректировав по пути удобным для себя образом. Точно так же и менеджеры, руководствующиеся в своей деятельности формальными алгоритмами очень часто не видят вообще компанию как таковую, а видят только соответствие или несоответствие неких показателей, действуя словно по универсальной инструкции для настройки уникального механизма. Точно так же и у велосипедного мастера, который будет настраивать по стандартным инструкциям производителей далеко не новый велосипед, претерпевший за время эксплуатации множество изменений — результаты будут в лучшем случае очень средними, но скорее всего — они будут ниже среднего.
Но относительно спорности того момента, что руководитель разработчиков обязан сам быть разработчиком лучше тех, кем руководит — полностью согласен. У менеджера своя сфера деятельности, и я не думаю, что сами разработчики будут рады, если управленец будет на полном серьёзе пытаться постоянно контролировать и выносить какие-то суждения относительно internals разработки программного продукта, при этом являясь даже не тимлидом группы, а начальником отдела, например.
Но относительно спорности того момента, что руководитель разработчиков обязан сам быть разработчиком лучше тех, кем руководит — полностью согласен. У менеджера своя сфера деятельности, и я не думаю, что сами разработчики будут рады, если управленец будет на полном серьёзе пытаться постоянно контролировать и выносить какие-то суждения относительно internals разработки программного продукта, при этом являясь даже не тимлидом группы, а начальником отдела, например.
Всё правильно говорите. Но я бы добавил, что всё-таки часто проблема на другой стороне. Какой-нибудь заслуженный разработчик видит, что на роль менеджера назначили «девочку» или «мальчика», который никогда не писал промышленный код, и его оскорбляет, что теперь он находится «под началом» какого-то салаги.
Я даже пытался об этом напрямую говорить с некоторыми людьми, как разработчик с разработчиком, но этот стереотип сложно перешагнуть. Такие люди могут просто саботировать работу в новой системе: игнорировать совещания или отмахиваться от любой коммуникации.
Хотя это конечно тоже во многом сфера ответственности нового менеджера, как он сам себя сразу же позиционирует. Это отдельная история.
Я даже пытался об этом напрямую говорить с некоторыми людьми, как разработчик с разработчиком, но этот стереотип сложно перешагнуть. Такие люди могут просто саботировать работу в новой системе: игнорировать совещания или отмахиваться от любой коммуникации.
Хотя это конечно тоже во многом сфера ответственности нового менеджера, как он сам себя сразу же позиционирует. Это отдельная история.
Любое совещание и прочая коммуникация занимает время. Если это потраченное время не приблизило к выполнению поставленной задачи, то оно потрачено впустую.
В любом айти-проекте существует множество задач, и не все они связаны с разработкой. Иногда от разработчика требуется что-то пояснить менеджеру, например для того, чтобы он грамотно отбился от претензий заказчика, и дал разработчику спокойно продолжать работу. Плохо, если даже в такой ситуации он говорит менеджеру: «ты тупой, поэтому я тебе ничего не буду объяснять».
> По-моему как раз с «начальственностью» у разного рода варягов нет проблем: они считают себя исполнительным механизмом, работающим по какому-то «платиновому» алгоритму, описанному в толстых учебниках.
Важно, как они этот механизм позиционируют. А позиционируют они его как нечто, что все остальные участники должны обслуижвать.
Важно, как они этот механизм позиционируют. А позиционируют они его как нечто, что все остальные участники должны обслуижвать.
Это вы сейчас Россию описали.
Нет, хороших менеджеров конечно же мало, но…
Всю свою сознательную профессиональную деятельность лицезрею компании, избегающие «эффективных менеджеров», продвигающие своих лучших технарей на управляющие должности и тд. Все всегда идет по накатанному сценарию:
1. Технари вместо налаживания процессов и внедрения метрик нужных для грамотной оценки эффективности команды, занимаются внедрением технологий, кучи ненужных показателей, методологий разработки. «Доверить внедрение внутренних метрик команде аналитиков? Хахахаха!...»
2. Отделы между собой общаются как хотят, когда хотят и сколько хотят, пресекая на корню любую возможность выстроить хоть какое-то подобие процессов и планирование. Возникает масса параллельных планов, приоритетов, которые ведут к нерациональному распоряжению ресурсами.
3. Дедлайны вечно сорваны. Все проблемы, к которым компания приходит в результате отсутствия планирования, «эффективного менеджмента» и приоритезации, решаются авральными субботниками, перегоревшими технарями, критическими ошибками в продуктах.
4. Предложения и изменения в процессы, предложенные «эффективными менеджерами» отклоняются, игнорируются, команда саботирует следование инструкциям. В итоге «эффективных менеджеров» тыкают носами в несовершенство их представлений о процессах разработки, рассказывают про «решение проблем по мере их поступления» и «у нас тут суровая реальность, а не ваше МБА!».
Скорбь.
Всю свою сознательную профессиональную деятельность лицезрею компании, избегающие «эффективных менеджеров», продвигающие своих лучших технарей на управляющие должности и тд. Все всегда идет по накатанному сценарию:
1. Технари вместо налаживания процессов и внедрения метрик нужных для грамотной оценки эффективности команды, занимаются внедрением технологий, кучи ненужных показателей, методологий разработки. «Доверить внедрение внутренних метрик команде аналитиков? Хахахаха!...»
2. Отделы между собой общаются как хотят, когда хотят и сколько хотят, пресекая на корню любую возможность выстроить хоть какое-то подобие процессов и планирование. Возникает масса параллельных планов, приоритетов, которые ведут к нерациональному распоряжению ресурсами.
3. Дедлайны вечно сорваны. Все проблемы, к которым компания приходит в результате отсутствия планирования, «эффективного менеджмента» и приоритезации, решаются авральными субботниками, перегоревшими технарями, критическими ошибками в продуктах.
4. Предложения и изменения в процессы, предложенные «эффективными менеджерами» отклоняются, игнорируются, команда саботирует следование инструкциям. В итоге «эффективных менеджеров» тыкают носами в несовершенство их представлений о процессах разработки, рассказывают про «решение проблем по мере их поступления» и «у нас тут суровая реальность, а не ваше МБА!».
Скорбь.
Это у нас первый стул, а второй — 3 администратора на 1 девелопера. Две крайности.
3 администратора на 1 девелопера
Это может быть вполне рабочая и очень даже эффективная схема. Смотреть нужно по потребностям бизнеса.
Можете привести пример, когда это оправдано потребностями?
Когда сверху требуют трёх отчетов каждый день на каждого разработчика :)
Любая высокотехнологичная среда, котора кроме всего прочего регулируется кучей юридической, интерпрайз или другой подобной мути. Когда разработчика необходимо оградить от работы, которой он не должен заниматься. Когда предметная область продукта гораздо сложнее цэ рэ эм или интернет магазина. Чаще всего это продукты, которые должны пройти кучу регуляторики.
UFO just landed and posted this here
Я специально не стал описывать более банальную ситуацию.
De jure так в любой компании. Но, по факту, со временем при любом подобии стабильности в компании, где менеджеров и разработчиков больше одного, начинаются процессы упрощения коммуникаций. Цепочка менеджер-тл-разработчик превращается в менеджер-разработчик, и значительный пул задач начинает лететь минуя непосредственных руководителей, причем, нередко с согласия этих самых руководителей. Причем, параллельно могут выстраиваться совершенно разные процессы, подходы, методологии. Пока есть видимый результат и позитивный опыт, никто не лезет в эту саморегулирующуюся среду. Тыкаешь носом в реальную схему — кивают головами, мол «плохо, неправильно, нужно что-то делать», но работает же.
Не считаю, кстати, это чем-то плохим. Если руководители действительно грамотные, то они не мешают подобному. Все что нужно — формализировать коммуникации, покрыть метриками процесс и поглядывать, чтоб откровенной фигни не делали.
но у конкретного разработчика — должен быть 1 руководитель
De jure так в любой компании. Но, по факту, со временем при любом подобии стабильности в компании, где менеджеров и разработчиков больше одного, начинаются процессы упрощения коммуникаций. Цепочка менеджер-тл-разработчик превращается в менеджер-разработчик, и значительный пул задач начинает лететь минуя непосредственных руководителей, причем, нередко с согласия этих самых руководителей. Причем, параллельно могут выстраиваться совершенно разные процессы, подходы, методологии. Пока есть видимый результат и позитивный опыт, никто не лезет в эту саморегулирующуюся среду. Тыкаешь носом в реальную схему — кивают головами, мол «плохо, неправильно, нужно что-то делать», но работает же.
Не считаю, кстати, это чем-то плохим. Если руководители действительно грамотные, то они не мешают подобному. Все что нужно — формализировать коммуникации, покрыть метриками процесс и поглядывать, чтоб откровенной фигни не делали.
Современные представления об управлении считают иначе.
В матричной структуре у разработчика может быть руководитель подразделения (строго говоря, это он и будет «одним руководителем», с которым он будет беседовать про зарплату, отдельный кабинет и повышение квалификации), однако, при этом задачи он будет получать от менеджера проекта и планированием его работ тоже будет заниматься менеджер. И такая система кстати неплохо работает в ряде случаев.
Больше того, сейчас считается модным работать по agile, в котором по определению не будет ТЗ или его заменителя, потому что communication over documentation.
В матричной структуре у разработчика может быть руководитель подразделения (строго говоря, это он и будет «одним руководителем», с которым он будет беседовать про зарплату, отдельный кабинет и повышение квалификации), однако, при этом задачи он будет получать от менеджера проекта и планированием его работ тоже будет заниматься менеджер. И такая система кстати неплохо работает в ряде случаев.
Больше того, сейчас считается модным работать по agile, в котором по определению не будет ТЗ или его заменителя, потому что communication over documentation.
Матричная структура – вообще неработоспособная система, по моему опыту. Кто платит, тот и заказывает музыку. А платить в таком случае де-факто будет именно менеджер проекта. Поэтому всё это приводит к тому, что просто начинают совмещать обязанности руководителя подразделения и проекта.
Не будем даже углубляться в то, что не любая деятельность имеет проектный характер.
Не будем даже углубляться в то, что не любая деятельность имеет проектный характер.
По вашему опыту одно, а по моему опыту другое. Любая оргструктура, как и любая методология, имеют свои сильные и слабые стороны, что-то лучше работает в одном случае, что-то в другом. Поэтому любые общие утверждения на этот счёт всегда вызывают улыбку.
Что касается «совмещения обязанностей» — такого не будет, потому что у руководителя есть свои рычаги управления. Да, это недостаток матричной структуры — сложность для менеджеров и руководителей, им надо чётко разобраться где чья юрисдикция, им надо много общаться, но здесь и плюсы.
Уж если в компании проектная деятельность (а в айти такое часто, пусть даже это не внешний заказчик), то матричная структура складывается буквально сама собой, потому что даёт фокус на результат проекта, при этом оставляет и традиционную иерархию, привычную и даже требуемую некоторыми отраслевыми стандартами.
Что касается «совмещения обязанностей» — такого не будет, потому что у руководителя есть свои рычаги управления. Да, это недостаток матричной структуры — сложность для менеджеров и руководителей, им надо чётко разобраться где чья юрисдикция, им надо много общаться, но здесь и плюсы.
Уж если в компании проектная деятельность (а в айти такое часто, пусть даже это не внешний заказчик), то матричная структура складывается буквально сама собой, потому что даёт фокус на результат проекта, при этом оставляет и традиционную иерархию, привычную и даже требуемую некоторыми отраслевыми стандартами.
UFO just landed and posted this here
UFO just landed and posted this here
Лучший способ избежать найма эффективного менеджера — искать на должность руководителя технических команд именно технического специалиста. Это снимает как минимум вопросы с адекватностью выставления метрик, понимания процесса разработки и конфликта интересов, когда подчиненные более квалифицированы, чем их новый начальник.
Вот это еще не понравилось. Во-первых, у технарей все очень плохо с аналитикой. У всех, кроме аналитиков, плохо с аналитикой. Есть отдельные талантливые ребята — исключение из правил, — но в управлении не принято ориентироваться на исключения.
Эм. что за уникальные способности нужны для «аналитике», что у всех технарей с этим проблемы?
Здоровый пессимизм.
Такие же, какие нужны врачам, чтоб лечить, летчикам, чтоб управлять самолетами, инженерам НАСА — строить аппараты, которые летят за много сотен тысяч километров, чтоб исследовать космос. Да, палец себе перебинтовать или выпить таблетку парацетамола вы сможете, но удалить аппендицит или провести коррекцию зрения — нет. То же самое с аналитикой. Хороший программист сможет покрыть метриками систему и анализировать ее состояние, но когда речь идет большом сложном бизнесе, больших объемах, сложных схемах монетизации, больших периодах, заниматься этим должны те, кто к этому готовился. Амазон почему-то команду аналитиков набирал из ученных.
Какае-то концентрированная чушь. Во-первых в оригинале вы говорили о технарях, а не о программистах. Во-вторых, программисты не могут управлять самолетом? те научился программировать и все? а я как раз хотел в летное пойти, беда.
С точки зрения технаря/программиста/врача и тд — можно научиться и летать на самолете, и стать аналитиком и даже научиться оперировать. При наличии времени и желания можно освоить любой навык. Вы оцениваете это именно с такой позиции.
С точки зрения управленца — я не пущу за штурвал А-320 программиста или врача, как и не доверю без крайней необходимости оперировать пациентов инженеру НАСА или программисту. Из врача тоже так себе проектировщик лунной базы получится. Естественно, всех их можно пустить за штурвал Цесны, если они прошли летную школу. Как и намазать друг-другу лоб зеленкой.
Если у компании небольшой интернет магазин, статистикой и аналитикой может заниматься любой толковый сотрудник. Если у компании задача — подвинуть Амазон, то команду аналитиков ей следует искать в университетах. Среди научных степеней. Это стратегия управленца.
С точки зрения управленца — я не пущу за штурвал А-320 программиста или врача, как и не доверю без крайней необходимости оперировать пациентов инженеру НАСА или программисту. Из врача тоже так себе проектировщик лунной базы получится. Естественно, всех их можно пустить за штурвал Цесны, если они прошли летную школу. Как и намазать друг-другу лоб зеленкой.
Если у компании небольшой интернет магазин, статистикой и аналитикой может заниматься любой толковый сотрудник. Если у компании задача — подвинуть Амазон, то команду аналитиков ей следует искать в университетах. Среди научных степеней. Это стратегия управленца.
Вы не поверите, каким навыками обязаны обладать космонавты или работники арктических станций.
Как минимум, для простого инженера оперативное лечения аппендицита не должно представлять трудности.
Как минимум, для простого инженера оперативное лечения аппендицита не должно представлять трудности.
Как минимум, для простого инженера оперативное лечения аппендицита не должно представлять трудности.
Простите, а можно пруф? Особенно про космонавтов интересует, но и про полярников сойдет.
Вы не поверите, каким навыками обязаны обладать… работники арктических станций.Как зимовавший на станции в Заполярье, с интересом жду списка навыков.
Вы удивитесь, но аналитиков для амазона нужен один отдел на всю планету. Боюсь большинство аналитиков никогда с задачами такого масштаба не сталкивались и не столкнуться. А если взять задачи типового аналитика, то толковый разработчик их вполне закрывает.
Я бы даже сказал — у большинства аналитиков проблемы с аналитекой.
Наблюдаю/наблюдал такие картины как там, где продвигают технарей, так и там где ставят PMP и MBA. И обратное так же и в том и в другом случае.
Рыба гниет с головы. Хорошо, что на место умершего бизнеса всегда придет новый. До тех пор пока все не станет одной огромной монополией.
Рыба гниет с головы. Хорошо, что на место умершего бизнеса всегда придет новый. До тех пор пока все не станет одной огромной монополией.
По пункту 2 вопрос: у вас процессы регламентируют общение между командами? Но как и зачем?
Сначала отвечу на вопрос зачем. Опишу очень простую ситуацию.
Есть у вас компания, состоящая из команды менеджеров, и команды разработчиков.
менеджеры ставят задачи, разработчики из решают.
Каждый менеджер ставит задачи по своему — один просто пишет в таск трекер «ничего не работает», второй описывает избыточно, теряется суть того, что нужно сделать. Третий не читает задачи коллег, и описывает требования, противоречащие имеющейся бизнес-логике. Кроме того, у каждого свой приоритет. Кроме того, менеджеры при постановке задач идут к разработчику напрямую, не зная, работает ли он над чем-то, отвлекая его от текущих задач.
В результате — разработчики злые и уставшие, потому что нужно постоянно уточнять условия задач, отрываться от текущей работы, чтоб оценить новые таски, ругаться с коллегами, при возникновении конфликтов в бизнес-логике. Команда тратит время технических специалистов на то, чтоб привести описание задачи к виду, в котором понятно, что нужно делать. Это если тех команда очень хорошая. Могут ведь и не уточнять, а делать как понимают. Это обычная ситуация в небольших быстро развивающихся it командах.
А теперь добавьте сюда тестировщиков, аналитиков, маркетинг, сейлз, системных администраторов, юристов. Коммуникации усложняться, процент проблем и задержки во времени вырастут многократно. Я ответил на вопрос, зачем?
Как это можно регулировать, чтоб облегчить жизнь компании? Просто — регламент общения.
Команда менеджеров предоставляет разработчикам задачи в определенном формате, который описан в документации компании. Например, задача должна иметь четкий приоритет, бриф, описание того, что именно нужно сделать, как оно должно выглядеть, описание требований, дедлайны. Задачи команде разработки должны не сыпаться на голову как снег, а приходить в определенное время, когда разработчики не занятые работой. Тимлид разработчиков регулирует этот процесс, следит за правильностью оформления, актуальностью дедлайнов, валидацией требований.
Все то же самое распространяется и на остальные команды. Каждая имеет свой уникальный «интерфейс» или «протокол» — вид, в котором информация должна поступать в команду, чтоб команда работала эффективно. Разработчикам нужно понятное описание задач, приоритеты и время, когда их никто не будет отвлекать. Тестировщикам — описание, что тестировать, как. Системным администраторам — внятные требования к инфраструктуре, которую нужно построить, бюджет.
Регламент должен прописываться в документации компании — инструкции, должностные обязанности, зоны отвественности. Конечно, необходимо избегать бюрократизма. Регуляторика не должна мешать функционированию компании. Требования следует устанавливать минимально необходимые, для получения результата.
И да, это не поможет, если топ менеджмент компании не заинтересован в повышении эффективности.
Есть у вас компания, состоящая из команды менеджеров, и команды разработчиков.
менеджеры ставят задачи, разработчики из решают.
Каждый менеджер ставит задачи по своему — один просто пишет в таск трекер «ничего не работает», второй описывает избыточно, теряется суть того, что нужно сделать. Третий не читает задачи коллег, и описывает требования, противоречащие имеющейся бизнес-логике. Кроме того, у каждого свой приоритет. Кроме того, менеджеры при постановке задач идут к разработчику напрямую, не зная, работает ли он над чем-то, отвлекая его от текущих задач.
В результате — разработчики злые и уставшие, потому что нужно постоянно уточнять условия задач, отрываться от текущей работы, чтоб оценить новые таски, ругаться с коллегами, при возникновении конфликтов в бизнес-логике. Команда тратит время технических специалистов на то, чтоб привести описание задачи к виду, в котором понятно, что нужно делать. Это если тех команда очень хорошая. Могут ведь и не уточнять, а делать как понимают. Это обычная ситуация в небольших быстро развивающихся it командах.
А теперь добавьте сюда тестировщиков, аналитиков, маркетинг, сейлз, системных администраторов, юристов. Коммуникации усложняться, процент проблем и задержки во времени вырастут многократно. Я ответил на вопрос, зачем?
Как это можно регулировать, чтоб облегчить жизнь компании? Просто — регламент общения.
Команда менеджеров предоставляет разработчикам задачи в определенном формате, который описан в документации компании. Например, задача должна иметь четкий приоритет, бриф, описание того, что именно нужно сделать, как оно должно выглядеть, описание требований, дедлайны. Задачи команде разработки должны не сыпаться на голову как снег, а приходить в определенное время, когда разработчики не занятые работой. Тимлид разработчиков регулирует этот процесс, следит за правильностью оформления, актуальностью дедлайнов, валидацией требований.
Все то же самое распространяется и на остальные команды. Каждая имеет свой уникальный «интерфейс» или «протокол» — вид, в котором информация должна поступать в команду, чтоб команда работала эффективно. Разработчикам нужно понятное описание задач, приоритеты и время, когда их никто не будет отвлекать. Тестировщикам — описание, что тестировать, как. Системным администраторам — внятные требования к инфраструктуре, которую нужно построить, бюджет.
Регламент должен прописываться в документации компании — инструкции, должностные обязанности, зоны отвественности. Конечно, необходимо избегать бюрократизма. Регуляторика не должна мешать функционированию компании. Требования следует устанавливать минимально необходимые, для получения результата.
И да, это не поможет, если топ менеджмент компании не заинтересован в повышении эффективности.
Возможно стоит добавить к рассматриваемой гепотезе, что появление «менеджеров» свойственно не только для этапа роста компаний.
Из наблюдений предполагаю, что финальной точкой назначения «эффективных менеджеров» являются технологически сложные крупные компании с государственной долей участия. Так как там негативный эффект управляния «менеджерами» нивелируется финансовой гос. поддержкой разного рода.
Из наблюдений предполагаю, что финальной точкой назначения «эффективных менеджеров» являются технологически сложные крупные компании с государственной долей участия. Так как там негативный эффект управляния «менеджерами» нивелируется финансовой гос. поддержкой разного рода.
UFO just landed and posted this here
У государственной компании гораздо реже возникают те проблемы, для решения которых руководство привлекает «эффективных менеджеров». Как правило, именно в государственных предприятиях можно видеть технический заповедник, когда люди просто решают свои задачи и мало обеспокоены бизнес-эффективностью этого процесса. Деятельность сотрудников госпредприятий вообще редко имеет проектные формы. Поэтому «эффективные менеджеры» — обычно явление чисто коммерческое.
Дочитал-таки до конца. То же самое, но кратко:
* выгоднее управленцев выращивать;
* управленец всегда должен быть уровня 1-й категории (сеньоры) с большим опытом работы;
* должно поощряться любое взаимодействие внутри компании (в том числе между разными отделами);
* обоснованные метрики должны быть основаны на разных параметрах и не должны быть беспрекословными;
* больше менеджеров — не значит лучше.
По большей части согласен, но статья слишком негативная. И от себя добавлю, что у разработчиков уровня 1-ой категории должна быть определённая доля свободы в принятии решений при разработке, вплоть до сдвига сроков разработки отдельных функций для реализации других или отказа от их реализации в предложенном виде на данном этапе разработки.
* выгоднее управленцев выращивать;
* управленец всегда должен быть уровня 1-й категории (сеньоры) с большим опытом работы;
* должно поощряться любое взаимодействие внутри компании (в том числе между разными отделами);
* обоснованные метрики должны быть основаны на разных параметрах и не должны быть беспрекословными;
* больше менеджеров — не значит лучше.
По большей части согласен, но статья слишком негативная. И от себя добавлю, что у разработчиков уровня 1-ой категории должна быть определённая доля свободы в принятии решений при разработке, вплоть до сдвига сроков разработки отдельных функций для реализации других или отказа от их реализации в предложенном виде на данном этапе разработки.
Все верно. По последнему абзацу — это все же немного другое. На эту тему можно целую серию постов запустить, потому что в одну калитку это банально не пролезет. Вообще самый адекватный менеджмент по моему опыту — это когда руководитель среднего звена может влиять на сроки и задачи от вышестоящих менеджеров и обоснованно высказывать недоверие к задачам/срокам и или при наличии оснований инициировать их изменение в адекватную сторону. То есть обеспечивать вертикальную связь, а не просто быть погонщиком с плетью или мартышкой, пишущей отчеты.
Просто в статье высмеивается найм профессионалов вместо подготовки кадров:
Но не из всех программистов 3-й категории (junior) может получиться 2-я или 1-я, либо на это потребуется очень много времени. Многое зависит от черт характера и мотивации. Средств тратится на обучение иногда много, в то время как найм нескольких программистов 1-й категории на высокую заработную плату в очень долгосрочной перспективе может окупить работу пары десятков программистов 3-й категории.
В терминальных стадиях это может выражаться в постулате «лучших людей можно и нужно нанять, нам некогда готовить своих».
Но не из всех программистов 3-й категории (junior) может получиться 2-я или 1-я, либо на это потребуется очень много времени. Многое зависит от черт характера и мотивации. Средств тратится на обучение иногда много, в то время как найм нескольких программистов 1-й категории на высокую заработную плату в очень долгосрочной перспективе может окупить работу пары десятков программистов 3-й категории.
Просто в статье высмеивается найм профессионалов вместо подготовки кадров
Я своими глазами видел этот постулат в действии. Он означал полную остановку профессионального роста уже нанятых специалистов и вместо повышений даже на одну ступень — 100% найм со стороны. Также это сопровождалось возросшей текучкой, потому что вместе с «мы можем нанять» фоном шла установка «мы никого не держим и не считаем ресурсы, потраченные на сотрудника».
То, что Вы описываете, просто ещё одна крайность. Готовить кадры нужно, но найм этому не помеха, по крайней мере не должен быть и может не быть помехой.
Ну и далеко не каждый сеньор хочет переквалифицироваться в управленцы, даже если может, и даже если компании это было бы выгодно.
В этом вопросе полностью солидарен. Компания должна предоставлять все средства для повышения квалификации персонала и максимально к этому мотивировать.
Внутри тоже «рождаются менеджеры». Их нужно замечать и выдвигать. Но процесс этот должен быть осмысленным, таким же как и найм. Именно для этого есть служба HR. Зачастую, если хочешь испортить хорошего разработчика — сделай его начальником. Но, если он сам этого хочет, готов прокачиваться в этом направлении, изучает тему, то тут нужно помогать, направлять, так, чтобы он был успешен. Если ты не будешь ему помогать, цель его от этого не изменится. Просто он уйдет в другую компанию, в которой на него будут смотреть иначе. В общем, нет универсального решения.
управленец всегда должен быть уровня 1-й категории (сеньоры) с большим опытом работы
Это красиво звучит, но через какой промежуток времени, оторванный от разработки управленец с высоким уровнем профессионализма, потеряет свой уровень в разработке? Так что опять таки спорный тезис.
Это красиво звучит, но через какой промежуток времени, оторванный от разработки управленец с высоким уровнем профессионализма, потеряет свой уровень в разработке?
Я не использовал волновой алгоритм уже около 13 лет. Я до сих пор помню, как он реализуется. Примерно столько же я не программировал на Turbo Pascal, но если мне дадут его, то я без проблем напишу требуемую программу. Я даже до сих пор помню, что команда очистки экрана называется примерно `clrscr();` из модуля `CRT`. И я не гуглил, чтобы подглядеть (поэтому не гарантирую, что правильно). И вот зачем мне сейчас знать, что разрешение EGA или CGA около 320x200? Это при том, что паскалеподобные языки я не использую давным давно, а информация того времени мне уже вообще не нужна.
Профессиональная специализация — это то, что очень хорошо заседает в голове, вряд ли её получится оттуда убрать даже, если захочется.
Проблема менеджера будет скорее в выгорании из-за намного менее интересной работы. На этот случай можно было бы ввести практику поощрения перемещения по должностям с постоянной подготовкой новых менеджеров из сеньоров. Это и повышение квалификации программистов, и гарантия, что не потребуется срочно в панике искать нового менеджера проекта.
Управленец скорее не потеряет уровень в разработки, а просто отстанет от быстро меняющихся технологий. Но опять же решается или периодическим повышением квалификации, или свободными перемещениями по карьерной лестнице.
Первая половина статьи шикарная, узнал ребят, которые успешно развалили компанию, в которой работал. Но вторая половина получилась скомканая и неоднозначная.
Потому что однозначного решения этой проблемы нет. Как писали выше — синьоры без менеджеров идут в разнос и кодят ради кода, слишком много администрации — стагнация и упадок. Рассматривать все варианты развития событий в одной статье минимум глупо, потому что простыня.
Вы случайно не про лучшего хостинг-провайдера из СПб?)
Мы все их узнали.
UFO just landed and posted this here
Хороший руководитель — это иной взгляд на жизнь, чем взгляд хорошего специалиста. Это работа с людьми, живыми. Это способность ИХ ПОНИМАТЬ и это более крутая способность, чем понимать ЧТО-ТО… Крутые, уважаемые коллегами и подчиненными, руководители должны заниматься выращиванием руководителей, так же как более крутые специалисты растят менее крутых. Для этого они должны много беседовать и передавать знания, целенаправленно развивая подходящего потенциального преемника.
Но это всё применимо к хорошей компании, где нет подковерных интриг, борьбы за власть и т.п.
Пока человеческая природа не изменится, всё это будет в любой компании больше 10 человек (и это довольно оптимистичная оценка, в реальности, думаю, человек от 5-7).
Это способность ИХ ПОНИМАТЬ и это более крутая способность, чем понимать ЧТО-ТО…
Не согласен, что более крутая. Их невозможно сравнивать. Крутой технический специалист такая же редкость, как и крутой менеджер. Просто мозги у них свернуты в разную сторону, у каждого в свою. Но почему-то сложилось мнение, что менеджером (как и риэлтором или психологом) может стать любой дурак, кто больше ничего не умеет.
Полностью с Вами согласен. В одной компании с нуля запускали крупный проект небольшой командой менее 20 человек. Руководитель одного из отделов был опытный сотрудник и это была его первая руководящая должность. Как только проект начал работать по накатанной, начали разрастаться отделы и потребовались дополнительные сотрудники. Вот тут и проявился «эффективный менеджер». По ему одному известной причине, деление отдела было произведено не в иерархическом порядке с распределением обязанностей по принципу «каждый сотрудник может заменить любого другого», а таким образом, что одни копаются в бумажках и ничего не знают об операционной деятельности, а операционка ничего не знает о бумажках по закрепленным клиентам. Один сотрудник высказал свое видение распределения обязанностей, за что был проклят попал в немилость и спустя N-ое время сделал ноги. Параллельно «эффективный менеджер» успел в хлам разругаться с разработчиком и тем кто пришел на его замену. В итоге разработка была передана на аутсорс, который в свой очередь также не устроил «эффективного менеджера» и привел к тому что народ из отдела побежал.
Сталкивался с таким в самом начале карьеры. Компания была довольна крупная, но называть я ее не буду. Дружно жили не тужили своим отделом. Делали свое дело, был адекватный начальник, пятничные вечерушки с пиццей, тимбилдинги, гибкий график, печеньки, попугайчик в офисе и все такое. В какой-то момент в компанию приезжает топ-менеджер, да непростой, заграничный. Начинает всех ругать, все плохо работают, неэффективно, бездельники. Начальника нашего (к слову, из рабочей среды) от реальной власти отстранили. Все, теперь у нас новый менеджер — молодая девочка, которая вообще не в теме. Но знает, как сделать круто. Появляются мудреные метрики. Появляется матрица ресурсов, т.е. тебя начинают разрывать на части между кучей проектов, чтобы ты не «простаивал». Тебя так и называют — ресурс. Тебя можно зарезервировать, использовать, заменить или освободить. Премии и тимбилдинги уже не даются и не проводятся за просто так, а только по результатам метрик. Гибкий график больше не гибкий, ибо ты не должен спать, когда другие работают, и наоборот. Старожилы и самые шарящие спецы постепенно уходят в другие компании. Зато приходит много новых людей. У менеджера появляется заместитель, который курирует проекты. Турникеты начинают измерять время, проведенное в туалете. Появляются регулярные митинги, на которых ты должен доказать, что ты не бездельник. Премии начинают резать за любые проступки. Затем каждый день заставляют писать отчет о проделанной работе. Не сказать, что все это происходит мгновенно. В моем случае прошло около года, ну а потом я сменил работодателя.
Не следили, что стало с этой компанией после вашего ухода?
Это очень большая компания. Ничего с ней не случилось. Я думаю, что негативные последствия таких менеджеров (на компанию в целом) в статье сильно преувеличены. Не такие уж дураки те, кто их нанимает.
Тогда ваш рассказ выходит как «жили мы в компании как в раю, а потом пришел эффективный менеджер и заставил всех пахать, нам не понравилось и мы поувольнялись». Т.е. вопрос эффективности или неэффективности остался открытым.
стоя рядом с палкой конечно можно замотивировать сотрудника, но работа будет сделана на отвали, то есть лишь бы от него отстали, а создавая комфортные условия труда, когда сотрудки имеют время и на творчество, люди смогут созидать действительно шедевральные вещи, и делать не на от....
Скорее, здесь более правильной оценкой ситуации будет философское выражение, в переводе с нецензурного звучащее как «путь в никуда может длиться бесконечно долго».
Это из разряда — пока толстый сохнет, худой сдохнет.
Большие транснациональные компании тоже успешно идут ко дну.
В реально больших компаниях, кстати, в связи с огромной управляющей вертикалью, до самого низа могут не так доходить негативные эффекты и возможны адекватные «файрволы» в виде менеджеров нижних уровней.
Большие транснациональные компании тоже успешно идут ко дну.
В реально больших компаниях, кстати, в связи с огромной управляющей вертикалью, до самого низа могут не так доходить негативные эффекты и возможны адекватные «файрволы» в виде менеджеров нижних уровней.
Да, очень знакомо. Наверное, это просто неизбежный этап развития любой крупной компании. Рано или поздно появляются они — «эффективные менеджеры», которые начитались умных книжек по эффективному управлению людьми, но никогда не участвовавшие в реальной работе.
То есть по факту вам не понравилось, что вас наконец заставили работать? По-моему, описанный менеджмент все правильно сделал. Хотите бездельничать и пиццу есть — делайте это дома, а на работу вас наняли работать и держать просто так не собираются.
Работал в небольшой технологичной конторе где найм очень эффективного менеджера привёл к массовым увольнениям с попустительства начальства, так что при всей кажущейся бредовости статьи — прецеденты есть…
Отличная статья. Очень жизненно.
Кхм. Простите меня за такое мнение, но вот со стороны создаётся ощущение, что как раз Crossover-то и стал жертвой "эффективных менеджеров" в первую очередь.
К сожалению, в последние годы приставку «IT» опошлили и стали совать везде, где только можно, но IT-рекрутеры или IT-продажники все еще существуют.
Идеальный вариант: IT-reseacher.
Хорошая статья, всё как в реальной жизни, кроме одного — иногда случается что «эффективный менеджер» вдруг выделяется из старой команды. Стиль написания также импонирует.
Работал в одной фирме, как раз в период перехода из сплочённой команды давно знающих друг друга друзей с количеством порядка 20 человек в вертикально организованную компанию. Правда ушёл оттуда раньше описанной вами конечной стадии и вообще после этого завязал с крупными компаниями с их корпоративной структурой.
Работал в одной фирме, как раз в период перехода из сплочённой команды давно знающих друг друга друзей с количеством порядка 20 человек в вертикально организованную компанию. Правда ушёл оттуда раньше описанной вами конечной стадии и вообще после этого завязал с крупными компаниями с их корпоративной структурой.
Прошу прощения, наболело. Иногда хочется сказать этим самым «эффективным» менеджерам: пожалуйста, просто не мешайте, не меняйте правила посреди проекта, не лезьте в область в которой мало что понимаете, дайте доделать дело до конца.
Если хотите помочь, то слушайте и доверяйте своим разработчикам. Тогда все будет и у вас хорошо.
Если хотите помочь, то слушайте и доверяйте своим разработчикам. Тогда все будет и у вас хорошо.
В английском языке есть специальный термин для описанного в статье процесса — bozo explosion. Так же существует целый раздел науки, посвященный этому явлению.
Примерил статью на себя. Сделал выводы, поскольку я частично подпадаю под признаки «эффективного менеджера»: внедрил метрики, которые говорят, что некоторых сотрудников, которые вроде по старому определению справляются (ага, фичи выкатываются в production, вот только после них надо чистить диск от загаженных PHP-warning'ами логов Apache), надо гнать вон. Собственно, вопрос — а судьи кто?
Судьи-конечный продукт и пользователи. Если предидущие метрики были сделаны через жопу и все постоянно падало, а с новыми половину выгнали взашей но стало работать и апдейтится без критикал инцидентов, то все ок.
Проблема будет в том что если выкинут даже (Д) менеджера, нужно вычищать всю что ниже его, а это массовые расстрелы персонала. Директору или владельцу это тоже не особо заходит. Вот тут сидишь и думаешь, как выкинуть половину народу отседова, но при этом не вылететь самому в процессе.
Проблема будет в том что если выкинут даже (Д) менеджера, нужно вычищать всю что ниже его, а это массовые расстрелы персонала. Директору или владельцу это тоже не особо заходит. Вот тут сидишь и думаешь, как выкинуть половину народу отседова, но при этом не вылететь самому в процессе.
Так может code review ввести?
Обычный разработчик будет долго упираться когда его захотят сделать начальником. Ибо это ответственность. «Эффективный менеджер» всё сделает чтобы стать им, т.к. в их представлении, за них будут работать другие. Это самые обычные болтуны и бессовестные жулики. Единственное их нормальное применение — отдел продаж.
Выше уже было отмечено, что имитация бурной деятельности при неэффективно-вредном менеджменте м.б. не только в обновлении кадров, но и технологий при единственном общем доводе «новое — это эффективное, а кто не согласен — тот устарел». Это очень серьезный момент современной массовой психологии (см. здесь):
Однако так называемая культура общества потребления вносит заметный деструктивный вклад в сознание людей.
[...] стоит сказать, что у тебя старая версия чего-то, тут же кто-то не преминет назвать тебя в лучшем случае консерватором.
Прошу прощения, я не понял смысла статьи. Какой-то плач Ярославны. Плохие менеджеры плохие? Интересное открытие:) А хорошие, значит, хорошие? Такая логика? Кто целевая аудитория? Люди, которые испытали тяготы и лишения от плохих менеджеров? Сообщить, что они не одиноки? Может владельцы бизнеса? Сообщить им, что нужно не обращая внимание, на то, что у них толпа народа, скрамы, тимбилдинги, плюшки, печенюшки, митапы, стендапы, факапы, пампы и т.д. релизы раз в пол года кривенькие выходят… а это нормально? Для всего есть причина. И причина появления менеджеров — бардак. Менеджеры не заводятся сами. Их нанимают люди, которые наняли "сеньора, такого умного", "янгера, такого смышленого", которые оплатили печенюшки и тимбилдинги. Так может причина в том, что эти люди отчаялись получить "взаимность" от своей команды? Что настроение это хорошо, но любой бизнес создается для заработка?
Во всем должен быть баланс. Основная задача менеджера — найти этот баланс. Все остальное (метрики, регламенты, уставы, ресурсные матрицы и т.д.) это инструменты для его поиска и поддержания. Такие же как для программиста IDE, например.
Да можете меня хоть в хлам заминусовать. Это не изменит реальности. У статьи рейтинг 82, на момент написания этого комментария. А чему она кого учит? Что она раскрывает? Сколько замечательных статей на хабре, которые действительно имеют профессиональную ценность, но… разве они сравнятся с тем, что каждый душевно раненый при очередном перфоманс-ревью пережил? Когда ему наглядно показали, что его реальная работа не соответствует его представлениям о его «крутезне». Ведь он не будет себя в этом винить… «эффективные менеджеры»… они зло! А статья хорошая!
Только минусы ничего не изменят… именно вас ровно так же оценят ваши руководители. Именно вы будете «страдать». Пока не вылизите из своей «ракушки» и не перестанете оценивать мир из ее просвета.
Любое развитие находится за рамками комфорта. Запомните простое правило: если вам комфортно — значит вы не растете. И обратное: если вам некомфортно — вы получаете ценный опыт который поможет вам в жизни быть успешным.
P.S. Попугаи говорите? Ну давайте прикинем… рейтинг 83, закладок 82, а просмотров 34К. Т.е. она реально пригодится (они так думают) 0,24% людей, которые потратили свое время на ее прочтение. Вот вам и разница между реальной эффективностью и «субъективным восприятием». Это факты.
Только минусы ничего не изменят… именно вас ровно так же оценят ваши руководители. Именно вы будете «страдать». Пока не вылизите из своей «ракушки» и не перестанете оценивать мир из ее просвета.
Любое развитие находится за рамками комфорта. Запомните простое правило: если вам комфортно — значит вы не растете. И обратное: если вам некомфортно — вы получаете ценный опыт который поможет вам в жизни быть успешным.
P.S. Попугаи говорите? Ну давайте прикинем… рейтинг 83, закладок 82, а просмотров 34К. Т.е. она реально пригодится (они так думают) 0,24% людей, которые потратили свое время на ее прочтение. Вот вам и разница между реальной эффективностью и «субъективным восприятием». Это факты.
Любое развитие находится за рамками комфорта. Запомните простое правило: если вам комфортно — значит вы не растете. И обратное: если вам некомфортно — вы получаете ценный опыт который поможет вам в жизни быть успешным.
Странная у вас логика, как, впрочем, и сам ваш коммент.
Руководитель быдло и хамло — значит вы растете. Если компания создала отличные условия для вашего комфортного творения — то вы стагнируете. Судя по стилистике написания вашего комментария и тем эмоциям, которые вы в него вложили, люди не хотят с вами работать, и бегут от вас только завидев.
Запомните простое правило
Есть такая поговорка: «Дураки уверены, а умные сомневаются».
Тут многие, на хабре, взрослые и высококвалифицированные специалисты в своих сферах. Я думаю, что они сами смогут сделать соответствующие выводы и без вашего «глубокого анализа» и категорических утверждений.
Это вы как разработчик с философским подходом пишите? Для которого стартапы — жизнь?
Мне кажется… это не ваша тема. О каких менеджерах вы можете судить?
Сколько я ужевидел этих стартапов… где вся суть стартапа: настарапить и слиться.
Сколько я ужевидел этих стартапов… где вся суть стартапа: настарапить и слиться.
Я в стартапы вкладываю десятки и сотни тысяч долларов! Куда мне сливаться? Стартапы — это не работа в уютном кабинете на раслабоне. Это реальный адский труд действительно профессиональных специалистов. Как раз опыт новаторских, современных подходов получают не в старых легаси проектах, а именно в стартапах. Именно большие инвестиционные риски заставляют команду работать сплоченно и в условиях жестких дедлайнов, без права на ошибки. И если все и идет «коту под хвост», то только благодаря «успешным менеджерам», которые наобещали инвестору златые горы, размутили капусты и слились, как туман по утру.
Мне кажется… это не ваша тема. О каких менеджерах вы можете судить?
Вам слишком много кажется, а я многие вещи знаю наверняка, так как и сам часто бываю и в роли разработчика, и в роли менеджера, и владельца бизнеса.
А по факту не стоит проецировать свой ограниченный мирок на всю картину мироздания. В истории огромное количество примеров, как затролленные такими, как вы, «знатоками всего на свете», не благодаря, а вопреки, добивались сумасшедших успехов. Да практически — это истории любого успешного стартапа.
Хоспади… не смешите меня… ладно меня… людей. Жестких дедлойнов :))) В стартапах… да там по 40 раз на дню все меняется. Потому, что никто не в силах увидеть что-то за рамками горизонта неделя. Месяц! месяц!!! Это уже гордо именуется роудмэп!
Ну да… ну да :))) Я вам так скажу. Вы станете очень опытном специалистом. Знаете почему? Потому, что опыт это то, что ты получаешь вместо того, что хотел ;))
Удачи вам в ваших «стартапах» с полностью сумашедшими.
А по факту не стоит проецировать свой ограниченный мирок на всю картину мироздания.
Ну да… ну да :))) Я вам так скажу. Вы станете очень опытном специалистом. Знаете почему? Потому, что опыт это то, что ты получаешь вместо того, что хотел ;))
Удачи вам в ваших «стартапах» с полностью сумашедшими.
Хоспади… не смешите меня… ладно меня… людей. Жестких дедлойнов :))) В стартапах… да там по 40 раз на дню все меняется. Потому, что никто не в силах увидеть что-то за рамками горизонта неделя. Месяц! месяц!!! Это уже гордо именуется роудмэп!
Не стоит свой опыт проецировать на объективную реальность. Все бывает по разному. Если у вас только голая идея и есть деньги, то их лучше кому-то подарить, будет эффективнее. Я уже на Хабре об этом писал статью. Грамотные стартапы имеют четкое ТЗ, которое не меняется по сто раз на день, так как попросту не хватит финансирования. В первую очередь выпускается MVP, после чего идет закрепление на рынке и монетизация. А уже потом, когда проект себя кормит (если), то уже и происходит улучшения/расширения и т.д. Ну или проект умирает, поскольку был не востребован, что чаще и происходит.
А вот именно в крупных компаниях, где есть постоянный приток финансов и происходят всякие тупые идеи и хотелки, которые меняются по сто раз в месяц. Так как считают, что от такого поведения бизнес не просядет и не пострадает (и зря так считают), а точно выиграет. Поэтому и занимаются экспериментальной бизнес мастурбацией, не просчитывая никаких шагов и последствий. Мол незаменимых нет, всех уволим, если что, и наберем новых с улицы. Вот поэтому уровень бизнеса в бывшем СССР больше похож на УГ, чем на серьезный и успешный бизнес процесс. Думаете я после универа стал стартапами заниматься не поработав в крупных конторах на галерах?
Ну да… ну да :))) Я вам так скажу. Вы станете очень опытном специалистом. Знаете почему? Потому, что опыт это то, что ты получаешь вместо того, что хотел ;))
Опыт будет получен в любом случае, не зависимо от того, получилось у вас что-то или нет. Вся жизнь человека от рождения до смерти — это путь получения опыта. И если вы сумеете правильно пользоваться этим опытом, то не зря эту жизнь проживете.
Я не совсем понимаю, что вы мне хотите доказать или показать? Я в этом бизнесе кручусь почти 20 лет. Видел и пережил очень многое, где-то достиг успехов, где-то потерпел фиаско. Вы думаете, что ваш комментарий как-то изменит мое представление о жизни?
Вот несколько постулатов в найме и управлении которые стоит взять на вооружение хотя бы частично:Усматриваю противоречие. Если частичного соответствия не бывает, то и частичного вооружения быть не должно.
Не бывает «частичного соответствия»
Все руководители должны иметь больший опыт в разработке, нежели их подчиненные. Обычно это разрыв в 3-5 лет между ними.Опыт разработки накапливается во время разработки, а не руководства. Когда я 15 лет назад пришёл на работу — да, мой руководитель имел много больше опыта. Сейчас наоборот.
Никаких «попугаев». Оценка работы должна проводится по разным параметрам, в том числе и сложности, а не по количеству строк кода.Сложность — это лишь другой вид «попугаев». Как её оценивать? Сложно то, что вне твоей компетенции. Запутать код или архитектуру, чтобы увеличить его/её сложность тоже сможет каждый.
давно заметил, чем меньше денег и управленческого опыта — тем лучше человек разбирается в эффективном менеджменте
описанные в статье перегибы имеют место быть, но вся статья это просто внешний локус контроля автора, помноженный на генерализацию частных случаев и ошибки выживших
когда читаешь это это бесконечное нытье про «плохих HR», «тупое руководство», «кодинг на говностеке» и бла-бла-бла — возникает только один вопрос: почему бы не утереть сопли — сперва себе, а потом другим, сделав правильный бизнес и порвав рынок продажами?
описанные в статье перегибы имеют место быть, но вся статья это просто внешний локус контроля автора, помноженный на генерализацию частных случаев и ошибки выживших
когда читаешь это это бесконечное нытье про «плохих HR», «тупое руководство», «кодинг на говностеке» и бла-бла-бла — возникает только один вопрос: почему бы не утереть сопли — сперва себе, а потом другим, сделав правильный бизнес и порвав рынок продажами?
спойлер
потому что спамить статейки на хабр — не мешки ворочать
Возникают «эффективные менеджеры» в компаниях, которые выросли рывком и не успели (либо не смогли) подготовить руководящие кадры внутри собственной структуры.
Не только так. Встречаются еще и случаи сознательного замещения собственных руководящих кадров на дефективных.
Именно потому что собственные кадры мешают выжать из компании всю кровь и выкинуть трупик.
Первым делом когда приходит эффективный он читает устав предприятия, а там написало что оно создано с целью извлечения прибыли. Собственно на это направлена деятельность менеджера. В первую очередь он добивается предсказуемости цели.
И ещё эти люди как масоны имеют свои тайные знаки типа МВА и они начинают тянуть своих. Собственно это притяжения наблюдается не только среди эффективных, а и например национальной диаспоры
Что люди так к MBA прикапались? MBA как и люди разные бывают. Если человек говорит, что он закончил западную школу из ТОП 20, то я примерно понимаю его уровень, специализацию и возможности. Бренд школы в данном вопросе имеет большое значение для поставленной цели. А если серьезно, то для трансформации бизнеса и преодоления проблемы роста лучше искать именно MBA из ТОП 20, тогда на выходе будет результат.
Все что написано про эффективный менеджмент – это понимание проблемы глазами технаря и полное непонимание бизнеса. А вот из моего дцатилетнего опыта именно технари убивают продукт, погружаясь в технологии и забывая о клиенте и той потребности, которую создаваемый продукт удовлетворяет. А причина этого в том, что в стране никогда не было школы, которая учила бы бизнесу отсюда и растут все байки про эффективных менеджеров. Технарей российские ВУЗы может еще выпускают, а вот специалистов по бизнесу эта страна в принципе не может выпускать, так как для этого нужно совсем другое мышление в головах. Когда я слышу, про МБА в России мне уже становится смешно. У нас очень низкая профессиональная подготовка всех менеджеров. Именно поэтому 90% компаний представляют собой большие колхозы, где на ключевых ролях лояльные друзья, а не профессионалы. Это все работает, когда коллектив из 20 человек делает нишевый продукт, но уже не работает когда ты пытаешься выходить на международные рынки. А то, что описано называется проблемой роста и трансформации стартапа в серьезный бизнес и очень хорошо изучено за последние двести лет. Это ключевой и очень сложный этапа в жизненном цикле любой компании. Большинство компаний так и не могут преодолеть этот этап и перейти на следующий уровень, оставаясь прозябать в своей узкой нише с пиццами по пятницам, а еще больше компаний выходят из бизнеса, разругавшись или потеряв импульс развития и свой рынок. Успех или неудача на этом этапе зависят от огромного количества факторов, но определяющим фактором всегда является основатель компании и его бекгрануд.
тут еще помимо всего в комментах началось юление, про разницу «эффективных» и эффективных, хотя по тем же комментариям понятно что эту разницу не все комментаторы понимают.
вообще это конечно все одна большая беда, непонимание принципов здорового роста.
Например в какой-то момент оказывается что универсальный солдат, тот парень который в стартапе кодил и поднимал/поддерживал серваки, один уже не справляется и на его место нужно два человека. При этом «старичок» кодит хуже чем рекрутированный профи-программист и админит хуже чем рекрутированный профи-админ.
В желаемом для себя варианте этот человек становится руководителем эти двух профи (неэффективно, но по старой дружбе с основателем, если стартап на грани выживания — такие шаги могут его просто убить) или срочно поднимает квалификацию до одного из профи (полумера, которая хоть и отнимет немного ресурсов компании, но позволит еще немного сохранить коллектив/атмосферу), а у эффективных менеджеров он просто увольняется и на его место приходят профессионалы (жестко, но эффективно — нет лишних затрат на лишнего сотрудника, нет затрат на обучение).
конечно «старичку» обидно, ведь он работал не только за деньги, но и за идею, но и у руководства выбор небольшой — либо потерять в росте/прогореть, но сохранить пятничные посиделки с пиццей либо сохранить и приумножить компанию — и это решение тоже не всем руководителям легко дается, а некоторым не дается вообще.
«Бизнес есть бизнес, ничего личного» — эта фраза как раз про подобные случаи
вообще это конечно все одна большая беда, непонимание принципов здорового роста.
Например в какой-то момент оказывается что универсальный солдат, тот парень который в стартапе кодил и поднимал/поддерживал серваки, один уже не справляется и на его место нужно два человека. При этом «старичок» кодит хуже чем рекрутированный профи-программист и админит хуже чем рекрутированный профи-админ.
В желаемом для себя варианте этот человек становится руководителем эти двух профи (неэффективно, но по старой дружбе с основателем, если стартап на грани выживания — такие шаги могут его просто убить) или срочно поднимает квалификацию до одного из профи (полумера, которая хоть и отнимет немного ресурсов компании, но позволит еще немного сохранить коллектив/атмосферу), а у эффективных менеджеров он просто увольняется и на его место приходят профессионалы (жестко, но эффективно — нет лишних затрат на лишнего сотрудника, нет затрат на обучение).
конечно «старичку» обидно, ведь он работал не только за деньги, но и за идею, но и у руководства выбор небольшой — либо потерять в росте/прогореть, но сохранить пятничные посиделки с пиццей либо сохранить и приумножить компанию — и это решение тоже не всем руководителям легко дается, а некоторым не дается вообще.
«Бизнес есть бизнес, ничего личного» — эта фраза как раз про подобные случаи
Описанный вами кейс имеет место быть, но, мне кажется он крайне редок. Как правило, российский бизнес в большей степени придерживается стратегии найма дешевых кадров, преимущественно студентов с небольшим опытом с их последующем развитием под себя. Это основная стратегия найма в России, как разработчиков, так и эффективных менеджеров. Отсюда в описанном вам кейсе компания скорее просто повысит “старичка” близкого к основателю, пристегнув к нему помощника или двух студентов, так как на найм руководителя, да еще и опытного, просто жалко денег. Это формула работает и успешна при определенных условиях, но не всегда. Опытный админ и кодер, как и опытный эффективный менеджер не будет работать за ставку студента, но большинство компаний ищут именно таких. Это наглядно видно из вакансий на hh, где на директорские и руководящие позиции ищутся люди с опытом 3 года на ставки чуть выше студенческих, что как бы противоречит здравому смыслу.
Совершенно верно, никто не станет нанимать двух людей на место одного удвоив затраты на зарплату. Логика очень простая, если старый админ работал за Х и не справляется, то брать ещё одного специалиста — дорого и не нужно ибо нам не надо удваивать производительность, а достаточно поднять на скажем 20%. Добавим к его зарплате 20% и найдём двух на зарплату (Х+20%)/2 каждый. По идее они вдвоём будут выдавать как раз на 20% больше. По факту понятно что на такие деньги придет персонал без опыта и скорее всего проходной. В результате потратив время (и деньги) на его обучение, надо либо поднимать ему зарплату, либо он уйдёт так как уже имеет опыт. В результате получаем или двух спецов уровня прошлого админа но с зарплатой больше, либо постоянную текучку и завал.
Совершенно верно, никто не станет нанимать двух людей на место одного удвоив затраты на зарплату.
По всякому бывает.
Искали как то младших админов в помощники более квалифицированному, хотели нанять 2 человека таких.
Случайно зашел на собеседование один квалифицированный админа. Тут же переиграли бюджет на зарплату — заработок двух человек объединили и отдали этому одному. То есть вместо двух менее квалифицированных, взяли 1 более квалифицированного. Не прогадали.
Всяко бывает.
Работа в стартапе «за идею» должна означать наличие юридически оформленной доли, если таковая у сотрудника есть и сохранится, он не будет в обиде на замену себя новыми людьми (тем более, что нанятые менеджеры и нанятые сотрудники означают уже достигнутых финансовых успехов, в таких случаях доля очень хорошо греет душу).
не в России. у нас вообще нет такой традиции — доли раздавать.
ну и пока человек работает на энтузиазме — зачем ему платить, пусть радуется что грошовая работа совпадает с хобби, именно так радиодиджеинг и прочий вебмастеринг в регионах по оплате скатилось дешевле уборщиц в начала 2000х :), спасибо что наоборот с исполнителя денег не берут.
а когда наивный исполнитель перегорел и за энтузиазм работать не хочет — его меняют, а он дико обижается (а некоторые еще и заподлянки строят), короче обычный развод по-русски, с битьем посуды.
ну и пока человек работает на энтузиазме — зачем ему платить, пусть радуется что грошовая работа совпадает с хобби, именно так радиодиджеинг и прочий вебмастеринг в регионах по оплате скатилось дешевле уборщиц в начала 2000х :), спасибо что наоборот с исполнителя денег не берут.
а когда наивный исполнитель перегорел и за энтузиазм работать не хочет — его меняют, а он дико обижается (а некоторые еще и заподлянки строят), короче обычный развод по-русски, с битьем посуды.
А что вы скажете когда все описанное в статье происходит НЕ в растущей компании? И вообще не в ИТ, а в Росатоме, Роскосмосе, Ростелекоме-Билайне-Мегафоне-МТС, РЖД, РАО ЕЭС, на крупных горнодобывающих предприятиях? Короче там, где уже лет 20 (а то и 50) ничего не растет даже под микроскопом?
в смысле не растет, за 50 лет в России ни компов, ни 1с, ни новых 40 тонных самосвалов взамен 3х тонных ЗИЛов не появилось?
Развитие идет всегда, но не всегда экстенсивно в виде увеличения количества допофисов и количества вышек. И да, при развитии требуется менять подходы к управлению, что-то внедрять, что-то наоборот оптимизировать, как в сбере заменили почти кассы с живыми операторами терминалами самообслуживания например.
Развитие идет всегда, но не всегда экстенсивно в виде увеличения количества допофисов и количества вышек. И да, при развитии требуется менять подходы к управлению, что-то внедрять, что-то наоборот оптимизировать, как в сбере заменили почти кассы с живыми операторами терминалами самообслуживания например.
Еще раз. Есть отрасли в которых РАЗВИТИЯ — нет. Есть производство, сервис, логистика, гос или нацмонополия наконец. Просто опасные отрасли, или на грани технического риска.
Взамен 3тонных Зилов появились 3тонные Вольво, Ховы и прочие китайцы/японцы, так что и тут мимо.
Поэтому повторяю вопрос: что делать если это НЕ стартап, а роста в компании практически нет? Или еще точнее: количество переделанной работы и нанятого/уволенного персонала в компании колеблется в районе едениц процентов? Стабильная ситуация.
Взамен 3тонных Зилов появились 3тонные Вольво, Ховы и прочие китайцы/японцы, так что и тут мимо.
Поэтому повторяю вопрос: что делать если это НЕ стартап, а роста в компании практически нет? Или еще точнее: количество переделанной работы и нанятого/уволенного персонала в компании колеблется в районе едениц процентов? Стабильная ситуация.
и конфликта интересов, когда подчиненные более квалифицированы, чем их новый начальник.
Директор завода не должен быть квалифицированнейшим слерарем, инженером и токарем.
Это неплохо, когда директор начинал с слесаря и в курсе как это в принципе работает. Но не более.
Но «подчиненные более квалифицированы» — это же бредовый критерий.
У директора должны быть другие навыки — эти квалификации не сопоставимы.
Непосредственный руководитель должен быть компетентнее своего подчиненного.
Непосредственный руководитель должен быть компетентнее своего подчиненного.
В чем именно.
Практически во всем.
Начальник группы должен иметь компетенцию подменить своего подчиненного в случае его отсутствия + выполнять обязанности координации с вышестоящими отделам и смежными группами. Начальник отдела должен быть способен кроме выполнения своих непосредственных обязанностей иметь возможность выполнять обязанности начальника группы, т.е. координацию с вышестоящими отделам и смежными группами.
И так далее.
Начальник группы должен иметь компетенцию подменить своего подчиненного в случае его отсутствия + выполнять обязанности координации с вышестоящими отделам и смежными группами. Начальник отдела должен быть способен кроме выполнения своих непосредственных обязанностей иметь возможность выполнять обязанности начальника группы, т.е. координацию с вышестоящими отделам и смежными группами.
И так далее.
Вы же понимаете, что это не всегда возможно? Чтобы быть компетентнее узкого специалиста, надо тратить на работу и обучение как минимум, столько же времени, сколько и он.
А руководить и учиться руководству когда?
Я уж не говорю о том, что руководитель должен в идеале иметь представление не только о деятельности своих подчинённых, но и о смежных областях, чтобы не получалось так, что начальник отдела разработки не имеет понятия ни о тестах, ни о развертывании, ни о продажах и положении на рынке.
так он и зарабатывает больше именно потому что знает больше… а у нас зачастую принято, когда начальник просто делигирует полномочия, и руководит армейским способом, не особо понимая в деталях как это всё работает. в таком случае он должен зарабатывать так же как и специалист, просто он занимается управленческой специализацией, а специалист своей узкой. тут недавно наткнулся ( правда не знаю на сколько достоверные данные) на разницу зарплат в НАСА, так там управленцы не зарабатывают в разы больше специалистов, в отличии от нашей страны
Не понимаю. В организации среди низшего и среднего звена не должно быть «ключевых кадров»
Причем тут ключевые кадры? Есть предел времени, которое можно потратить на обучение, и предел знаний, которые можно держать в один момент в памяти. Соответственно, начальник пяти человек, которые профессионалы каждый в своем деле(допустим, бек+фронт+инженер+админ+дизайнер) просто не имеет возможности знать сумму того, что знают они, просто потому, что каждый из них потратил 5-10 лет на учебу и наработку опыта, и сумма этого времени — это уже 30-50 лет(не говоря уж о том, что пока ты учишь следующую специальность, знания предыдущей становятся неактуальными).
Вы хотите сказать, что руководителем небольшой команды средней руки проекта должен быть обязательно человек 50-70+ лет с идеальной памятью? Это же чушь.
Понимать, что делают подчиненные — да, надо. Просто, чтобы иметь представление, что вот эта страничка рисуется за два дня, верстается еще день, и если на задачу потрачена неделя — надо разобраться почему, а не говорить «ну, они профессионалы, им видней». Компетенцию надо иметь, это важно.
Но говорить о том, что начальник должен в любой произвольный момент времени «встать к станку» и заменить подчиненного на том же уровне — какая-то фигня. Красивая идея, не имеющая ничего общего с реальностью.
Вы хотите сказать, что руководителем небольшой команды средней руки проекта должен быть обязательно человек 50-70+ лет с идеальной памятью? Это же чушь.
Понимать, что делают подчиненные — да, надо. Просто, чтобы иметь представление, что вот эта страничка рисуется за два дня, верстается еще день, и если на задачу потрачена неделя — надо разобраться почему, а не говорить «ну, они профессионалы, им видней». Компетенцию надо иметь, это важно.
Но говорить о том, что начальник должен в любой произвольный момент времени «встать к станку» и заменить подчиненного на том же уровне — какая-то фигня. Красивая идея, не имеющая ничего общего с реальностью.
Но говорить о том, что начальник должен в любой произвольный момент времени «встать к станку» и заменить подчиненного на том же уровне — какая-то фигня. Красивая идея, не имеющая ничего общего с реальностью.
Не обязательно на том же уровне. Можно потратить в 3-5 раз больше времени, сделать чуть менее качественно, но «заткнуть дыру» обязан. Иначе больничный или увольнение всего одного сотрудника может привести к коллапсу целой компании.
Непосредственный руководитель должен быть компетентнее своего подчиненного.
Не обязательно на том же уровне.
Вы уж определитесь, компетентнее или не обязательно.
Тут лучше всего подходит любимая советская формулировка «должен, но не обязан».
Определенно, должен быть компетентнее каждого из подчиненных и обязан иметь возможность подменить каждого из них.
Как-то так.
Определенно, должен быть компетентнее каждого из подчиненных и обязан иметь возможность подменить каждого из них.
Как-то так.
А, т.е. значит вы, когда говорили «должен быть компетентнее», на самом деле имели ввиду «должен, но не обязан быть компетентнее», я правильно понял?
Вы сами-то понимаете, что именно вы хотели сказать? Я вот нет. Для меня такая формулировка — взаимоисключающие параграфы, что приводит к схлопыванию в ноль. С моей точки зрения, после уточнения вами определения, вы не написали в этом комментарии ничего.
Вы сами-то понимаете, что именно вы хотели сказать? Я вот нет. Для меня такая формулировка — взаимоисключающие параграфы, что приводит к схлопыванию в ноль. С моей точки зрения, после уточнения вами определения, вы не написали в этом комментарии ничего.
Русский язык для Вас родной?
Слабо понимаю, какое это имеет значение в контексте дискуссии, но да.
И я не понимаю, почему более сложное предложение, содержащие уточнение, стало вызывать больше непонимания, чем абстрактное простое предложение. Парадокс, не иначе.
Потому что уточнение превращает исходное предложение в «Непосредственный руководитель должен, но не обязан быть компетентнее своего подчиненного.», что мой парсер русского считает какой-то фигней. Не то, чтобы ложным утверждением, скорее просто бессмысленным.
Я очень рад за традиции СССР в которых, видимо, эта фраза имела какой-то сакральный смысл, но все-таки, не могли бы вы пояснить, что именно вы имели ввиду этим предложением в контексте этой статьи и этой дискуссии?
Я очень рад за традиции СССР в которых, видимо, эта фраза имела какой-то сакральный смысл, но все-таки, не могли бы вы пояснить, что именно вы имели ввиду этим предложением в контексте этой статьи и этой дискуссии?
Иначе больничный или увольнение всего одного сотрудника может привести к коллапсу целой компании.
Менеджер привел систему к bus factor = 1, после чего единственное что ему приходит в голову — самому делать?
При этом ряд квалифицированных технарей, которых повысили до руководящих позиций, поджидает классическая ловушка: сделать всё самому, вместо того, чтоб обеспечить выполнение задачи подчиненными.
Бредятина какая ужасная. Эдак по цепочке от дворника, генеральный директор должен быть признанными гением во всех областях! А специалисты-исполнители и эксперты в подчинении вообще не возможны.
На самом деле единственный правильный подход для начальника любого уровня — нанимать грамотных людей умнее себя, и доверять им вопросы в их компетенции.
Ну и с их помощью учеников-помощников брать и растить.
UFO just landed and posted this here
«Эффективные менеджеры» вас не поймут. Они считают, что способны управлять абсолютно любой фирмой и в любой области, лишь имея навык правильного делегирования, распределения ресурсов.
Руководителю не обязательно быть квалифицированнее своих подчиненных. И это нормально, что подопечные знают больше чем их начальник. В конце концов ежедневно они решают разные задачи. Но естественно, что разница в этих знаниях не должна быть провальная и хороший руководитель стремится понимать, что делают его подчиненные.
Хорошая статья. Не соглашусь c негативной оценкой HR, в частности HRD. HR никогда не допустит снижения вовлеченности и изменения корпкультуры, т.к. эти изменения не приводят к повышению эффективности.
Непонятно как опыт руководителя в технологиях может быть больше опыта сотрудников, которые эти технологии применяют? Особенно с учетом динамичности этих технологий. В конечном итоге любой хороший руководитель тратящий личное время на то, чтобы стать еще более хорошим руководителем, обречен на потерю технических навыков. Можете прояснить как вы предлагаете сохранять эту дельту между опытом руководителя и подчиненных в технологиях?
Скажите, а что такое стек А+В? Первый раз такой термин встречаю.
По теме скажу, что у медали, как всегда, есть две стороны.
С одной стороны согласен, что приход нового человека со своим уставом часто мешает работе монастыря.
С другой стороны, мы же понимаем, что описанный коллектив с пиццей и комфортом будет всегда работать немножко «на расслабоне». То есть будут фанаты своего дела, кто с утра до вечера пашет, но большая часть сотрудников тратит часть рабочего времени не на работу. На самом деле, это нормально, на коллективе из загнанных лошадей далеко не уедешь.
Но все же приходит новый человек, у которого задача поднять эффективность. Он видит, что народ на работу приезжает с опозданием, уходит пораньше и еще перерыв по два часа. Разумеется, с этим начнется борьба. И разумеется, привыкшему к комфорту и приятному графику коллективу такое не по душе.
Дальше обычно так. На первое время, с саботажем и скрипом, но новые правила игры все же принимаются и дел действительно делается больше. Это ведет к простому выводу — ужесточили условия, получили прибавление к производительности. Давайте дальше затягивать.
И вот уже на второй фазе оптимизации начинается коллектив загнанных лошадей и побег наиболее ценных сотрудников.
По теме скажу, что у медали, как всегда, есть две стороны.
С одной стороны согласен, что приход нового человека со своим уставом часто мешает работе монастыря.
С другой стороны, мы же понимаем, что описанный коллектив с пиццей и комфортом будет всегда работать немножко «на расслабоне». То есть будут фанаты своего дела, кто с утра до вечера пашет, но большая часть сотрудников тратит часть рабочего времени не на работу. На самом деле, это нормально, на коллективе из загнанных лошадей далеко не уедешь.
Но все же приходит новый человек, у которого задача поднять эффективность. Он видит, что народ на работу приезжает с опозданием, уходит пораньше и еще перерыв по два часа. Разумеется, с этим начнется борьба. И разумеется, привыкшему к комфорту и приятному графику коллективу такое не по душе.
Дальше обычно так. На первое время, с саботажем и скрипом, но новые правила игры все же принимаются и дел действительно делается больше. Это ведет к простому выводу — ужесточили условия, получили прибавление к производительности. Давайте дальше затягивать.
И вот уже на второй фазе оптимизации начинается коллектив загнанных лошадей и побег наиболее ценных сотрудников.
Как-то однобоко вы мыслите. Если наняли эффективного менеджера, то обязательно до его прихода все работали на расслабоне и это был стартап с пиццами. А по-другому быть не может? К примеру, руководство просто захотело больше денег, новую яхту, дом и так далее, а тут как по мановению волшебной палочки появляется человек, который обещает прибавку к доходу с минимумом усилий, потому что он "уже имеет опыт и делал это в других компаниях". Но, если у такого человека свой интерес, который не учитывает ни интересы коллег, ни интересы компании, то вот вам и "эффективный" менеджер. И не обязательно, что до него в компании было не все хорошо, могло быть и хорошо, но руководство захотело, чтобы стало ещё лучше.
Далеко не всегда. Но если нанимают человека повысить эффективность, значит у владельцев бизнеса есть смутное ощущение, что все работают не в полную силу.
Если IT ишачит как лошади, просто не справляется с валом работы и есть финансовый эффект от их работы, то их начнут не оптимизировать, а расширять.
Если IT ишачит как лошади, просто не справляется с валом работы и есть финансовый эффект от их работы, то их начнут не оптимизировать, а расширять.
Если человек пришел на час позже и на два часа меньше просидел на офисной табуретке, он обязательно низкопроизводительный сотрудник? Это категории XIX века. Судите конкретно по выполненным делам за отчетный период, а не по времени из СКУД.
Прошу заметить, что выводы в стиле 19 века сделали вы) Я как раз считаю, что работа «на расслабоне» часто оказывается эффективней табуна мчащихся все 8 часов, но уже загнанных лошадей. И даже написал про это.
Но при таком «расслабоне» почти всегда есть задел на увеличение эффективности. И, как я уже писал выше, его часто ошибочно переоценивают. Закручу гайку на полборота, станет работать на 20 процентов лучше. Значит на полный оборот — плюс сорок процентов. А оно уже на 3/4 резьбу срывает.
Но при таком «расслабоне» почти всегда есть задел на увеличение эффективности. И, как я уже писал выше, его часто ошибочно переоценивают. Закручу гайку на полборота, станет работать на 20 процентов лучше. Значит на полный оборот — плюс сорок процентов. А оно уже на 3/4 резьбу срывает.
UFO just landed and posted this here
Видимо автор статьи ожидает, что здесь много разработчиков, которые не любят менеджеров и залайкают статью.
Но, если пораскинуть мозгами, то призыв «не нанимайте» это призыв к руководству фирм только.
Но, если пораскинуть мозгами, то призыв «не нанимайте» это призыв к руководству фирм только.
Люди, вы всерьёз обсуждаете ЭТО? Это же контент из серии "не ешьте всего один продукт, чтобы похудеть". Или "винда — абсолютное зло". Максимум субъективности, минимум объективности. Автор просто вкидывает свои тезисы из серии "все автомеханики алкоголики, все менеджеры — паразиты".
Менеджеры бывают разные, плохие и хорошие. Так же как и разработчики, шофёры, музыканты и все остальные.
И ещё один момент, про который обиженные разработчики (автор, возможно, из их числа) забывают. Менеджер не обязан делать хорошо и приятно сотрудникам. Он обязан делать хорошо компании и её собственникам. Это разные вещи.
И ещё один момент, про который обиженные разработчики (автор, возможно, из их числа) забывают. Менеджер не обязан делать хорошо и приятно сотрудникам. Он обязан делать хорошо компании и её собственникам. Это разные вещи.
Так об этом и есть вся статья. «Эффективные менеджеры» сами придумывают «метрики» хорошо/плохо, прикрываясь псевдонаучными статьями. Пользуясь своими превосходными коммуникатвными навыками мошенничеством убеждают владельцев в своей правоте. Затем стагнируют компанию, но по бумагам выдают прекрасные показатели. Выбивают себе огромные бонусы, «золотой парашют» и уходят в следующую компанию кризис-менеджерами.
Ну откуда вы такое взяли? Есть много противоположных ситуаций, когда пришедшие менеджеры вытащили компанию из кризиса. Да и давайте вернемся к тому, с чего всё началось — с того, что собственник «катается по Кипрам» и просто не хочет заниматься бизнесом. В этой ситуации у него выходов по большому счету 2 — продать компанию (за сумму в ~2 годовых прибыли) или отдать «эффективным менеджерам», которые выжмут из этой коровы всё что можно (и получить суммарно ~4 годовых прибыли, пусть даже она загнется через N лет — да и не факт что загнется).
О, да, еще же можно отдать компанию в управление «эффективным разработчикам», которые с упоением будут играться в технологии, забыв и о пользователях, и о продажах, и об интересах собственников.
Я не знаю почему так получается, но манагеры не считают, что понимают именно в технической части разработки больше. Они не лезут под руку и не критикуют разработчиков за то, что они выбирают Inheritance вместо Dependency Injection. Зато вот разработчики считают себя самыми умными во всем, и естественно лучше знают, как правильно управлять компанией (на самом деле нет). Синдром инженера, да. У меня преподаватель по матлогике такой в универе был, чуть не отбил у меня любовь к программированию.
О, да, еще же можно отдать компанию в управление «эффективным разработчикам», которые с упоением будут играться в технологии, забыв и о пользователях, и о продажах, и об интересах собственников.
Я не знаю почему так получается, но манагеры не считают, что понимают именно в технической части разработки больше. Они не лезут под руку и не критикуют разработчиков за то, что они выбирают Inheritance вместо Dependency Injection. Зато вот разработчики считают себя самыми умными во всем, и естественно лучше знают, как правильно управлять компанией (на самом деле нет). Синдром инженера, да. У меня преподаватель по матлогике такой в универе был, чуть не отбил у меня любовь к программированию.
Мне кажется не стоит смешивать понятия. Термин «эффективный менеджер» (без кавычек) пришёл из научных работ по менеджменту и означает действительно хорошего управленца, обладающего рядом качеств для продуктивной работы подчинённых и развития бизнеса в целом. За примером далеко ходить не надо, Илон Маск вполне себе эффективный менеджер
UFO just landed and posted this here
Но этот термин опошлили реальные кейсы, когда под прикрытием умных слов и терминов банкротились и разорялись предприятия…
Есть и другая сторона медали.
Запускается стартап — красивая идея, умный агрессивный собственник, мотивированная команда, стартап за год из 5 человек разрастается до 100. И тут вдруг оказывается, что управлять командой из 100 человек так же, как стартапом из 5 не получается, не получается решать все проблемы только за счет ресурса. Легко спланировать работу пяти человек просто проговорив с утра планы на день, но подобный подход с командой в 100 человек не работает. Оказывается, что бывшие технари, которые выросли до топов, плохо справляются с функциями менеджеров. Идея все еще жива и прекрасна, но компания просто не может разрулить внутренние проблемы и справиться с требованиями большого бизнесса. Владелец с опозданием принимает решение — искать специалистов, которые могут организовать работу большой компании. Эффективные менеджеры приходят, офигевают, пытаются навести порядок. Приходится усложнять работу, бюрократизировать потоки информации, увольнять, нанимать, перекраивать подразделения, закрывать направления, открывать новые. Цель эффективных менеджеров — спасти компанию. Естественно, на атмосферу в коллективе это не может влиять позитивно. Изнутри кажется, что компания умирает, уходят «старички», будущее туманно.
Сложнее всего в этой ситуации осознать, что компания начала умирать еще до того, как ее начало лихорадить.
А если это НЕ стартап?
Не могли бы вы уточнить вопрос?
Легко. Что делать если это, ну пусть будет Ростелеком?
Стартапы таких товарищей не интересуют, они не дураки на самом деле.
Стартапы таких товарищей не интересуют, они не дураки на самом деле.
Суть вопроса все равно не ясна. Условный Ростелеком испытывает трудности с решением внутренних проблем? Рассмотреть возможные варианты выхода из ситуации?
Ну, вполне обычная ситуация. Частая причина — ценности компании устарели и не соответствуют требованиям рынка, процессы внутри команды не могут обеспечить переход на новые ценности, ресурс ограничен.
Могут ли эффективные менеджеры помочь? Могут. Скорее всего новые направления востребованные рынком потребуют перемен в культуре компании, новых ценностей и оптимизированных процессов. Если собственник условного Ростелекома будет готов на такие глобальные перемены, то шанс есть. Предположу, что эффективные менеджеры выделят самые перспективные направления, сформируют новые ценности, проанализируют возможность адаптации старых процессов. Если процессы адаптируются, имеет смысл выделить новые подразделения внутри компании, занимающиеся перспективными направлениями. Ресурс используется имеющийся. Если процессы не подходят, то либо создание автономных подразделений со своей культурой, либо создание новой дочерней компании. Ресурс придется расширять за счет новых технологий, сотрудников и тд.
Если собственника такой план не устроит, нужно «подешевле», или менеджеры в большинстве неэффективные, то предсказать что-то тяжело. Скорее всего будет по одному из сценариев в самых популярных тут комментариях.
Ну, вполне обычная ситуация. Частая причина — ценности компании устарели и не соответствуют требованиям рынка, процессы внутри команды не могут обеспечить переход на новые ценности, ресурс ограничен.
Могут ли эффективные менеджеры помочь? Могут. Скорее всего новые направления востребованные рынком потребуют перемен в культуре компании, новых ценностей и оптимизированных процессов. Если собственник условного Ростелекома будет готов на такие глобальные перемены, то шанс есть. Предположу, что эффективные менеджеры выделят самые перспективные направления, сформируют новые ценности, проанализируют возможность адаптации старых процессов. Если процессы адаптируются, имеет смысл выделить новые подразделения внутри компании, занимающиеся перспективными направлениями. Ресурс используется имеющийся. Если процессы не подходят, то либо создание автономных подразделений со своей культурой, либо создание новой дочерней компании. Ресурс придется расширять за счет новых технологий, сотрудников и тд.
Если собственника такой план не устроит, нужно «подешевле», или менеджеры в большинстве неэффективные, то предсказать что-то тяжело. Скорее всего будет по одному из сценариев в самых популярных тут комментариях.
Какая в комментариях замечательная перепись людей, не имевших никакого опыта руководства, или имевшего его в лучшем случае на уровне "ставлю таски в жире двум своим коллегам".
Спасибо за хорошую статью.
Я не совсем согласен с тем, что с приходом «эффективного менеджера» растёт бюрократический аппарат. Точнее даже так, он растёт, но не за счёт организации новых должностей, а за счёт перевода туда технарей. То есть «эффективному менеджеру» в принципе не интересно как какое либо подразделение будет выполнять работу, ему интересно иметь во главе лояльную фигуру готовую прикрыть и взять на себя вину. А так будут делать только не компетентные сотрудники, которые понимают что занимают не своё место и держаться только за счёт демонстрации полной лояльности к начальству. В результате и «вымываются» технари, чьи места занимают сознательно нанятые не компетентные сотрудники. Рядовые работники так же сортируются по признаку лояльности, такому руководителю лучше плохой, но послушный работник, чем профессионал, который может его дискредитировать в глазах начальства. Вот в результате такой цепочки полностью вымываются нормальные руководители нижних звеньев, теряется нормальная ценность рядовых работников, что и крайне негативно сказывается на всех процессах.
Выводы о взращивании руководителей внутри или подборе руководителями профессионалов в данной области на мой взгляд очень верные. Кадры решают всё (с)
Я не совсем согласен с тем, что с приходом «эффективного менеджера» растёт бюрократический аппарат. Точнее даже так, он растёт, но не за счёт организации новых должностей, а за счёт перевода туда технарей. То есть «эффективному менеджеру» в принципе не интересно как какое либо подразделение будет выполнять работу, ему интересно иметь во главе лояльную фигуру готовую прикрыть и взять на себя вину. А так будут делать только не компетентные сотрудники, которые понимают что занимают не своё место и держаться только за счёт демонстрации полной лояльности к начальству. В результате и «вымываются» технари, чьи места занимают сознательно нанятые не компетентные сотрудники. Рядовые работники так же сортируются по признаку лояльности, такому руководителю лучше плохой, но послушный работник, чем профессионал, который может его дискредитировать в глазах начальства. Вот в результате такой цепочки полностью вымываются нормальные руководители нижних звеньев, теряется нормальная ценность рядовых работников, что и крайне негативно сказывается на всех процессах.
Выводы о взращивании руководителей внутри или подборе руководителями профессионалов в данной области на мой взгляд очень верные. Кадры решают всё (с)
Скажите, термин «профессионал» в Вашем понимании что? В общепринятом, этот тот, кто получает деньги за то, что он делает. Все. Ничего больше. Вы, мне кажется, вкладываете в термин «професионал» понятие «специалист высокого уровня».
Ну так вот… на моей памяти из-за вот таких ошибок, команды приходили к фейлу. Потому, что они месяцами говорили одно, а подразумевали другое. И каждый старался делать вид, что понимает о чем речь.
Одна из задач менеджера, для начала, создать «внутренний язык», который однозначно понимают все.
Скажите, кто из «профессионалов» должен это знать?
Что касается лояльности сотрудника, то это важная составляющая успешной команды. Это не значит, что он должен как баран делать что ему скажут. Как раз напротив. Ибо, выходит, что его начальник единственный на ком стоит компания. Но лояльность, это понимание значимости своей роли в существующем механизме. Готовность брать на себя, в рамках роли, ответственность и выполнять обязанности. А нелояльность, этот как раз постоянно оспаривать свою роль, что-то кому-то доказывать, считать, что все не правы и можно сделать в 100 раз лучше… Ну так нафига такой специалист «интересный»? Люди то собрались работать, а не его развлекать.
Ну так вот… на моей памяти из-за вот таких ошибок, команды приходили к фейлу. Потому, что они месяцами говорили одно, а подразумевали другое. И каждый старался делать вид, что понимает о чем речь.
Одна из задач менеджера, для начала, создать «внутренний язык», который однозначно понимают все.
Скажите, кто из «профессионалов» должен это знать?
Что касается лояльности сотрудника, то это важная составляющая успешной команды. Это не значит, что он должен как баран делать что ему скажут. Как раз напротив. Ибо, выходит, что его начальник единственный на ком стоит компания. Но лояльность, это понимание значимости своей роли в существующем механизме. Готовность брать на себя, в рамках роли, ответственность и выполнять обязанности. А нелояльность, этот как раз постоянно оспаривать свою роль, что-то кому-то доказывать, считать, что все не правы и можно сделать в 100 раз лучше… Ну так нафига такой специалист «интересный»? Люди то собрались работать, а не его развлекать.
А нелояльность, этот как раз постоянно оспаривать свою роль, что-то кому-то доказывать, считать, что все не правы и можно сделать в 100 раз лучше… Ну так нафига такой специалист «интересный»? Люди то собрались работать, а не его развлекать.
А если именно этот специалист прав? И даже хуже вариант — есть два специалиста, которые утверждают и доказывают, что все не правы, и можно сделать в 100 раз лучше. Один из них прав, а второй нет, но выяснится это через год.
Увольняем обоих, чтобы не выпендривались, и остаёмся при своих?
термин «профессионал» в Вашем понимании что?
ПРОФЕССИОНАЛ — мастер своего дела (экономический словарь)
Именно это значение, на мой взгляд, общепринятое. Представленное вами значение, скорее книжно-словарное, устаревшее.
Ну так вот… на моей памяти из-за вот таких ошибок, команды приходили к фейлу.
Из за ошибок в толковании терминов? Серьёзно?
Что касается лояльности сотрудника, то это важная составляющая успешной команды
Безусловно, но если лояльность становиться основным и практически единственным показателем, о какой профпригодности можно говорить?
www.google.ru/search?q=профессионал+определение&oq=профессионал+&aqs=chrome.0.35i39j0j69i57j0j69i61l2.3742j1j9&client=ms-android-samsung-ss&sourceid=chrome-mobile&ie=UTF-8
Я вам демонстрирую факт того, что задача менеджера создать механизм успешной работы команды. Это его роль. А не технарей.
Я вам демонстрирую факт того, что задача менеджера создать механизм успешной работы команды. Это его роль. А не технарей.
Ну в некотором смысле бюрократический аппарат действительно растет. если раньше работали по наитию и запискам в электронной почте, то в какой-то момент это все либо заваливается без контроля либо должно перейти на какой-то учет, документооборот, CRM и все такое.
А весь учет тоже требует времени, сил и усидчивости и в большой организации документирование своей работы у сотрудника может занять вплоть до 25% рабочего времени.
Конечно же это скучно и «бюрократия» (в отличии от любимого кодинга и внедрение ансибля на три сервера, происходящих на энтузиазме), но без этого вообще непонятно как все работает, кто виноват что прощелкали все дедлайны и кто виноват в том что клиент не может месяц получить фидбэк на минутный вопрос.
Помимо этого при достаточном росте и длительности существования возникают вопросы уже другого порядка, т.к. рано или поздно в офис придет с проверками МЧС, Росстандарт, СЭС и прочие государственные ребята и зададут вопросы про журналы ТБ, планы эвакуации, расположение огнетушителей и освещенность рабочих мест (и да, они по своему заботятся о жизни и здоровье работяг), на которые тоже надо иметь ответы, что влечет за собой увеличение штата/расходов и прочую «бюрократию». и хороший менеджер знает об этом, а не надеется что пронесёт.
А весь учет тоже требует времени, сил и усидчивости и в большой организации документирование своей работы у сотрудника может занять вплоть до 25% рабочего времени.
Конечно же это скучно и «бюрократия» (в отличии от любимого кодинга и внедрение ансибля на три сервера, происходящих на энтузиазме), но без этого вообще непонятно как все работает, кто виноват что прощелкали все дедлайны и кто виноват в том что клиент не может месяц получить фидбэк на минутный вопрос.
Помимо этого при достаточном росте и длительности существования возникают вопросы уже другого порядка, т.к. рано или поздно в офис придет с проверками МЧС, Росстандарт, СЭС и прочие государственные ребята и зададут вопросы про журналы ТБ, планы эвакуации, расположение огнетушителей и освещенность рабочих мест (и да, они по своему заботятся о жизни и здоровье работяг), на которые тоже надо иметь ответы, что влечет за собой увеличение штата/расходов и прочую «бюрократию». и хороший менеджер знает об этом, а не надеется что пронесёт.
Не прекратят. Можно расходиться.
Чтобы не пооучить себе в нагрузку эффективного менеджера, просто надо не жевать сопли, когда у владельца появляется в них потребность, а придумывать и предлагать эффективные реформы самих себя. Это несложно. Точно не сложнее битвы с эффективными менеджерами. Ведь надо понимать, почему их наняли — именно чтобы разрушить гегемонию технической элиты.
Как мне кажется одна из ключевых причин процветания «эффективных менеджеров» в имитации или отсутствии «миссии» компании.
Миссию очень многие недооценивают, считая ее бутафорией для «тимбилдинга». Но фишка в том, что как правило на первых этапах развития компании, пока у руля реальный собственник поднявший ее на своих плечах( часто из списка подобных компании нужно исключить компании связанные с государством или прокладки для выкачивания денег из другой компании, т.е. компании существующие в не конкурентных условиях ) миссия, может быть не четко сформулированная, присутствует.
Миссия, это то, что позволяет принимать решения, относительно ее выстраивается система ценностей компании позволяющая решить, что хорошо, а что плохо, что нужно, а что нет, что приоритетно, а что вторично.
Извлечение прибыли не может быть миссией компании, прибыль это необходимы фактор существования компании, но не миссия.
Обычно у «эффективных менеджеров» миссия подменена прибылью, эффективность и качество, метриками, люди, инструкциями и алгоритмами. Именно по этому им все равно чем руководить, они не являются симбиотом компании, не разделяют ее идеалы и «мечты».
Данные люди длительно время развиваются в рамках подобной парадигмы, не задач, не реальных целей, не людей, а цифр, отчетов, бумаг и инструкции.
Как результат, они очень хорошо умеют мутить именно эту воду, и сделав ее мутной великолепно себя чувствуют. Они даже могут не понимать, что убивают компанию, искренне веря в свою правоту.
Эти людям очень не хватает желания и умения делать, что-то руками в рамках руководимой компании.
Условно говоря, не может мебельным производство руководить человек не любящий мебель и не державший в руках стамеску. Человек у которого не возникает желания потрогать антикварный комод случайно оказавшийся в квартире снятой на AirBnB.
Миссию очень многие недооценивают, считая ее бутафорией для «тимбилдинга». Но фишка в том, что как правило на первых этапах развития компании, пока у руля реальный собственник поднявший ее на своих плечах( часто из списка подобных компании нужно исключить компании связанные с государством или прокладки для выкачивания денег из другой компании, т.е. компании существующие в не конкурентных условиях ) миссия, может быть не четко сформулированная, присутствует.
Миссия, это то, что позволяет принимать решения, относительно ее выстраивается система ценностей компании позволяющая решить, что хорошо, а что плохо, что нужно, а что нет, что приоритетно, а что вторично.
Извлечение прибыли не может быть миссией компании, прибыль это необходимы фактор существования компании, но не миссия.
Обычно у «эффективных менеджеров» миссия подменена прибылью, эффективность и качество, метриками, люди, инструкциями и алгоритмами. Именно по этому им все равно чем руководить, они не являются симбиотом компании, не разделяют ее идеалы и «мечты».
Данные люди длительно время развиваются в рамках подобной парадигмы, не задач, не реальных целей, не людей, а цифр, отчетов, бумаг и инструкции.
Как результат, они очень хорошо умеют мутить именно эту воду, и сделав ее мутной великолепно себя чувствуют. Они даже могут не понимать, что убивают компанию, искренне веря в свою правоту.
Эти людям очень не хватает желания и умения делать, что-то руками в рамках руководимой компании.
Условно говоря, не может мебельным производство руководить человек не любящий мебель и не державший в руках стамеску. Человек у которого не возникает желания потрогать антикварный комод случайно оказавшийся в квартире снятой на AirBnB.
Это всё хорошо и правильно, только собственников коммерческой организации (на этапе, когда она пошла по рукам посторонних людей) волнует прибыль, а не миссия.
Волновать их может, что угодно. Но живет кампания пока в ее основе идея. Если в основе компании зарабатывание денег, то все в ней и начинают зарабатывать деньги, только не компании, а себе, поскольку разделяют ее главную ценность — деньги. Такая компания может достаточно долго быть вполне успешной, особенно, если вокруг другие такие же компании, но потом рушиться с огромной скорость, поскольку весь каркас гнилой.
Условно говоря, не может мебельным производство руководить человек не любящий мебель и не державший в руках стамеску. Человек у которого не возникает желания потрогать антикварный комод случайно оказавшийся в квартире снятой на AirBnB.
Может. И будет делать это эффективнее, чем человек, любящий мебель, но ничего не понимающий в руководстве. Да, руководитель, любящий мебель, будет делать это еще лучше. Но говорить о том, что руководитель должен обязательно любить то, чем он руководит, некорректно.
Руководитель должен любить… руководить?
Такой руководитель весьма оперативно приведет компанию к краху или разделению. Потому что нельзя сделать что-то лучше других если ты это не любишь. Твой продукт будет хуже, сервис хуже, и вся компания будет выстроена, очень эффективно, но вокруг кривого стержня.
Вокруг такого человека не смогут объясняться люди которые горят продуктом. Которым нужны не деньги, а реализация.
Да, безусловно в управлении компании могут быть люди и не живущие ее идеей, но если такие люди начинают единолично принимать решения, они убивают компанию.
В в роли менеджера изначально заложен конфликт между метриками и деньгами с одной стороны, и идей и людьми с другой. У человека не любящего свое дело, данный конфликт отсутствует.
Вокруг такого человека не смогут объясняться люди которые горят продуктом. Которым нужны не деньги, а реализация.
Да, безусловно в управлении компании могут быть люди и не живущие ее идеей, но если такие люди начинают единолично принимать решения, они убивают компанию.
В в роли менеджера изначально заложен конфликт между метриками и деньгами с одной стороны, и идей и людьми с другой. У человека не любящего свое дело, данный конфликт отсутствует.
Точку зрения автора легко принять, разработка во все времена плохо переваривала менеджеров, в этом нет ничего удивительного. Похоже, само определение на протяжении статьи взято в кавычки по причине отсутствия понимания, какой менеджер может быть хорошим или плохим в контексте существующей проблемы. И, таким образом, выставляя в плохом свете и тех и других.
Есть такая старая добрая книга, называется Code Complete. В ней дается хорошее представление о том, чем по своей сути является создание продукта. Её вроде как многие читают, если не все, но похоже что полезное из неё выносят лишь еденицы. Кто-нибудь помнит чтобы в ней уделялось внимание менеджменту?
Набыдлокодили, выстрелило, и теперь не знаем что делать? Процесс внесения изменений в код багоёмкий и занимает слишком много времени? — Никакой менеджмент это не исправит. Использование методологий, автотестов, технологий, паттернов — это может разрешить часть проблем, если есть понимание зачем это нужно, но фундаментальным такое решение не будет.
Если нет понимания продукта на должном уровне, вряд ли возможно построить по настоящему качественное решение. Архитектура — не забыли еще такое слово? Она структурирует/определяет процесс разработки в рамках существующих требований (не менеджеры), упрощает реализацию типовых задач, переводит в плоскость компоновки лаконичных сущностей. Она может быть не везде нужна, но если возникают проблемы, послужившие началом появления этой статьи, то определенно потому что ей не уделяется должное внимание.
Есть такая старая добрая книга, называется Code Complete. В ней дается хорошее представление о том, чем по своей сути является создание продукта. Её вроде как многие читают, если не все, но похоже что полезное из неё выносят лишь еденицы. Кто-нибудь помнит чтобы в ней уделялось внимание менеджменту?
Набыдлокодили, выстрелило, и теперь не знаем что делать? Процесс внесения изменений в код багоёмкий и занимает слишком много времени? — Никакой менеджмент это не исправит. Использование методологий, автотестов, технологий, паттернов — это может разрешить часть проблем, если есть понимание зачем это нужно, но фундаментальным такое решение не будет.
Если нет понимания продукта на должном уровне, вряд ли возможно построить по настоящему качественное решение. Архитектура — не забыли еще такое слово? Она структурирует/определяет процесс разработки в рамках существующих требований (не менеджеры), упрощает реализацию типовых задач, переводит в плоскость компоновки лаконичных сущностей. Она может быть не везде нужна, но если возникают проблемы, послужившие началом появления этой статьи, то определенно потому что ей не уделяется должное внимание.
«Эффективные менеджеры» нарушили работу многих госпредприятий и госбюджетных организаций (вплоть до банкротств, невыплат зарплат и пр.), воруют (вон сколько в последнее время их было осуждено), получают огромные зарплаты (и про золотые парашюты не забывают); в результате их работы в т.ч. ухудшилось качество продукции Роскосмоса (падают ракеты), до этого еще Сердюков разваливал армию, проводится оптимизация медицины и образования (объединения, ликвидации, коммерциализация и т.д.), и т.д.
На лекциях в ВУЗе нам это преподносили как «войну энтузиастов с профессионалами». И появление «эффективных менеджеров» является одним из этапов жизненного цикла компании.
Появление эффективных менеджеров всегда (не, не так) ВСЕГДА! означает деградацию и смерть компании.
Законы Паркинсона всесильны, потому что они верны.
Кстати, именно эффективные менеджеры разрушили СССР в смысле социализма. Это получилось легко, потому, что степень централизации была очень высока. С капитализмом такое получается тяжелее, потому, что система более распределённая.
Но если посмотреть на комсомольских секретарей и нынешних американских эффективных менеджеров (им не обязательно быть российскими), то покажется, что попал в 80е… Это клоны из одной пробирки! Единственное отличие — у тех костюмчики были подешевле.
Законы Паркинсона всесильны, потому что они верны.
Кстати, именно эффективные менеджеры разрушили СССР в смысле социализма. Это получилось легко, потому, что степень централизации была очень высока. С капитализмом такое получается тяжелее, потому, что система более распределённая.
Но если посмотреть на комсомольских секретарей и нынешних американских эффективных менеджеров (им не обязательно быть российскими), то покажется, что попал в 80е… Это клоны из одной пробирки! Единственное отличие — у тех костюмчики были подешевле.
Про гос и около-гос конторы разговор отдельный, там всё намного хуже, чем большинство себе представляет…
… контролировать уборщиц, чтобы они не протирали серверные стойки влажной тряпкой.
А шкафы купить? — Нет?
Я бы заменил слово «эффект» на «результат». Бизнесу результаты нужны, а не эффекты, и результаты положительные.
Потом непонятно, почему владелец бизнеса или как минимум генеральный директор не создает сам, а если не может, то не вникает во внедряемые менеджерами метрики. Это все равно что сказать: «я вас нанял, теперь идите и зарабатывайте мне деньги». В РФ такие вещи не проходят. И если в компании появляются описанные в статье менеджеры, то владельцы и генеральный директор просто неадекватные. И поэтому да, такая компания должна умереть. Аминь.
Потом непонятно, почему владелец бизнеса или как минимум генеральный директор не создает сам, а если не может, то не вникает во внедряемые менеджерами метрики. Это все равно что сказать: «я вас нанял, теперь идите и зарабатывайте мне деньги». В РФ такие вещи не проходят. И если в компании появляются описанные в статье менеджеры, то владельцы и генеральный директор просто неадекватные. И поэтому да, такая компания должна умереть. Аминь.
Подскажите, вот была такая известная фирма как
Digital Equipment Corporation, выпускавшая Компьютеры VAX c OpenVMS, Alpha серверы с DEC Alpha c Digital Unix на отличном ядре, легендарную серию мини-ЭВМ PDP… включая PDP11.
Выпускающая кучу софта, включая банковскую систему…
Она от чего загнулась?
Тоже манагеры эффективные доконали?
Ведь казалось, что серьезнее фирмы Digital просто нет, или почти нет, — а вот…
Digital Equipment Corporation, выпускавшая Компьютеры VAX c OpenVMS, Alpha серверы с DEC Alpha c Digital Unix на отличном ядре, легендарную серию мини-ЭВМ PDP… включая PDP11.
Выпускающая кучу софта, включая банковскую систему…
Она от чего загнулась?
Тоже манагеры эффективные доконали?
Ведь казалось, что серьезнее фирмы Digital просто нет, или почти нет, — а вот…
Была ещё фирма Моторола…
Была ещё фирма Нортель…
Была ещё фирма Нортель…
Digital Equipment Corporation
Провал конкретно этой компании чуть ли не в учебниках описан. Если вкратце — у них были все ресурсы, для того, чтоб преуспеть, но процессы не отвечали условиям, которые диктовал рынок персональных компьютеров. Их процессы были выстроены вокруг создания миникомпьютеров — дизайн и сборка всех компонентов на своей стороне. Создание нового продукта занимало несколько лет. Когда начался бум PC, которые проектировались и выпускались гораздо быстрее, а большая часть их компонентов отдавались на аутсорс, Digital просто не успевали со своими процессами и ценностями. В компании не оказалось эффективных менеджеров, способных предвидеть ситуацию на рынке и начать перестраивать процессы. То есть, Digital — хороший пример того, как компания с огромным ресурсом, технологиями и опытом, не смогла в PC из-за того, что не смогла измениться. Потому что менеджмент был неэффективен.
В компании не оказалось эффективных менеджеров, способных предвидеть ситуацию на рынке и начать перестраивать процессы.
Предвидеть ситуацию — не задача менеджеров, это вообще не задача.
Так что тут варианта два — либо ситуацию предвидели и была задача перестроить процессы, но с ней не справились, и тогда виноваты менеджеры, либо такой задачи не стояло и результат — просто естественный процесс, который ждет рано или поздно любую компанию.
Ну, справедливости ради — из серьёзных людей никто не предвидел бума ПК. Из ИТшной молодёжи 70х тоже немногие отнеслись к ПК с уважением.
«Вы вообще знаете, что такое ЭВМ? ЭВМ — это 100 квадратных метров площади, 25 человек обслуживающего персонала и 30 литров спирта ежемесячно!»
«Вы вообще знаете, что такое ЭВМ? ЭВМ — это 100 квадратных метров площади, 25 человек обслуживающего персонала и 30 литров спирта ежемесячно!»
да при чем тут бум PC?
Они делали лучшее, легендарное серверное железо, лучшие операционки для СЕРВЕРОВ,
и рынок этот никуда не уходил и сейчас не уходит.
Если не ошибаюсь, IBM сама скинула с себя PC часть.
Они делали лучшее, легендарное серверное железо, лучшие операционки для СЕРВЕРОВ,
и рынок этот никуда не уходил и сейчас не уходит.
Если не ошибаюсь, IBM сама скинула с себя PC часть.
Вычислить «эффективного» очень легко:
Он/она всё знает и умеет, но:
1) Не умеет пользоваться проектором. При этом инструктаж был.
2) Не умеет пользоваться офисной охранной сигнализацией (сдать/снять с охраны). При этом инструктаж был.
3) Вытряхнуть отходы из кофемашины взападло. Ровно как и засыпать зёрна из коробки рядом. Хотя попадаются индивидуумы, которые могут засыпать растворимый кофе в кофемашину (facepalm).
4) Поменять бутыль в диспенсере (если мужчина) взападло.
5) Поставить чайник кипятиться, если он пустой после тебя — взападло.
Он/она всё знает и умеет, но:
1) Не умеет пользоваться проектором. При этом инструктаж был.
2) Не умеет пользоваться офисной охранной сигнализацией (сдать/снять с охраны). При этом инструктаж был.
3) Вытряхнуть отходы из кофемашины взападло. Ровно как и засыпать зёрна из коробки рядом. Хотя попадаются индивидуумы, которые могут засыпать растворимый кофе в кофемашину (facepalm).
4) Поменять бутыль в диспенсере (если мужчина) взападло.
5) Поставить чайник кипятиться, если он пустой после тебя — взападло.
Мне тут один молодой товарищ объяснял, что повторно кипятить воду вредно,
мол тяжелая вода там появляется…
Блин, поколение пепси, что-то где-то поверхностно прочитал, или скорее увидел,
и во всё верят.
Моск не хочет подумать — а сколько времени надо воду эту грешную кипятить,
чтобы там что-то вредно-тяжелое появилось…
Была бы вода из крана — там соли, хлорка,… еще можно понять, но когда говорят,
про воду из «поилки», где она практически дистиллированная, да еще и в контексте тяжелой воды…
Но это так, к слову… — мне понравились ваши критерии эффективного манагера.
мол тяжелая вода там появляется…
Блин, поколение пепси, что-то где-то поверхностно прочитал, или скорее увидел,
и во всё верят.
Моск не хочет подумать — а сколько времени надо воду эту грешную кипятить,
чтобы там что-то вредно-тяжелое появилось…
Была бы вода из крана — там соли, хлорка,… еще можно понять, но когда говорят,
про воду из «поилки», где она практически дистиллированная, да еще и в контексте тяжелой воды…
Но это так, к слову… — мне понравились ваши критерии эффективного манагера.
Да тут дело даже не в возрасте — мне попадаются фрукты, которым далеко за 30 и начинают всех вокруг учить жизни. Тем не менее я рад, что вы согласны с некотороми моими тезисами, однако судя по «минусам», большинство этого формума как раз состоит из этих эффективных. З.Ы. про кипячение воды уже столько вбросов по всяим РенТВ и интернетам было.
Все руководители должны иметь больший опыт в разработке, нежели их подчиненные. Обычно это разрыв в 3-5 лет между ними.
Между сроком работы и опытом не всегда есть корреляция.
Иногда 10 лет опыта — это 1 год опыта, повторенный 10 раз.
Несмотря на негативный окрас статьи, в целом она неплохая. Хотя больше похожа на крик души. Тема руководства всегда и везде очень болезненна. Нам всегда кажется, что мы могли бы руководитель лучше и качественнее, чем наши начальники. Ровно до тех пор пока не оказываемся на месте начальников.
Обилие различных метрик существует для иллюзии контроля. Чем шире зона ответственности руководителя, тем ему больше хочется контролировать. И тогда растут эти разные системы оценки. Когда есть куча цифирок, начальнику кажется что он в курсе происходящего в отделе. И когда начальник решает, что только на цифирках можно принимать решения, он становится «эффективным».
Порой после смены руководства, вносятся очень странные изменения в процесс работы. Не однократно это наблюдал. Зачастую эти изменения не имеют никакого отношения к реалиям. Это связано с тем, что руководитель не понимает происходящих процессов, но ему надо себя зарекомендовать. Ему самому в этой ситуации кажется, что он что-то меняет, и меняет к лучшему. Перефразируя мысль одного, широко известного в узких кругах, прокрастинолога: Из двух задач, срочной и важной, человек сделает понятную. В управлении так же. Если нет понимания, что происходит, но есть желание что-то делать, то «что-то» и делается. Например случай из практики, ИТ отдел торговой компании, утонул в техническом долге, после резкого внедрения одного продукта, и отдел разработки 80% времени занимается тех поддержкой и латанием дыр в костылях, чтобы всё не рухнуло. Дальнейшая автоматизация же вошла в ступор, а временные проходные решения начинали костенеть. Руководство отдела же сосредоточилось на составлении планов для руководства, переименованием должностей разработчиков, разработкой КПИ, внедрением нового режима контроля рабочего времени. Это от того, что руководство не желая понимать реальные проблемы, оно начинает дергать то, что где-то когда то делало. Понять причины застоя в автоматизации сложно, а вот накрячить людей демотивацией проще и понятнее.
Можно много критериев приводить «эффективных» и эффективных управленцев. Для себя же выявил один самый главный – начальник должен помогать подчиненным, а не мешать. Начальник большую часть времени должен не контролировать работу подчиненных, а обеспечивать условия работы, создавая комфортную среду. Хотя, несомненно, контроль важен. Но он вторичен. Руководитель должен получать задачу, определять в ней проблемную область и выделять варианты решения проблемы. Для определения проблемы и решений ему необходимо проведение совещаний с подчиненными, так как проф квалификация руководителя всегда ниже чем у его подчиненных (тут важно чтобы она вообще присутствовала, иначе этому начальнику какой-нить ушлый программист так наездит по ушам, что добавление одной строчки в код, будет выглядеть как проект с бюджетом на год). После определения задач, руководитель принимает решения о приоритетах решения задач. И это делает только он, так как с места разработчика не видна вся картина. И далее уже ставит задачу и следит за её выполнением. Получив сверху люлей от вышестоящего руководства, хороший начальник не передает люли ниже, а выступает перед подчиненными с пламенной речью, после которой у тех вырастают крылья и работают в разы качественнее.
В любом случае эффективный менеджер — это человек, который способен понять реальные, глубинные проблемы, и выработать алгоритм их решения, от которого все кругом довольны. Это конечно утопия, но каждый руководитель должен к этому стремиться.
Обилие различных метрик существует для иллюзии контроля. Чем шире зона ответственности руководителя, тем ему больше хочется контролировать. И тогда растут эти разные системы оценки. Когда есть куча цифирок, начальнику кажется что он в курсе происходящего в отделе. И когда начальник решает, что только на цифирках можно принимать решения, он становится «эффективным».
Порой после смены руководства, вносятся очень странные изменения в процесс работы. Не однократно это наблюдал. Зачастую эти изменения не имеют никакого отношения к реалиям. Это связано с тем, что руководитель не понимает происходящих процессов, но ему надо себя зарекомендовать. Ему самому в этой ситуации кажется, что он что-то меняет, и меняет к лучшему. Перефразируя мысль одного, широко известного в узких кругах, прокрастинолога: Из двух задач, срочной и важной, человек сделает понятную. В управлении так же. Если нет понимания, что происходит, но есть желание что-то делать, то «что-то» и делается. Например случай из практики, ИТ отдел торговой компании, утонул в техническом долге, после резкого внедрения одного продукта, и отдел разработки 80% времени занимается тех поддержкой и латанием дыр в костылях, чтобы всё не рухнуло. Дальнейшая автоматизация же вошла в ступор, а временные проходные решения начинали костенеть. Руководство отдела же сосредоточилось на составлении планов для руководства, переименованием должностей разработчиков, разработкой КПИ, внедрением нового режима контроля рабочего времени. Это от того, что руководство не желая понимать реальные проблемы, оно начинает дергать то, что где-то когда то делало. Понять причины застоя в автоматизации сложно, а вот накрячить людей демотивацией проще и понятнее.
Можно много критериев приводить «эффективных» и эффективных управленцев. Для себя же выявил один самый главный – начальник должен помогать подчиненным, а не мешать. Начальник большую часть времени должен не контролировать работу подчиненных, а обеспечивать условия работы, создавая комфортную среду. Хотя, несомненно, контроль важен. Но он вторичен. Руководитель должен получать задачу, определять в ней проблемную область и выделять варианты решения проблемы. Для определения проблемы и решений ему необходимо проведение совещаний с подчиненными, так как проф квалификация руководителя всегда ниже чем у его подчиненных (тут важно чтобы она вообще присутствовала, иначе этому начальнику какой-нить ушлый программист так наездит по ушам, что добавление одной строчки в код, будет выглядеть как проект с бюджетом на год). После определения задач, руководитель принимает решения о приоритетах решения задач. И это делает только он, так как с места разработчика не видна вся картина. И далее уже ставит задачу и следит за её выполнением. Получив сверху люлей от вышестоящего руководства, хороший начальник не передает люли ниже, а выступает перед подчиненными с пламенной речью, после которой у тех вырастают крылья и работают в разы качественнее.
В любом случае эффективный менеджер — это человек, который способен понять реальные, глубинные проблемы, и выработать алгоритм их решения, от которого все кругом довольны. Это конечно утопия, но каждый руководитель должен к этому стремиться.
Диссертационно.
Но вот здесь: «Не бывает «частичного соответствия» позиции. Кандидат либо подходит, либо нет. Особенно касается руководящих должностей» на мой взгляд вы неправы совершенно.
Не бывает так чтобы вот и образование строго профильное, и опыт работы огромный (и свежий! это очень важно), и делал человек на предыдущем месте то же что и у вас, и специфика с прошлым опытом у вас одинаковая, и курсы-сертификаты, и возраст, и пол (да-да, пол!) и все-все-все. И еще 100500 пожеланий можно выставить. Кстати, это обоюдно — надо ведь и чтобы у вас такого руководителя/работника вот прямо все-все устраивало. Короче идеальная семейная пара, как в болливудах, НЕВОЗМОЖНА. Всегда что-то да закрадется в досье что безупречного арийца, что ваше.
Эрго: с такой максимой как у вас вы не найдете никогда никого. Ну, короче, будете искать принцев на белом мерсе, ага. Всю оставшуюся жизнь. А в реальности ВСЕГДА приходится идти на компромисс, если нужен человек, а не как обычно.
Но вот здесь: «Не бывает «частичного соответствия» позиции. Кандидат либо подходит, либо нет. Особенно касается руководящих должностей» на мой взгляд вы неправы совершенно.
Не бывает так чтобы вот и образование строго профильное, и опыт работы огромный (и свежий! это очень важно), и делал человек на предыдущем месте то же что и у вас, и специфика с прошлым опытом у вас одинаковая, и курсы-сертификаты, и возраст, и пол (да-да, пол!) и все-все-все. И еще 100500 пожеланий можно выставить. Кстати, это обоюдно — надо ведь и чтобы у вас такого руководителя/работника вот прямо все-все устраивало. Короче идеальная семейная пара, как в болливудах, НЕВОЗМОЖНА. Всегда что-то да закрадется в досье что безупречного арийца, что ваше.
Эрго: с такой максимой как у вас вы не найдете никогда никого. Ну, короче, будете искать принцев на белом мерсе, ага. Всю оставшуюся жизнь. А в реальности ВСЕГДА приходится идти на компромисс, если нужен человек, а не как обычно.
В конце статьи, конечно, замечательные постулаты. Осталось ответить на вопрос, где этих руководителей найти.
Особенно понравилось «Не бывает «частичного соответствия» позиции». Могу только пожелать удачи искать идеального кандидата в течение 15 лет.
Особенно понравилось «Не бывает «частичного соответствия» позиции». Могу только пожелать удачи искать идеального кандидата в течение 15 лет.
Все руководители должны иметь больший опыт в разработке, нежели их подчиненные. Обычно это разрыв в 3-5 лет между ними.
Формально из-за этого пункта — 80, а то и 90 процентов манагеров IT должны просто уйти из сферы. Ага — щаз они прям собрались и побежали.
А с какой целью Crossover написала эту статью, чем компания пытается поделиться с сообществом?
Отличная статья!
Может кто заморочился с переводом на английский? Я бы отправил это некоторым людям.
Может кто заморочился с переводом на английский? Я бы отправил это некоторым людям.
А как надо говорить? Си Диез?
Прочитал статью, прочитал комментарии… Созрел вопрос.
Как наняться менеджером, если качества хорошего менеджера у тебя есть, но тебе 25 и у тебя не MBA, а незаконченное PhD в физике?
Образование структурное и системное. Владею статистикой (не только в области манипулирования) и продвинутым мат. аппаратом. Программирую сам плохо, но понимаю все, о чем говорят программисты. Был во многих коллективах, видел эффективный и неэффективный менеджмент, причем, в разных средах (безнес, IT, наука, образование) и трех странах (Украина, РФ, США)
На меня повесили менеджмент лабы. Принимал убитый хаос (абсолютная дезорганизация, молоток могли искать полчаса). Сейчас лаба работает как часы. В ней есть все, что нужно, химикаты обновляются, отходы сдаются, халаты стираются, инструменты сложены. И все это сделано мной. Но ты никому это не докажешь — есть только слова. В крайнем случае — пара предложений от руковода.
Заведовал финансами и хоз. частью рок-группы (была своя база, оборудование и т.д.).
Да, распалась. По естественным причинам (взросление, профессиональное развитие). Но при распаде съезд и закрытие прошли без проблем. Аппарат вывезен, сложен и финансы остались еще на 2 переезда.
+ Знаю за собой естественную административную жилку.
+ Еще много мелочных факторов и разного опыта
+ Правильное целеполагание (эффективность, безопасность, надежность)
Но все это СЛОВА и утверждения. Да, некоторые из них можно подтвердить словами других людей, но от этого мне не предложат позицию тимлида или даже младшего менеджера.
Я знаю очень важную вещь — нет ничего хуже, чем человек не на своем месте.
А именно это и происходит.
Хороший менеджер не обязательно будет хорошим программистом. Но если ты не будешь в топе по «показателям» — то и менеджером ты не станешь. А менеджером делают синьора Васю, которому менеджить вот вообще не в дугу. Потому что его — кодить.
Точно такое же происходит в науке, когда классный ученый, который показал себя как офигительный эксперт, становится профессором, формирует свою научную группу и…
случается жопа.
Потому что он был супер-экспертом в среде с налаженным процессом управления проектами, а создать сам не может.
Но еще хуже, когда сильные ученые, начинают верить в то, что они хорошие менеджеры.
Итак вопрос уже прозвучал, но я повторю:
Как стать менеджером в нормальном проекте (а не в том гумусе, который на сайтах вакансий), когда ты — скилованный ноунейм?
Как наняться менеджером, если качества хорошего менеджера у тебя есть, но тебе 25 и у тебя не MBA, а незаконченное PhD в физике?
Образование структурное и системное. Владею статистикой (не только в области манипулирования) и продвинутым мат. аппаратом. Программирую сам плохо, но понимаю все, о чем говорят программисты. Был во многих коллективах, видел эффективный и неэффективный менеджмент, причем, в разных средах (безнес, IT, наука, образование) и трех странах (Украина, РФ, США)
На меня повесили менеджмент лабы. Принимал убитый хаос (абсолютная дезорганизация, молоток могли искать полчаса). Сейчас лаба работает как часы. В ней есть все, что нужно, химикаты обновляются, отходы сдаются, халаты стираются, инструменты сложены. И все это сделано мной. Но ты никому это не докажешь — есть только слова. В крайнем случае — пара предложений от руковода.
Заведовал финансами и хоз. частью рок-группы (была своя база, оборудование и т.д.).
Да, распалась. По естественным причинам (взросление, профессиональное развитие). Но при распаде съезд и закрытие прошли без проблем. Аппарат вывезен, сложен и финансы остались еще на 2 переезда.
+ Знаю за собой естественную административную жилку.
+ Еще много мелочных факторов и разного опыта
+ Правильное целеполагание (эффективность, безопасность, надежность)
Но все это СЛОВА и утверждения. Да, некоторые из них можно подтвердить словами других людей, но от этого мне не предложат позицию тимлида или даже младшего менеджера.
Я знаю очень важную вещь — нет ничего хуже, чем человек не на своем месте.
А именно это и происходит.
Хороший менеджер не обязательно будет хорошим программистом. Но если ты не будешь в топе по «показателям» — то и менеджером ты не станешь. А менеджером делают синьора Васю, которому менеджить вот вообще не в дугу. Потому что его — кодить.
Точно такое же происходит в науке, когда классный ученый, который показал себя как офигительный эксперт, становится профессором, формирует свою научную группу и…
случается жопа.
Потому что он был супер-экспертом в среде с налаженным процессом управления проектами, а создать сам не может.
Но еще хуже, когда сильные ученые, начинают верить в то, что они хорошие менеджеры.
Итак вопрос уже прозвучал, но я повторю:
Как стать менеджером в нормальном проекте (а не в том гумусе, который на сайтах вакансий), когда ты — скилованный ноунейм?
Sign up to leave a comment.
Прекратите нанимать «эффективных менеджеров». Они не только бесполезны, но и вредны