Пользователь
0,0
рейтинг
18 ноября 2013 в 21:04

Управление → Проблемы перехода в менеджеры среднего звена из песочницы

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

Сегодня могу смело сказать — я руководитель среднего звена. Уже прошел переходный период, официально звучит по другому должность и реально делаю совершенно другую работу, чем некоторое время тому назад. Но с какими трудностями пришлось столкнуться в эти пару лет, чего стало не хватать, почему я стал немного по другому относится к проблемам — тут давайте поподробней.

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

Проблема №1 — Я перестал творить


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

Проблема №2 — Общение с людьми


В работе менеджера это одно из важнейших качеств и его пришлось резко развивать. Программист чаще всего общается со своей командой, парой начальников и смежными специалистами. Круг общения менеджера гораздо шире и надо уметь говорить с разными людьми, причем клиент, начальство и твоя команда — это всего лишь вершина айсберга. Гораздо больше сюрпризов и интересных событий связано с другими людьми. Например, пойти в соседний отдел и попросить одного человека в помощь на неделю (кризис у нас) или думать как поздравить сотрудника с юбилеем, подключая корпоративные ресурсы. Думаю, эта проблема является краеугольной для многих программистов, ведь общение им часто дается тяжело, и у каждого свои навыки ведения дискуссии, степень наглости и обаяния, умение начать и поддержать разговор в нужном русле. Если же у вас нет хотя бы частички желания развиваться в каждом пункте, то такая работа не для вас.

Проблема №3 — Все успевать вовремя


Я специально не стал говорить в ключе «Не хватает времени, ничего не успеваю», ведь чаще эта фраза — вопрос восприятия, а не реальной проблемы. И задачи надо ставить так, чтобы их было возможно сделать (речь здесь не о целях, а именно о задачах). Можно сделать всё что угодно, но очень сложно это всё сделать вовремя (не забыть про несколько совещаний, про вопросы, которые тебе задали и хотят получить ответ во вменяемое время). Ещё держать руку на пульсе и следить за основным бизнес процессом, или стоп — может это и есть основной бизнес процесс — быть готовым ответить на любой вопрос. В общем, было тяжело, не помогали ни планировщики, ни напоминалки, коллеги злились, потом ругались, потом жаловались начальству, пока наконец не выработалось несколько правил, которые помогли именно мне. В интернете очень много статей по тайм-менеджменту, каждая из которых, надеюсь, помогла кому-то, главное — найти то что поможет тебе.

Проблема №4 и наверно самая страшная — Нервы


Менеджер — это ответственность за проект, за команду, и если что-то идет не так, то ты начинаешь переживать. Были моменты, когда я плохо спал, когда выпивал, чтобы сбросить напряжение, но, как оказалось, время все лечит. Через пару кризисов и год такой работы стало намного проще. Сейчас я спокоен и со стороны могу показаться толстокожим гиппопотамом, которого не пробить. А всего лишь надо сказать себе — если я пережил вон ту штуку, то вот эта — вообще мелочи жизни. А дальше решать задачу, не отвлекаясь на эмоции. Есть люди, которые уходили с руководства проектами именно по причине излишней нервотрепки, и это было верное решение, так как человек не должен идти против своей природы. Умейте остановиться и пересесть в другой вагон, если так будет для вас лучше.

