17 апреля 2014 в 10:28

Нужны ли менеджеры в IT?

image

Ларри Пейдж и Сергей Брин всерь­ез считали, что их компании управленцы незачем. В 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. Обладает основными профессиональными навыками, поэтому может давать советы группе.

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

Идеальных менеджеров мало, но если человек с такими качествами и навыками вам случайно попадётся, отличные результаты не заставят себя долго ждать.
Spice IT @Chebanov
карма
16,0
рейтинг 0,0
IT-специализированное рекрутинговое агентство
Самое читаемое Разное

Комментарии (60)

  • +44
    Мне повезло, я еще ни разу я не жаловался на наличие менеджера. Менеджер избавляет от кучи головняков, которые бы свалились на меня. Я искренне благодарен, что он у нас есть. Коротко о статье:
    Когда менеджер – это плохо? Когда менеджер — плохой менеджер.
    Когда менеджер – это хорошо? Когда менеджер — хороший менеджер.
  • +1
    Если бы менеджеры были не нужны то их бы и не было. см. Конкуренция.
    • +26
      Нужны ли программисты в IT?

      Программисты бывают плохие и хорошие! Мало кто об этом знает. Плохие программисты в IT не нужны, а хорошие нужны.

      Минусы от использования программистов в IT
      — Высокая зарплата.
      — Могут завалить серьёзный проект на сотни денег.
      — Постоянно толпятся возле кофемашины.
      — Могут сутками ничего не делать.

      Плюсы от использования программистов в IT
      — Делают проекты на сотни денег.
      — Соблюдают противопожарную технику безопасности.

      Брать или не брать программистов в IT решать вам, но во всём мире берут и наверное это правильно. Выводы сделайте сами. Если сможете.

  • +2
    Один из главных отрицательных эффектов плохого менеджера — снижение у подчиненных самооценки и/или уверенности в компетенции руководства. В итоге работа подразделения или проектной команды начинает зависеть от одного-двух специалистов, которые двигают эту работу только своей энергией. При этом, очень часто такие «менеджеры» идут на повышение (потому что ну ведь подразделение задачи-то свои выполняет).
  • 0
    из 8-и перечисленных пунктов, самый важный, на мой взгляд — пункт 2. очень часто менеджер не может найти золотую середину и начинает либо дергать разработчика слишком часто, не давая сосредоточиться и вгоняя его в стрессовое состояние, либо дает слишком много свободы, и удивляется, когда проходят все мыслимые сроки (хотя тут, конечно, завитсит от разработчика и его мотивации).

    пункт 1 немного спорный, мне кажется достаточно пункта 8, т.к. менеджер вряд ли должен (именно «должен», а не «может») разбираться во всех технических тонкостях, хотя это так же было бы неплохо.
    • –12
      >> либо дает слишком много свободы

      Как говорит один мой знакомый: «Чтобы разработчики работали, нужно стоять над ними или брать в заложники их детей».
      • +7
        разработчика нужно мотивировать, а не запугивать.
      • +10
        Не представляю, как можно работать, когда кто-нибудь стоит над душой.
        У вашего знакомого никто не брал в заложники детей? Как он, эффективно сам то работает под таким давлением?
      • +6
        Если кто-то возьмет в заложники кого-то из моих родных, то половина строк в получившейся программе будут закладками.
        • –1
          думаю, вы так будете делать до первого аудита :)
          • +4
            Думаете, сынок директора что-нибудь найдет?)
            • 0
              Не, я развивал гипотетическую ситуацию с закладками в коде, написанным под давлением и шантажом захваченной семьи. Те, кто бы так сделал, исходили бы из предпосылки — а) выгоды от дела (ПО) весьма высоки, б) оперирующая команда достаточно сильная и не стеснена ни в каких ресурсах., в) — психологический портрет исполнителя скорее всего был бы составлен до дела, в том числе и реакция на подобный прессинг. А значит — надо проверять (на самом деле, проверять и дважды — обязательно) — и потому ваш код проверял бы второй разработчик (на которого бы давили другим способом) и, как минимум, еще один человек, проверяющий обоих, в ряде случаев мотивирован позитивно (например, большой премией).
              • 0
                В таком случае от идеи давить на меня заложниками отказались бы еще в процессе составления психологического портрета.

                Я не могу представить себе человека, который заранее знает, что в коде будут закладки, но предполагает решить эту проблему в дальнейшем с помощью аудита…
                • 0
                  Все решения в этих областях (грубо говоря — военные, космос и связанные с безопасностью во всех вариантах) принимаются исходя из ситуации, что исходное решение и/или поведение содержит ошибки.
                  • 0
                    Ошибка != закладка

                    Чем профессиональнее программист, тем реже в его коде будут ошибки, но и тем проще ему спрятать закладку, коли потребуется.
                    • 0
                      ну ошибка тут в самом общем случае: если программа делает еще что-то кроме того что должна и /или имеет возможность влияния на результат, кроме предусмотренного.

                      Потому и надо проверять :) и перепроверять перекрестным методом, исключая личностные и другие факторы.
                      • 0
                        А простая перекрестная проверка с целью поиска ошибок и не страшна. Ну найдут парочку, ну и что? Их же еще много осталось. Да и меня обвинить в них нельзя — я же старался. Вон, в коде соседа тоже три ошибки нашел.
                        • 0
                          Не уверен — нет такого, обвинить нельзя. Будет просто условие, для пример — за каждую найденную закладку -1 орган у рандомного родственника :)
                          • 0
                            Как они отличат закладку от ошибки? А ошибки делают все, за них наказывать нельзя — в момент вообще без программистов останутся.
                            • 0
                              Для равного по квалификации разработчика отличить достаточно просто. Так как это совсем разные вещи. к тому же, еще раз — основной поинт — перекладывания на разработчика бремени ответственности за любые неожиданности.
                              • 0
                                Неожиданности? Не буду я никаких неожиданностей устраивать. Просто совершенно независимые хакеры через два года нанесут урона на пару лярдов — и гадай, чья закладка сработала. И была ли она вообще.
                                • 0
                                  Такие операции не организовывают для столь долгосрочных процессов :)
                                  • 0
                                    Значит, закладка сработает быстрее. Я думаю, я как-нибудь смогу понять по своему же ТЗ, как долго должна проработать программа.
      • –2
        Ну как, кааак это высказывание можно воспринять всерьёз?! Непонятно.
        • +3
          Все просто — высказывание или смешное — или воспринимается всерьез. Найти, где тут можно хотя бы улыбнуться — не получилось.
        • +2
          Понимаете ли, в каждой шутке есть доля шутки. Дело не в том, что это шутка, а в том, что вы с вашим знакомым вообще такие шутки употребляете.
          • 0
            Знакомый — мой менеджер.
            • +1
              В такой ситуации главное — не заводить детей.
  • +1
    Очень часто менеджеры, дабы оправдать отсутствие каких-либо результатов своей работы, заставляют своих подчиненных рисовать ежедневные отчеты, фиксировать каждый шаг, например, потраченное время на посещение курилки


    Вот тут недавно была статья от менеджера — habrahabr.ru/post/218435/
    Очень хорошо подходит под ваше описание.

  • 0
    Все же мне кажется менеджера нужно нанимать не со стороны, а выделять человека со временем из уже сколотившейся команды и исходя из определенных критериев (хотя бы даже гугловских).
    P.S. очень тяжело найти достойного менеджера с хорошим пониманием IT.
    • +3
      Вовсе не гарантировано, что IT-шник будет хорошим менеджером.
    • 0
      Согласен. Как правило такой менеджер будет сильнее погружен в процесс. Его будут связывать не только формальные обязательства. Сплоченность и нацеленность коллектива на результат одно из важнейших составляющих успеха.
      • 0
        У всякой медали есть обратная сторона. В данном случае, этот менеджер будет скорее всего прикрывать некомпетентных сотрудников, если такие окажутся в команде.
        • 0
          Главное ведь результат.
          • 0
            А что, неэффективный член команды никак не влияет на результат?
            • 0
              На мой взгляд, если менеджер полностью справляется со своими обязанностями, то в принципе он может выделять больше времени на ликбез молодого специалиста (не путать с безнадежно глупым) — но это строго его дело. Тем более что большинство фирм не могут себе позволить нанимать только лучших спецов, а значит нужно заниматься обучением и молодых работников.
              • +1
                Про молодых согласен, безусловно. Но бывают и просто бездельники. Или прогульщики. Или пьяницы. Много каких бывает, увы.
                А если менеджер с ними работал вместе много лет, ему крайне сложно на них эффективно воздействовать или принимать решительные меры вплоть до увольнения.
  • –4
    Если нанимают менеджеров — значит нужны.
  • +1
    Книга «Deadline» — очень неоднозначная. Не устаю всем рекомендовать отзыв Стаса Фомина (belonesox) на эту книгу:
    http://lib.custis.ru/Deadline_(Демарко)
    • +2
      Сдаётся мне, автор рецензии не уловил основной сути «романа», который хоть и роман, но главным образом об «управлении проектами», то есть это скорее учебная литература, а не художественная, в которой ГГ должен быть суперкрутым, а мир, даже фэнтезийный, подчиняться привычным законам. Сюжет в ней слишком второстепенен и служит лишь элементарной оболочкой для донесения основных тезисов грамотного управления.
      Хотя лично мне больше нравится книга «Человеческий фактор: успешные проекты и команды» Демарко и Листера. Там более подробно, хотя и в менее развлекательной форме.
      • +2
        Проблема «Дедлайна» в том, что «обрамление» не нужно.
        Герой записываем умные мысли, не принимает решений, проблемы решаются сами собой.
        Т.е., он собственно как таковым управлением не занимается. Ничего не решает. Ну и зачем он тогда нужен? Для чего введён? Что бы был?

        Поддержу автора рецензии, почему все считают её «настольной книги» — не понимаю. Упомянутый вами «человеческий фактор» на эту роль подходит гораздо больше — и читается интереснее, и все полезные мысли рассмотрены на примерах и жизненных ситуациях, а не в сферическом вакууме идеальной для героя ситуации.
  • +4
    Ни раз сталкивался с тем, что в коллектив приходили менеджеры не только далекие от темы, но и лишенные опыта управления, не умеющие вести диалог. В итоге потихоньку коллектив устранялся, вырастала текучка кадров. Для молодых проектов это большая проблема, ибо вникнуть в процесс, который на этапе становления с ходу получается далеко не у всех. Причиной появления таких «менеджеров» в большинстве случаев было банальное «кумовство». Сталкивался я с этим трижды, причем, как работая в небольшой конторе, так и в одной из крупнейших российских интернет-компаний. Следствием являлось, если и не падение показателей (во многих случаях система была крупной и сбить ее с курса одним ошибочным назначением было тяжело), то стагнация или падение показателей относительно конкурентов.
  • +1
    Менеджер — менеджеру рознь. Некоторые менеджеры не понимают, что для руководства программистами не годятся те же самые методы, что для управления грузчиками. Для того, чтобы программист хорошо работал, ему должно быть комфортно, он должен быть расслаблен, уверен в себе и уверен в успехе проекта. Задача менеджера — успокоить программиста, замотивировать положительно, и оградить от конфликтных клиентов. Я думаю, лучшие менеджеры в IT — это бывшие программисты, которые на своей шкуре знают, что по чем.
  • +1
    Если нет клиентов, а программисты опытны, мотивированы внутренне самим проектом и дисциплинированны — менеджеры будут либо помехой, либо нахлебниками. Valve, Blizzard и т.п. подтверждают это.

    Если есть клиенты, а значит есть неадекватные и жадные клиенты, и плюс работает половина джуниоров, менеджеры необходимы для двух целей:
    — быть прослойкой с заказчиком, не забивать программисту голову лишними проблемами;
    — держать дисциплину среди джуниоров, среди которых много «звезд, кодивших на асме и сишке», заставлять их слушаться старших товарищей, банально просить сеньоров присмотреть за детишками, т.к. сами девелоперы от такой работы отгораживаются.

    Ну и в больших корпорациях 90% работы — рутина рутинная, скучная до невообразимых масштабов. Тогда надо хоть как-то мотивировать программистов на работу левой рукой в перерывах на ютуб; в лучшем случае появляется Гугл, в худшем — mail.ru group.
    • +1
      Ну уж Valve-то как раз пример крупнейшего затягивания сроков, так что лучше бы там были менеджеры…
      • +1
        Ага, тогда бы и игры выходили наподобие Electronic Arts (FIFA 2001, 2002, 2003,…, 2034)
        • +3
          Ну, кстати, серия FIFA — это как раз тот пример, когда выход игр по расписанию оправдан.
          • 0
            Объясните не-любителю FIFA почему? Что кроме набора и состава команд можно менять каждый год?
            • 0
              Перечисленных вами вещей вполне достаточно для выпуска новой игры, учитывая год выпуска первой игры серии.
              • 0
                А в чём проблема обновлять команды патчами?
                • +2
                  В том, что патч — это слишком маленький объем данных, чтобы записывать его на оптический диск и продавать.
                  • 0
                    Ну, кстати, серия FIFA — это как раз тот пример, когда выход игр по расписанию оправдан.

                    Подумал, что речь о целесообразности с точки зрения пользователя.
                    Тогда да, вы правы.
                    • 0
                      С точки зрения пользователя все обстоит точно так же: патч — это слишком мало, чтобы его покупать.
  • 0
    все верно. сейчас в новом проекте тим лид/менеджер — все 4 пункта в точку.
  • +1
    Рискую конечно, понимаю что большая часть аудитории — именно разработчики.
    Эти 8 пунктов верны, но это к сожалению не всё. Все что в этих пунктах — не так уж сложно повторить. И все это работает пока не случится какая-нибудь серьезная проблема, требующая решительных действий. И здесь менеджер должен уметь делать ряд неприятных вещей:
    1. Увольнять сотрудников, если это необходимо.
    2. Вводить в команде непопулярные но необходимые меры. Но так, чтобы все не разбежались.
    3. Эффективно отдуваться перед командой за негативные решения вышестоящего руководства.
    4. Наказывать за реальные косяки.
    По себе могу сказать, что не все эти пункты смог освоить, когда превратился из менеджера в программиста. А первые 8 — да без проблем :)
    • 0
      превратился из менеджера в программиста
      Наборот, конечно. Из программиста в менеджера.
    • 0
      вобщем-то все верно.
  • 0
    Мне наверное не везет, я еще не разу не видел хорошего (понимающего что да как) проект менеджера, вечно далекие от IT. Вернее когда он более менее набирался опыта, не выдерживал рабочего хауса и увольнялся. Как и сейчас происходит замечательная компания, интересный проект, но тупые проект менеджеры(парень — отсутствие тех.знаний но хорошо говорит и девушка бывший прогер как собака все понимает но сказать нечего не может )
  • –1
    был проведен небольшой опрос на тему: читали ли они книгу “Deadline: роман об управлении проектами”
    Вполне возможно что и повезло той компании! Это все совсем не об управлении проектами. А о коллективах людей, работающих головой. Причем спорные утверждения. Заказчик проекта (не продукта) — бизнес, поэтому ему требуются не человеко-месяцы, а деньги.

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

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

    Так что посыла статьи «менеджер должен это, и это не должен» я не понимаю. Это какой-то взгляд снизу — «нам должны». Попробуйте стать менеджером — и окажетесь всем должны. И сверху, и снизу, и слева, и справа. Какой там ДеМарко…
    • –1
      Попробуйте стать менеджером — и окажетесь всем должны. И сверху, и снизу, и слева, и справа
      Есть очень точная иллюстрация на эту тему
      image

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.