Пользователь
0,0
рейтинг
20 ноября 2013 в 03:17

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

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

Немного лирики


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

Ремарки по посту автора


Я перестал творить

Согласен — бида (ошибка в написании специальна). Тем не менее, проблема решаема, как автор справедливо указал в первой части, посредством кодинга. Свой проект, чужой — да пофигу, на самом деле, чей именно. Но вторая часть просто взбесила. Тот, кто сталкивался во время работы с заказчиком, который «я тоже кодил», меня поймет. Если работа, код, его стиль и написание не регламентированы четкими правилами, принятыми стандартами или внутренними распоряжениями компании — отойди от разработчика! Он не обязан писать код так, чтобы тебе нравилось (опять же ремарка — «ты» — обращение общее, а не направленное на конкретного автора). Он обязан писать код так, чтобы он работал. И все наши пристрастия и требования — всего лишь НАШЕ видение кода. А если это джуниор, у которого вы боитесь найти конструкцию вида:
id=0;
id++;
id++;
id++;
то за этим должен следить тот, кто к этому человеку преставлен, как начальник, но никак не тимлид.

Общение с людьми

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

Я написал код вот так. А я вот так. А у него не правильно. А это не я сломал. А дизайнер сошел с ума. А делать это 2 недели. А клал я на дедлайн через неделю. А архитектор ошибся. А тут надо было вот так. А БД не правильная. А давайте гуиды индексами.

Мало? Есть еще и заказчик.

А вот тут должно быть так. А тут вот этак. А мне наплевать на ТЗ. А я не подпишу акт. А я визуал, пока не увижу — не скажу, как оно должно работать. А вот тут нужно кнопочку. А мне плевать, что переписать пол проекта. А вы меня обманываете. А почему вы сразу не заложили, если теперь пол проекта переписать. И вообще, я 20 лет назад лабы на паскале писал, ща я научу вас работать.

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

Все успевать вовремя

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

Нервы

Пожалуй, единственное, с чем я не стал бы спорить. Нервов уходит прямо пропорционально сумме в зарплатной ведомости. Как сказал мне однажды один из начальников — «Чем больше денег, тем больше тараканов в коллективе».

Пропущено

Работа с документами. Это действительно становится проблемой, когда их размер скачкообразно увеличивается. Все ведь любят писать комменты, верно? Особенно к готовому коду? Каждый программист в душе смакует тот сладостный миг, когда ты начинаешь выполнять самое сложное и важное — писать комментарии к коду, который появился всего лишь за минуту работы, да подумаешь, левой пяткой в перерыве между кофе и сигаретой. Но хватит иронии — если даже документирование кода вызывает четкий рвотный рефлекс, то о чем говорить, когда подобной дребедени нужно писать на порядки больше.

Работа с коллективом. Уже описывал, но остановлюсь отдельно. Ты вдруг выныриваешь, и видишь, что вокруг — тоже программисты. И — о ужас! — они все пишут по-разному. Кто то решает задачу так, кто то иначе. Кто пишет кучу кода, лишь бы было красиво и элегантно, но при этом выполняет таск на 8 часов в течение 40, другой — решает задачу в лоб. Третий — кривопаттерный олигофрен, который вообще не знает, как правильно писать ПО, в отличие от великого гуру вас. Даже если это не транслировать в открытую, то один черт это лезет подспудно, как червячки. И с этим приходится бороться и душить в себе. Более того — все эти люди работают с разной скоростью. Которая при этом еще и зависит от внешних факторов. Которые, естественно, чушь.
Когда вы были программистами, такое объяснение, как не выспался, могло быть оправданием, причем существенным, вашей пониженной скорости работы. А когда вы стали руководителем — то какого покемона?! Разницу сложно понять и прочувствовать.
Хуже всего, когда вас бросает на уровень, в котором вы раньше не плавали. Писали бизнес-логику? А на-ка тебе дезигнера! Креатили гуя? Вот тебе работа с базами данных. И шнелле, шнелле! Время = деньги.

