Comments 26
«Вырос в менеджера из программиста...» Как-то неполиткорректно получилось. Не понятно еще, кто в кого вырасти должен.
«Вырос в менеджера из программиста...»
Этот подход вообще зачастую является контр-продуктивны. При таком назначении программиста менеджером компания получает два минуса — теряется хороший программист и добавляется плохой менеджер.
Этот подход вообще зачастую является контр-продуктивны. При таком назначении программиста менеджером компания получает два минуса — теряется хороший программист и добавляется плохой менеджер.
сам подход — не обязательно. вполне возможно, что программист со временем стал лучше понимать, как создаётся ПО не только с точки зрения технологий. Ему становится интересно улучшать и там, но на позиции программиста это делать не получится. Но вот формулировка «вырос» действительно не очень. Хорошая формулировка «перешел в менеджеры из программистов»
Вот вы только что добавили в историю нового персонажа, о котором и речи не шло :) Какие-то назначатели тут вообще не нужны, но даже если он и присутствует, который назначил человека на некую позицию вне интересов, склонностей и умений самого человека, можем просто договориться о том, что он или недостаточно компетентен или недобросовестен. Но в посте по большей части о добровольном менеджменте.
Несколько вопросов:
— «Назначатель» — это или управляющий, или директор. или старший менеджер. Кто-то должен же управлять компанией. Я не очень понимаю, как без этого вообще компания может работать? Объясните, пожалуйста.
— Что такое добровольный менеджмент?
— «Назначатель» — это или управляющий, или директор. или старший менеджер. Кто-то должен же управлять компанией. Я не очень понимаю, как без этого вообще компания может работать? Объясните, пожалуйста.
— Что такое добровольный менеджмент?
Я имею ввиду, что назначение не пришло или не приходит извне (от главный менеджеров и т.д.) без всяких к тому предпосылок. Обычно, человек сам берет на себя часть обязанностей менеджера (иногда своего), выполняет какие-то организационные задачи и стремится перейти в должность, собственно, менеджера. Он высказывает свои желания, компания нуждается в менеджере, таким образом его и назначают. Ну или создатели стартапов еще.
Мы, наверное, работает в параллельных вселенных. Ответственный назначается, а не выбирается, так как желающих «поуправлять» обычно много, а способных — практически нет.
> Обычно, человек сам берет на себя часть обязанностей менеджера (иногда своего), выполняет какие-то организационные задачи и стремится перейти в должность, собственно, менеджера.
Обычно человек добровольно остается допоздна, не для того, чтобы закончить код к дедлайну, а для того, чтобы написать отчет, о котором его никто не просил, или составить план для отдела программистов, о котором его никто не просил? Такой «обычный» человек мне не встречался за 20+ лет работы в IT.
> Он высказывает свои желания, компания нуждается в менеджере, таким образом его и назначают.
Это, мягко говоря, странно. В реальной жизни, если компания нуждается в менеджере, она его находит извне, не спрашивая у сотрудников, хотят ли они стать менеджерами.
> Обычно, человек сам берет на себя часть обязанностей менеджера (иногда своего), выполняет какие-то организационные задачи и стремится перейти в должность, собственно, менеджера.
Обычно человек добровольно остается допоздна, не для того, чтобы закончить код к дедлайну, а для того, чтобы написать отчет, о котором его никто не просил, или составить план для отдела программистов, о котором его никто не просил? Такой «обычный» человек мне не встречался за 20+ лет работы в IT.
> Он высказывает свои желания, компания нуждается в менеджере, таким образом его и назначают.
Это, мягко говоря, странно. В реальной жизни, если компания нуждается в менеджере, она его находит извне, не спрашивая у сотрудников, хотят ли они стать менеджерами.
Обычно, в реальной жизни все происходит по-разному, ну а статья — один из многих взглядов на тему. Кроме того, думаю, не только самим менеджерам может быть полезна такая информация. Подчиненным тоже быть проще, когда немного понимаешь, какие процессы там в голове могут происходить у руководства.
Вы видимо работаете в какой-то странной конторе, т.к. в крупных типа mail.ru, yandex, все именно как человек выше написал.
Если программист решил переродиться в менеджера и у него не будет такой возможности, то он просто уйдёт из компании, ведь у человека сместились интересы.
> «Вырос в менеджера из программиста...»
> Этот подход вообще зачастую является контр-продуктивны.
Пожалуйста, приведите про себя десять примеров того, как программист стал менеджером. Пусть даже в IT. Несложно, правда?
А теперь десять примеров того, как менеджер стал программистом. Несложно?
> компания получает два минуса — теряется хороший программист и добавляется плохой менеджер
Значит, компания дуинг ит вронг.
В нормальных компаниях обычно получается сразу три плюса:
— не теряется хороший программист,
— его лучшие черты перенимаются его подчинёнными,
— добавляется неплохой менеджер с глубоким пониманием технической части и бизнес-логики.
> Этот подход вообще зачастую является контр-продуктивны.
Пожалуйста, приведите про себя десять примеров того, как программист стал менеджером. Пусть даже в IT. Несложно, правда?
А теперь десять примеров того, как менеджер стал программистом. Несложно?
> компания получает два минуса — теряется хороший программист и добавляется плохой менеджер
Значит, компания дуинг ит вронг.
В нормальных компаниях обычно получается сразу три плюса:
— не теряется хороший программист,
— его лучшие черты перенимаются его подчинёнными,
— добавляется неплохой менеджер с глубоким пониманием технической части и бизнес-логики.
> Пожалуйста, приведите про себя десять примеров того, как программист стал менеджером. Пусть даже в IT. Несложно, правда?
Можно и двадцать. Толку то? Хороший программер исключительно редко становится хорошим менеджером.
> А теперь десять примеров того, как менеджер стал программистом. Несложно?
Зачем? Это две разные профессии.
> Значит, компания дуинг ит вронг. В нормальных компаниях обычно получается сразу три плюса:
Мы с Вами в параллельных вселенных живем.
Можно и двадцать. Толку то? Хороший программер исключительно редко становится хорошим менеджером.
> А теперь десять примеров того, как менеджер стал программистом. Несложно?
Зачем? Это две разные профессии.
> Значит, компания дуинг ит вронг. В нормальных компаниях обычно получается сразу три плюса:
Мы с Вами в параллельных вселенных живем.
Директор компании, в которой я работаю, несколько лет назад пришел в эту компанию на должность программиста и он отличный менеджер. Больше половины PM, с которыми я работал в прошлом программисты и я не вижу в этом ничего плохого.
Где-то упоминалось что когда разработчик становится мидлом — у него два пути — либо расти в сениора, либо в менеджера, потому что на этом этапе он уже разбирается как в технологиях, так и в процессах ведения проекта.
Где-то упоминалось что когда разработчик становится мидлом — у него два пути — либо расти в сениора, либо в менеджера, потому что на этом этапе он уже разбирается как в технологиях, так и в процессах ведения проекта.
Дело в том, что кроме упомянутых выше больших, успешных и (главное!) частных молодых компаний, которых не так много, существует огромное количество немолодых, полу или целиком государственных фирм (или частных, но ставших такими из государственных, или просто заплывших жиром бюрократизма), где всё, увы, не так хорошо.
а почему вы решили, что программист был хороший?.. В менеджера может вырасти посредственный программист, которому стало не интересно программировать. Но он обладает достаточной компетенцией и кругозором, чтобы понимать как это вообще должно быть.
Ну это зависит от того, с какой стороны мы ставим этот вопрос. Бывает, что человек сначала работает программистом, а потом, в силу каких-то своих внутренних причин хочет стать менеджером. И не все успевают разобраться в новой деятельности, ко времени, когда нужно в нее окунуться. Опять же, есть талантливые программисты, создатели стартапов, которые умеют делать крутейший продукт, но им сложно справляться с командой из даже 10 человек.
Я извиняюсь, но я так и не понял, о каком менеджменте идет речь? Если об Управлении Проектами (PM), то при чем тут подбор команды и контроль? Проекты зачастую кросс-функциональны и вовлекают в себя участников из различных команд и на разном уровне иерархий.
Откуда эти «популярные» тезисы? Из книжек, на которые Вы ссылаетесь? В моей работе ни у одного из моих сотрудников, коллег или подчиненных не возникал в голове такой «популярный тезис».
Извините, но какая-то каша с картинками получилась.
Откуда эти «популярные» тезисы? Из книжек, на которые Вы ссылаетесь? В моей работе ни у одного из моих сотрудников, коллег или подчиненных не возникал в голове такой «популярный тезис».
Извините, но какая-то каша с картинками получилась.
Но иногда случается, что правила и сроки оговорены, все в курсе дела, и вот какой-то дятел прощелкал все на свете, и проект валится.
совершенно не согласен с этим примером особенно в контексте пункта «Менеджер всегда защищает свою команду» и том, что написано выше про контроль (с этим согласен на 100%). Если 1 «дятел» в команде что-то «прощелкал» и менеджер узнал об этом, когда проект уже завалился — плохой менеджер. Узнал раньше и ничего не сделал — плохой менеджер. Допустил, что персональная ошибка 1 человека в «комманде» привела к краху проекта — плохой менеджер. Но это опять же ИМХО, при чем не ПМа, но человека знающего о процессе разработки ПО не по слухам.
По статье сразу видно что бывает когда мэнеджеры вырастают из программистов.
Когда же они вырастают из инженеров, то подход выражается куда как более системно. Собственно Арни Файоль уже лет 100 как сформулировал основные принципы:
Предвидение
Организация
Распорядительство
Координация
Контроль
На этом базисе построен весь западные мэнеджмент вообще.
Зачем изобретать велосипед, когда он уже есть?
Когда же они вырастают из инженеров, то подход выражается куда как более системно. Собственно Арни Файоль уже лет 100 как сформулировал основные принципы:
Предвидение
Организация
Распорядительство
Координация
Контроль
На этом базисе построен весь западные мэнеджмент вообще.
Зачем изобретать велосипед, когда он уже есть?
Не нашел в статье про ситуации когда количество менеджеров над разработчиками зашкаливает, и некоторые из них полные бездари.
Комментарий по поводу: «Менеджер всегда защищает свою команду».
Так вот, это золотое правило. Если менеджер не защищает свою команду перед вышестоящим руководством, то он не менеджер. Есть проект или операционная деятельность за которые несет ответственность менеджер. И только он несет всю полноту ответственности. Кто-то нарушает правила и срывает сроки? А что в это время делал менеджер? Ничего? Значит он виноват. А придти к руководству и сказать: «Я все правильно делал, а вот Вася сроки сорвал и он поэтому редиска», это за гранью здравого смысла.
Еще раз. Менеджер всегда защищает свою команду! Но это не значит, что нельзя ругать своих подчиненных. Можно (желательно один на один). Это не значит, что нельзя своих подчиненных наказывать. Можно (и вот здесь как раз нужен упоминаемый вами здравый смысл). Это не значит что нельзя увольнять подчиненных. Можно (помня, что у вас есть сроки и вам придется выделять ресурсы на поиск нового сотрудника и введение его в проект/операционную деятельность). Но перед вышестоящим руководством всегда несет ответственность только менеджер.
Так вот, это золотое правило. Если менеджер не защищает свою команду перед вышестоящим руководством, то он не менеджер. Есть проект или операционная деятельность за которые несет ответственность менеджер. И только он несет всю полноту ответственности. Кто-то нарушает правила и срывает сроки? А что в это время делал менеджер? Ничего? Значит он виноват. А придти к руководству и сказать: «Я все правильно делал, а вот Вася сроки сорвал и он поэтому редиска», это за гранью здравого смысла.
Еще раз. Менеджер всегда защищает свою команду! Но это не значит, что нельзя ругать своих подчиненных. Можно (желательно один на один). Это не значит, что нельзя своих подчиненных наказывать. Можно (и вот здесь как раз нужен упоминаемый вами здравый смысл). Это не значит что нельзя увольнять подчиненных. Можно (помня, что у вас есть сроки и вам придется выделять ресурсы на поиск нового сотрудника и введение его в проект/операционную деятельность). Но перед вышестоящим руководством всегда несет ответственность только менеджер.
Но перед вышестоящим руководством всегда несет ответственность только менеджер.
Как-то это интересно, и звучит почти как про футбол. Когда при неудачах команды меняют тренера (проще ведь 1-го поменять, чем 20, так же?).
Давайте определимся за что несет ответственность менеджер. За провал проекта в целом — да. За конкретные баги — нет. За срыв сроков проекта — да, за срыв сроков по задаче/задачам исполнителя — нет. И так далее.
Отсюда вывод — менеджер должен держать в курсе всего происходящего на проекте своё вышестоящее руководство, особенно если вопрос рисковый и вне рамок его полномочий (а такое очень, очень часто бывает).
Была у меня история. Один паренек постоянно срывал сроки. И заменить его было некем. Что оставалось мне как менеджеру? Правильно, сужать скоуп, менять задачи, цели… передоговариваться. Это искусство. Но это всё равно провал. В конце концов я ушел — понял, что проект изначально провальный в текущих обстоятельствах. Не потому что не захотел нести ответственность, а потому что win-win не выходило. Мораль: менеджер несет ответственность за план и разницу план-факт, за все остальное несут ответственность те, кто непосредственно что-то делает.
Давайте определимся за что несет ответственность менеджер. За провал проекта в целом — да. За конкретные баги — нет. За срыв сроков проекта — да, за срыв сроков по задаче/задачам исполнителя — нет. И так далее.
Бинго. Вы сами все рассказали. Моего руководителя не должен интересовать срыв сроков задачи или появление багов. Я эти проблемы должен решать сам со своими подчиненными. За срыв сроков проекта, которые произошли по причине срывов сроков задач, несу ответственность я. Давайте покажу на примере вашей истории.
Итак, у нас есть ключевой разработчик (раз заменить его не кем). Мы планируем некий проект и у нас есть два варианта развития событий:
1. На старте проекта, в рамках процесса по планированию рисков мы закладываемся на риск: «ключевой разработчик не сможет выполнить весь запланированный на него скоуп задач». Риск достаточно серьезный по последствиям и с достаточно высокой вероятностью, т.к. разработчик может забить, заболеть, уйти в другую организацию. Т.е. с риском надо работать. Планируем мероприятия по снижению вероятности наступления риска и/или снижению его последствий (например, обучаем других сотрудников навыкам нужным для решения таких задач). Также планируем мероприятия позволяющие в случае реализации риска снизить последствия (например, через вышестоящее руководство договариваемся с другим отделом о предоставлении сотрудников для решения этих задач). Ок. Проект начался. Проводим мероприятия по предотвращению риска, при наступлении нежелательного явления — мероприятия по снижению последствий. Информируем руководство о возможных сдвигах графика или о необходимости доп. ресурсов в рамках первоначальной договоренности.
2. На старте проекта околачиваем груши. В процессе работы над проектом «контролируем» факт срыва сроков ключевым разработчиком и ничего не делаем. При срыве сроков идем к руководителю и радостно сообщаем: Ваня Петров — редиска, он сорвал все сроки, ну а я ухожу.
Как вы не знаю, а я за первый вариант развития событий. А вы?
Sign up to leave a comment.
Менеджмент. Краткое руководство для начинающих менеджеров и опытных подчиненных