Эффективный работник

Сегодня я считаю что как и ранее – статья неплохая, но более применима к тем сферам, которые заняты созданием чего-либо, а не разрушением(что более характерно для QA).

~~~
Давайте разберемся, что к чему. Допустим, у нас есть абстрактный IT-работник, очень сильно смахивающий на программиста, который будет создавать не менее абстрактный продукт в некой компании таких же абстрактных работников. Первое, что сделал бы оценщик середины 19 века, это вывел вполне четкие показатели труда. И были бы это время и количество кода. Чем больше кода создает работник, при минимальных временных затратах, тем более эффективный работник. Все это хорошо, но это не работает.

Continue reading

О микро-менеджменте

Сегодня приведу описания одного из стилей управления, называемого микроменеджментом. Отрывок касается программистов, но отлично переносится и на лидов команды тестеров.

Микроменеджмент – попытка сверхдетального контроля за работой подчиненного. По моим наблюдениям, в программировании это весьма распространненная практика.

Ведь обычно (проектный) менеджер – это вчерашний программист. Причем программист наверное неплохой, по крайней мере был таковым, когда программировал. Сейчас он проектирует/управляет и кодировать ему некогда, реализацией целая команда занимается.

Тогда и появляется боязнь, что “они” все сделают “не так” и желание проконтролировать процесс реализации, вплоть до выбора имен классов, советов по реализации конкретных алгоритмов и прочее. Причем часто технические вопросы продавливаются авторитетом – “я так сказал”.

Проблема в том, что такая “материнская опека” обычно только вредит. Она показывает, что менеджер не доверяет своей команде и не верит, что она способна самостоятельно вытянуть проект. А ведь “как вы яхту назовете …”. Теряется мотивация, инициатива подавляется, в конце концов, это просто раздражает (меня, по крайней мере).

Конечно же, контролировать процесс нужно. Но по возможности незаметно и ненавязчиво. Если команда слабая, то даже самая пристальная опека не поможет. Сильной же команде такое может принести урон значительно больший, чем потенциальные выгоды.

Программисты – как дети – имеют право на ошибку. Без ошибок нет роста. Безответственный программист (за которого все решает менеджер) – плохой программист. Найти же правильный баланс между свободой и контролем – это и есть забота хорошего менеджера.

материал взят здесь