Ларри Пейдж и Сергей Брин всерь­ез считали, что их компании управленцы незачем. В 2002 году они попытались выстроить горизонтальную оргструктуру — без менеджеров, руководящих программистами. Так, считали они, ничто не будет мешать быстрому обмену и появлению идей. Кроме того, им хотелось воссоздать ту атмосферу студенческой жизни, которая так нравилась им в университете. Эксперимент длился недолго: спустя несколько месяцев его пришлось прекратить. Брин и Пейдж изменили свое мнение о внутреннем устройстве компании, когда сотрудники валом повалили к Пейджу с вопросами, далекими от творчества: с финансовыми отчетами, жалобами друг на друга и т.п. А уж когда компания стала расти, ее основатели убедились, что управленцы полезны и в других отношениях: объясняют стратегию, значимость проектов и их очередность, налаживают сотрудничество в коллективе, следят за карьерным ростом людей и за тем, чтобы все рабочие процессы и системы соответствовали задачам бизнеса.

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

Когда менеджер – это плохо

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

Доля правды (причем, очень существенная) у этой точки зрения есть. Очень часто менеджеры, дабы оправдать отсутствие каких-либо результатов своей работы, заставляют своих подчиненных рисовать ежедневные отчеты, фиксировать каждый шаг, например, потраченное время на посещение курилки, с целью имитации бурной менеджерской деятельности. Некоторые менеджеры только тем и занимаются, что “внедряют процесс”, проводят скрамовские пятиминутки и организовывают митинги по каждому поводу.

Первое правило плохого менеджера: не знаешь, что делать – организуй митинг.

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

В одной компании, где в отделе работало около десяти проджект-менеджеров, был проведен небольшой опрос на тему: читали ли они книгу “Deadline: роман об управлении проектами”. Результат был ошеломляющий: книгу не читал никто. Спрашивать о Бруксе и его мифическом человеко-месяце никто не стал.

Почему никто не готовит менеджеров? Давайте займемся арифметикой. Чтобы из айтишника сделать менеджера нужно от 0.5 года (практически идеальный и редко встречающийся в дикой ИТ-природе случай) до четырех лет. Средняя продолжительность работы айтишника в компании – год/полтора. Таким образом, если компания начнет вкладывать деньги в процесс трансформации “айтишник-менеджер”, то с большой долей вероятности трудами этого обучения воспользуются конкуренты. Поэтому компании с удовольствием обучают айтишников на курсах повышения квалификации, но не готовы вкладывать в обучение менеджеров.

Что же делать айтишнику в таком случае? Во-первых, решить, хочет ли он в будущем быть менеджером. Если ответ положительный, то, начиная где-то с уровня мидл, нужно параллельно с книгами по технологиям начинать читать книги по психологии, риск-менеджменту и проджект-менеджменту.

Когда менеджер – это хорошо

И все же, для чего нужны менеджеры? Вначале статьи Пейдж и Грин уже немного ответили на этот вопрос: объясняют стратегию, значимость проектов и их очередность, налаживают сотрудничество в коллективе, следят за карьерным ростом людей и за тем, чтобы все рабочие процессы и системы соответствовали задачам бизнеса.

Хотим добавить в копилку еще несколько важных задач менеджера.
Задача №1: быть стеной между заказчиками и исполнителями

Как-то одному нашему знакомому, будучи еще довольно молодого возраста, довелось выступить в роли “23-летнего сеньора” (а еще и в роли тим-лида) для одного очень серьезного заказчика (Fortune 100). Проект был не сложный технически, но непростой с точки зрения интеграции и требований к аппаратной среде. Для интеграции была выделена отдельная машина (на стороне заказчика), где всё благополучно запустилось. Но инженерам заказчика этого показалось мало и они решили развернуть систему на персональном ноутбуке, а также на рабочем компьютере. И в какой-то момент система не завелась. Пришлось долго разбираться почему, причем проблемы возникали одна за другой.

Это могло продолжаться довольно таки долго, если бы в ситуацию не вмешался менеджер. Он запретил инженерам заказчика давать исполнителю задания без его ведома и разворачивать систему на не проверенном железе. После этого вмешательства ситуация устаканилась, разработчика перестали дергать, а проект был благополучно сдан спустя несколько дней.

Задача №2: брать на себя ответственность за весь проект

– У нас проблемы с проектом, — сказал как-то топ-менеджер компании, для которой делался проект. У разработчика похолодело внутри. – Но ты не переживай, это не твоя область ответственности, – добавил он.

Стоит запомнить одну простую мысль: программист кодит, менеджер отвечает. Если программист плохо накодил – в любом случае виноват менеджер, ведь он не проследил за ходом выполенения проекта и/или нанял не подходящего сотрудника.

Да, менеджер получает больше плюшек, но и ответственность у него на порядок выше.

Задача №3: гарантировать достижение цели в условиях ограниченного доступа к ресурсам

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

Но если менеджер может гарантировать результат, то не важно, где, сколько и как он работает. Более того, менеджер, который будет работать по 7-8 часов в день – гарантированно завалит проект. Менеджеру должны платить за его решения и конечный результат. В идеале менеджер должен получать основной доход в виде бонусов за вовремя выполненные проекты, а не за количество просиженных в linkedin или skype часах.

Задача №4: быть мотиватором и следить за развитием подчиненных

Если бы разработчики нас спросили, в какой компании лучше всего работать, мы бы без раздумий ответили: в той, где у них будет адекватный менеджер (даже если денег там будут платить вдвое меньше).

В одной из компаний, мы программист получил большой кредит доверия от своего менеджера. Доверие заключалось в полном одобрении принятых им (программистом) решений, автономность работы, помощи при организации встреч разработчиков, учебных курсов и поездок на всевозможные конференции. Результат не заставил себя долго ждать: был открыт новый отдел на 5-6 человек; знания, полученные на мероприятиях, были внедрены в рабочий процесс, на проектах начали использовать современные технологии и иструменты. Итог? Все предложения других компаний (включая предложения с более высокой зарплатой), на протяжении года-полтора были отклонены программистом без капли сожаления.

Какой он, идеальный менеджер?

В Google выделяют 8 качеств хороших менеджеров:

1. Чуткий наставник.
2. Предоставляет коллективу свободу и не контролирует каждый шаг.
3. Следит за успехами подчиненных и старается помочь.
4. Компетентен и нацелен на результат.
5. Умеет разговаривать с людьми — выслушивает и делится информацией.
6. Помогает подчиненным делать карьеру.
7. Имеет четкое представление о будущем своей группы и понимает стратегию её работы.
8. Обладает основными профессиональными навыками, поэтому может давать советы группе.

Мы бы добавили к этому портрету следующее: идеальный менеджер должен быть компетентным в вопросах авторского права, риск-менеджменте, в таких областях, как психология, мотивация, управление ресурсами, юриспруденция, а также должен обладать рядом дополнительных качеств: коммуникабельность, твердость, справедливость, адекватность.

Идеальных менеджеров мало, но если человек с такими качествами и навыками вам случайно попадётся, отличные результаты не заставят себя долго ждать.

Автор: Chebanov

Источник