Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 109
Для меня самой большой проблемой в работе менеджера средней руки оказался тот факт, что теперь в поле зрения не одна задача, которую можно спокойно обдумывать и погружаться, а целый рой (от пяти до двадцати) самых разных задач. От «надо успеть в этот срок развернуть систему» до «когда же придут эти новые более удобные стулья?»
Да ладно, в песочнице обычное весенне-осеннее обострение.
Типичная хабра-неделя в заголовках:
1) «Колючесть ежей приводит к уколам.»
2) «Правильно написанный еж не колется»
3) «Колется ёж или нет — личное дело каждого»
4) «Моя история про ежа»
5) «Настраиваем дикобраза в OpenVZ через ssh посредством Rest-API с дискового телефона подводной лодки. 900 простых шагов. „
6) “Пишем ежа в 30 строк ассемблера»
7) «Я ёж, и вот моё мнение»
1) «Колючесть ежей приводит к уколам.»
2) «Правильно написанный еж не колется»
3) «Колется ёж или нет — личное дело каждого»
4) «Моя история про ежа»
5) «Настраиваем дикобраза в OpenVZ через ssh посредством Rest-API с дискового телефона подводной лодки. 900 простых шагов. „
6) “Пишем ежа в 30 строк ассемблера»
7) «Я ёж, и вот моё мнение»
Это уже ближе к правде. Ожидаю еще ряд статей, срывающих покровы с нелегкого труда руководителя.
Типичная судьба менеджера среднего звена
Орал я одно время, что у менеджеров судьба лёгкая, а мы разработчики мол бедолаги. А потом однажды позвали меня на спринт митинг, а потом по телефону дали с заказчиком поговорить, а потом писать письма. А потом я заткнулся и не орал больше.
Самое паршивое в работе менеджера, как по мне — наша работа воспринимается как некий «воздух». Он был, есть и будет всегда и везде, он бесплатен и его не может не быть (опустим инсинуации на эту тему). Но осязаемого результата нет, т.е. результат воспринимается потребителями как нечто естественное, а вот его отсутствие — как нечто из ряда вон выходящее. Т.е. за положительный результат твоей работы тебя не ценят, не отмечают т.д. и т.п., кроме того он не осязаем в виде конечного продукта, как результат программиста.
Вспоминается Экклезиаст на эту тему — суета сует и всё суета.
P.S.
Несколько сумбурное изложение личных ощущений, но как-то так пока, м.б. кто-то более изящно изложит.
Вспоминается Экклезиаст на эту тему — суета сует и всё суета.
P.S.
Несколько сумбурное изложение личных ощущений, но как-то так пока, м.б. кто-то более изящно изложит.
кроме того он не осязаем в виде конечного продукта, как результат программистаИнтересно, каким образом программист делает конечный продукт?
Программирует, как ни странно.
Программа, написанная программистом — это еще далеко не продукт.
Как минимум кто-то должен этот продукт придумать концептуально, обосновать экономически. Далее аналитик — написать программисту ТЗ, тестировщик должен программу проверить, документатор — написать пользовательскую документацию, дизайнер — сделать красиво, менеджер по продукту — правильно спозиционировать продукт на рынке (еще до начала разработки) установить правильные цены, разработать стратегию развития и продвижения. Как видите работа программиста хоть и черезвычайно важный этап создания продукта, но это всего лишь один из множества этапов создания Продукта.
Как минимум кто-то должен этот продукт придумать концептуально, обосновать экономически. Далее аналитик — написать программисту ТЗ, тестировщик должен программу проверить, документатор — написать пользовательскую документацию, дизайнер — сделать красиво, менеджер по продукту — правильно спозиционировать продукт на рынке (еще до начала разработки) установить правильные цены, разработать стратегию развития и продвижения. Как видите работа программиста хоть и черезвычайно важный этап создания продукта, но это всего лишь один из множества этапов создания Продукта.
Я вам про разницу между созидательным и организационным трудом, а вы мне расписываете схему создания конкретного продукта.
Тёплое с мягким сравниваете.
Тёплое с мягким сравниваете.
Критерием успеха менеджера является достижение целей. Очень просто.
Нет, не очень просто.
Достижение целей — коллективная заслуга, из которой вычленить вклад менеджера почти всегда невозможно. В то же время, в случае провала вину менеджера можно достаточно выявить. Именно об этом, на мой взгляд, написал выше пользователь hDrummer.
Достижение целей — коллективная заслуга, из которой вычленить вклад менеджера почти всегда невозможно. В то же время, в случае провала вину менеджера можно достаточно выявить. Именно об этом, на мой взгляд, написал выше пользователь hDrummer.
Вот тут ответил habrahabr.ru/post/202754/#comment_7004292
не могу согласится.
иногда правильней остановить проект, чем достигать целей любой ценой.
мобилизационный принцип в голове («все для фронта, все для победы!») часто мешает менеджерам.
поиск вот этого баланса, между достижением цели и затраченными ресурсами и есть, по сути, работа менеджера.
не будем, пожалуй, рассуждать про постановку целей и критерии успешности.
это — отдельная, большая и больная, тема.
иногда правильней остановить проект, чем достигать целей любой ценой.
мобилизационный принцип в голове («все для фронта, все для победы!») часто мешает менеджерам.
поиск вот этого баланса, между достижением цели и затраченными ресурсами и есть, по сути, работа менеджера.
не будем, пожалуй, рассуждать про постановку целей и критерии успешности.
это — отдельная, большая и больная, тема.
мобилизационный принцип в голове («все для фронта, все для победы!») часто мешает менеджерам.На эту тему очень интересно написано в книге «Русская система управления» М.Прохорова. Сейчас читаю. Прелюбопытнейший труд, надо сказать!
мы тут про менеджмент говорим, а не про национальную идентичность.
я имел в виду, что установка на достижение цели может быть вредна и оценка «успешности» только по целям — признак слабого менеджмента, обычно.
кстати, работа прохорова — весьма спорная.
я имел в виду, что установка на достижение цели может быть вредна и оценка «успешности» только по целям — признак слабого менеджмента, обычно.
кстати, работа прохорова — весьма спорная.
я имел в виду, что установка на достижение цели может быть вреднаТогда очевидно цели неверные? Зачем менеджеру поставили вредные цели? Да, косяк его руководства.
кстати, работа прохорова — весьма спорная.Да, есть такое. Но весьма интересная. Многое объясняет.
в моей вселенной руководитель сам формирует цели ориентируюсь на стратегию компании. самостоятельность принятия решений и отличает руководителя от линейного сотрудника,
т.е. «руководство» формирует стратегические цели (мы же не говорим сейчас о топ менеджерах и корпоративном управлении?)
более того, менеджер всегда может (даже должен) отказаться от проекта, если ему навязывают решения, с которыми он не согласен.
т.е. «руководство» формирует стратегические цели (мы же не говорим сейчас о топ менеджерах и корпоративном управлении?)
более того, менеджер всегда может (даже должен) отказаться от проекта, если ему навязывают решения, с которыми он не согласен.
в моей вселенной руководитель сам формирует цели ориентируюсь на стратегию компании.Да, он сам формирует цели для своей команды. При этом ему сверху тоже спускают цели. Это в моей реальности.
Я говорю именно о выполнении целей, поставленных сверху конкретному менеджеру как о критерии его успешности. Естественно он должен принять эти цели, прежде чем начинать работать.
Цели которые он сам обозначил команде — это другая история.
более того, менеджер всегда может (даже должен) отказаться от проекта, если ему навязывают решения, с которыми он не согласенРазумеется, мы ж не роботы.
Тогда очевидно цели неверные? Зачем менеджеру поставили вредные цели? Да, косяк его руководства.
Цель может быть верная, если не добиваться её любой ценой, а вовремя доложить, что она слишком дорого обойдется или хотя бы о рисках этого. Руководство могло рассчитывать на компетентность менеджера в оценке «слишком дорого», поскольку все возможные критерии явно задавать сложно и оно рассчитывает, что в критические ситуации менеджер распознает и доведет до сведения.
Разумеется менеджер должен эскалировать проблемы, которые сам не может решить. Но тут речь шла про оценку его работы. Оценка через достижение целей — один из вариантов.
Кроме целей можно придумать еще какие-то KPI конечно.
Кроме целей можно придумать еще какие-то KPI конечно.
Я о ситуациях, когда он решить может и решает, цели достигает, но такими методами, что лучше бы вынес наверх предложение закрыть проект — это оказалось бы менее убыточно.
Пример: проект релизиться в срок, но все ключевые разработчики уходят как только получают бонусы за него — некому ни поддерживать, ни развивать, ни делать другие проекты. Для релиза в срок пришлось людей мотивировать работать не 8/5, а 12/7, за обещанную «морковку» они зарелизили, но больше даже мысли о такой возможности допускать не хотят и уходят в другие места, где такого скорее всего не будет.
Пример: проект релизиться в срок, но все ключевые разработчики уходят как только получают бонусы за него — некому ни поддерживать, ни развивать, ни делать другие проекты. Для релиза в срок пришлось людей мотивировать работать не 8/5, а 12/7, за обещанную «морковку» они зарелизили, но больше даже мысли о такой возможности допускать не хотят и уходят в другие места, где такого скорее всего не будет.
Как и любую ситуацию, эту можно оценивать с разных точек зрения. Если этот менеджер сам собирается валить после проекта? Наверное с точки зрения своей мотивации он все сделал правильно. С точки зрения команды — возможно тоже, бонусы то все получили. Возможно — нет. С точки зрения руководства — смотря что они ждали от этого проекта и команды. Может проект изначально мертвый, коррупционный? Если проект реальный и живой — значит конечно менеджер здорово им все испортил.
Все упирается в единую систему ценностей компании, или стратегических целей. Любая локальная цель не должна противоречить стратегической, разумеется.
Как показывает практика, если эти цели четко не сформулированы и не доведены до всех сотрудников — все их понимают по своему.
Все упирается в единую систему ценностей компании, или стратегических целей. Любая локальная цель не должна противоречить стратегической, разумеется.
Как показывает практика, если эти цели четко не сформулированы и не доведены до всех сотрудников — все их понимают по своему.
Любая локальная цель не должна противоречить стратегической, разумеется.
Собственно об этом я и говорю. По идее это должно быть само собой разумеющимся и потому высшее руководство может не считать необходимым сообщать это, а менеджер может решить, что ему дан карт-бланш на любые методы достижения локальной цели. Может и есть в таких ситуациях косяки руководства, но и менеджер явно проявляет непрофессионализм не уточняя необходимость принятия рискованных в стратегическом плане решений ради формальной оценки по результату.
менеджер явно проявляет непрофессионализм не уточняя необходимость принятия рискованных в стратегическом плане решений ради формальной оценки по результатуСогласен.
Кроме того, повторюсь, стратегические цели должны быть. И они должны быть доведены до каждого человека, принимающего решения. С этим часто проблемы бывают.
Вы придираетесь и спорите о формулировках, не о сути.
Вот аналитик написал ТЗ — его видно, 40 страниц, схемы, диаграммы…
Вот поработал дизайнер — эскизы предоставил.
Вот программист кнопочки понажимал — и формочки заработали, письма отправляются, циферки автоматом считаются
Вот менеджер поработал… что показать? Уже сложнее.
Вот об этом и речь шла. Все они — аналитик, программист, дизайнер, менеджер — вложили усилия в продукт. Но менеджеру сложнее обосновать свой вклад. Мне просто кажется, именно об этом говорил hDrummer, не более того.
Вот аналитик написал ТЗ — его видно, 40 страниц, схемы, диаграммы…
Вот поработал дизайнер — эскизы предоставил.
Вот программист кнопочки понажимал — и формочки заработали, письма отправляются, циферки автоматом считаются
Вот менеджер поработал… что показать? Уже сложнее.
Вот об этом и речь шла. Все они — аналитик, программист, дизайнер, менеджер — вложили усилия в продукт. Но менеджеру сложнее обосновать свой вклад. Мне просто кажется, именно об этом говорил hDrummer, не более того.
В точку.
Вот менеджер поработал… что показать? Уже сложнее.У менеджера должны быть заранее обозначенные конкретные цели. Выполнил — молодец.
Например — выпустить продукт к такому-то сроку. Что тут может быть неочевидного?
А как доказать роль его в этом процессе? «Сидел, кофеёк попивал, с кем то там болтал, а остальные работали! А цели все подчинённые добились! Нафиг он там нужен, все же профессионалы?» Что именно он добился? Что верно делегировал, а не подчинённые сами разобрали задачи между собой, сами решили все проблемы в обход менеджера, потому что тот тормозил или больше мешал, т.к. коллектив сработавшийся давно.
Повторюсь, речь об этом. Не о достигнутом результате, а об роли в процессе. Она у менеджера чем то сродни сапера/барабанщика/кого там ещё в пример ставят — если всё хорошо работает, не очевидно, что благодаря ему, а вот если ошибется — виноватый сразу находится.
Повторюсь, речь об этом. Не о достигнутом результате, а об роли в процессе. Она у менеджера чем то сродни сапера/барабанщика/кого там ещё в пример ставят — если всё хорошо работает, не очевидно, что благодаря ему, а вот если ошибется — виноватый сразу находится.
А как доказать роль его в этом процессе?
Кажется понял вас. Тут все зависит от наблюдателя.
Для руководителей верхнего звена — работа программиста это что-то за ширмой. Цели ставятся Менеджеру, он их выполнил используя доступные ресурсы — однозначно его заслуга.
Для члена команды, если проект спокойный и делается по накатаным рельсам — да, роль менеджера может показаться лишней. Есть такой момент. Его неочевидная заслуга в том что он выстроил работу так, что все работает без его явного участия.
Если проект проблемный, работа менеджера становится заметной и членам команды. Но опять же оценка может быть разной — ведь команда не всегда знает какие цели поставили перед менеджером. И эти цели кстати могут противоречить интересам отдельных исполнителей. Тогда менеджер превращается в одиозную фигуру.
Для руководителей верхнего звена — работа программиста это что-то за ширмой.
Если этот руководитель не любитель общаться с исполнителями напрямую, минуя пару уровней субординации. Мало того что общаться, так задания ставить или менять, а менеджеру об этом сообщить никто не удосуживается. А спрашивают потом с него.
Если этот руководитель не любитель общаться с исполнителями напрямую, минуя пару уровней субординацииДа, подобные проблемы существуют. Тут менеджеру нужно выдерживать жесткую позицию по отношению к своему начальству.
В этом кстати нет никаких проблем. Пойдите и наорите на своего биг-босса, тет-а-тет разумеется.
>Программа, написанная программистом — это еще далеко не продукт.
А ну-ка откройте консольку и напишите там
Скачалось? Скачалось. А теперь покажите мне в wget работу дизайнеров, аналитиков, экономическое обоснование, работу менеджера по позиционированию продукта, бла-бла-бла.
А ну-ка откройте консольку и напишите там
wget http://habrahabr.ru/
Скачалось? Скачалось. А теперь покажите мне в wget работу дизайнеров, аналитиков, экономическое обоснование, работу менеджера по позиционированию продукта, бла-бла-бла.
Кто-то спроектировал интерфейс — дизайнер
Кто-то поставил задачу «тулза, позволяющая скачивать страницы по хттп» — аналитик
Кто-то решил что проще написать один раз универсальную программу, чем для каждой страницы свою — экономист
Кто-то выложил тулзу в паблик — позиционирование
Кто-то привлек других людей к работе над ней — эйчар
Кто-то поставил задачу «тулза, позволяющая скачивать страницы по хттп» — аналитик
Кто-то решил что проще написать один раз универсальную программу, чем для каждой страницы свою — экономист
Кто-то выложил тулзу в паблик — позиционирование
Кто-то привлек других людей к работе над ней — эйчар
tangro как бы намекает, что одному программисту понадобилось скачивать файлы — он написал утилиту, скачивающую файлы. У него не было аналитика, экономиста и прочего. Он просто сам написал программу — и она является «продуктом», хотя труд вложен только его.
Просто программист выполнил все эти функции. «Всё-в-одном».
А, так Вы просто алиасов навешали на слово «программист» — ну ок. Допишите ещё тогда уборщика (наверняка ведь он по ходу дела хоть раз мусор выбрасывал) и повара (ну чай там он себе делал, скорее всего).
Суть не меняется — программист может сделать продукт, если ему по ходу дела надо будет накидать интерфейс или выложить тулзу на гитхабик — он это сделает. Всякие там эйчары и экономисты могут сами по себе только воду в ступе толочь.
Суть не меняется — программист может сделать продукт, если ему по ходу дела надо будет накидать интерфейс или выложить тулзу на гитхабик — он это сделает. Всякие там эйчары и экономисты могут сами по себе только воду в ступе толочь.
C:\Users\user_123>wget http://habrahabr.ru
"wget" не является внутренней или внешней
командой, исполняемой программой или пакетным файлом.А этот баг недавно пофиксили, Вам просто одну мелочь обновить надо.
Виталий, вообще на мой взгляд с благодарностью за сделанную работу у нас в ИТ большииие проблемы. Просто даже «спасибо» никто не скажет. Типа ты за это зарплату получаешь и будь доволен, вот твоё спасибо.
Общая тенденция кстати для наёмных рабочих.
Вы водителю автобуса часто говорите спасибо за то, что довез вас до нужной остановки?
В маршрутке говорю за то что не проехал мою остановку :)
Не надо передёргивать, это разные типы отношений.
Между мной и водителем маршрутки — оказывается услуга, я клиент, расчёт происходит непосредственно. Моё уважение к труду водителя я выражаю тем что вовремя и аккуратно передаю ему деньги.
Между ПМом и мной как допустим программистом — отношения начальника и подчинённого по проектной иерархии. Мы оба делаем свою работу, за которую получаем деньги. Но деньги непосредственно (как правило) НЕ фигурируют, только опосредовано. И даже если фигурируют (например как компенсация за овертайм), они проходят такой длинный круг что в виде поощрения их трудно рассматривать.
Между мной и водителем маршрутки — оказывается услуга, я клиент, расчёт происходит непосредственно. Моё уважение к труду водителя я выражаю тем что вовремя и аккуратно передаю ему деньги.
Между ПМом и мной как допустим программистом — отношения начальника и подчинённого по проектной иерархии. Мы оба делаем свою работу, за которую получаем деньги. Но деньги непосредственно (как правило) НЕ фигурируют, только опосредовано. И даже если фигурируют (например как компенсация за овертайм), они проходят такой длинный круг что в виде поощрения их трудно рассматривать.
результат воспринимается потребителями
А кто потребитель результата труда менеджера? Вышестоящий менеджер?
Не всегда так.
Да, я не раз встречал со стороны заказчика непонимание, когда в ведомости проекта значилась строчка «менеджмент проекта». Но, как правило, это решалось достаточно просто — вот тебе дизайнер, вот программист, вот архитектор, вот разработчик базы данных. Работайте. Особо упертым хватало 3 дней, чтобы понять, что это АД.
С другой стороны, при правильной постановке рабочего процесса, вопросов не возникает. По сути дела данная должность — прослойка между руководителем и группой программистов (берем только ситуацию с оценкой результатов, на самом деле предметное поле несколько шире). Если человек, занимаемый должность, не перекладывает на плечи начальства мелкие проблемы коллектива, а на плечи коллектива — спускаемые директивы начальства в прямом виде, то он как раз и выполняет то, зачем он работает — несет полную ответственность за вверенный участок работы. Потому отчитывается перед начальником он. И в голове начальника прежде всего не «ой какая крутая группа программистов, которая все сделала», а «ой какой Вася/Петя/пофиг как зовут молодец, правильно поставил рабочий процесс и все сделал вовремя». Да, группа программистов стоит за плечами этого руководителя, и их успеха никто не умаляет. Это те люди, чьими руками ковалась победа. А тим лид при этом — тот, кто привел к победе. Так что вроде все закономерно.
Да, я не раз встречал со стороны заказчика непонимание, когда в ведомости проекта значилась строчка «менеджмент проекта». Но, как правило, это решалось достаточно просто — вот тебе дизайнер, вот программист, вот архитектор, вот разработчик базы данных. Работайте. Особо упертым хватало 3 дней, чтобы понять, что это АД.
С другой стороны, при правильной постановке рабочего процесса, вопросов не возникает. По сути дела данная должность — прослойка между руководителем и группой программистов (берем только ситуацию с оценкой результатов, на самом деле предметное поле несколько шире). Если человек, занимаемый должность, не перекладывает на плечи начальства мелкие проблемы коллектива, а на плечи коллектива — спускаемые директивы начальства в прямом виде, то он как раз и выполняет то, зачем он работает — несет полную ответственность за вверенный участок работы. Потому отчитывается перед начальником он. И в голове начальника прежде всего не «ой какая крутая группа программистов, которая все сделала», а «ой какой Вася/Петя/пофиг как зовут молодец, правильно поставил рабочий процесс и все сделал вовремя». Да, группа программистов стоит за плечами этого руководителя, и их успеха никто не умаляет. Это те люди, чьими руками ковалась победа. А тим лид при этом — тот, кто привел к победе. Так что вроде все закономерно.
Она не легкая/трудная, она разная. Каждому свое.
Типичная встреча менеджера с директором:
— Сколько тебе нужно людей чтобы успеть в срок?
— Еще 3 человека.
— Это плохо, потому что мы урезали бюджет на разработку и тебе еще придется кого-то отдать в другую команду.
— Тогда я не успею.
— Почему?
— Потому что мало людей.
— Ну а если постараться?
— Тоже не успею. Кстати, один из разработчиков просил прибавки.
— Ну и что делать?
— Вот план по вытаскиванию из жопы.
— Нет, у меня другое видение. Мы построим космический корабль и улетим на нем на Марс. И тогда мы завоюем рынок.
— 0_o
По реальным событиям.
— Сколько тебе нужно людей чтобы успеть в срок?
— Еще 3 человека.
— Это плохо, потому что мы урезали бюджет на разработку и тебе еще придется кого-то отдать в другую команду.
— Тогда я не успею.
— Почему?
— Потому что мало людей.
— Ну а если постараться?
— Тоже не успею. Кстати, один из разработчиков просил прибавки.
— Ну и что делать?
— Вот план по вытаскиванию из жопы.
— Нет, у меня другое видение. Мы построим космический корабль и улетим на нем на Марс. И тогда мы завоюем рынок.
— 0_o
По реальным событиям.
Глеб, а нафига менеджер при обсуждении планов сообщает о том, что кто-то просил прибавки?
У него всё в порядке с головой? Он для чего нужен, просто транслировать события?)
У него всё в порядке с головой? Он для чего нужен, просто транслировать события?)
Это несколько сокращенный и художественный пересказ :)
Предупреждает о возможных проблемах, что скоро может понадобиться не 3, а 4 человека. И поэтому в план входит повышение зарплаты тому, кто просил.
А вы Глеб?
«в план входит» или «попросил»?
«в план входит» или «попросил»?
Денис, ты должен понимать различие между формами изложения. В малой форме (комментарии) всех нюансов не отразить. Разумеется, человек который просит прибавки в контексте общего урезания бюджета это потенциальный минус в штатном расписании, отчего и строился разговор.
Малые формы тем и хороши, что наглядно показываю тострые углы.
«Мой подчинённый попросил прибавку» — это слова не менеджера, а передаста.
Менеджер может сказать, «я считаю, что моему подчинённому нужно поднять зарплату, потому что *аргументы*» и «есть *оценка масштаба* риск того, что мой сотрудник уволится, т.к. не доволен текущим уровнем зарплаты, а она объективно на уровне».
«Мой подчинённый попросил прибавку» — это слова не менеджера, а передаста.
Менеджер может сказать, «я считаю, что моему подчинённому нужно поднять зарплату, потому что *аргументы*» и «есть *оценка масштаба* риск того, что мой сотрудник уволится, т.к. не доволен текущим уровнем зарплаты, а она объективно на уровне».
А вы Глеб?
Публичные обсуждения подразумевают, что вклиниться в них может любой. Если вам этого не хочется, то есть возможность написать в личку.
А затем, чтобы показать — есть неудовлетворенный зарплатой сотрудник. Который потенциально может написать заявление — и придется затыкать еще одну прореху.
А где он раньше был с этой ситуацией?
Не слышал еще ни об одном примере, когда плановое повышение оплаты труда могло быть пропихнуто снизу. По факту это низкая культура производственных процессов на предприятии, что ты с ней сделаешь на месте линейного менеджера?
А при чём тут плановое повышение?
Если только ситуация возникла не вчера, решение по ней должно быть.
Если только ситуация возникла не вчера, решение по ней должно быть.
Если ты не повышаешь зарплату разработчикам планово, то они заявляют об этом внезапно и так же внезапно уходят. Не сталкивался что ли?
Это если ты плохой менеджер и не мониторишь степень их удовлетворённости.
Я лично не сталкивался, от меня по таким причинам не уходили.
Я лично не сталкивался, от меня по таким причинам не уходили.
Степень удовлетворенности и так понятна если ты варишься в коллективе.
Заканчиваю дискуссию, ибо не понимаю, что мы тут обсуждаем. Какое-то капитанство (надо планировать, надо риски, надо то се).
Заканчиваю дискуссию, ибо не понимаю, что мы тут обсуждаем. Какое-то капитанство (надо планировать, надо риски, надо то се).
Мы обсуждаем представления друг друга о менеджементе.
Мне из фразы «варишься в коллективе» понятно, с чем ты имел дело.
Если хочешь научиться делать так, чтобы от тебя не уходили внезапно люди, рекомендую книгу:
www.amazon.com/Behind-Closed-Doors-Management-Programmers/dp/0976694026
Мне из фразы «варишься в коллективе» понятно, с чем ты имел дело.
Если хочешь научиться делать так, чтобы от тебя не уходили внезапно люди, рекомендую книгу:
www.amazon.com/Behind-Closed-Doors-Management-Programmers/dp/0976694026
Ты же знаешь с чем я имел дело, с размером компаний и т.д. :) Уже из этого должно быть все понятно. Совершенно разный подход к управлению к организациях в 50, в 500 и в 5000 человек.
Слово внезапно наверное было выбрано неверно, т.к. имеет отенок загадочности. Нет, если ты едешь по колючей проволоке, то ничего незапланированного и загадочного в проколе для тебя не будет. Но это в любом случае произойдет внезапно, т.е. в неизвестный момент времени.
Слово внезапно наверное было выбрано неверно, т.к. имеет отенок загадочности. Нет, если ты едешь по колючей проволоке, то ничего незапланированного и загадочного в проколе для тебя не будет. Но это в любом случае произойдет внезапно, т.е. в неизвестный момент времени.
Всё-таки я считаю, что менеджер может иметь персональные управленческие практики, вне зависимости от того, какая культура принята в компании.
— Сколько тебе нужно людей чтобы успеть в срок?Ээээ, с каких это пор добавление людей в проблемный проект ускоряет сроки?
— Еще 3 человека.
По классике это только увеличивает хаос. Только вот бывает, что хаоса нет, а нужно просто давать стране больше угля. Если в проекте 5 больших подзадач поторые полностью параллелятся и на это был расчет, то 2 человека на него будет недостаточно. В добавок, эти задачи выполняются разными специалистами.
Да, но только на старте и если эти люди — не с улицы и знают проект.
В примере речь вообще шла не об одном проекте, если что. Т.е. разговор был о работе подразделения, где уже как минимум идет 2-3 проекта. Люди между ними перекидываются (проекты над одной кодовой базой и специалисты в ней ориентируются). Если нужно заткнуть дыру по одному фронту, то некому работать на другом.
Я вам завидую, если вы не были в таких ситуациях :)
Я вам завидую, если вы не были в таких ситуациях :)
Конечно бывал. Только редко такие ситуации заканчивались успешно. Больше направлял усилий на то чтобы таких ситуаций не происходило. Это уже управление рисками.
Т.е. разговор был о работе подразделения, где уже как минимум идет 2-3 проектаТут кстати надо бы определиться о каком «менеджере» идет речь и какая оргструктура в компании: иерархическая или матричная. Или еще какая.
Если срок проекта год, прошло полгода, сделано процентов 30, то разве не разумно увеличить штат, считая что вход в проект займет где-то месяц?
it depends, как говорится. Но в общем случае — да. Правда редко кто за целых полгода до окончания поднимает панику с недостатком ресурсов. Обычно это происходит за день до релиза :)
Сильно зависит от того, что за проект, каковы причины задержек. У любого производства/проекта есть узкое место. Если горлышко там, где добавление людей что-то решит, то это одно. А если нет, то другое.
Ситуации бывают разные.
Ни с каких. Сколько бы не брал примеров из личной практики, какой бы ни был проект — приплюсовывание рабочих рук на позднем этапе с явным запаздыванием ведет всегда только к лишней нервозности и беготне по кругу. Полностью с Вами согласен.
Если это один проект который все-таки продвигается вперед. А если он замораживается, потому что там некому работать от слова вообще? Все ушли на другой фронт, отбивать атаку немцев. Тоже не нужно людей?
Есть разница между равномерно текущим проектом (где добавление ничего не даст) и хронической нехваткой рабочих рук. Которая решается лишь их добавлением либо закрытием/заморозкой некоторых проектов отдела.
Есть разница между равномерно текущим проектом (где добавление ничего не даст) и хронической нехваткой рабочих рук. Которая решается лишь их добавлением либо закрытием/заморозкой некоторых проектов отдела.
Вы чего, по кругу пошли?
habrahabr.ru/post/165091/
habrahabr.ru/post/165147/
habrahabr.ru/post/165721/
habrahabr.ru/post/165091/
habrahabr.ru/post/165147/
habrahabr.ru/post/165721/
Вспоминается группа Ленинград с клипом Менеджер. И Оргия праведников с песней Офис.
Все эмоции в нескольких минутах.
Все эмоции в нескольких минутах.
Не ожидал что моя статья вызовет такие бурные дебаты и критику. Возможно для части случаев примеры были подобраны весьма утрировано, но только для лучшего понимания. Немного отвечу на посылы, но без фанатизма, т.к. все таки это обсуждение того же самого, только с другой точки зрения.
1. Абсолютно согласен про тепличные условия, у нас в конторе это гораздо проще и много уровней руководства, которые могут тебе помочь, если откровенно ошибешься. Но это я считаю достоинством своего места работы, которое позволяет более легко входить в новою роль.
2. Насчет времени. Для менеджера это качество должно немного иное, чем для программиста, объясню почему. Как писали в комментариях разработчик занимается 1-2 задачами и если говорит что не успевает, то тут уже ничего не поделаешь в большинстве случаев — либо сокращаем функционал, либо ждем (случай навалимся всей толпой не рассматриваю). У менеджера задач в разы больше и очень важно сделать их вовремя, иначе последствия могут быть гораздо больше чем от косяка 1 программиста, ведь нитки часто сходятся именно на тебе.Профакапил срок опоздал немного, еще три пути после тебя теперь с задержкой на день идут. Можно это свести к организации времени, но я просто переформулировал для себя, что в итоге проблемой стало — все успевать вовремя, ключевое слово не «вовремя», а «Всё».
В вашей статье мне очень понравилась проблема про документы — это просто бесило меня и бесит сейчас, никто не любит бумажек и вечных согласований, пожалуй стоило ее тоже упомянуть.
1. Абсолютно согласен про тепличные условия, у нас в конторе это гораздо проще и много уровней руководства, которые могут тебе помочь, если откровенно ошибешься. Но это я считаю достоинством своего места работы, которое позволяет более легко входить в новою роль.
2. Насчет времени. Для менеджера это качество должно немного иное, чем для программиста, объясню почему. Как писали в комментариях разработчик занимается 1-2 задачами и если говорит что не успевает, то тут уже ничего не поделаешь в большинстве случаев — либо сокращаем функционал, либо ждем (случай навалимся всей толпой не рассматриваю). У менеджера задач в разы больше и очень важно сделать их вовремя, иначе последствия могут быть гораздо больше чем от косяка 1 программиста, ведь нитки часто сходятся именно на тебе.
В вашей статье мне очень понравилась проблема про документы — это просто бесило меня и бесит сейчас, никто не любит бумажек и вечных согласований, пожалуй стоило ее тоже упомянуть.
Спасибо за Ваш ответ. Собственно, тезисно по Вашей статье я прошел, не буду повторяться.
что касается систем управления проектом, то на мой взгляд, они очень и очень сильно схожи с проблемами, стоящими перед одним программистом.
Давайте немного раскрою мною же и выданный постулат:
Проблемы есть везде. У менеджера, у программиста. И у того, и у другого корень проблемы практически всегда один и тот же. Согласование рабочего процесса для менеджера = ожиданию программистом кода от другого участника. И там и там возможны задержки, накладки.
непостоянство технического задания одинаково ударяет что по менеджеру, что по программисту
нехватка ресурсов может ощущаться и там и там.
Одним словом — проблемы прямо рядышком. Менеджеру даже проще — у него больше возможностей для их решения.
что касается систем управления проектом, то на мой взгляд, они очень и очень сильно схожи с проблемами, стоящими перед одним программистом.
Давайте немного раскрою мною же и выданный постулат:
Проблемы есть везде. У менеджера, у программиста. И у того, и у другого корень проблемы практически всегда один и тот же. Согласование рабочего процесса для менеджера = ожиданию программистом кода от другого участника. И там и там возможны задержки, накладки.
непостоянство технического задания одинаково ударяет что по менеджеру, что по программисту
нехватка ресурсов может ощущаться и там и там.
Одним словом — проблемы прямо рядышком. Менеджеру даже проще — у него больше возможностей для их решения.
Вот одного не пойму. При чем здесь менеджер среднего звена? В этом, а также предыдущем посте на тему менеджерских проблем, идет речь о линейном работнике, перешедшем в менеджмент низшего звена. (см пирамиду управления)
У среднего звена совсем другие проблемы.
P.S. Прошу прощения, если зацепил чью-то гордость.
У среднего звена совсем другие проблемы.
P.S. Прошу прощения, если зацепил чью-то гордость.
Особенно крах — с фрилансерами. Вы будете, пусть и с опозданием, узнавать о проблемах на линии у провайдера в городе, в котором живет исполнитель, о нелетной погоде, о здоровье неизвестной вам доселе бабушке, а если повезет — о прекрасной незнакомке и не менее прекрасной ночи. Может, даже, с подробностями, но это на любителя. А еще вы узнаете, как учиться кодить самому на незнакомом языке за 2 часа, чтобы выполнить поставленную задачу.
Замените «фрилансеры» на «идиоты» и всё встанет на свои места. Не надо работать с идиотами. Надо работать с профессионалами и платить им соответствующие деньги. Они будут хорошо работать, следить за дедлайнами и, при необходимости, работать до поздней ночи в режиме аврала.
А если не хотите нормально платить или не умеете выбирать фрилансеров — так и скажите, признайте проблему. Не надо проецировать идиотов на всех фрилансеров. Вы ведь не хотите, чтобы вас называли вором и бездельником потому, что некоторые менеджеры воруют и бездельничают?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проблемы перехода в менеджеры среднего звена — это проблемы?