Умное делегирование

Умное делегирование

Как известно, одним из методов борьбы с нехваткой времени является делегирование. До этого, правда, не все менеджеры доходят. Некоторые приводят такой аргумент: «Да у меня.
сотрудники и так загружены по самое не балуйся. Куда им еще можно что-то делегировать?» Так и живут.
Ну, про то, почему и как делегировать написано в моей книжке «Секреты управления программистами». Но есть одна тонкость. Большинство менеджеров начинают с того, что делегируют самые тупые задачи - типа компиляции группового отчета из индивидуальных или еще какую-нибудь такую же хрень.
Это работает до определенной степени, потому что позволяет вам разгрузиться и занять свое время чем-то более полезным -например, мыслями о стратегии проекта или поиском новых идей. Более того, выполнение тупых задач довольно просто контролировать. Посмотрели групповой отчет - ну, вроде нормально - и заслали наверх.
Однако такая работа никак не способствует развитию сотрудников. То есть, у них даже может быть впечатление, что вы их развиваете, но на самом деле, они будут стоять на месте. Доверяя сотрудникам только написание отчета, вы никогда не вырастите себе хорошего заместителя. Вы вырастите человека, который умеет хорошо составлять групповые отчеты.
А если у вас не будет заместителя, то это будет значить, что все самые сложные задачи по-прежнему придется делать кому? Ага.
Поэтому, крайне рекомендуется, выбрав кандидата в заместители, доверять ему задачи сложные, все сложнее и сложнее. Общение с заказчиком - да. Подготовка презентации для вице-президента - да. Подготовка заявки на новый проект - да.
Контролировать, конечно, придется очень плотно. Но зато, если человек окажется правильный, то потом появится просто туча свободного времени. А если ее не появится, то это будет означать, что вы продвинулись на уровень вверх, и надо готовить себе нового заместителя. ©.
Инженерные компромиссы.
«Если два коммуниста не могут договориться по вопросу, имеющему оборонное значение, значит, один из них - враг. Мне сейчас некогда выяснять, кто из вас враг. Я вернусь через час...» (Л.П.Берия).
У меня пару раз происходила такая история. Ну, допустим, инженер в моей команде разрабатывал какие-то клевые скрипты. Например, для автоматизации тестов. И тут оказывалось, что в другой команде в другом городе человек тоже разработал аналогичные скрипты. В этот же самый момент.
И тут же рождалась идея, а не внедрить ли нам подобные скрипты во все проекты? Ну конечно, внедрить! Есть только маленький вопрос: чьи скрипты внедрять?.
Казалось бы, да не по фигу ли чьи? Мне обычно было по фигу. Но были люди, которым было не все равно - сами инженеры, которые были готовы перегрызть кому-нибудь что-нибудь, лишь бы остался ИХ код.
И вот инженеры приходят к своим менеджерам, говорят: «Ну ты посмотри, у Васи же полное дерьмище, не то, что у меня». Менеджеры проникаются, да и как-то неловко сдаваться, хотя понимают, что по фигу, чей код будет. Потому что польза будет для всего проекта в любом случае. В итоге начинается маленькая война, которая обычно быстро заканчивается компромиссом.
Менеджеры, устав от воплей инженеров, сажают двух инженеров вместе, чтобы они соединили две свои системы скриптов в одну, чтобы никому не было обидно.
Оба инженера пыхтят, кряхтят, плюются, но соединяют. Потом обычно одного из них оставляют эти скрипты поддерживать, и он все равно все переписывает так, как ему казалось правильным.
Так вот, коллеги, это все неправильно. Ну, понятно, что прежде всего неправильно, когда такая ситуация происходит - налицо недостаток обмена информацией между командами.
Но когда случилось - плохо искать компромиссы. Лучше работает принять чью-то сторону. Потому что в этом случае человек будет реально замотивирован довести дело до конца и показать, что вы в нем не ошиблись. В случае же компромисса обе стороны будут плеваться и думать про вас плохо. И никакой мотивации чего-то достичь у них не будет.
В моем примере системы скриптов сливали в одно целое - месяц! Один человек управился бы за неделю.
В общем, компромиссы хороши не всегда, не всегда. ©