Зачем нужны менеджеры в IT
Ларри Пейдж и Сергей Брин всерьез считали, что их компании управленцы незачем. В 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. Обладает основными профессиональными навыками, поэтому может давать советы группе.
Мы бы добавили к этому портрету следующее: идеальный менеджер должен быть компетентным в вопросах авторского права, риск-менеджменте, в таких областях, как психология, мотивация, управление ресурсами, юриспруденция, а также должен обладать рядом дополнительных качеств: коммуникабельность, твердость, справедливость, адекватность.
Идеальных менеджеров мало, но если человек с такими качествами и навыками вам случайно попадётся, отличные результаты не заставят себя долго ждать.
Тем не менее, многие разработчики до сих пор считают, что менеджеры им не нужны. Так ли это? Давайте разбираться вместе.
Когда менеджер – это плохо
Очень часто разработчики недовольны менеджерами. Вместо того, чтобы писать код и думать об идеальной архитектуре, их заставляют заполнять какие-то отчеты и заниматься другой скучной и непонятной работой. Менеджеры часто отсуствуют на рабочем месте, принимают участие в огромном количестве митингов, а результат их работы очень сложно измерять в строках кода, а это как раз то мерило, за которое в результате платит заказчик.
Доля правды (причем, очень существенная) у этой точки зрения есть. Очень часто менеджеры, дабы оправдать отсутствие каких-либо результатов своей работы, заставляют своих подчиненных рисовать ежедневные отчеты, фиксировать каждый шаг, например, потраченное время на посещение курилки, с целью имитации бурной менеджерской деятельности. Некоторые менеджеры только тем и занимаются, что “внедряют процесс”, проводят скрамовские пятиминутки и организовывают митинги по каждому поводу.
Первое правило плохого менеджера: не знаешь, что делать – организуй митинг.
Причина того, что многие ИТ-менеджеры не очень компетентны, заключается в том, что у нас нет полноценного образовательного института, который готовил бы менеджеров с ИТ-уклоном. Поэтому в менеджеры часто идут либо очень плохие, либо очень хорошие разработчики, либо те, кто в ИТ никогда не работали, но хорошо говорят на английском. Во всех этих случаях наличие менеджера на проекте, скорее, вредит проекту, чем помогает.
В одной компании, где в отделе работало около десяти проджект-менеджеров, был проведен небольшой опрос на тему: читали ли они книгу “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
Материал опубликован 10-05-2014, 12:51, его прочитали 7 233 раз(а).
Похожие публикации: