На что обратить внимание ИТ-руководителю

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


    / фото Markus Spiske CC

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

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

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

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

    Этот подход относится и к организации работы ИТ-отдела. На этом уровне следует понимать, как продвигать новые инструменты и выстраивать процессы таким образом, чтобы повысить качество работы сотрудников и (в идеале) снизить нагрузку на каждого из них.

    Книги по теме


    Помимо общих мыслей и советов участники дискуссии на HackerNews делились примерами книг, которые так или иначе отвечают на поставленные вопросы. Мы решили собрать их в список:

    P.S. Немного о работе нашего провайдера виртуальной инфраструктуры:

    1cloud.ru
    IaaS, VPS, VDS, Частное и публичное облако, SSL

    Комментарии 15

      +2
      А что почитать на русском?
        0
        «Мифический человеко-месяц» точно есть в электронке на Books.ru в переводе (hint: а ещё там периодически бывают распродажи ;)).
        +1
        Вопрос только, зачем переходить в руководители, терять квалификацию, если ведущий разраб в среднем получает столько сколько ПМ.
          0
          Не все решают деньги. А если просто хочется? Мне кажется это единственная существенная причина (конечно при наличии такой возможности). Переходить в руководители против собственного желания конечно не нужно.
            0
            Руководить людьми это не самое приятная задача, я бы не советовал…
              0
              Согласен. Но не попробуешь — не узнаешь. Если есть желание — нужно обязательно искать такую возможность.
              Всегда лучше сделать и ошибиться, чем не сделать и всю жизнь себя пилить неопределенностью «а вот если бы я тогда...».
                +1
                Полностью Вас поддерживаю!
            0
            Вот хороший ответ на аналогичный вопрос: habrahabr.ru/company/payonline/blog/268325/#comment_8617761
            Если вкратце, то смысл в расширении сферы влияния и власти. На руководящей должности можно реализовать столько интересных задумок, сколько не под силу даже самому крутому ведущему разработчику.
              0
              На мой взгляд руководители вырастают не из первоклассных разработчиков. Скорее из QA или Product Owner/Manager.
              Т.к. тут требуется несколько иные скиллы, чем виртуозное владение байтами. Хотя и наличие технических знаний очень важно.

              Нужно иметь соответствующий склад характера, а разработчики в большинстве своем интроверты.
              Да и по деньгам выигрыша не наблюдается на рынке, а трудоустроиться разработчику проще.
                0
                Мировой тренд — сокращение управленческих кадров. Так что не рекомендую, хотя я сам руководитель и сейчас ухожу больше в разработку.
              +2
              Прочитал я это все, а мысль одна: «ну кто так проводку-то делает?!».
                +1
                Если кто-то из членов команды хочет задать вопрос, хороший руководитель должен быть всегда доступен для этого
                Верно, только руководителю стоит всегда думать — а не сможет ли исполнитель сам ответить на свой вопрос? Если так, то не нужно его «отфутболивать». Даже если вы сейчас читаете «Мегамозг», сделайте очень сосредоточенное лицо, и предложите поговорить об этом через полчаса. Через полчаса сотрудник в половине случаев сам решит эту проблему, проверенно на собственном опыте.
                Если же кидаться решать все подряд вопросы — сотрудники просто потеряют напрочь инициативу. Они будут спрашивать у вас общедоступную информацию и задавать совершенно юниорские вопросы, просто потому что считают что так и нужно. Развивайте инициативу в своих сотрудниках!
                  0
                  Важно держать в уме цели бизнеса
                  Если мы говорим о руководителях уровня тимлидов, то бизнес это совсем не их уровень компетенции.
                    0
                    Технический руководитель проекта больше всех заинтересован в том, чтобы его архитектура была продуманной, а код — качественным, считает пользователь arnonejoe. Это значит, что руководитель должен продвигать внедрение признанных механизмов, помогающих улучшить качество работы — например, логирование или инструментацию кода.
                    Руководитель должен прежде всего думать о приоритетах конкретного проекта. Если есть время и ресурсы — конечно стоит подумать об инвестициях в будущее в виде глубокого рефакторинга и внедрения новых инструментов.
                    Если «сроки горят» нужно иметь смелость настаивать на быстрых решениях.
                      +1
                      А вот история о том, как бармен сначала стал разработчиком, потом ушел в проджект-менеджмент: dou.ua/lenta/interviews/barman-project-manager

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

                      Самое читаемое