Резюмирую — я не стал рассказывать все, что накопилось, многие аспекты не затронуты, но именно эти 4 проблемы были самыми сложными и, пожалуй, если решить их, то остальное тоже под силу победить.
@uster
карма
4,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Управление

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

  • +3
    А какая была мотивация менять профессию?
    • +2
      Было 2 основных момента:
      1. Стало скучно только программировать
      2. Ситуация так сложилось что я был лучшим кандидатом.
  • +12
    Искренне не понимаю зачем, будучи программистом, переходить на административную работу.

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

    Возвращайся, пока не поздно! :)
    • +6
      Ну менеджер среднего звена это совсем другие деньги, не уверен, что uster захочет назад.
      • +5
        Действительно хороший разработчик зарабатывает на уровне менеджера среднего звена, а иногда и больше.

        Когда я переходил на позицию менеджера для себя оперировал следующими аспектами:
        — На позиции производственной единицы (разработчик, дизайнер etc) человек занимается низкоуровневым творчеством, выполняя поставленные задачи, чаще всего имея меньше степеней свободы, так как действуешь в рамках чужой постановки.
        — На позиции менеджера (PM, CTO etc) ты имеешь больше степеней свободы, действуешь в рамках более выскоуровневой постановки, можешь влиять сразу на весь проект или на несколько, по сути простор для творчества не меньше, а часто больше, так как ты являешься первоочередным постановщиком задач и можешь моделировать\проектировать в своем видении, ограничиваясь лишь рамками проекта и здравого смысла.

        Попробовав себя в обеих ролях выбрал второе, но тут уж вопрос предрасположенности и личного настроя.
        • +9
          Если сравнивать действительно хорошего разработчика и действительно хорошего менеджера среднего звена, то разработчик будет даже не близко. Плюс самая большая разница в том, что труд разработчика не масштабируется так хорошо, как труд управленца.
          • 0
            Результаты труда программиста масштабируются на порядки лучше. Так что это не аргумент.
            • +10
              Вы издеваетесь или у вас шутки такие? Управленец может нанять второго программиста и потенциально увеличить этим выхлоп вдвое. А у программиста 24 часа в сутках и если он уже 8 работает то 16 работать он сможет ну недели 2, а потом будет следующие 2 балду пинать, что бы отойти от перенапряжения.
              • 0
                Абсолютно верно. Покинул фриланс и перешел на административную работу во многом из-за этого.
              • +2
                А вы не путаете понятия «масштабирование труда» и «масштабирование результатов труда»? :)
      • 0
        Как раз по деньгам разницы особой нет
  • +2
    Менеджеры среднего звена это менеджеры у которых в подчинении менеджеры. Если лидов считать менеджерами, то проджект менеджер среднее звено, если не считать то проджект менеджер это менеджер нижнего звена.
    • 0
      Сеньоры тоже могут выполнять часть менеджерских функций.
      • +1
        Проджект менеджер тоже может писать код или креативить.

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

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

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

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

      • +3
        Работа программиста отличается от работы менеджера в том, что программист работает с детерминированными сущностями, а менеджер — нет :)
  • 0
    Чего только не прочитаешь в статьях про менеджмент и менеджеров и комментариях к ним.

    Большинство из них пестрит заблуждениями на тему того, что есть менеджмент, что есть проект и кто такой менеджер проектов.
    Сам являюсь менеджером среднего звена, сам когда-то был разработчиком, затем синьором, затем лидом.
    Перешёл в менеджмент целиком по собственной инициативе. Однако периодически имею возможность заниматься разработкой на работе.
    Я не согласен с тем, что работа менеджера проектов не креативна.
    Она в чём-то похожа на программирование, только для создания результата используются не классы, функции, операторы и прочие сущности, а ресурсы, люди, взаимоотношения и т.д. и т.п.
    Кроме того, будучи разработчиком никогда не мог дома отключаться от работы полностью. И поэтому если и занимался разработкой дома, то всё это было связано с работой.
    Сейчас я могу отключаться от работы полностью. Возможно, это не так, но я это связываю именно со своей позицией. И теперь дома я могу заниматься разработкой для себя. Какие-то свои проекты, идеи и т.п.
    И, наконец, по поводу доходов. Чаще всего ЗП разработчика выше, чем ЗП менеджера среднего звена.
    • 0
      — Кроме того, будучи разработчиком никогда не мог дома отключаться от работы полностью.

      Здесь безусловно соглашусь. У меня изза этого возникла проблема, не мог полностью абстрагироваться от работы (работаю дома, рабочее место всегда на виду). Сняв с себя полностью кодинг по работе — научился расслабляться и «ничегонеделать» в нерабочие часы, по крайней мере по работе.
    • +1
      А я перешел в сферу разработки из управленцев среднего звена (это не было связано с разработкой). Прямиком в разработчики, да. И будучи менеджером, я не мог отключаться от проблем дома, а став синьором, выхожу за порог — и словно бы погружаюсь в другой мир — рабочие задачи улетучиваются и не мешают спать, жить, есть, общаться с девушками, заниматься спортом. Внутренняя речь полностью исчезла. Стал гораздо менее агрессивным. И я тоже связывал это изменение со сменой деятельности (что, кстати, тоже положительно отразилось на доходах в целом даже на первых порах). Но теперь уже даже и не знаю…
    • 0
      > Чаще всего ЗП разработчика выше, чем ЗП менеджера среднего звена.
      Менеджер среднего звена (=руководит другими менеджерами) по самому минимальному сценарию организует работу 15-20 человек, реально до сотни.
      Его зарплата никаким образом не может быть меньше зарплаты типичного сотрудника, находящегося ниже по иерархии.

      То, что обозначено в этой статье («руководитель небольшого отдела») — это тимлид, младший менеджер. Но никак не среднего звена.
      • –1
        Да ну, бросьте…
        Средняя ЗП менеджера (лезем на hh) ниже, чем средняя, скажем, Java-разработчика.
        Хотя тут могут быть различия в трактовании слова «среднего».
        • 0
          Гораздо удобнее у Яндекса:
          Менеджер проектов
          Java-программист
          • 0
            Штука в том, что вакансия «менеджер проектов» есть не только в IT, и сумму занижают вот эти неайтишные вакансии.
            • 0
              Не переживайте, нефтегазовый и банковский сектора это с лихвой компенсируют
  • +1
    сидел с новыми программистами и заставлял их переписывать код, который по моему мнению был неудачным

    Очень напомнило из "Москва-Петушки":
    Со мною на трассе дядя Коля работал — тот тоже: сам не пьет, боится, что чуть выпьет и сорвется, загудит на неделю, на месяц… А нас — так прямо чуть не принуждал. Разливает нам, крякает за нас, блаженствует, гад, ходит, как обалделый…
    Вот так и ваш хваленый Иоганн фон Гете! Шиллер ему подносит, а он отказывается — еще бы! Алкоголик он был, алкаш он был, ваш тайный советник, Иоганн фон Гете! И руки у него как бы тряслись!

    Не поймите не правильно.
    • 0
      Это эгоистично было, полностью согласен. Сейчас слава богу не занимаюсь такими вещами. Зато нашел другую отдушину — начал немного работать сопровожденцем, находить проблемы пользователей и решать их. Это позволяет и оставаться в курсе продукта и не мешает нормальным программистам делать свою работу.
  • 0
    А дальше решать задачу, не отвлекаясь на эмоции.

    Как бы их вообще отключать (на время) научиться, было бы здорово.
    (Я тоже менеджер из программистов. Но всё ещё программирую дома ночью под одеялом =) ).
  • 0
    Спасибо за статью. Сам в свое время проходил через это, но в итоге решил вернуться в разработку. По мимо всего вышеперечисленного, для меня стало проблемой, что для менеджера, по мимо самих результатов, еще важно, как ты эти результаты преподнесешь. Т.е. просто отработал план на все 100%, в глазах руководства может быть менее ценно, чем отработать план на 70% + три часа рассказывать, какие все молодцы и как все здорово.
  • 0
    Можно немного расшифровать эту фразу:
    Менеджер — это ответственность за проект, за команду

    Запивать стресс алкоголем, не спать и сильно переживать — это безусловно здорово и молодежно, но какая конкретно ответственность лежит на менеджере? И что он может сделать, если он не пишет и не ревьювит код? Придет к начальству после наступления дедлайна, потупив глаза в пол, со словами: «Мы недостаточно сильно старались, но в следующий раз будем стараться сильнее?»

    P. S. не троллинг, просто в самом деле интересно
    • 0
      Менеджер — это ответственность за проект, т.е. ответственность за то, что эта активность будет выполнена в соответствии с ожиданиями всех заинтересованных сторон, а сроки и бюджет будут соблюдены.
      Проект — это не только писать и ревьюить код. Тем более, что проекты по своему роду бывают очень разные, в том числе не связанные с разработкой или связанные не только с разработкой.
      Контролировать выполнение задач, качество выполнения задач, сроки, бюджет, согласовывать изменения в проекте, следить за рисками и реагировать на них и многое-многое другое.
      Те слова, которые вы процитировали, — это пример плохого менеджмента. Хороший менеджер определит это самое «мы недостаточно сильно старались» своевременно и примет меры.
      Я понимаю, что это как игра в шахматы, но попробуйте побыть для себя одновременно и заказчиком, и исполнителем. Представьте, что на кону очень-очень большие деньги и положение на рынке. Если вы сделаете упор только на код, вы быстро поймёте, что гарантировать качество, сроки и бюджет без кучи посторонней для программиста деятельности очень трудно. Вот эта «куча посторонней для программиста деятельности», сильно утрируя, и есть деятельность менеджера проекта.
    • +1
      но какая конкретно ответственность лежит на менеджере?

      Увольнение за профнепригодность, но плюс кучу минусов в карму как и от исполнителей, так и от заказчиков.
      • 0
        Согласен с VolCh, это такая же работа, просто не имеющая такой явной оценки результата как программирование. Можно конечно уйти в абсолютизм — завалил проект, значит твой косяк. Но наверху обычно тоже не дураки сидят и видят окружение. Плюс это один из аспектов работы — уметь себя разрекламировать (без фанатизма).
        • 0
          просто не имеющая такой явной оценки результата как программирование
          Если нет критериев оценки менеджера, значит его руководство недорабатывает. Как правило — это достижение заданных целей. Это могут быть не только релизы и законченные проекты, а например построение команды, инфраструктуры, разработка и введение каких-то регламентов и стандартов и т.п.
          • 0
            Тогда немного перефразирую — у программиста гораздо легче понять добился результата или нет и это даже в разных конторах более или менее похоже. У менеджера — такой разброс гораздо шире, что по одной системе молодец, по другой — просто недоразумение занимающее стул.
            • 0
              у программиста гораздо легче понять добился результата или нет
              Расскажите пожалуйста, подробнее, как вы это определяете. Из моей практики это очень непростая задача.
              • 0
                Приемочные тесты (необязательно автоматизированные).
                • +1
                  1. тесты прошли успешно. Правда со 110 раза и с отставанием на полгода. Добился результата?
                  2. Тесты прошли успешно, раньше срока. Правда выяснилось, что программа работает только на машине разработчика и тестовом сервере. А у клиента не работает. Добился результата?
                  3. Тесты прошли успешно, все работает, клиент счастлив. Через месяц клиент просит допилить фичу, команда программистов смотрит код и выясняет, что хоть фича и мелкая но код настолько негибкий, что придется переписать половину.
                  И т.п. кейсы. не все так просто.
                  • 0
                    Если в задании на разработку был указан срок, окружение в котором должно всё работать и требования к архитектуре/коду, то всё это довольно просто верифицируется в булевых значениях (разве что субъективно может быть мнение гибко/не гибко, но какие-то формальные условия все равно можно предусмотреть).
    • 0
      В статье про менеджера «среднего звена» пишут. Это ближе, что по-английски Resource manager, а по-русски — начальник отдела. Т.е. руководитель 15-50 человек обычно. Одна из форм ответственности — финансовая за отдел. Т.е., скажем, приходы по проектам, где заняты подчиненные проектные менеджеры и программисты, должны покрыть расходы на зп, аренду и т.п. Плюс норма прибыли. Ответственность — не покрыли — ищи деньги.
      • 0
        Т.е. руководитель 15-50 человек обычно
        Напрямую руководить такой оравой получится только в армии, на стройке или низкоквалифицированном производстве. Предельное рекомендуемое количество подчиненных — 7. Если больше, надо выстраивать иерархию снизу.
  • 0
    Всего 4 проблемы? Пффф…
    • 0
      Я не хотел писать топик на 5 листов, поэтому путем отбора выбрал 4 проблемы. Так то их больше гораздо
      • 0
        А как отбирали? Это же все ваш опыт, я так понимаю?
  • 0
    По критерию «Что для меня было самое сложное и где надо было себя перебороть». Были трудности связанные с недостатком знаний и умений, но их пришлось преодолевать и это верно. А эти 4 проблемы прямо были как кость в горле.
    • +1
      Для меня самой большой проблемой было делегирование ответственности. Т.е. полномочия я вполне успешно делегировал, а ответственность принимал всю на себя. Когда случился большой фейл (что бывает у всех) и система отреагировала репрессиями на всех уровнях, команда была сильно обижена, т.к. раньше руководителю удавалось оградить команду от суровой корпоративной действительности.
  • 0
    Удалил

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