когда я находился в поиске работы, объемные тестовые задания на ранних этапах общения вызывали скорее раздражение, чем желание их делать.
Сейчас сам ищу себе работников и выработал следующую тактику:
-задание должно быть небольшим (макс. 6 часов рабочего времени)
-задание имеет смысл давать, только если в портфолио человека нет чего-либо подобного
-задание имеет смысл давать уже на более поздних этапах собеседования
-так как задание по итогу может не отображать всего того, что необходимо знать и уметь работнику, оно не должно являться основополагающим при принятии решения
Это одна из составляющих. Большинство работает за деньги. Помимо этого, также необходимо показывать руководителю проекта в чем конкретно польза от его проекта для всех (социальная ответственность внутри компании и для заказчика) и давать определенную свободу действий (я никогда не понимал жесткого графика для ПМ, сейлов, РП и подобного звена — график человека должен определяться рабочими нуждами).
Автору поста: «Шестерство», как вы его называете — нужно вводить, но аккуратно и обдуманно. Хотя бы потому, что вы сами его так называете. Обычный руководитель проекта и исполнитель проекта — оба наемники, каждый со своими функциональными обязанностями. Попытка дистанцироваться от возможных проблем в их взаимодействии — попытка засунуть голову в песок, не более. Если эти 2 человека не срабатываются — подобные сигналы надо ловить и обрабатывать, а не спускать на тормозах. В одной из моих команд так потеряли 2 хороших программистов, сигналы выловили слишком поздно.
Согласен, но пришлось бы вводить программную эмуляцию контроллера — хакинтош. Я не думаю, что эппл и сони пошли бы на тотальную унификацию архитектуры ради кросс-фирменности ОС. А все это на стабильности скажется не лучшим образом. В последнее время и так у эппл баги пошли, что не радует.
плохо сформулировал. Он не становится им автоматически. С первой минуты — он тот же человек, но с пометкой менеджер. Менеджером он станет, только окунувшись в работу и выработав свою тактику (или взяв чужую). А то, каким он станет — неизвестно, в этом согласен)
Вероятность услышать «высер наверх» зависит больше от внутренних цензов человека, нежели от его позиции в служебной иерархии. Бывают и адекватные сотрудники низшего звена, которые адекватно воспринимают проблемы, в которых они абсолютно вправе упрекнуть менеджера, что он придурок (отсутствие обещанного повышения зарплат) и стараются проблему решить, а бывают и менеджеры, которые срут на свое начальство потому что им нехрен делать. Человек, будучи поставлен на позицию менеджера, менеджером не становится. А становится им только при итеративном развитии и учете своих и чужих ошибок. И никакого плюса в карму он не получает.
Чтобы у подчиненных возникало понимание айсберга, его им надо показывать, в рамках разумного, допустимого и необходимого. Когда я только стал менеджером, мое руководство по этому айсбергу меня буквально за ручку водило и поясняло нюансы. За что могу сказать только огромное СПАСИБО. Это вызывало понимание айсберга и желание помогать им в ведении этого айсберга. Тоже самое я делал для своих подчиненных, для своей команды.
И далеко не всегда люди рвутся на руководящие позиции, в мире есть больше оттенков, нежели черное и белое.
согласен на все 100%. А в данной ситуации стоит объяснять человеку подобные вещи на примерах и вживую. Если менеджер объяснит исполнителю «парень, я эти отчеты на завтрак не ем, они мне нужны для того, чтобы Петя Иванов (его руководитель, заказчик, страшный дядя из регуляторных органов) знал как идут дела и не дергал нас обоих ежечасно. Мы с тобой в одной лодке, и у каждого по веслу», то жизнь пойдет проще. Это же вопрос методологии. Если день изо дня тратится по полчаса на препирательства с отчетом, стоит пересилить себя, сдвинуть все задачи на 2 дня и потратить эти 2 дня на то, чтобы адекватно все команде объяснить, показать, показать почту, показать процесс жизни заявки немного шире. Обычно вопросы после этого отпадают
при возможности для маневра — можно сделать человеку его рутину интересной. Существует прослойка технарей — «ученых», которые знают потаенные закоулки вверенной им системы (а она может отвечать за очень скучные вещи — банковский бэк, DWH банковский же) и могут творить с ней чудеса — ядра пересобирать, очень тонко ее тюнить, разрабатывая под это свои инструменты, тд. вот таких нужно отгонять от рутины, пока они сами ее не захотят. в любой крупной системе им и так найдется чем заняться. А отчетность такие ребята все равно не пишут :)
В ситуации с менее одаренными ребятами им следует рассказывать по максимуму pro и contra предстоящей работы и наблюдать склонности каждого из них — отчетность, формы, интеграционные блоки, тд. И нужно развивать в них эти наклонности и давать задачи соответственно их предпочтениям. Целиком от рутины это не избавит, но сведет ее к адекватной величине
вы в качестве внимания подразумеваете только выговор или увольнение?
Первое проявление внимания — копать причины, Если вы про поведенческие аспекты здесь и сейчас — жестко предложить сотруднику продолжить разговор приватно.
зачастую такого работника можно перевести на другой проект (если работник стоящий). Отношения менеджер исполнитель — это не пара «раб-хозяин», а пара «работник-работник», связанная тем, что менеджер распределяет задачи, создает комфортные условия работы для своих подчиненных и ведет продукт в целом, а исполнитель — кормит менеджера своим трудом. Бывают и хреновые менеджеры и хреновые работники.
В такой ситуации не увольнять надо, а копать причины.
в подавляющем большинстве случаев это проблема скатывается к нулевой внутренней мотивации сотрудника на выполнение задачи.
К статье могу добавить, что в этом случае упредительно работает механизм открытости, которым во многих компаниях почему-то пренебрегают: при каждом нововведении или изменении существующего порядка, лучше толково и внятно объяснить команде, зачем это. Желательно с примерами и аллюзиями. И еще желательнее раза два-три, дав им высказаться (возможно что-то сразу скорректируется). и если нововведение воспринимается в целом негативно, но это необходимо сделать — стоит продумать как внедрить так, чтобы на команде сказалось минимально именно с негативной стороны. Единстенная оговорка — так делать стоит, не скомпрометировав некие закрытые данные (обычно их много меньше, чем может показаться на первый взгляд).
как мило выглядит красная надпись top secret в заголовке каждого слайда. А по факту дали всяким параноикам еще одну страшилку на ночь. Сноуден, фейсбук, твиттер, канадские спецслужбы. Самое негативное в этом то, что наши дети уже не будут знать словосочетания «личное пространство»
Сейчас сам ищу себе работников и выработал следующую тактику:
-задание должно быть небольшим (макс. 6 часов рабочего времени)
-задание имеет смысл давать, только если в портфолио человека нет чего-либо подобного
-задание имеет смысл давать уже на более поздних этапах собеседования
-так как задание по итогу может не отображать всего того, что необходимо знать и уметь работнику, оно не должно являться основополагающим при принятии решения
Автору поста: «Шестерство», как вы его называете — нужно вводить, но аккуратно и обдуманно. Хотя бы потому, что вы сами его так называете. Обычный руководитель проекта и исполнитель проекта — оба наемники, каждый со своими функциональными обязанностями. Попытка дистанцироваться от возможных проблем в их взаимодействии — попытка засунуть голову в песок, не более. Если эти 2 человека не срабатываются — подобные сигналы надо ловить и обрабатывать, а не спускать на тормозах. В одной из моих команд так потеряли 2 хороших программистов, сигналы выловили слишком поздно.
Чтобы у подчиненных возникало понимание айсберга, его им надо показывать, в рамках разумного, допустимого и необходимого. Когда я только стал менеджером, мое руководство по этому айсбергу меня буквально за ручку водило и поясняло нюансы. За что могу сказать только огромное СПАСИБО. Это вызывало понимание айсберга и желание помогать им в ведении этого айсберга. Тоже самое я делал для своих подчиненных, для своей команды.
И далеко не всегда люди рвутся на руководящие позиции, в мире есть больше оттенков, нежели черное и белое.
В ситуации с менее одаренными ребятами им следует рассказывать по максимуму pro и contra предстоящей работы и наблюдать склонности каждого из них — отчетность, формы, интеграционные блоки, тд. И нужно развивать в них эти наклонности и давать задачи соответственно их предпочтениям. Целиком от рутины это не избавит, но сведет ее к адекватной величине
Первое проявление внимания — копать причины, Если вы про поведенческие аспекты здесь и сейчас — жестко предложить сотруднику продолжить разговор приватно.
В такой ситуации не увольнять надо, а копать причины.
К статье могу добавить, что в этом случае упредительно работает механизм открытости, которым во многих компаниях почему-то пренебрегают: при каждом нововведении или изменении существующего порядка, лучше толково и внятно объяснить команде, зачем это. Желательно с примерами и аллюзиями. И еще желательнее раза два-три, дав им высказаться (возможно что-то сразу скорректируется). и если нововведение воспринимается в целом негативно, но это необходимо сделать — стоит продумать как внедрить так, чтобы на команде сказалось минимально именно с негативной стороны. Единстенная оговорка — так делать стоит, не скомпрометировав некие закрытые данные (обычно их много меньше, чем может показаться на первый взгляд).