Комментарии 21
Кто так думает? Хватит уже писать прописные истины (тем более переводить). Это на уровне учебника для 8 класса.
Наверное, вы просто уже занимаетесь менеджментом :-) Инженерам эта истина открывается далеко не сразу и не всем.
Имхо, в статье совсем не про мнение инженеров говорится. Если инженеры в компании начинают настолько замечать менеджмент, что о нём начинают рассуждать, значит, менеджмент хреновый.
Такие мифы бродят именно среди инженеров. Менеджеры уже все на своей шкуре прочувствовали :-)
Ещё раз повторюсь — если инженеры реально рассуждают о том, что менеджмент у них хреновый, значит, так оно и есть. Причём менеджмент — это организация процесса, а совсем не Василий Пупкин, менеджер проекта (TM). Хотя, конечно, при наличии выделенного менеджера (человека, который и отвечает за качество организации комфортного и эффективного процесса), то хреновый менеджмент — целиком и полностью его вина.
Менеджмент — не только в контроле времени и внедрении неких пресловутых методологий, проводимых кем-то вышестоящим. Менеджмент — в умении разделять, объединять, мотивировать, планировать (хотя бы в далёком приближении) и ещё куче глаголов.
Именно поэтому в маленьких командах успешно справляются без выделенных менеджеров — разделение ответственности, объединение усилий (в том числе налаживание коммуникаций), мотивация и планирование спускается не сверху, а рождается эволюционно.
Вы, похоже, менеджер. Так вот, если вы думаете, что вся беда в мифах среди инженеров — у меня для вас крайне плохие новости.
Менеджмент — не только в контроле времени и внедрении неких пресловутых методологий, проводимых кем-то вышестоящим. Менеджмент — в умении разделять, объединять, мотивировать, планировать (хотя бы в далёком приближении) и ещё куче глаголов.
Именно поэтому в маленьких командах успешно справляются без выделенных менеджеров — разделение ответственности, объединение усилий (в том числе налаживание коммуникаций), мотивация и планирование спускается не сверху, а рождается эволюционно.
Вы, похоже, менеджер. Так вот, если вы думаете, что вся беда в мифах среди инженеров — у меня для вас крайне плохие новости.
Поскольку вы меня совсем не знаете и не потрудили погуглить, на ваш комментарий я отвечать не буду ибо не по адресу :-)
НЛО прилетело и опубликовало эту надпись здесь
Вот если бы я была профессором экономики, то ваш комментарий про маленькие команды и прочее, возможно открыл бы мне глаза :-)
Все, что вы там написали, я знаю не хуже вас. На своей шкуре все это пройдено — и инженерная стезя, и стезя руководителя маленькой команды. Мои мытарства как разработчика и руководителя команды подробно описаны в статьях на этом же ресурсе. Поэтому когда мне пишут, что я верю в какие-то мифы, мне смешно :-)
Заявляю вам со всей ответственностью — взгляд меняется очень сильно, когда ты переходишь в менеджеры из инженеров. Особенно, если при этом продолжаешь оставаться инженером, архитектором, аналитиком. И пока ты не попал на этот уровень — в голове и правда много мифов :-) Это я не только по себе сужу, наблюдала этот переход многократно у других.
Если вы его еще не совершили, мы вряд ли поймем друг друга.
Все, что вы там написали, я знаю не хуже вас. На своей шкуре все это пройдено — и инженерная стезя, и стезя руководителя маленькой команды. Мои мытарства как разработчика и руководителя команды подробно описаны в статьях на этом же ресурсе. Поэтому когда мне пишут, что я верю в какие-то мифы, мне смешно :-)
Заявляю вам со всей ответственностью — взгляд меняется очень сильно, когда ты переходишь в менеджеры из инженеров. Особенно, если при этом продолжаешь оставаться инженером, архитектором, аналитиком. И пока ты не попал на этот уровень — в голове и правда много мифов :-) Это я не только по себе сужу, наблюдала этот переход многократно у других.
Если вы его еще не совершили, мы вряд ли поймем друг друга.
НЛО прилетело и опубликовало эту надпись здесь
Я, действительно, очень рад за вас, если вас окружают только люди, для которых все это прописные истины. Мне же регулярно приходится встречать людей (инженеров), для которых это не так, и автору оригинальной статьи, судя по всему, тоже.
Имхо, вы совсем не поняли статью.
Почему вы так думаете?
Потому что проблема менеджмента не в инженерах, а в менеджерах — их отсутствии (когда они нужны), наличии (когда можно обойтись без них) или некомпетентности (когда они есть и нужны, но не такие).
Безусловно, вы правы — на менеджерах лежит большая часть ответственности, но ведь не только на них. Я упомянул инженеров, потому что в моем личном кругу общения больше инженеров, чем менеджеров. Однако, на мой взгляд, периодически ошибаются и те, и другие.
Например, если менеджер предлагает инженеру пойти в менеджмент в качестве «награды» за хорошую работу, то это, очевидно, его (менеджера) ошибка, ибо награда это весьма спорная, и для работы в менеджменте нужен другой набор навыков, которыми человек может и не обладать.
НО. Если инженер соглашается на такое предложение, считая, что переход в менеджмент является естественным развитием его карьеры, то он тоже совершает ошибку, потому что это не развитие, а смена карьеры.
Например, если менеджер предлагает инженеру пойти в менеджмент в качестве «награды» за хорошую работу, то это, очевидно, его (менеджера) ошибка, ибо награда это весьма спорная, и для работы в менеджменте нужен другой набор навыков, которыми человек может и не обладать.
НО. Если инженер соглашается на такое предложение, считая, что переход в менеджмент является естественным развитием его карьеры, то он тоже совершает ошибку, потому что это не развитие, а смена карьеры.
НЛО прилетело и опубликовало эту надпись здесь
Мифов всё-таки больше, чем три слона, которые стоят на большой черепахе..., но то, что менеджмент — это не карьерное продвижение, а смена карьеры — согласен, но лучше поздно, чем никогда. Чтобы делать именно свою работу (которая вам нравится, которую вы любите) нужно стать менеджером, иначе им станет другой и вы будете делать не свою, а его работу. К сожалению, эта истина не очень очевидна.
У нас, к сожалению, менеджеры чаще всего являются всего лишь диспетчерами — прокладками между заказчиком или вышестоящим руководством и конечными исполнителями. Конечно, инженеры таких «менеджеров» не любят. Никто не любит, когда им мешают работать.
С другой стороны, все любят, когда процесс налажен хорошо.
Я работал в различных компаниях — где был хороший менеджмент при наличии менеджеров, плохой менеджмент при наличии менеджеров и хороший менеджмент при отсутствии менеджеров (процесс строили сами, почти демократическим путём, с учётом того, что вышестоящее руководство всё-таки хочет иметь возможность получать информацию о состоянии проекта).
Последняя феерия менеджмента наблюдалась в следующем виде: регулярно спускаются новые «процессы» с необходимостью «информировать всех заинтересованных лиц», при этом процессы с самими исполнителями никак не обсуждаются — всем просто пофиг, удобно это или нет («ну что тебе, сложно письмо написать?»)
Причём люди не понимали того мудачества, которое они творили.
Пример:
Что у нас было: Jira с простым процессом, поддерживающим задачи по рефакторингу, система контроля версий с поддержкой веток, CI с тестами (какими-никакими).
Что от нас хотели: при рефакторинге писать письмо всему менеджменту проекта со следующим содержанием:
1. Короткое описание рефакторинга.
2. Что, где и зачем хотят поменять.
3. Ссылка на Jira.
Т.е. рефакторинг этими людьми воспринимался не как необходимость, а как нечто исключительное (проекту при этом 5 лет и никакой спешки нет). К сожалению, после непринятия моего «идите вы в жопу со своими нововведениями» пришлось просто забить и уволиться. Правда, так получилось, что в день, когда принёс заявление «delivery-менеджеру» (напридумывали, мать их), тот самый менеджер собрал нас всех (30 человек) и сообщил — завтра проект закрывается.
Так вот, по моему опыту, около 2/3 проектов закрывается до публичного релиза по вине менеджеров — их необходимости «делать свою работу» (понятно, надо же «зарабатывать», а не «получать») и реализовывать свои «великие, уникальные(TM) (либо зарекомендовавшие себя(TM)) идеи и процессы».
С другой стороны, все любят, когда процесс налажен хорошо.
Я работал в различных компаниях — где был хороший менеджмент при наличии менеджеров, плохой менеджмент при наличии менеджеров и хороший менеджмент при отсутствии менеджеров (процесс строили сами, почти демократическим путём, с учётом того, что вышестоящее руководство всё-таки хочет иметь возможность получать информацию о состоянии проекта).
Последняя феерия менеджмента наблюдалась в следующем виде: регулярно спускаются новые «процессы» с необходимостью «информировать всех заинтересованных лиц», при этом процессы с самими исполнителями никак не обсуждаются — всем просто пофиг, удобно это или нет («ну что тебе, сложно письмо написать?»)
Причём люди не понимали того мудачества, которое они творили.
Пример:
Что у нас было: Jira с простым процессом, поддерживающим задачи по рефакторингу, система контроля версий с поддержкой веток, CI с тестами (какими-никакими).
Что от нас хотели: при рефакторинге писать письмо всему менеджменту проекта со следующим содержанием:
1. Короткое описание рефакторинга.
2. Что, где и зачем хотят поменять.
3. Ссылка на Jira.
Т.е. рефакторинг этими людьми воспринимался не как необходимость, а как нечто исключительное (проекту при этом 5 лет и никакой спешки нет). К сожалению, после непринятия моего «идите вы в жопу со своими нововведениями» пришлось просто забить и уволиться. Правда, так получилось, что в день, когда принёс заявление «delivery-менеджеру» (напридумывали, мать их), тот самый менеджер собрал нас всех (30 человек) и сообщил — завтра проект закрывается.
Так вот, по моему опыту, около 2/3 проектов закрывается до публичного релиза по вине менеджеров — их необходимости «делать свою работу» (понятно, надо же «зарабатывать», а не «получать») и реализовывать свои «великие, уникальные(TM) (либо зарекомендовавшие себя(TM)) идеи и процессы».
В то же время у нас был опыт почти демократического налаживания процесса. Это было в команде из 20 разработчиков. Реализовывалось четырьмя тимлидами.
Шаги были следующие:
0. В команду пришло три новых тимлида (достаточно бурное расширение компании).
1. Собрались на ППР.
2. Решили, что происходит какая-то шляпа.
3. Оповестили руководство.
4. Получили добро на разработку более простого и удобного процесса.
5. Разработали процесс.
6. Провели пару презентаций с красочными презентациями «с картинками».
7. Внедрили.
До:
1. Отчёты: ежедневно в свой блог в интранете (с распиской по часам), позадачно в трекер (с логированием по минутам — взял задачу, поработал с ней, отписал, сколько потратил времени и на что), еженедельно перед тимлидом в Excel-файлах на файловый сервер (в формате: задача — часы по одной в строчку). Ежемесячно с указанием суммарно затраченных часов для оплаты в Excel на файловый сервис под аппрув тимлида.
2. Задачи: спланировать общее время на реализацию, реализовать, протестировать, смёржить, протестировать после тест-релиза, протестировать после релиза.
Результат:
1. Отчёт позадачно в трекер (с логированием по минутам), ежемесячно с суммой затраченных часов для оплаты для аппрува тимлидом.
2. Задача: спланировать время, если времени планируется много — кинуть тимлиду на аппрув, реализовать, кинуть на код-ревью тимлиду, кинуть мёрж-реквест тестировщикам.
Короче, убрали лишнее, добавили нужное, разделили ответственность.
Шаги были следующие:
0. В команду пришло три новых тимлида (достаточно бурное расширение компании).
1. Собрались на ППР.
2. Решили, что происходит какая-то шляпа.
3. Оповестили руководство.
4. Получили добро на разработку более простого и удобного процесса.
5. Разработали процесс.
6. Провели пару презентаций с красочными презентациями «с картинками».
7. Внедрили.
До:
1. Отчёты: ежедневно в свой блог в интранете (с распиской по часам), позадачно в трекер (с логированием по минутам — взял задачу, поработал с ней, отписал, сколько потратил времени и на что), еженедельно перед тимлидом в Excel-файлах на файловый сервер (в формате: задача — часы по одной в строчку). Ежемесячно с указанием суммарно затраченных часов для оплаты в Excel на файловый сервис под аппрув тимлида.
2. Задачи: спланировать общее время на реализацию, реализовать, протестировать, смёржить, протестировать после тест-релиза, протестировать после релиза.
Результат:
1. Отчёт позадачно в трекер (с логированием по минутам), ежемесячно с суммой затраченных часов для оплаты для аппрува тимлидом.
2. Задача: спланировать время, если времени планируется много — кинуть тимлиду на аппрув, реализовать, кинуть на код-ревью тимлиду, кинуть мёрж-реквест тестировщикам.
Короче, убрали лишнее, добавили нужное, разделили ответственность.
Извините, но инженеры о которых вы говорите, проповедуют модель поведения, свойственную людям никогда не занимавшимся управлением другими людьми — «начальство плохое, а я один в белом пальто стою», при полном нежелании понять кто, чем и зачем занимается.
В любой группе, больше нескольких человек — всегда будут недовольные менеджментом, как бы хорош ни был сам менеджер. В силу объективных причин (то бишь плохого менеджмента) либо субъективных — характер оценивающего, личная неприязнь к менеджеру, плохое настроение или, извините, ПМС.
Если по каждому чиху одного, или даже нескольких инженеров (в зависимости от размера команды) признавать менеджмент некачественным — будет беда для организации (хороший менеджер переживёт — он / она и так не ждёт всенародной любви, так как понимает, что это в принципе невозможно).
Про выборы слыхали? Если большинство считает управленца (любого уровня, включая президента) подходящим, то мнение меньшинства игнорируется. Нечестно? Согласен, но работает. Да, на фирмах обычно нет выборных должностей, но в данном случае заменой выборов будет желание или нежелание инженера продолжать работать в команде с таким управленцем. Можно просить сменить руководителя (если просит ценный специалист — его / её послушают), просить сменить команду, уволиться наконец. Демократия — штука хорошая, но довольно дорогостоящая (и по времени и по деньгам) и для ведения бизнеса целесообразная разве что в совете директоров или в управлении профсоюзом, то бишь на высшем уровне.
Да и объективно нельзя доверить выполнять некоторые задачи неподготовленным для этого работникам. Если бы у вас был свой бизнес, вы бы доверили одному из разработчиков, например — «поговорить с клиентом о том как ваша команда облажалась и что будем делать дальше»? Это задача менеджера, который работает с данным абстрактным клиентом постоянно (личные отношения пока никто не отменял), который имеет опыт переговоров, который умеет брать на себя ответственность. Иначе, боюсь, вы очень быстро останетесь без клиентов. «Прокладкой», как вы выразились ниже тоже нужно уметь быть. Руководитель стартапа, пока фирма не разрослась и он не делегировал функции менеджменту среднего звена, тоже выполняет задачу такой «прокладки» между работниками и клиентом. Вы же, надеюсь, не призываете воевать с топ-менеджером фирмы? Война с менеджментом среднего звена качественно мало чем отличается, так как тем самым вы оспариваете выбор топ-менеджера. Вы на 100% уверены, что вы умнее / опытней нанимателя, который считает менеджера достойным? Если да, то вам нечего делать в разработчиках — идите в менеджмент / создавайте бизнес. Если же не хотите ввязываться, то, извините, получайте удовольствие от своей работы и предоставьте решать тем, кто может и хочет.
Вообще тема очень обширная и в рамках одного комментария раскрыть её трудно. Буду рад услышать вопросы / замечания / возражения.
В любой группе, больше нескольких человек — всегда будут недовольные менеджментом, как бы хорош ни был сам менеджер. В силу объективных причин (то бишь плохого менеджмента) либо субъективных — характер оценивающего, личная неприязнь к менеджеру, плохое настроение или, извините, ПМС.
Если по каждому чиху одного, или даже нескольких инженеров (в зависимости от размера команды) признавать менеджмент некачественным — будет беда для организации (хороший менеджер переживёт — он / она и так не ждёт всенародной любви, так как понимает, что это в принципе невозможно).
Про выборы слыхали? Если большинство считает управленца (любого уровня, включая президента) подходящим, то мнение меньшинства игнорируется. Нечестно? Согласен, но работает. Да, на фирмах обычно нет выборных должностей, но в данном случае заменой выборов будет желание или нежелание инженера продолжать работать в команде с таким управленцем. Можно просить сменить руководителя (если просит ценный специалист — его / её послушают), просить сменить команду, уволиться наконец. Демократия — штука хорошая, но довольно дорогостоящая (и по времени и по деньгам) и для ведения бизнеса целесообразная разве что в совете директоров или в управлении профсоюзом, то бишь на высшем уровне.
Да и объективно нельзя доверить выполнять некоторые задачи неподготовленным для этого работникам. Если бы у вас был свой бизнес, вы бы доверили одному из разработчиков, например — «поговорить с клиентом о том как ваша команда облажалась и что будем делать дальше»? Это задача менеджера, который работает с данным абстрактным клиентом постоянно (личные отношения пока никто не отменял), который имеет опыт переговоров, который умеет брать на себя ответственность. Иначе, боюсь, вы очень быстро останетесь без клиентов. «Прокладкой», как вы выразились ниже тоже нужно уметь быть. Руководитель стартапа, пока фирма не разрослась и он не делегировал функции менеджменту среднего звена, тоже выполняет задачу такой «прокладки» между работниками и клиентом. Вы же, надеюсь, не призываете воевать с топ-менеджером фирмы? Война с менеджментом среднего звена качественно мало чем отличается, так как тем самым вы оспариваете выбор топ-менеджера. Вы на 100% уверены, что вы умнее / опытней нанимателя, который считает менеджера достойным? Если да, то вам нечего делать в разработчиках — идите в менеджмент / создавайте бизнес. Если же не хотите ввязываться, то, извините, получайте удовольствие от своей работы и предоставьте решать тем, кто может и хочет.
Вообще тема очень обширная и в рамках одного комментария раскрыть её трудно. Буду рад услышать вопросы / замечания / возражения.
Обычно это включает в себя обмен информацией, согласование направлений работы, распределение задач, и выяснение, что делать, когда возникает проблема.
т.е. обычное человеческое общение вы пытаетесь назвать словом «менеджмент». Похоже на высказывания эффективного в целях оправдания своей бесполезности…
т.е. обычное человеческое общение вы пытаетесь назвать словом «менеджмент». Похоже на высказывания эффективного в целях оправдания своей бесполезности…
Когда я искал работу после универа, здорово бесился.Что только не вкладывают в понятие «менеджер» работодатели. На собеседованиях я ожидал чего угодно. Могли предложить от продажи поясов для похудения (с выездом по близлежащим сёлам), до мелкого офисного сотрудника.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
3 мифа о менеджменте