Comments 9
Расскажу, как работать с микроменеджерами
Один раз говоришь микроменеджеру, что ты так не работаешь, если он не понял, пишешь заявление. Когда у него из команды уйдут все уважающие себя разработчики, и качество работы упадёт ниже плинтуса, тогда он научится не страдать хернёй или вышестоящее руководство сменит его на нормального.
Ох, если бы они учились...
Часто, я бы даже сказал, слишком часто, в качестве результата, после подобных событий, замечал за микроменеджерами не работу над собой, а "руководство ^@%#$, на столько #^!@%, не поняли, какой им изумруд в лице меня достался, а работники лентяи, подставили, бунт устроили, никто, кроме меня, работать не хочет".
"Страдание хернёй" в 90% случаев происходит следующим образом.
Мелкий менеджер попросил у исполнителя график разработки. Получил. Отправил сводный график наверх. Получил ок (график не изменился). Пришёл к исполнителю, выдал ему его же исполнителя график. Исполнитель, отставив ножку в третью позу, заявил, что "он так не работает".
Во-первых, мелкому менеджеру вообще нефиг что-то спрашивать у разработчика, пусть с тимлидом общается. Во-вторых, на планировании командой оценили сложность задач, набили бэклог спринта и всё, увидимся после спринта не ретроспективе, где можно будет задать вопросы, если спринт не закрыли. С каскадом в целом так же, если менеджеры не обгадились с процессами, то синхронизация на майлстоунах через руководителя группы. Если менеджер, как описано в статье, регулярно дёргает разработчиков, то он однозначно плохо делает свою работу.
Во-первых, мелкому менеджеру вообще нефиг что-то спрашивать у разработчика, пусть с тимлидом общается.
Во-первых, в тексте моём - "исполнитель". Это иерархия планирования - хоть "разработчик", хоть "тимлид", хоть, ну да, он сам. Непонимание работы в проекте ведёт к разговорам о "страдании хернёй" и в третьей позиции "ты так не работаешь" (гыы, а работа это?).
Во-вторых, "если спринт не закрыли", то "задавать вопросы" уже поздно.
"Дёргать" не нужно, нужно управлять. Процессы здесь, конечно, важны. Безусловно. Но. Если очевидно, что исполнитель 7,5 часов разговаривает с мамой по телефону, а 0,5 часа обедает, то бэклоги, спринты и ретроспективы здесь не помогут.
"если спринт не закрыли", то "задавать вопросы" уже поздно
Чего это вдруг? Вся суть спринтов в том, чтобы быстро получать промежуточные результаты и обратную связь. Если в спринте не сделаны или плохо сделаны пара задач, то для проекта это не должно быть чувствительным. Есть время и для ретроспективы, и для второй попытки, и для 1-1. Если всё это не помогло и разработчик продолжает не справляться с работой, то нужно просто с ним попрощаться. Самое что ни на есть управление, на основе фактов, а не ощущений тревожного менеджера.
Как выжить под руководством микроменеджера и откуда берется гиперконтроль — личный опыт и полезные советы