Ответственность за результат. Забудьте о том, что есть объяснение, почему не работает функция. Забудьте вообще, что есть функции. Есть продукт. Он либо работает, и вы молодец, почет, уважуха, и +2 печеньки к чаю, либо — не работает. Это понятно, что обосновать можно почти все, что угодно. Но первичен факт — в зоне ВАШЕЙ ответственности НЕТ результата. Прогресс есть, результата нет. Нужно менять парадигму мышления.

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

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

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

Если резюмировать — проблем может быть немало. Может и мой список для кого то покажется коротким. Да и мне он кажется коротким с точки зрения руководителя — у меня еще болтается куча факторов, о которых я бы мог рассказать. Но при этом это уже не задача руководителя среднего звена. Но то, что было написано в статье — это парниковые условия. Без вариантов. Реальность более жестокая, непредсказуемая, и самое главное — она полна людей. На которых и надо делать акцент. Все остальное — вторично.
@dtcDev
карма
68,5
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

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

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

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

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

    1) «Колючесть ежей приводит к уколам.»
    2) «Правильно написанный еж не колется»
    3) «Колется ёж или нет — личное дело каждого»
    4) «Моя история про ежа»
    5) «Настраиваем дикобраза в OpenVZ через ssh посредством Rest-API с дискового телефона подводной лодки. 900 простых шагов. „
    6) “Пишем ежа в 30 строк ассемблера»
    7) «Я ёж, и вот моё мнение»
    • +3
      Ответил бы в комментах к самой статье, если бы не был в статусе рид-онли. А так пришлось в песочницу накатать
  • +1
    Это уже ближе к правде. Ожидаю еще ряд статей, срывающих покровы с нелегкого труда руководителя.
    • 0
      Всё просто — сам-себе-начальник :)
      • +1
        У сожалению, сам себе начальник имеет еще больше проблемное поле и еще большую зону ответственности
        • 0
          Ответственность — да, повыше чем «менеджер среднего звена». Но возможностей больше: и прогулы, и зарплата и прямой контакт с клиентами. Если бизнес небольшой, то это даже проще и приятней, чем ходить под шефом.
  • +22
    Типичная судьба менеджера среднего звена
    image
  • +16
    Орал я одно время, что у менеджеров судьба лёгкая, а мы разработчики мол бедолаги. А потом однажды позвали меня на спринт митинг, а потом по телефону дали с заказчиком поговорить, а потом писать письма. А потом я заткнулся и не орал больше.
    • +4
      Самое паршивое в работе менеджера, как по мне — наша работа воспринимается как некий «воздух». Он был, есть и будет всегда и везде, он бесплатен и его не может не быть (опустим инсинуации на эту тему). Но осязаемого результата нет, т.е. результат воспринимается потребителями как нечто естественное, а вот его отсутствие — как нечто из ряда вон выходящее. Т.е. за положительный результат твоей работы тебя не ценят, не отмечают т.д. и т.п., кроме того он не осязаем в виде конечного продукта, как результат программиста.
      Вспоминается Экклезиаст на эту тему — суета сует и всё суета.

      P.S.
      Несколько сумбурное изложение личных ощущений, но как-то так пока, м.б. кто-то более изящно изложит.
      • 0
        кроме того он не осязаем в виде конечного продукта, как результат программиста
        Интересно, каким образом программист делает конечный продукт?
        • 0
          Программирует, как ни странно.
          • 0
            Программа, написанная программистом — это еще далеко не продукт.

            Как минимум кто-то должен этот продукт придумать концептуально, обосновать экономически. Далее аналитик — написать программисту ТЗ, тестировщик должен программу проверить, документатор — написать пользовательскую документацию, дизайнер — сделать красиво, менеджер по продукту — правильно спозиционировать продукт на рынке (еще до начала разработки) установить правильные цены, разработать стратегию развития и продвижения. Как видите работа программиста хоть и черезвычайно важный этап создания продукта, но это всего лишь один из множества этапов создания Продукта.
            • 0
              Я вам про разницу между созидательным и организационным трудом, а вы мне расписываете схему создания конкретного продукта.
              Тёплое с мягким сравниваете.
              • 0
                Критерием успеха менеджера является достижение целей. Очень просто.
                • 0
                  Нет, не очень просто.
                  Достижение целей — коллективная заслуга, из которой вычленить вклад менеджера почти всегда невозможно. В то же время, в случае провала вину менеджера можно достаточно выявить. Именно об этом, на мой взгляд, написал выше пользователь hDrummer.
                • 0
                  не могу согласится.
                  иногда правильней остановить проект, чем достигать целей любой ценой.
                  мобилизационный принцип в голове («все для фронта, все для победы!») часто мешает менеджерам.
                  поиск вот этого баланса, между достижением цели и затраченными ресурсами и есть, по сути, работа менеджера.

                  не будем, пожалуй, рассуждать про постановку целей и критерии успешности.
                  это — отдельная, большая и больная, тема.
                  • +1
                    мобилизационный принцип в голове («все для фронта, все для победы!») часто мешает менеджерам.
                    На эту тему очень интересно написано в книге «Русская система управления» М.Прохорова. Сейчас читаю. Прелюбопытнейший труд, надо сказать!
                    • 0
                      мы тут про менеджмент говорим, а не про национальную идентичность.
                      я имел в виду, что установка на достижение цели может быть вредна и оценка «успешности» только по целям — признак слабого менеджмента, обычно.

                      кстати, работа прохорова — весьма спорная.
                      • 0
                        я имел в виду, что установка на достижение цели может быть вредна
                        Тогда очевидно цели неверные? Зачем менеджеру поставили вредные цели? Да, косяк его руководства.

                        кстати, работа прохорова — весьма спорная.
                        Да, есть такое. Но весьма интересная. Многое объясняет.
                        • 0
                          в моей вселенной руководитель сам формирует цели ориентируюсь на стратегию компании. самостоятельность принятия решений и отличает руководителя от линейного сотрудника,
                          т.е. «руководство» формирует стратегические цели (мы же не говорим сейчас о топ менеджерах и корпоративном управлении?)
                          более того, менеджер всегда может (даже должен) отказаться от проекта, если ему навязывают решения, с которыми он не согласен.
                          • 0
                            в моей вселенной руководитель сам формирует цели ориентируюсь на стратегию компании.
                            Да, он сам формирует цели для своей команды. При этом ему сверху тоже спускают цели. Это в моей реальности.

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

                            более того, менеджер всегда может (даже должен) отказаться от проекта, если ему навязывают решения, с которыми он не согласен
                            Разумеется, мы ж не роботы.
                        • 0
                          Тогда очевидно цели неверные? Зачем менеджеру поставили вредные цели? Да, косяк его руководства.

                          Цель может быть верная, если не добиваться её любой ценой, а вовремя доложить, что она слишком дорого обойдется или хотя бы о рисках этого. Руководство могло рассчитывать на компетентность менеджера в оценке «слишком дорого», поскольку все возможные критерии явно задавать сложно и оно рассчитывает, что в критические ситуации менеджер распознает и доведет до сведения.
                          • 0
                            Разумеется менеджер должен эскалировать проблемы, которые сам не может решить. Но тут речь шла про оценку его работы. Оценка через достижение целей — один из вариантов.
                            Кроме целей можно придумать еще какие-то KPI конечно.
                            • 0
                              Я о ситуациях, когда он решить может и решает, цели достигает, но такими методами, что лучше бы вынес наверх предложение закрыть проект — это оказалось бы менее убыточно.

                              Пример: проект релизиться в срок, но все ключевые разработчики уходят как только получают бонусы за него — некому ни поддерживать, ни развивать, ни делать другие проекты. Для релиза в срок пришлось людей мотивировать работать не 8/5, а 12/7, за обещанную «морковку» они зарелизили, но больше даже мысли о такой возможности допускать не хотят и уходят в другие места, где такого скорее всего не будет.
                              • 0
                                Как и любую ситуацию, эту можно оценивать с разных точек зрения. Если этот менеджер сам собирается валить после проекта? Наверное с точки зрения своей мотивации он все сделал правильно. С точки зрения команды — возможно тоже, бонусы то все получили. Возможно — нет. С точки зрения руководства — смотря что они ждали от этого проекта и команды. Может проект изначально мертвый, коррупционный? Если проект реальный и живой — значит конечно менеджер здорово им все испортил.

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

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

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

                                    Кроме того, повторюсь, стратегические цели должны быть. И они должны быть доведены до каждого человека, принимающего решения. С этим часто проблемы бывают.
            • +5
              Вы придираетесь и спорите о формулировках, не о сути.

              Вот аналитик написал ТЗ — его видно, 40 страниц, схемы, диаграммы…
              Вот поработал дизайнер — эскизы предоставил.
              Вот программист кнопочки понажимал — и формочки заработали, письма отправляются, циферки автоматом считаются
              Вот менеджер поработал… что показать? Уже сложнее.

              Вот об этом и речь шла. Все они — аналитик, программист, дизайнер, менеджер — вложили усилия в продукт. Но менеджеру сложнее обосновать свой вклад. Мне просто кажется, именно об этом говорил hDrummer, не более того.
              • +1
                В точку.
              • +1
                Вот менеджер поработал… что показать? Уже сложнее.
                У менеджера должны быть заранее обозначенные конкретные цели. Выполнил — молодец.

                Например — выпустить продукт к такому-то сроку. Что тут может быть неочевидного?
                • 0
                  А как доказать роль его в этом процессе? «Сидел, кофеёк попивал, с кем то там болтал, а остальные работали! А цели все подчинённые добились! Нафиг он там нужен, все же профессионалы?» Что именно он добился? Что верно делегировал, а не подчинённые сами разобрали задачи между собой, сами решили все проблемы в обход менеджера, потому что тот тормозил или больше мешал, т.к. коллектив сработавшийся давно.

                  Повторюсь, речь об этом. Не о достигнутом результате, а об роли в процессе. Она у менеджера чем то сродни сапера/барабанщика/кого там ещё в пример ставят — если всё хорошо работает, не очевидно, что благодаря ему, а вот если ошибется — виноватый сразу находится.
                  • +3
                    А как доказать роль его в этом процессе?

                    Кажется понял вас. Тут все зависит от наблюдателя.

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

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

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

                      Если этот руководитель не любитель общаться с исполнителями напрямую, минуя пару уровней субординации. Мало того что общаться, так задания ставить или менять, а менеджеру об этом сообщить никто не удосуживается. А спрашивают потом с него.
                      • +1
                        Если этот руководитель не любитель общаться с исполнителями напрямую, минуя пару уровней субординации
                        Да, подобные проблемы существуют. Тут менеджеру нужно выдерживать жесткую позицию по отношению к своему начальству.
                        В этом кстати нет никаких проблем. Пойдите и наорите на своего биг-босса, тет-а-тет разумеется.
            • +6
              >Программа, написанная программистом — это еще далеко не продукт.

              А ну-ка откройте консольку и напишите там
              wget http://habrahabr.ru/
              


              Скачалось? Скачалось. А теперь покажите мне в wget работу дизайнеров, аналитиков, экономическое обоснование, работу менеджера по позиционированию продукта, бла-бла-бла.
              • 0
                Кто-то спроектировал интерфейс — дизайнер
                Кто-то поставил задачу «тулза, позволяющая скачивать страницы по хттп» — аналитик
                Кто-то решил что проще написать один раз универсальную программу, чем для каждой страницы свою — экономист
                Кто-то выложил тулзу в паблик — позиционирование
                Кто-то привлек других людей к работе над ней — эйчар
                • +3
                  tangro как бы намекает, что одному программисту понадобилось скачивать файлы — он написал утилиту, скачивающую файлы. У него не было аналитика, экономиста и прочего. Он просто сам написал программу — и она является «продуктом», хотя труд вложен только его.
                  • 0
                    Просто программист выполнил все эти функции. «Всё-в-одном».
                    • 0
                      А, так Вы просто алиасов навешали на слово «программист» — ну ок. Допишите ещё тогда уборщика (наверняка ведь он по ходу дела хоть раз мусор выбрасывал) и повара (ну чай там он себе делал, скорее всего).

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

                        И вы удивитесь, но бывают экономисты, которые пишут программы сами, не привлекая программистов. Наверное и эйчары такие бывают :)
                        • 0
                          Наверное и эйчары такие бывают :)
                          Когда им надо срочно закрыть позицию — сами на ней работают.
              • 0
                C:\Users\user_123>wget http://habrahabr.ru
                "wget" не является внутренней или внешней
                командой, исполняемой программой или пакетным файлом.
      • 0
        Виталий, вообще на мой взгляд с благодарностью за сделанную работу у нас в ИТ большииие проблемы. Просто даже «спасибо» никто не скажет. Типа ты за это зарплату получаешь и будь доволен, вот твоё спасибо.
        • 0
          Общая тенденция кстати для наёмных рабочих.
        • +2
          Вы водителю автобуса часто говорите спасибо за то, что довез вас до нужной остановки?
          • 0
            В маршрутке говорю за то что не проехал мою остановку :)
          • 0
            Не надо передёргивать, это разные типы отношений.

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

            Между ПМом и мной как допустим программистом — отношения начальника и подчинённого по проектной иерархии. Мы оба делаем свою работу, за которую получаем деньги. Но деньги непосредственно (как правило) НЕ фигурируют, только опосредовано. И даже если фигурируют (например как компенсация за овертайм), они проходят такой длинный круг что в виде поощрения их трудно рассматривать.
            • 0
              Поэтому я писал про водителя автобуса. Вы ему лично деньги не даете в руки, правда? Особенно если у вас проездной.
      • +1
        результат воспринимается потребителями

        А кто потребитель результата труда менеджера? Вышестоящий менеджер?
      • +2
        Не всегда так.
        Да, я не раз встречал со стороны заказчика непонимание, когда в ведомости проекта значилась строчка «менеджмент проекта». Но, как правило, это решалось достаточно просто — вот тебе дизайнер, вот программист, вот архитектор, вот разработчик базы данных. Работайте. Особо упертым хватало 3 дней, чтобы понять, что это АД.

        С другой стороны, при правильной постановке рабочего процесса, вопросов не возникает. По сути дела данная должность — прослойка между руководителем и группой программистов (берем только ситуацию с оценкой результатов, на самом деле предметное поле несколько шире). Если человек, занимаемый должность, не перекладывает на плечи начальства мелкие проблемы коллектива, а на плечи коллектива — спускаемые директивы начальства в прямом виде, то он как раз и выполняет то, зачем он работает — несет полную ответственность за вверенный участок работы. Потому отчитывается перед начальником он. И в голове начальника прежде всего не «ой какая крутая группа программистов, которая все сделала», а «ой какой Вася/Петя/пофиг как зовут молодец, правильно поставил рабочий процесс и все сделал вовремя». Да, группа программистов стоит за плечами этого руководителя, и их успеха никто не умаляет. Это те люди, чьими руками ковалась победа. А тим лид при этом — тот, кто привел к победе. Так что вроде все закономерно.
    • 0
      Она не легкая/трудная, она разная. Каждому свое.
  • +12
    Типичная встреча менеджера с директором:
    — Сколько тебе нужно людей чтобы успеть в срок?
    — Еще 3 человека.
    — Это плохо, потому что мы урезали бюджет на разработку и тебе еще придется кого-то отдать в другую команду.
    — Тогда я не успею.
    — Почему?
    — Потому что мало людей.
    — Ну а если постараться?
    — Тоже не успею. Кстати, один из разработчиков просил прибавки.
    — Ну и что делать?
    — Вот план по вытаскиванию из жопы.
    — Нет, у меня другое видение. Мы построим космический корабль и улетим на нем на Марс. И тогда мы завоюем рынок.
    — 0_o

    По реальным событиям.

    • +1
      Глеб, а нафига менеджер при обсуждении планов сообщает о том, что кто-то просил прибавки?

      У него всё в порядке с головой? Он для чего нужен, просто транслировать события?)
      • 0
        Это несколько сокращенный и художественный пересказ :)
      • +4
        Предупреждает о возможных проблемах, что скоро может понадобиться не 3, а 4 человека. И поэтому в план входит повышение зарплаты тому, кто просил.
        • –8
          А вы Глеб?

          «в план входит» или «попросил»?
          • +1
            Денис, ты должен понимать различие между формами изложения. В малой форме (комментарии) всех нюансов не отразить. Разумеется, человек который просит прибавки в контексте общего урезания бюджета это потенциальный минус в штатном расписании, отчего и строился разговор.
            • 0
              Малые формы тем и хороши, что наглядно показываю тострые углы.

              «Мой подчинённый попросил прибавку» — это слова не менеджера, а передаста.

              Менеджер может сказать, «я считаю, что моему подчинённому нужно поднять зарплату, потому что *аргументы*» и «есть *оценка масштаба* риск того, что мой сотрудник уволится, т.к. не доволен текущим уровнем зарплаты, а она объективно на уровне».
              • –1
                Менеджер — это тот, кто решает проблемы, не тот, кто их создает. Оценки и масштабы — это создание проблемы и задача для аналитика. Менеджер приходит с решением, уже оценив проблемы у себя в голове.
                • 0
                  вот ыменно.

                  Плюс я ещё напомню, что анализ — часть управления (PDCA) и в 90% проектов у ПМа нет выделенного аналитика и эту функцию он естественным образом выполняет сам.
          • +4
            А вы Глеб?

            Публичные обсуждения подразумевают, что вклиниться в них может любой. Если вам этого не хочется, то есть возможность написать в личку.
            • –9
              А я специально использую личные обращения, т.к меня интересует мнение конкретного человека, а не неизвестных людей с неизвестными мне ценностями.
              • +3
                Ок, постараюсь запомнить, но не обещаю.
      • 0
        А затем, чтобы показать — есть неудовлетворенный зарплатой сотрудник. Который потенциально может написать заявление — и придется затыкать еще одну прореху.
        • 0
          А где он раньше был с этой ситуацией?
          • 0
            Не слышал еще ни об одном примере, когда плановое повышение оплаты труда могло быть пропихнуто снизу. По факту это низкая культура производственных процессов на предприятии, что ты с ней сделаешь на месте линейного менеджера?
            • 0
              А при чём тут плановое повышение?

              Если только ситуация возникла не вчера, решение по ней должно быть.
              • +4
                Если ты не повышаешь зарплату разработчикам планово, то они заявляют об этом внезапно и так же внезапно уходят. Не сталкивался что ли?
                • 0
                  Это если ты плохой менеджер и не мониторишь степень их удовлетворённости.

                  Я лично не сталкивался, от меня по таким причинам не уходили.
                  • 0
                    Степень удовлетворенности и так понятна если ты варишься в коллективе.
                    Заканчиваю дискуссию, ибо не понимаю, что мы тут обсуждаем. Какое-то капитанство (надо планировать, надо риски, надо то се).
                    • 0
                      Мы обсуждаем представления друг друга о менеджементе.

                      Мне из фразы «варишься в коллективе» понятно, с чем ты имел дело.

                      Если хочешь научиться делать так, чтобы от тебя не уходили внезапно люди, рекомендую книгу:
                      www.amazon.com/Behind-Closed-Doors-Management-Programmers/dp/0976694026
                      • 0
                        Ты же знаешь с чем я имел дело, с размером компаний и т.д. :) Уже из этого должно быть все понятно. Совершенно разный подход к управлению к организациях в 50, в 500 и в 5000 человек.

                        Слово внезапно наверное было выбрано неверно, т.к. имеет отенок загадочности. Нет, если ты едешь по колючей проволоке, то ничего незапланированного и загадочного в проколе для тебя не будет. Но это в любом случае произойдет внезапно, т.е. в неизвестный момент времени.
                        • 0
                          Всё-таки я считаю, что менеджер может иметь персональные управленческие практики, вне зависимости от того, какая культура принята в компании.
                          • 0
                            Не согласен. Ты поедешь к чукчам в шубе, а к папуасам в соломенной юбке. И никак иначе — съедят. Ну или замерзнешь.
                            Управление — коллективная деятельность и ты обязан учитывать коллектив в своих активностях.
                            • 0
                              Я вообще-то говорил про айтишников и только айтишников.

                              Но книжку-то почитай :)
                              • 0
                                За книжку спасибо, почитаю :)
                            • 0
                              .
    • +3
      — Сколько тебе нужно людей чтобы успеть в срок?
      — Еще 3 человека.
      Ээээ, с каких это пор добавление людей в проблемный проект ускоряет сроки?
      • +1
        По классике это только увеличивает хаос. Только вот бывает, что хаоса нет, а нужно просто давать стране больше угля. Если в проекте 5 больших подзадач поторые полностью параллелятся и на это был расчет, то 2 человека на него будет недостаточно. В добавок, эти задачи выполняются разными специалистами.
        • 0
          Да, но только на старте и если эти люди — не с улицы и знают проект.
          • 0
            В примере речь вообще шла не об одном проекте, если что. Т.е. разговор был о работе подразделения, где уже как минимум идет 2-3 проекта. Люди между ними перекидываются (проекты над одной кодовой базой и специалисты в ней ориентируются). Если нужно заткнуть дыру по одному фронту, то некому работать на другом.
            Я вам завидую, если вы не были в таких ситуациях :)
            • 0
              Конечно бывал. Только редко такие ситуации заканчивались успешно. Больше направлял усилий на то чтобы таких ситуаций не происходило. Это уже управление рисками.
              • 0
                Одно другое не исключает.
            • 0
              Т.е. разговор был о работе подразделения, где уже как минимум идет 2-3 проекта
              Тут кстати надо бы определиться о каком «менеджере» идет речь и какая оргструктура в компании: иерархическая или матричная. Или еще какая.
          • 0
            Если срок проекта год, прошло полгода, сделано процентов 30, то разве не разумно увеличить штат, считая что вход в проект займет где-то месяц?
            • +1
              it depends, как говорится. Но в общем случае — да. Правда редко кто за целых полгода до окончания поднимает панику с недостатком ресурсов. Обычно это происходит за день до релиза :)
              • 0
                Как вариант — прошел весь год, должен быть релиз, но сделано процентов 30 и стоит вопрос закрывать проект или может за полгода все же возможно его допилить :)
            • 0
              Сильно зависит от того, что за проект, каковы причины задержек. У любого производства/проекта есть узкое место. Если горлышко там, где добавление людей что-то решит, то это одно. А если нет, то другое.
      • +2
        Ситуации бывают разные.
      • 0
        Ни с каких. Сколько бы не брал примеров из личной практики, какой бы ни был проект — приплюсовывание рабочих рук на позднем этапе с явным запаздыванием ведет всегда только к лишней нервозности и беготне по кругу. Полностью с Вами согласен.
        • 0
          Если это один проект который все-таки продвигается вперед. А если он замораживается, потому что там некому работать от слова вообще? Все ушли на другой фронт, отбивать атаку немцев. Тоже не нужно людей?
          Есть разница между равномерно текущим проектом (где добавление ничего не даст) и хронической нехваткой рабочих рук. Которая решается лишь их добавлением либо закрытием/заморозкой некоторых проектов отдела.
          • 0
            Я говорил о рабочем процессе, в котором есть постоянная команда, которая не успевает. но никак не о крайнем случае заморозки проекта и его последующем форсировании.
  • 0
    • +1
      Скорее по квадрату, учитывая 3 ваших ссылки — это 4-й пост =)
      • 0
        Сколько нужно отрезков, что бы приблизить многоугольник к визуально-гладкому кругу?)
        • 0
          А вот это уже зависит от зрения и разрешения вашего монитора =)
          При соблюдении определенных условий и квадрат за круг может сойти )))
  • 0
    Вспоминается группа Ленинград с клипом Менеджер. И Оргия праведников с песней Офис.
    Все эмоции в нескольких минутах.
  • 0
    Не ожидал что моя статья вызовет такие бурные дебаты и критику. Возможно для части случаев примеры были подобраны весьма утрировано, но только для лучшего понимания. Немного отвечу на посылы, но без фанатизма, т.к. все таки это обсуждение того же самого, только с другой точки зрения.
    1. Абсолютно согласен про тепличные условия, у нас в конторе это гораздо проще и много уровней руководства, которые могут тебе помочь, если откровенно ошибешься. Но это я считаю достоинством своего места работы, которое позволяет более легко входить в новою роль.
    2. Насчет времени. Для менеджера это качество должно немного иное, чем для программиста, объясню почему. Как писали в комментариях разработчик занимается 1-2 задачами и если говорит что не успевает, то тут уже ничего не поделаешь в большинстве случаев — либо сокращаем функционал, либо ждем (случай навалимся всей толпой не рассматриваю). У менеджера задач в разы больше и очень важно сделать их вовремя, иначе последствия могут быть гораздо больше чем от косяка 1 программиста, ведь нитки часто сходятся именно на тебе. Профакапил срок опоздал немного, еще три пути после тебя теперь с задержкой на день идут. Можно это свести к организации времени, но я просто переформулировал для себя, что в итоге проблемой стало — все успевать вовремя, ключевое слово не «вовремя», а «Всё».

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

      что касается систем управления проектом, то на мой взгляд, они очень и очень сильно схожи с проблемами, стоящими перед одним программистом.
      Давайте немного раскрою мною же и выданный постулат:
      Проблемы есть везде. У менеджера, у программиста. И у того, и у другого корень проблемы практически всегда один и тот же. Согласование рабочего процесса для менеджера = ожиданию программистом кода от другого участника. И там и там возможны задержки, накладки.
      непостоянство технического задания одинаково ударяет что по менеджеру, что по программисту
      нехватка ресурсов может ощущаться и там и там.

      Одним словом — проблемы прямо рядышком. Менеджеру даже проще — у него больше возможностей для их решения.
  • 0
    Вот одного не пойму. При чем здесь менеджер среднего звена? В этом, а также предыдущем посте на тему менеджерских проблем, идет речь о линейном работнике, перешедшем в менеджмент низшего звена. (см пирамиду управления)

    У среднего звена совсем другие проблемы.

    P.S. Прошу прощения, если зацепил чью-то гордость.
    • 0
      Пожалуй да, в такой классификации статья про менеджеров нижнего звена. Я использовал более известный термин, впредь буду аккуратней
  • +1
    Особенно крах — с фрилансерами. Вы будете, пусть и с опозданием, узнавать о проблемах на линии у провайдера в городе, в котором живет исполнитель, о нелетной погоде, о здоровье неизвестной вам доселе бабушке, а если повезет — о прекрасной незнакомке и не менее прекрасной ночи. Может, даже, с подробностями, но это на любителя. А еще вы узнаете, как учиться кодить самому на незнакомом языке за 2 часа, чтобы выполнить поставленную задачу.

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

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