Я попробовал поискать в гугле определение «Хороший менеджер» – но наткнулся на кучу ссылок о менеджерах по продажам («продавец» в народе). Я попробовал изменить запрос на: «Хороший менеджер в IT» – но снова не получил толковых ссылок на первой странице.
Я решил изложить свое видение, что такое хороший менеджер в IT. Я собираюсь поговорить о менеджерах низкого/среднего уровней – это тим-лиды, так называемые project-менеджеры, менеджеры по разработке, менеджеры по тестированию, etc. На самом деле все нижесказанное относится в равной мере и к другим (более высокого уровня) менеджерам в IT. Я основываюсь на своем (не очень большом) опыте работы, на опыте других людей и на классических книгах.
Итак, хороший менеджер должен:
1) Защищать свою команду от давления сверху. Менеджер должен помнить, что если что-то идет не так – это в первую очередь его вина. Если на команду давят, то он должен защищать команду, отстаивая ее точку зрения. Если требуется сократить срок сдачи проект под давлением сверху – он должен сделать все, чтобы не допустить этого. Если проект не сдан в срок и команду напрягают сверху – это проблема менеджера. Здесь несколько вариантов: неправильная оценка объема работы, неправильный просчет рисков, плохая команда, плохие процессы, etc.
a. Неправильная оценка объема работы – менеджер часто делает оценку самостоятельно. Здесь все очевидно: ошибся с оценкой – сам виноват. Если оценку делает команда, используя Scrum или другой подход, то см. пункт «с»
b. Менеджер неправильно просчитал риски – очевидно, что если менеджер согласился использовать необкатанную технологию, либо согласился использовать third-party компоненты, которые в итоге не подошли и неправильно оценил риски – это его личный просчет, а не команды.
c. Плохая команда – менеджер всегда принимает финальное решение – брать человека в команду или нет. Если менеджер набрал себе некомпетентных людей или просто идиотов – это его проблема, а не команды. Если менеджер пришел в существующую команду – он видел куда шел, по крайней мере, у него был выбор не соглашаться на эту работу. Если менеджера повысили из обычного работника – у него был выбор не становиться менеджером среди некомпетентных людей.
d. Плохие процессы – если в команде очень умные люди, но нет нормальных процессов разработки, то проект будет преподносить сюрпризы. Он может быть непредсказуемым. Одна из целей хорошего менеджера – настроить процессы в своей команде. Если он этого не сделал – это его вина, а не команды. Пример процесса – использование баг-трекинг системы. Если команда не использует (или неадекватно использует) баг-трекинг систему, то это означает некомпетентность менеджера, а не команды.
e. Etc. – любая причина по которой проект провалился (не был выпущен в срок) прямо либо косвенно связанна с менеджером. Если менеджер не владеет таким инструментом как risk-management – то я в очередной раз повторяю, что это его вина, а не вина команды.
2) Менеджер должен всеми силами расчищать путь команде. Он должен устранять все препятствия для того чтобы команда могла работать на полном ходу. Не хватает оперативной памяти в компьютерах разработчиков – менеджер должен найти деньги на память (выпросить у начальства сверху), а не оправдание почему это нельзя купить. У человека не загружается компьютер – менеджер должен найти того, кто разберется с проблемой – будь то человек из соседнего отдела или черт с Марса, вместо того чтобы как часто бывает сказать: «Попробуй перезагрузи, а если не получится иди найди какого-то Васю с 4-го этажа, пусть он посмотрит». Используется устаревший софт – менеджер должен доказать начальству необходимость в покупке и добиться того, что нужно команде. Команда говорит что этот релиз нельзя сдать в срок и нужно отложить его на 2 недели – менеджер должен использовать все свои коммуникативные навыки и доказать это своему боссу, вместо того чтобы доказывать команде что нужно работать по 12 часов в сутки без выходных.
3) Помнить что любой успех – это успех команды, а любой провал – это недоработка менеджера. Менеджер обязан помнить, что его основная цель это указание направления команде и помощь в решении проблем. Команда делает работу, а менеджер помогает. А не наоборот, как считается при раздаче бонусов. Про провал (несданный в срок проект, etc.) см. 1)
4) Менеджер должен публично хвалить людей из своей команды. Если ругать, то только 1 на 1. А не наоборот, как это часто бывает. Ничто так не мотивирует как хорошие слова за выполненную работу. Ничто так не демотивирует как публичное порицание (особенно если человек искренне старался сделать хорошо, а случайно сделал плохо). Лучше незаслуженно похвалить, чем незаслуженно поругать (тем более публично).
5) Хороший менеджер должен иметь уважение. Впрочем, этот пункт для меня следствие первых 4-х. Если команда получает от менеджера помощь, если она чувствует его щитом от менеджмента сверху, если она получает похвалу, если любой успех считается успехом общим, а любой провал принимается менеджером как личный – такой менеджер будет уважаем и далеко пойдет в своей карьере.
Если же менеджер является прокси между Jira/TFS/Whatever и командой, если он является усилителем давления сверху, если он во всех бедах ищет виноватых в команде, а все заслуги приписывает себе; если он вместо помощи мешает работать идиотскими отчетами и если от него кроме заданий и ругани ничего не слышно – мудак он, а не менеджер…
