Здравствуйте, turbocode, Вы писали:
T>Как вы относитесь к тому когда есть PM который постоянно всех опрашивает: "Ну что там? Много еще осталось? Сколько нужно еще времени чтобы закончить?" T>Действительно ли это помогает существенно ускорить разработку?
Идея выдать программисту кусок работы, и в следующий раз пообщаться с ним через месяц, когда работа, теоретически, должна быть закончена, с большинством программистов не работает. Люди имеют привычку откладывать все на последний момент, человека может понести сделать Великий Универсальный Фреймворк Для Всего, человек может упереться в сложное место, и постесняться об этом сказать, просто мозги могут застопориться и т.д. и т.п.
Опыт показывает, что лучше бы с подчиненными регулярно общаться и быть в курсе их дел.
Другой вопрос, что никто не любит, когда у него висят над душой и постоянно дергают. Кроме того, многие люди устроены так, что в один период времени у человека очень большая производительность, а в другой — все тормозится, и это нормально, но не со всяким начальством это можно открыто обсуждать. Иное начальство считает, что человек должем производить товар с постоянной скоростью в сутки, и начинает беспокоиться, если в какие-то сутки произведено меньше товара, чем ожидается (в чем бы этот товар не измерялся, в закрытых тикетах, в строках кода и т.п.).
В общем, искусство менеджмента заключается в том, чтобы быть в курсе, чем занимаются люди, быть готовым помочь, когда надо, но не висеть у человека над душой.
Конкретно про ваш случай сказать сложно, не хватает информации.
Здравствуйте, turbocode, Вы писали:
Pzz>>Нет, если усреднить мой выхлоп за более-менее разумное время, то он очень достойный. Так что на мороз не выпрут.
T>Какая разница? Ты профакапал несколько дней (считай что ушел в запой и не приходил на работу) и что с такими делают? Правильно! Выпирают на мороз не смотря на былые подвиги и заслуги.
В каком смысле, зафакапал? У меня мозги работают циклически, и цикл длинный, измеряется днями. Если меня лишить возможности "факапить", то и периодов большого выхлопа не будет. В период "факапа" я как раз обдумываю следующий выхлоп.
Организации с подходом "у каждого работника с 8-и до 17:00 в руках должна быть лопата или метла" очень быстро остаются сами со своей лопатой.
Здравствуйте, Pzz, Вы писали:
T>>Ты можешь вкалывать как раб и всего лишь на минутку отдохнуть но именно в этот момент за отдыхом тебя спалит PM и всё пропало.
Pzz>Какие-то у тебя ПМ неадекватные...
Судя по уровню развития, он еще или учится и теоретизирует (почему бы не поразвлекаться на форуме с взрослыми дядями и побыть наравне с ними, это ж круто), или только-только вышел в свет.
Отсюда и представления о ПМ-ах.
А судя по тому, что ПМ его часто спрашивает о прогрессе — turbocode работает плохо.
А судя по тому, что turbocode считает ПМ-а тупым — он еще молодой зеленый дартаньян, и переносит своё видение мира на ПМ-а.
Логично, раз плохо ко мне относится — значит, тупой.
Здравствуйте, turbocode, Вы писали: T>PM знает во сколько оценили задачу но при этом хочет контролировать каждый маленький шажочек выполнения этого задания.
"нормальных" людей вообще не надо контролировать. они сами подойдут. другое дело, что если ты человеку не доверяешь и есть за что, то приходится дрючить его по нескольку раз в день, чтобы хоть что-то шевелилось
Pzz>В общем, искусство менеджмента заключается в том, чтобы быть в курсе, чем занимаются люди, быть готовым помочь, когда надо, но не висеть у человека над душой.
Есть только три варианта:
— твой PM знает как ты себе "дни отдыха" устраиваешь но покрывает тебя;
— твой PM тупой и ведется на твою симуляцию работы в "дни отдыха";
— все всё знают до самого верха и неспешно ищут тебе замену;
Здравствуйте, turbocode, Вы писали:
T>Для хорошего PM: вчера ты поставил рекорд, а сегодня это норма.
Слишком толстый троллинг пошел. Тоньше надо.
Раньше тебе еще удавалось себя выдавать за "успешного" сотрудника типичной говноконторы, сейчас сильно перебарщиваешь.
T>Как вы относитесь к тому когда есть PM который постоянно всех опрашивает: "Ну что там? Много еще осталось? Сколько нужно еще времени чтобы закончить?"
Очень положительно отношусь. В жизним мне поговорить не с кем, а тут есть кому съесть мозг.
T>Действительно ли это помогает существенно ускорить разработку?
отладка методом рассказа кошке!
У меня так другая проблема, ПМ "экономит время" и рассказы по-быстрому заворачивает: "ты напиши свои предложения в письменном виде"
Здравствуйте, turbocode, Вы писали:
Pzz>>В общем, искусство менеджмента заключается в том, чтобы быть в курсе, чем занимаются люди, быть готовым помочь, когда надо, но не висеть у человека над душой. T>Есть только три варианта: T> — твой PM знает как ты себе "дни отдыха" устраиваешь но покрывает тебя; T> — твой PM тупой и ведется на твою симуляцию работы в "дни отдыха"; T> — все всё знают до самого верха и неспешно ищут тебе замену;
Интересно, а минуты отдыха в течении дня работник может себе устраивать? А часы? Где граница допустимого и почему она проходит именно там?
Здравствуйте, turbocode, Вы писали:
T>А работу надежного таким образом нельзя ускорить? Думаешь надежный всегда на максимуме работает?
Я, например, могу неделю работать, выдавая очень высокую производительность, а потом буду несколько дней тормозить. В среднем производительность получается вполне нормальная. Однако не тормозить меня постоянным пинанием не заставишь, мозгам надо отдохнуть/подумать.
Если с меня требуют какую-нибудь ежедневную отчетность, я просто беру в эти тормозные дни какую-нибудь маленькую простенькую проблему, которую можно сделать за полчаса, и рассказываю про нее, как будто она была настоящей проблемой. Но предпочитаю доверительные отношения, когда мне не надо морочить людям голову.
Здравствуйте, turbocode, Вы писали:
Pzz>>я просто беру в эти тормозные дни какую-нибудь маленькую простенькую проблему, которую можно сделать за полчаса, и рассказываю про нее, как будто она была настоящей проблемой.
T>Тебя так быстро раскусят и выпрут на мороз.
Нет, если усреднить мой выхлоп за более-менее разумное время, то он очень достойный. Так что на мороз не выпрут.
Просто я в работе марафонец, а не спринтер. На далеких дестанциях я очень хорош, а делать мелкие разрозненные задачки по нескольку штук в день я сам не пойду.
Здравствуйте, turbocode, Вы писали:
T>Как вы относитесь к тому когда есть PM который постоянно всех опрашивает: "Ну что там? Много еще осталось? Сколько нужно еще времени чтобы закончить?" T>Действительно ли это помогает существенно ускорить разработку?
Ну в общем-то контроль и отчет перед заказчиком/вышестоящим начальством входит в работу ПМа. Меня это несколько напрягает, но в то же время это дополнительная такая мотивация чтобы не слишком не расслабляться/отвлекаться, а сфокусироваться на работе. Мне лично иногда она нужна
Здравствуйте, turbocode, Вы писали:
T>Как вы относитесь к тому когда есть PM который постоянно всех опрашивает: "Ну что там? Много еще осталось? Сколько нужно еще времени чтобы закончить?" T>Действительно ли это помогает существенно ускорить разработку?
Это не микроменеджмент, а погоняйло контроль процесса, что есть его работа. Сабж — это когда ПМ лезит в код, и указывает на ошибки форматирования, пропущенные пробелы перед (, имена переменных ему не такие итд. Поубивал бы.
__>"нормальных" людей вообще не надо контролировать. они сами подойдут. другое дело, что если ты человеку не доверяешь и есть за что, то приходится дрючить его по нескольку раз в день, чтобы хоть что-то шевелилось
дело не в доверии, PM хочет быть эффективным и он думает что таким образом он ускорит процесс разработки (возможно на курсах MBA этому учат).
Здравствуйте, MozgC, Вы писали:
MC>Ну в общем-то контроль и отчет перед заказчиком/вышестоящим начальством входит в работу ПМа.
пусть даже и так, но какие же выводы из этого ты делаешь? если директор спросил как там дела у ПМ, то ПМ должен сходить к прогеру и делегировать ему вопрос "как дела" ? совсем даже не должен. он не должен трогать прогера, а должен дать ответ директору самостоятельно
авральные моменты оставлю за скобками
Pzz>Нет, если усреднить мой выхлоп за более-менее разумное время, то он очень достойный. Так что на мороз не выпрут.
Какая разница? Ты профакапал несколько дней (считай что ушел в запой и не приходил на работу) и что с такими делают? Правильно! Выпирают на мороз не смотря на былые подвиги и заслуги.
Здравствуйте, turbocode, Вы писали:
Pzz>>Интересно, а минуты отдыха в течении дня работник может себе устраивать? А часы? Где граница допустимого и почему она проходит именно там?
T>Ты можешь вкалывать как раб и всего лишь на минутку отдохнуть но именно в этот момент за отдыхом тебя спалит PM и всё пропало.
Здравствуйте, antonio_banderas, Вы писали:
_>Судя по уровню развития, он еще или учится и теоретизирует (почему бы не поразвлекаться на форуме с взрослыми дядями и побыть наравне с ними, это ж круто), или только-только вышел в свет.
Общение в интернете прекрасно тем, что когда понимаешь, что не хочешь продолжения разговора с каким-то человеком, можно просто не отвечать.
Попробуй, это волшебный метод, и он работает безотказно.
Pzz>>Интересно, а минуты отдыха в течении дня работник может себе устраивать? А часы? Где граница допустимого и почему она проходит именно там? T>Ты можешь вкалывать как раб и всего лишь на минутку отдохнуть но именно в этот момент за отдыхом тебя спалит PM и всё пропало.
у меня на одной из старых работ был начальник —
он садился со мной рядом и зырил в монитор, как я пишу код
я ему пару раз намекнул, что мне это не нравится — перестал так делать
Как вы относитесь к тому когда есть PM который постоянно всех опрашивает: "Ну что там? Много еще осталось? Сколько нужно еще времени чтобы закончить?"
Действительно ли это помогает существенно ускорить разработку?
L>Это не микроменеджмент, а погоняйло контроль процесса, что есть его работа. Сабж — это когда ПМ лезит в код, и указывает на ошибки форматирования, пропущенные пробелы перед (, имена переменных ему не такие итд. Поубивал бы.
PM знает во сколько оценили задачу но при этом хочет контролировать каждый маленький шажочек выполнения этого задания.
Здравствуйте, turbocode, Вы писали: T>дело не в доверии, PM хочет быть эффективным и он думает что таким образом он ускорит процесс разработки (возможно на курсах MBA этому учат).
если он работает со, скажем так, ненадежными людьми, то он прав
T>>дело не в доверии, PM хочет быть эффективным и он думает что таким образом он ускорит процесс разработки (возможно на курсах MBA этому учат). __>если он работает со, скажем так, ненадежными людьми, то он прав
А работу надежного таким образом нельзя ускорить? Думаешь надежный всегда на максимуме работает?
Здравствуйте, turbocode, Вы писали: T>А работу надежного таким образом нельзя ускорить? Думаешь надежный всегда на максимуме работает?
разговор идет не про максимум, а про выполнение работы вообще. если ненадежному человеку дать месяц, сказать будут проблемы — подходи, то через месяц выяснится, что половину дней его не было на работе вообще, а другую половину он ничего не делал
T>>А работу надежного таким образом нельзя ускорить? Думаешь надежный всегда на максимуме работает? __>разговор идет не про максимум, а про выполнение работы вообще. если ненадежному человеку дать месяц, сказать будут проблемы — подходи, то через месяц выяснится, что половину дней его не было на работе вообще, а другую половину он ничего не делал
Нет, не так: независимо от того [надежный] или [не надежный] PM таким образом может выжать результат за три недели вместо месяца, отчитаться наверх и получить себе бонус за эффективный менеджмент.
Здравствуйте, turbocode, Вы писали: T>Нет, не так: независимо от того [надежный] или [не надежный] PM таким образом может выжать результат за три недели вместо месяца, отчитаться наверх и получить себе бонус за эффективный менеджмент.
у нормального человека такая манера вызывает только желание уволиться. уволившийся главный программист так сорвет проект, что менеджер получит мегавтык. поэтому pm идет на такой риск только тогда когда знает, человека больше никто никуда не возьмет. на самом деле никому так работать не нравится, если даже человеку хочется, чтобы все багали вокруг него, он всегда может сам организовать так работу, что без него никак. а бегать и самому пинать кого-то постоянно никому не хочется. это вынужденная мера, если нанимают самых бюджетных алкоголиков-студентов и ва этом духе
Здравствуйте, turbocode, Вы писали: __>>это вынужденная мера, если нанимают самых бюджетных алкоголиков-студентов и ва этом духе T>На студентах-алкоголиках так много не сэкономишь они и так дешево стоят.
имею в виду когда бюджет проекта позволяет нанять только их. заставить их делать хоть что-то вообще достаточно сложно. вопроса о том, что они еще что-то будут делать еще и быстро качественно вообще не стоит
T>Как вы относитесь к тому когда есть PM который постоянно всех опрашивает: "Ну что там? Много еще осталось? Сколько нужно еще времени чтобы закончить?"
Постоянно — это с какой периодичностью? Раз в час, раз в день, раз в неделю?
Иногда бывает так — ПМ-у от его начальства приходит запрос — есть у нас такая задача, она, типа, выжная для бизнеса. Как, в графике, сроки не про... задерживаем? И с этим ПМ идет уже к исполнителю.
Кстати, на мой взгляд один из плюсов Скрама, что подобные вопросы задаются обычно на daily. (это не ради затеять холивар про Скрам, просто мнение, относящееся к данной теме)
S>Постоянно — это с какой периодичностью? Раз в час, раз в день, раз в неделю?
Раза 3 — 4 за рабочий день.
S>Кстати, на мой взгляд один из плюсов Скрама, что подобные вопросы задаются обычно на daily. (это не ради затеять холивар про Скрам, просто мнение, относящееся к данной теме)
Это само собой.
Здравствуйте, turbocode, Вы писали:
S>>Постоянно — это с какой периодичностью? Раз в час, раз в день, раз в неделю? T>Раза 3 — 4 за рабочий день.
это ненормально в разработке
у прогеров крайне неравномерная производительность труда
иногда целый день чаи гоняешь и котиков читаешь, иногда за день недельный план выполняешь. просто потому что поперло
дополнительное пинание от манагера может лишь все затормозить просто из-за психологического дискомфорта
думаю, один-два раза за неделю вполне достаточно спрашивать
Здравствуйте, turbocode, Вы писали:
L>>Это не микроменеджмент, а погоняйло контроль процесса, что есть его работа. Сабж — это когда ПМ лезит в код, и указывает на ошибки форматирования, пропущенные пробелы перед (, имена переменных ему не такие итд. Поубивал бы.
T>PM знает во сколько оценили задачу но при этом хочет контролировать каждый маленький шажочек выполнения этого задания.
Наблюдал такое со стороны по отношению к другим сотрудникам.
Предыстория:
Сотрудник оценивает задачу, например, на 5 дней.
Делает её. Тимлид не мешает. Проходит 5 дней. Ничего не сделано. На вопрос почему какое-то или мычание, или отмазки.
Ок. Следующая задача. Теперь уже у него интересуются чаще — ну как у тебя дела, что сделал за сегодня.
Если снова окажется, что 1-2 дня вникуда просрал, то могут еще чаще интересоваться.
Похоже что turbocode еще молодой разработчик, и начальник помогает ему "чутким мудрым руководством" (как это любил называть bazis1).
_>Ок. Следующая задача. Теперь уже у него интересуются чаще — ну как у тебя дела, что сделал за сегодня. _>Если снова окажется, что 1-2 дня вникуда просрал, то могут еще чаще интересоваться.
По скраму больше одного дня не просрешь.
_>Похоже что turbocode еще молодой разработчик, и начальник помогает ему "чутким мудрым руководством" (как это любил называть bazis1).
Ты не прав. PM в коде ничего не соображает и таким образом ничем помочь не сможет.
Pzz>я просто беру в эти тормозные дни какую-нибудь маленькую простенькую проблему, которую можно сделать за полчаса, и рассказываю про нее, как будто она была настоящей проблемой.
Здравствуйте, turbocode, Вы писали:
Pzz>>Организации с подходом "у каждого работника с 8-и до 17:00 в руках должна быть лопата или метла" очень быстро остаются сами со своей лопатой.
T>Я ж говорил что симуляция работы не пройдет: посмотрят твой код который ты закомитил за эти "дни отдыха" и выпрут на мороз.
Я что хочу сказать. Ежедневная отчетность в стиле, "Вася, а сколько ты выдал готового продукта за сегодня" в разработке софтвария не работает потому что 1) выдача колеблется, и далеко не всегда можно сделать за день что-то осмысленное 2) очень легко симулировать.
Pzz>Я что хочу сказать. Ежедневная отчетность в стиле, "Вася, а сколько ты выдал готового продукта за сегодня" в разработке софтвария не работает потому что 1) выдача колеблется, и далеко не всегда можно сделать за день что-то осмысленное 2) очень легко симулировать.
Для хорошего PM: вчера ты поставил рекорд, а сегодня это норма.
Здравствуйте, turbocode, Вы писали:
_>>Ок. Следующая задача. Теперь уже у него интересуются чаще — ну как у тебя дела, что сделал за сегодня. _>>Если снова окажется, что 1-2 дня вникуда просрал, то могут еще чаще интересоваться.
T>По скраму больше одного дня не просрешь.
_>>Похоже что turbocode еще молодой разработчик, и начальник помогает ему "чутким мудрым руководством" (как это любил называть bazis1).
T>Ты не прав. PM в коде ничего не соображает и таким образом ничем помочь не сможет.
Но поймет что есть проблема если оценки были одни а прогресс дуругой и начнет принимать меры.
Здравствуйте, turbocode, Вы писали:
P>>Но поймет что есть проблема если оценки были одни а прогресс дуругой и начнет принимать меры.
T>Если ошиблись в оценках то можно опрашивать прогресс хоть каждые пять минут но завершить задачу в срок это не поможет.
Почему не поможет.
PM спрость в чем проблема? Что разработчик ему отвечает?
Например если ошибся в оценка задачу можно разбить и часть отдать другим. Для PM важны сроки и качество, а кто будет делать вторично.
Можно поменять архитектуру или технологию и т д.
Т е PM контролиоует процесс.
Здравствуйте, uzhas, Вы писали:
U>Здравствуйте, MozgC, Вы писали:
MC>>Ну в общем-то контроль и отчет перед заказчиком/вышестоящим начальством входит в работу ПМа.
U>пусть даже и так, но какие же выводы из этого ты делаешь? если директор спросил как там дела у ПМ, то ПМ должен сходить к прогеру и делегировать ему вопрос "как дела" ? совсем даже не должен. он не должен трогать прогера, а должен дать ответ директору самостоятельно U>авральные моменты оставлю за скобками
Все верно, но периодически должен уточнять у разаработчиков статус работы. Иначе откуда он может знать что сказать директору.
Если у какого то рабрабочика проблемы банально потребовалось больше времени что то не учли в оценках, а он молчить и пилит свой функционал.
Откуда PM узнает об этом?
T>>Ты можешь вкалывать как раб и всего лишь на минутку отдохнуть но именно в этот момент за отдыхом тебя спалит PM и всё пропало. Pzz>Какие-то у тебя ПМ неадекватные...
Причем здесь я? Каких ПМ-ов ты считаешь адекватными?: Тех кто покрывают? Тех которые сдают тебя наверх и потом ищут замену? Или тупых?
Здравствуйте, turbocode, Вы писали:
_AB>>Раньше тебе еще удавалось себя выдавать за "успешного" сотрудника типичной говноконторы, сейчас сильно перебарщиваешь. T>Пруф?
Пруф на то, что удавалось выдавать? Это моё частное мнение. Можеть быть, кто-то тебе с самого начала не поверил.
_AB>>>Раньше тебе еще удавалось себя выдавать за "успешного" сотрудника типичной говноконторы, сейчас сильно перебарщиваешь. T>>Пруф? _AB>Пруф на то, что удавалось выдавать? Это моё частное мнение. Можеть быть, кто-то тебе с самого начала не поверил.
Без пяти минут PMP в треде.
T>Как вы относитесь к тому когда есть PM который постоянно всех опрашивает: "Ну что там? Много еще осталось? Сколько нужно еще времени чтобы закончить?"
Сильно зависит от того, что такое "постоянно" и в каких формулировках. Если он просто рисуется на горизонте и задает вопросы — это плохо и для проекта, и для команды, потому что PM не может организовать эффективную коммуникацию в проекте, а вместо этого создает дополнительное напряжение, которое может сказаться на производительности и качестве работы. Если это запланированное им совещание, на котором команда синхронизирует свои статусы, то это правильно. Что касается формулировок, то вопрос "ну что там" это какой-то глупый вопрос. У хорошего PMа есть план, по которому должен двигаться проект. В этом плане всегда есть какие-то контрольные точки и анализ возможных рисков в каждой из них. Есть регулярные совещания, на которых участники проекта докладывают свой статус — что сделано, какие есть проблемы. Если в первой точке PM выясняет, что разработчики отстают от графика, он запускает сценарий, связанный с этим риском, который может включать и более частые контрольные точки, и авторизацию доп.бюджета (например, на переработку) и т.д. Но в первую очередь PM должен минимизировать риск оказаться в такой ситуации, поэтому организует и достаточно продолжительные этапы формулирования бизнес-требований и проектирования архитектуры, и соберет нормальные оценки времени, и м.б. проведет какой-нибудь небольшой тимбилдинг, чтобы снизить трение между участниками.
T>Действительно ли это помогает существенно ускорить разработку?
Нет. Разве что в редких случаях, когда исполнитель совсем плох и нужно его реально пинать, чтобы работал. Но проект, на котором работают такие люди, это уже практически провал руководства. Если ПМ не кодер, плохие разработчики будут вешать ему лапшу на уши практически неограниченное время, пока проект не будет окончательно просран, так что в таком контроле нет особого смысла.
Здравствуйте, licedey, Вы писали:
L>Это не микроменеджмент, а погоняйло контроль процесса, что есть его работа.
Контроль процесса должен быть плановым, а на хаотическим. Если человек просто подходит среди дня и спрашивает "Как оно?", это именно микроменеджмент.
Здравствуйте, Baudolino, Вы писали:
L>>Это не микроменеджмент, а погоняйло контроль процесса, что есть его работа. B>Контроль процесса должен быть плановым, а на хаотическим. Если человек просто подходит среди дня и спрашивает "Как оно?", это именно микроменеджмент.
А как нужно не просто подходить?
Если на словах объяснить трудно, можно видео.
Обычно подходят с той частотой, которая необходима для данного сотрудника. К некоторым можно вообще почти не подходить, к некоторым — часто.
Здравствуйте, Baudolino, Вы писали:
T>>Действительно ли это помогает существенно ускорить разработку?
B>Нет. Разве что в редких случаях, когда исполнитель совсем плох и нужно его реально пинать, чтобы работал. Но проект, на котором работают такие люди, это уже практически провал руководства.
Ну, такие люди могут решать второстепенные задачи, поскольку важных им лучше не давать.
B>Если ПМ не кодер, плохие разработчики будут вешать ему лапшу на уши практически неограниченное время, пока проект не будет окончательно просран, так что в таком контроле нет особого смысла.
Я думаю, большинство ПМ в прошлом были разработчиками.
Если ПМ вырос из отдела тестирования (что тоже бывает), то в команде есть технический тим-лид, бывший или действующий программист.
Так что сильно много лапши повесить не получится.
По крайней мере в тех командах, где я работал. Может, бывают и где получится, хз.
Здравствуйте, antonio_banderas, Вы писали:
_>А судя по тому, что ПМ его часто спрашивает о прогрессе — turbocode работает плохо. _>А судя по тому, что turbocode считает ПМ-а тупым — он еще молодой зеленый дартаньян, и переносит своё видение мира на ПМ-а.
1. В проекте на месте PMа была девочка-припевочка, которая судя по всему получила должность через постель с product owner. Отработала в индустрии до этого 1 год на месте тестировщика кнопочек.
2. Очень хороший разработчик, но плохой пм и тимлид. Всех подозревал в лентяйстве, под конец сдачи проекта его слала на три буквы вся команда.
Здравствуйте, Baudolino, Вы писали:
B>Сильно зависит от того, что такое "постоянно" и в каких формулировках. Если он просто рисуется на горизонте и задает вопросы — это плохо и для проекта, и для команды, потому что PM не может организовать эффективную коммуникацию в проекте, а вместо этого создает дополнительное напряжение, которое может сказаться на производительности и качестве работы. Если это запланированное им совещание, на котором команда синхронизирует свои статусы, то это правильно.
Скорее наоборот. Хорошо, если он может освободить разработчиков от ненужных им совещаний.
Здравствуйте, alzt, Вы писали:
A>Скорее наоборот. Хорошо, если он может освободить разработчиков от ненужных им совещаний.
Неправильно. PM должен минимизировать избыточные и непродуктивные коммуникации, но обеспечивать их необходимый минимум для успешного завершения проекта. Если разработчик может сообщить исчерпывающую информацию о статусе по почте и у других членов команды нет к нему вопросов, наверное тащить его на совещание не стоит. Если вопросы, требующие обсуждения, все же есть, то часть обязанностей разработчика состоит в том числе и в том, чтобы в таких обсуждениях участвовать.
Здравствуйте, antonio_banderas, Вы писали:
_>А как нужно не просто подходить?
PM вообще не должен, по-хорошему, ни к кому подходить, потому что руководит проектом и его точки синхронизации с исполнителями — проектные совещания. Конечно, бывают ситуации, когда менеджер проекта и руководитель команды — одно лицо, но и в этом случае такие "подходы" ни о чем хорошем не говорят. Ведущие специалисты (реальные, а не по выслуге лет) в контроле за пределами проектных совещаний не нуждаются, а наставничество для стажеров и граждан, компетенция которых временно не соответствует названию должности (ведущие по выслуге лет и нанятые по ошибке херы с горы), подразумевает совсем другой формат общения, нежели "ну что как там/сколько времени осталось".
_>Я думаю, большинство ПМ в прошлом были разработчиками.
Далеко не везде — в зарубежных компаниях часто можно встретить ПМа, который вышел откуда-нибудь из администрирования или из маркетинга. Хороший PM имеет прежде всего профильное образование, а управление проектами — это дисциплина, вообще никак не связанная с разработкой ПО. Знание технологий разработки ПО — не его прямая обязанность.
_>Если ПМ вырос из отдела тестирования (что тоже бывает), то в команде есть технический тим-лид, бывший или действующий программист.
А вот это — правда. Технически компетентный менеджер, которому можно делегировать вопросы оценки готовности кода и его качества, есть всегда, и руководитель проекта будет взаимодействовать прежде всего с ним.
Здравствуйте, Baudolino, Вы писали:
B>Здравствуйте, licedey, Вы писали:
L>>Это не микроменеджмент, а погоняйло контроль процесса, что есть его работа. B>Контроль процесса должен быть плановым, а на хаотическим. Если человек просто подходит среди дня и спрашивает "Как оно?", это именно микроменеджмент.
А что по вашему должен делать ПМ? Сидеть в сторонке, курить бамбук, пока его подопечные рубятся в xbox и постят Вконтактик?
Он должен погонять. Да любой менеджер должен надавить где нужно, иначе все рухнет к такой то маме. Плановый контроль процесса, имхо, это идеальный конь в вакууме.
Впринципе я имею ввиду, что подходить и спрашивать "Как оно?" оправдано если человек банально расгильдяйнечает. К нормальному спецу, эксперту, которых один на 100,
подходить низя, согласен.
L>А что по вашему должен делать ПМ? Сидеть в сторонке, курить бамбук, пока его подопечные рубятся в xbox и постят Вконтактик? L>Он должен погонять.
Зачем для этого PM? Охранник погонять лучше сможет.
L>Да любой менеджер должен надавить где нужно, иначе все рухнет к такой то маме. Плановый контроль процесса, имхо, это идеальный конь в вакууме. L>Впринципе я имею ввиду, что подходить и спрашивать "Как оно?" оправдано если человек банально расгильдяйнечает. К нормальному спецу, эксперту, которых один на 100,
PM должен правильно манипулировать, мотивировать, зажигать идеей (привет джопсу), создавать атмосферу корпоративных ценностей. Вердикт: он должен управлять прозрачно.
Здравствуйте, turbocode, Вы писали:
L>>А что по вашему должен делать ПМ? Сидеть в сторонке, курить бамбук, пока его подопечные рубятся в xbox и постят Вконтактик? L>>Он должен погонять.
L>>Да любой менеджер должен надавить где нужно, иначе все рухнет к такой то маме. Плановый контроль процесса, имхо, это идеальный конь в вакууме. L>>Впринципе я имею ввиду, что подходить и спрашивать "Как оно?" оправдано если человек банально расгильдяйнечает. К нормальному спецу, эксперту, которых один на 100,
T>PM должен правильно манипулировать, мотивировать, зажигать идеей (привет джопсу), создавать атмосферу корпоративных ценностей. Вердикт: он должен управлять прозрачно.
Манипулировать != прозрачно. Программисты коты вообще управлению мало поддаются. Почему то вспомнилась вот эта статья без цензуры
T>>PM должен правильно манипулировать, мотивировать, зажигать идеей (привет джопсу), создавать атмосферу корпоративных ценностей. Вердикт: он должен управлять прозрачно. L>Манипулировать != прозрачно. Программисты коты вообще управлению мало поддаются. Почему то вспомнилась вот эта статья без цензуры
Понравился этот пункт:
Напрягайте их. Они не должны быть на расслабоне, это не в ваших интересах. Убедитесь, что у них жесткие дедлайны, сложные задачи и достаточно чувства вины на плечах. Они не будут просить повышения, страдая от постоянного чувства вины за то, что огорчают вас и не поспевают по целям проекта. Постарайтесь навешать на них столько ответственности за неудачи, сколько получится.
Но это прозрачно сделать не получится и если долго этим злоупотреблять то серьезно повышает вероятность убегания сотрудника в другую компанию.
Здравствуйте, turbocode, Вы писали:
T>>>PM должен правильно манипулировать, мотивировать, зажигать идеей (привет джопсу), создавать атмосферу корпоративных ценностей. Вердикт: он должен управлять прозрачно. L>>Манипулировать != прозрачно. Программисты коты вообще управлению мало поддаются. Почему то вспомнилась вот эта статья без цензуры
T>Понравился этот пункт: T>
T>Напрягайте их. Они не должны быть на расслабоне, это не в ваших интересах. Убедитесь, что у них жесткие дедлайны, сложные задачи и достаточно чувства вины на плечах. Они не будут просить повышения, страдая от постоянного чувства вины за то, что огорчают вас и не поспевают по целям проекта. Постарайтесь навешать на них столько ответственности за неудачи, сколько получится.
T>Но это прозрачно сделать не получится и если долго этим злоупотреблять то серьезно повышает вероятность убегания сотрудника в другую компанию.
Здравствуйте, turbocode, Вы писали:
T>Понравился этот пункт: T>
T>Напрягайте их. Они не должны быть на расслабоне, это не в ваших интересах. Убедитесь, что у них жесткие дедлайны, сложные задачи и достаточно чувства вины на плечах. Они не будут просить повышения, страдая от постоянного чувства вины за то, что огорчают вас и не поспевают по целям проекта. Постарайтесь навешать на них столько ответственности за неудачи, сколько получится.
Верный способ воспитать мастеров "итальянской забастовки".
Здравствуйте, licedey, Вы писали:
L>А что по вашему должен делать ПМ? Сидеть в сторонке, курить бамбук, пока его подопечные рубятся в xbox и постят Вконтактик?
Уж поверьте, у руководства тоже много работы, которую надо делать. Обычно больше, чем у разработчиков.
L>Он должен погонять. Да любой менеджер должен надавить где нужно, иначе все рухнет к такой то маме.
Не должен. Не рухнет. Есть более эффективные способы мотивации, чем стоять над душой.
T>А что там увидишь? T>Есть Estimated Hours, а есть Actual Hours. T>Пока (Actual Hours < Estimated Hours) все видится хорошо и предъявить нечего.
Я обновляю эстимейт, если что то идёт не так, или пишу менеджеру. Мол так и так, в эстимейте ошибка. Более того, категорически отказываюсь от ответственности в задачах, где эстимейт составлял не я. Мол вы обещали, вам и отвечать
VM>Я обновляю эстимейт, если что то идёт не так, или пишу менеджеру. Мол так и так, в эстимейте ошибка.
Ты делал эстимейт, а потом говоришь менеджеру что твой эстимейт полная лажа? Верно?
VM>Более того, категорически отказываюсь от ответственности в задачах, где эстимейт составлял не я. Мол вы обещали, вам и отвечать
Тебя попросят подтвердить, согласен ты или нет. Если да, тогда тебе назначают эту задачу и будь здоров выполнять эстимейт.
Здравствуйте, Baudolino, Вы писали:
B>Здравствуйте, licedey, Вы писали:
L>>А что по вашему должен делать ПМ? Сидеть в сторонке, курить бамбук, пока его подопечные рубятся в xbox и постят Вконтактик? B>Уж поверьте, у руководства тоже много работы, которую надо делать. Обычно больше, чем у разработчиков.
L>>Он должен погонять. Да любой менеджер должен надавить где нужно, иначе все рухнет к такой то маме. B>Не должен. Не рухнет. Есть более эффективные способы мотивации, чем стоять над душой.
Я знаю только 2 организации, где метод "только пряника" и самоинициатива приветствуются. Это баптисти и анонимные алкоголики, ну и их аналоги.
В ином случае, не пнешь — не полетит. Даже самые талантливые или опытные разработчики работают на расслабоне или пинают балду, пока не придет дядя с палкой. По крайней мере за 10 лет кодинга так и было.
Здравствуйте, licedey, Вы писали:
L>Я знаю только 2 организации, где метод "только пряника" и самоинициатива приветствуются. Это баптисти и анонимные алкоголики, ну и их аналоги. L>В ином случае, не пнешь — не полетит. Даже самые талантливые или опытные разработчики работают на расслабоне или пинают балду, пока не придет дядя с палкой. По крайней мере за 10 лет кодинга так и было.
Вам не повезло работать в организациях со слабым менеджментом. Я такие тоже видел, хорошего мало. Однако, экстраполировать личный опыт на всю отрасль и говорить, что иначе не бывает — логическая ошибка. На одной из своих предыдущих работ мне пришлось восстанавливать команду, набирать новых людей и повышать производительность. Мы за два года вышли на в два раза больший объем сдаваемых проектов при заметном увеличении качества и объема кода. Без пинков, на нормальной мотивации людей интересными задачами, адекватной зарплатой и отсутствием конфликтов (внутри команды — от остальных я их изолировал).
B>Мы за два года вышли на в два раза больший объем сдаваемых проектов при заметном увеличении качества и объема кода. Без пинков, на нормальной мотивации людей интересными задачами, адекватной зарплатой и отсутствием конфликтов (внутри команды — от остальных я их изолировал).
Зарплата в два раза выросла? Или осталась прежней?
>на нормальной мотивации людей интересными задачами
T>Зарплата в два раза выросла? Или осталась прежней?
Ха. Чуть выше инфляции и рынка.
>>на нормальной мотивации людей интересными задачами T>Об этом подробнее расскажите.
Что именно?
T>>Зарплата в два раза выросла? Или осталась прежней? B>Ха. Чуть выше инфляции и рынка.
И зачем им в два раза сильнее напрягаться, если за углом можно не напрягаться за те же деньги?
>>>на нормальной мотивации людей интересными задачами T>>Об этом подробнее расскажите. B>Что именно?
При росте объем рутины обычно растет потому что поддержку никто не отменял. Особенно когда заказчики начинают просить прикрутить пятое колесо тогда как это новое колесо не лезет в основную архитектуру и отдельным модулем его тоже не сделаешь и так появляются custom versions которые все больше и больше расходятся между собой и разработка ради фана заканчивается и люди начинают потихоньку разбегаться.
Здравствуйте, turbocode, Вы писали:
T>И зачем им в два раза сильнее напрягаться, если за углом можно не напрягаться за те же деньги?
Во-первых, за углом довольно трудно найти интересную работу за такие же деньги. Во-вторых, повышение производительности труда — это не "в два раза сильнее напрягаться", а сделать жизнь исполнителям в два раза проще за счет оптимизации потока задач, повышения качества требований и т.п. Или вот простой пример технологической оптимизации: старт сервера приложений занимал изначально до 10 минут. Частая операция (поскольку не всегда горячая замена когда в режиме отладки возможна), в течение которой разработчик либо сидит тупит в экран, либо уходит в социальные сети на 15 минут. Выкидываем сервер приложений, переходим на легковесный контейнер, оптимизируем время запуска, получаем в итоге 25 секунд. Переключение внимания уже не требуется, мы экономим в среднем 15 минут каждые два часа и отбиваем инвестиции на реинжиниринг примерно за полгода. И таких историй много можно рассказать.
T>При росте объем рутины обычно растет потому что поддержку никто не отменял...
В заказной разработке, в отдельных сегментах — да. В этой области в целом творится ужас-ужас, но можно встретить компании, в которых живется довольно неплохо и в которых, опять же, процесс выстраивается без пинков. Мы делали внутренний облачный продукт на актуальном на данный момент стеке технологий, это совсем другая история.
B>Вам не повезло работать в организациях со слабым менеджментом. Я такие тоже видел, хорошего мало. Однако, экстраполировать личный опыт на всю отрасль и говорить, что иначе не бывает — логическая ошибка. На одной из своих предыдущих работ мне пришлось восстанавливать команду, набирать новых людей и повышать производительность. Мы за два года вышли на в два раза больший объем сдаваемых проектов при заметном увеличении качества и объема кода. Без пинков, на нормальной мотивации людей интересными задачами, адекватной зарплатой и отсутствием конфликтов (внутри команды — от остальных я их изолировал).
Где вы увидели, что я говорю про всю отрасль? Так и указал, что это только мой опыт. Я знаю например много стартапов, где действительно люди работают за идею, веря в светлое будущее и за опционы. Самый яркий пример — это Вконтакте. Насколько мне известно, Дуров там никого не гонял и не подгонял, люди сами видели в какой Клондайк они попали и их это мотивировало. Но опять же, среднестатистический "ООО Вектор", где проект нужен только руководству, требует пинков подчиненных, ибо кроме зарплаты им ничего не перепадает.
Здравствуйте, licedey, Вы писали:
L>Где вы увидели, что я говорю про всю отрасль?
Мне так показалось из вашего поста. Извините, если ошибся.
В любом случае, пинки начальства в среднестатистических ООО "Вектор" не есть вариант нормы. Это папуасы, которые жрут друг друга, и которых надо приобщать к цивилизации. Мне, кстати, довелось как-то работать в маленькой конторе, занимающейся заказной разработкой. Это, правда, была американская компания и там обходились без микроменеджмента. Но американцы, в отличие от европейцев и азиатов (и где-то между ними русских), вообще менее склонны к жестким иерархиям, и чаще предпочитают партнерские отношения между начальником и подчиненным. Возможно, стоит перенять этот подход.
B>Во-первых, за углом довольно трудно найти интересную работу за такие же деньги. Во-вторых, повышение производительности труда — это не "в два раза сильнее напрягаться", а сделать жизнь исполнителям в два раза проще за счет оптимизации потока задач, повышения качества требований и т.п.
Все это работает до определенного порога, потому что посидеть в социалочках никто не отменял.
А если запретить социалочки то снова будет некомфортно работать благодаря мысли: держат нас тут за рабов пора валить.
Здравствуйте, turbocode, Вы писали:
B>>Во-первых, за углом довольно трудно найти интересную работу за такие же деньги. Во-вторых, повышение производительности труда — это не "в два раза сильнее напрягаться", а сделать жизнь исполнителям в два раза проще за счет оптимизации потока задач, повышения качества требований и т.п.
T>Все это работает до определенного порога, потому что посидеть в социалочках никто не отменял. T>А если запретить социалочки то снова будет некомфортно работать благодаря мысли: держат нас тут за рабов пора валить.
Речь не идет о том, чтобы это запрещать. Нереально 8 часов подряд непрерывно работать над одной задачей, перезагрузка мозгов периодически требуется и в общем пофиг, пойдет человек при этом пить чай или читать фейсбук. Важно сделать так, чтобы появлялось как можно меньше препятствий в работе, которые стимулируют уход в непродуктивную деятельность.
Здравствуйте, turbocode, Вы писали:
T>Ты не прав. PM в коде ничего не соображает и таким образом ничем помочь не сможет.
Так пинками помогает, пинками. Разгоняет тебя, так сказать. Я тоже так делаю, каждый день спрашиваю у своих много ли сделали, много ли осталось, есть ли проблемы, надо ли помочь и т.д.
SK>Так пинками помогает, пинками. Разгоняет тебя, так сказать. Я тоже так делаю, каждый день спрашиваю у своих много ли сделали, много ли осталось, есть ли проблемы, надо ли помочь и т.д.
Это ежедневные скрам митинги.
Здравствуйте, turbocode, Вы писали: T>дело не в доверии, PM хочет быть эффективным и он думает что таким образом он ускорит процесс разработки (возможно на курсах MBA этому учат).
