Здравствуйте, Vzhyk, Вы писали:
V>Как там про одного чела, которого молиться заставили... (на личности не V>перехожу, просто напоминаю старую русскую поговорку).
Я человек простой, морали не уловил. Расшифруй.
V>Мне казалось, что основная функция менеджера определять, что делать, и V>помогать подчиненным, если не получается, решать вопросы взаимодействия V>с соседними группами и в последнюю очередь контролировать.
к пункту помогать подчиненным, если не получается прилагается еще пункт следить чтоб не косячили
genre пишет: > > > к пункту *помогать подчиненным, если не получается* прилагается еще > пункт /следить чтоб не косячили/
А вы попытайтесь не следить, это же ваши подчиненные и вы их брали,
эффективность труда их повысится.
Если же вы им не доверяете, какой смысл их держать и следить за ними?
Да и в таком случае проще делать все самому, но все сам не сделаешь.
Здравствуйте, Vzhyk, Вы писали:
>> к пункту *помогать подчиненным, если не получается* прилагается еще >> пункт /следить чтоб не косячили/ V>А вы попытайтесь не следить, это же ваши подчиненные и вы их брали, V>эффективность труда их повысится.
Это тебе кажется или ты точно знаешь?
Я — знаю точно о чем говорю. Потому что могу померять и получить объективные данные.
И знаю точно, что если не контролировать процесс то производительность труда падает стремительным домкратом.
V>Если же вы им не доверяете, какой смысл их держать и следить за ними?
Потому что собрать команду из фанатиков из разряда "хлебом не корми дай попрограммировать" невозможно.
А обычные люди они все разные. У всех разная мотивация, разные жизненные установки, разные жизненные ситуации в конце концов.
Упала например мотивация у человека, хоп и ошибки сразу. Или там трагедия в личной жизни и работа вообще не идет. Тут вот и нужно заметить и исправить, премию там выдать или там задачку похитрее и поинтереснее подкинуть ну или еще что, по ситуации, чтоб человека замотивировать, ну или наоборот, разгрузить человека если проблемы в жизни у него — оклемается спасибо скажет.
Так и живем.
PS Контролировать это конечно не стоять с кнутом за спиной. Это делается максимально незаметно для контролируемого, чтобы не повлиять контролем на процесс.
genre пишет: > > V>А вы попытайтесь не следить, это же ваши подчиненные и вы их брали, > V>эффективность труда их повысится. > Это тебе кажется или ты точно знаешь?
Проверено. На живых людях, а не в теории.
> Я — знаю точно о чем говорю. Потому что могу померять и получить > объективные данные.
Извини, но .
> И знаю точно, что если не контролировать процесс то производительность > труда падает стремительным домкратом.
Нет, не падает. Но, понятно, анархию я не пропагандирую.
Подавляющее большинство программистов любит работать и делает это с
удовольствием, главное им не мешать и направлять в нужное русло. Да, это
уже больше к области психологии, точнее даже области управления людьми.
> > V>Если же вы им не доверяете, какой смысл их держать и следить за ними? > Потому что собрать команду из фанатиков из разряда "хлебом не корми дай > попрограммировать" невозможно.
Не в тему. Мы не обсуждаем, как работать с фанатиками. > Упала например мотивация у человека, хоп и ошибки сразу. Или там > трагедия в личной жизни и работа вообще не идет. Тут вот и нужно > заметить и исправить, премию там выдать или там задачку похитрее и > поинтереснее подкинуть ну или еще что, по ситуации, чтоб человека > замотивировать, ну или наоборот, разгрузить человека если проблемы в > жизни у него — оклемается спасибо скажет. > Так и живем.
Да!!! И при чем тут контроль?
> > PS Контролировать это конечно не стоять с кнутом за спиной. Это делается > максимально незаметно для контролируемого, чтобы не повлиять контролем > на процесс.
Не знаю. Процесс контроля он как бы сам собой вытекает из планирования
деятельности и движения в соответствие с планами.
Я всегда знаю, как мы идем к нашей общей цели и мне не надо ни отчетов
ни чего-либо подобного.
Здравствуйте, Vzhyk, Вы писали:
V>genre пишет: >> >> >> к пункту *помогать подчиненным, если не получается* прилагается еще >> пункт /следить чтоб не косячили/ V>А вы попытайтесь не следить, это же ваши подчиненные и вы их брали, V>эффективность труда их повысится. V>Если же вы им не доверяете, какой смысл их держать и следить за ними? V>Да и в таком случае проще делать все самому, но все сам не сделаешь.
По меньшей мере контроль должен заключаться в проверке результатов. Потому что если подчиненный знает что его результат никого не интересует, его мотивация сильно падает и производительность труда вместе с ней.
Подчиненный всегда должен чувствовать что его результат нужен, в первую очередь его менеджеру.
Здравствуйте, Vzhyk, Вы писали:
V>genre пишет: >> >> >> к пункту *помогать подчиненным, если не получается* прилагается еще >> пункт /следить чтоб не косячили/ V>А вы попытайтесь не следить, это же ваши подчиненные и вы их брали, V>эффективность труда их повысится.
V>Если же вы им не доверяете, какой смысл их держать и следить за ними? V>Да и в таком случае проще делать все самому, но все сам не сделаешь.
Вопрос контроля это не вопрос доверия или недоверия. Исполнители должны быть уверены в том, что контроль результата наступит обязательно, и он неотвратим. Вопрос наличия контроля — это вопрос наличия обратной связи, необходимой для существования какого-либо управления в принципе. Это, вообще, один из основополагающих принципов управления. Если закрытие задачи не контролируется, то "менеджмент" отсутствует как явление, и ты просто не можешь ничего знать про эффективность труда, ибо не сможешь ее измерить.
Здравствуйте, Vzhyk, Вы писали:
V>Проверено. На живых людях, а не в теории.
>> Я — знаю точно о чем говорю. Потому что могу померять и получить >> объективные данные. V>Извини, но .
Так ты ответь, ты проверял объективные показатели или субъективные?
Если субъективные то сверху написано, что я именно мерял. Это малость точнее
V>Нет, не падает. Но, понятно, анархию я не пропагандирую. V>Подавляющее большинство программистов любит работать и делает это с V>удовольствием, главное им не мешать и направлять в нужное русло.
Ага. Щаз. Это миф.
Подавляющее большинство программистов ходит на работу, чтобы заработать деньги,
сделать карьеру, прокормить семью, удовлетворить свои амбиции, итд. нужное подчеркнуть. Ну и заодно получить удовольствие от программирования.
(это кстати вытекает даже из того, что ниже ты не споришь с тем, что проблема мотивирования существует )
И лишь небольшое меньшинство работает из любви к искусству.
V>Да!!! И при чем тут контроль?
ЭЭ. Как причем? У вас принято, чтобы программист сам приходил к менеджеру и говорил "Чето у меня мотивация упала, мне б премию"?
Контроль это единственный способ узнать, что с кем происходит.
И единственный метод обратной связи как ниже совершенно верно написали.
V>Не знаю. Процесс контроля он как бы сам собой вытекает из планирования V>деятельности и движения в соответствие с планами. V>Я всегда знаю, как мы идем к нашей общей цели и мне не надо ни отчетов V>ни чего-либо подобного.
Если бы все было так просто то никто не выдумывал бы методик как замотивировать, как померять производительность, как сравнить двух программистов и всяческие подобные вещи.
Вот смотри. Методики планирования бывают двух видов. Когда срок на решение задачи определяется снизу — исполнителем или сверху — руководством.
(Совместное определение сроков тяготеет к первому виду)
Второй способ крайне сложно заставить работать правильно. Потому что и руководство склонно сроки занижать, да и программировать оно может уже не программирует давным давно итд. А заниженные сроки это явный демотивирующий фактор для программиста.
Поэтому чаще применяют первый способ. Когда сроки решения задачи определяются снизу. И вот скажи мне как в таком случае программиста проконтролировать? Он сказал срок неделя, а работал реально 1 час(Это халтурщик). Или сказал неделя и работал реально неделю, хотя задача на самом деле на пару дней (Это демотивированный ). Или сказал неделя, но 5 дней изобретал велосипед и 2 дня девелопил (Это молодой )
Как ты планируешь это определять без контроля?
Проект программится, двигается к цели да и вполне может нормально работать и внешне все выглядит красиво и по плану. А на самом деле фигня творится.
И вот в какой-то момент приходится применять отдельные методики контроля.
Здравствуйте, Vzhyk, Вы писали:
>> к пункту *помогать подчиненным, если не получается* прилагается еще >> пункт /следить чтоб не косячили/ V>А вы попытайтесь не следить, это же ваши подчиненные и вы их брали, V>эффективность труда их повысится. V>Если же вы им не доверяете, какой смысл их держать и следить за ними? V>Да и в таком случае проще делать все самому, но все сам не сделаешь.
vb-develop пишет: > > > По меньшей мере контроль должен заключаться в проверке результатов. > Потому что если подчиненный знает что его результат никого не > интересует, его мотивация сильно падает и производительность труда > вместе с ней.
Да. Но какое отношение к этому имеет проверка результатов?
Проверка ваша типа: он сделал то, что должен был?
> Подчиненный всегда должен чувствовать что его результат нужен, в первую > очередь его менеджеру.
Скажу больше, менеджер здесь последний среди тех, ком нужен его результат.
Gaperton пишет: > > просто не можешь ничего знать про эффективность труда, ибо не сможешь ее > измерить.
Честно, Gaperton, ну меряй, все что ты хочешь, это твое развлечение, но
оное к результату обычно имеет очень далекое отношение.
genre пишет: > >> > Я — знаю точно о чем говорю. Потому что могу померять и получить >> > объективные данные. > V>Извини, но . > > Так ты ответь, ты проверял объективные показатели или субъективные?
Схоластикой мне развлекаться не интересно. Я написал выше именно то, что
хотел. О объективные это или субъективные, все одно в области управления
(ну не люблю я английское слова при наличии русского), очень сложно
сказать. Что есть здесь объективное? Статистика, а точнее трактовка
результатов? — Ой как оное субъективно.
> > Ага. Щаз. Это миф. > Подавляющее большинство программистов ходит на работу, чтобы заработать > деньги, > сделать карьеру, прокормить семью, удовлетворить свои амбиции, итд. > нужное подчеркнуть. Ну и заодно получить удовольствие от программирования. > (это кстати вытекает даже из того, что ниже ты не споришь с тем, что > проблема мотивирования существует ) > И лишь небольшое меньшинство работает из любви к искусству.
Значит с 93 года я работаю исключительно с меньшинством. Значит так мне
повезло или не повезло.
> > И единственный метод обратной связи как ниже совершенно верно написали.
Нет. Это ограниченность видеть только один способ.
> > Если бы все было так просто то никто не выдумывал бы методик как > замотивировать, как померять производительность, как сравнить двух > программистов и всяческие подобные вещи.
Все хотят деньги зарабатывать, А если можно продать кому-то воздух, то
это святое дело.
> > Вот смотри. Методики планирования бывают двух видов. Когда срок на > решение задачи определяется снизу — исполнителем или сверху — руководством. > (Совместное определение сроков тяготеет к первому виду)
Главное пройти здесь "черно-белое" видение, что ты привел выше.
> Второй способ крайне сложно заставить работать правильно. Потому что и > руководство склонно сроки занижать, да и программировать оно может уже > не программирует давным давно итд. А заниженные сроки это явный > демотивирующий фактор для программиста.
А вот здесь в каждой ситуации свой способ борьбы с заскоками того
руководства. Но если у оного это хроническое, то сачто проще сменить рук-во.
> Поэтому чаще применяют первый способ. Когда сроки решения задачи > определяются снизу. И вот скажи мне как в таком случае программиста > проконтролировать? Он сказал срок неделя, а работал реально 1 час(Это > халтурщик).
Нет. Но, это твоя недоработка. Не видел я программистов, которые
настолько ошибаются. Да программисты сильно оптимистичны. В твоем же
случае (включаю телепатию) похоже что у руководства начинаются реальные
проблемы.
> Или сказал неделя и работал реально неделю, хотя задача на > самом деле на пару дней (Это демотивированный ). Или сказал неделя, но 5 > дней изобретал велосипед и 2 дня девелопил (Это молодой )
Какие сказки. Такое впечатление, что разработчики сами по себе ты сам по
себе.
> > Как ты планируешь это определять без контроля? > Проект программится, двигается к цели да и вполне может нормально > работать и внешне все выглядит красиво и по плану. А на самом деле фигня > творится.
Какая такая фигня. Есть план, есть результат по плану. Все. Детализация
плана конкретным разработчиком ~3 дня (с учетом задач). Ты же все
видишь. Понятно, что продукт надо смотреть как работает, а не только
пивком баловаться целыми днями.
Здравствуйте, Vzhyk, Вы писали:
>> просто не можешь ничего знать про эффективность труда, ибо не сможешь ее >> измерить. V>Честно, Gaperton, ну меряй, все что ты хочешь, это твое развлечение,
Когда я вдруг захочу узнать твое мнение о том, что мне мерять — я тебя обязательно спрошу. Честно. И ради такого развлечения, еще и коллег позову.
V>но оное к результату обычно имеет очень далекое отношение.
Да кто б сомневался. Почти все, что ты говоришь, имеет и к результату и менеджменту очень далекое отношение, так что что тут удивляться.
ЗЫ: Ты кончай на личности переходить. Не надоело еще?
V>Схоластикой мне развлекаться не интересно. Я написал выше именно то, что V>хотел. О объективные это или субъективные, все одно в области управления V>(ну не люблю я английское слова при наличии русского), очень сложно V>сказать. Что есть здесь объективное? Статистика, а точнее трактовка V>результатов? — Ой как оное субъективно.
Какая может быть субъективная трактовка численного результата?
V>Значит с 93 года я работаю исключительно с меньшинством. Значит так мне V>повезло или не повезло.
Значит ты не так трактуешь увиденное. Заинтересованность то есть во многих. Но заинтересованность программированием не означает того, что человек выполняет свою работу хорошо и эффективно. Хороший кстати пример есть. Советские НИИ. люди там тоже работали увлеченные своим делом. А дело двигалось в большинстве мест очень медленно.
>> И единственный метод обратной связи как ниже совершенно верно написали. V>Нет. Это ограниченность видеть только один способ.
Какие есть еще?
>> >> Если бы все было так просто то никто не выдумывал бы методик как >> замотивировать, как померять производительность, как сравнить двух >> программистов и всяческие подобные вещи. V>Все хотят деньги зарабатывать, А если можно продать кому-то воздух, то V>это святое дело.
Скажи, тебе когда-нибудь приходилось отвечать на вопрос заказчика "Когда это будет готово?" зная, что права на ошибку у тебя маловато?
>> Вот смотри. Методики планирования бывают двух видов. Когда срок на >> решение задачи определяется снизу — исполнителем или сверху — руководством. >> (Совместное определение сроков тяготеет к первому виду) V>Главное пройти здесь "черно-белое" видение, что ты привел выше.
я ж говорю. мы люди простые. расшифруй
V>А вот здесь в каждой ситуации свой способ борьбы с заскоками того V>руководства. Но если у оного это хроническое, то сачто проще сменить рук-во.
Я и говорю. Поэтому такой способ разумные люди не определяют.
V>Нет. Но, это твоя недоработка. Не видел я программистов, которые V>настолько ошибаются. Да программисты сильно оптимистичны. В твоем же V>случае (включаю телепатию) похоже что у руководства начинаются реальные V>проблемы. V>Какие сказки. Такое впечатление, что разработчики сами по себе ты сам по V>себе.
Ты зря комментировал частные случаи. Я специально привел достаточно гротескные варианты, просто для иллюстрации идеи.
Общий смысл был такой: 90% программистов сильно ошибаются в оценке сроков. Иногда специально, иногда нет.
А если человек знает, что никто это не проверит он и думать не будет особо. Пальцем в потолок ткнет.
И работать потом будет так же. Удовлетворять любопытство за счет работодателя.
V>Какая такая фигня. Есть план, есть результат по плану. Все. Детализация V>плана конкретным разработчиком ~3 дня (с учетом задач). Ты же все V>видишь. Понятно, что продукт надо смотреть как работает, а не только V>пивком баловаться целыми днями.
А что ты видишь? Что человек поставил 3 дня на задачу, сделал ее за 1-3-5 дней. И какие ты отсюда можешь сделать выводы о его работе?
Еще вопрос
G>Скажи, тебе когда-нибудь приходилось отвечать на вопрос заказчика "Когда это будет готово?" зная, что права на ошибку у тебя маловато?
А главное потом, не рвя задницу на британский флаг, спокойно в эти сроки укладыватся?
Здравствуйте, Vzhyk, Вы писали:
V>senglory пишет: >> >> V>профессиональные в первую очередь, материальные во >> V>вторую >> >> Я не ослышался? Последовательность именно такая??? V>Да.
Жены нет рядом с детьми?
Re[6]: Защита от темных исскуств
От:
Аноним
Дата:
16.05.09 13:49
Оценка:
Люди слишком предсказуемы... в отличие от программ.
Это гениально, сэр!
Re: Защита от темных исскуств
От:
Аноним
Дата:
16.05.09 13:54
Оценка:
Главный вывод, который я сделал — что я не хотел бы работать с Гапертоном в одной фирме.
Здравствуйте, DemAS, Вы писали:
DAS> Кстати, все эти "темные искусства" и подковерная политика в глобальном DAS>плане, как я понимаю, сильно вредит компании в целом.
Рискну не согласиться.
1) Влияние — воздействие на других людей (как по их воле, когда они согласны с вами и сами с радостью выполняют, так и против их воли)
Власть — потенциальная возможность влияния.
2) Хорошему руководителю необходима власть, что бы достигать корпоративных целей. Если в компании не будет 1-го (единственного) человека, обладающего доминантой власти — компания будет как в басне, где все тянут воз в разные стороны. (Оговорюсь что я не фанат крайних случаев: авторитаризма и анархизма и прочих. В долгосрочной перспективе вредно когда 100% власти сосредоточено в одних руках. Я говорю о разумном превосходстве одной стороны над остальными). Возможны триумвираты, но лично я им почему то не особо доверяю.
3) Хороший руководитель должен уметь выживать и вытягивать компанию в жесткой среде реальной конкуренции, где применяются такие средства как "побухать с кем надо", взятки, лоббирование, лояльные гос-структуры и т.д. Увы надежного средства создать условия "честной" комкуренции в реальном мире пока нет.
С этой точки зрения искуственное нагнетание политизированной структуры важно как средство воспитания и валидации следующего поколения руководителей, готовых к реалиям нашего мира. Почему то складывается впечатление что хорошего руководителя днем с огнем не съищеш.
4) Хороший руководитель должен выполнять работу за минимум ресурсов. Работа занимает все отведенные на нее ресурсы.
Хороший способ создать политизированную структуру — организовать борьбу за ресурсы. (Имхо это не работает ибо ресурсы получают те, кто круче в политике а не те, кому они реально нужны.. но как можно узнать кому они реально нужны?)
DAS>Хотя бы за счет того, DAS>что компания может потерять талантливых людей, абсолютно не DAS>заинтересованных в этой политике, а также за счет того, что на должности, DAS>принимающие решения, могут придти некомпетентные в этом люди, но умеющие DAS>заниматься интригами.
Соглашусь: Политики на "рабочих" профессиях быть не должно. Политику мало кто любит, и люди просто могут уйти в менее политизированную компанию.
Однако: На практике все равно, именно ваш "политический" вес будет влиять на то, чье решение будет принято в споре. Кому достанутся фанфары и кто будет отдуваться за провал (При условии, что все решения примерно одинаково полезны). Хотя интриг в среде программитов благо почти не встречается и достаточно простых правил что бы их нейтролизовать.
DAS> Поэтому разумное высшее руководство любой компании должно быть DAS>заинтересовано в создании такой обстановки в своей компании, когда интриг DAS>не будет, хотя бы за счет того, что они не будут приносить никаких DAS>практических результатов интригантам.
Спорное утверждение. Разумное низщее руководство обязано де-политизировать работников, а вот высшее — хз.
DAS> 1. Создание простых и прозрачный критериев оценки работы.
Такие критерии не работают если нет возможности оценить насколько "работа" полезна компании. Ведь работы далеко не всегда проявляются сразу. (Например архитектура ядра системы: узнать хорошая ли архитектура и насколько она соответствует реалиям вы можете только через год-два. Все остальное — это лишь догадки). Кроме того, трудно оценить насколько хороши были альтернативы т.к. они вообще не были попробованы.
Кроме того такие критерии могут подменить цели компании ради которых существуют все отделы и к которым они должны стремиться ложными целями которые плохо коррелированы с реальными. Например хорошая архитектура ядра вовсе не означает что продукт удовлетворяет потребности пользователя (что есть конечная цель создания продукта).
DAS> 2. Один центр ответственности — один человек. Не должно быть 2 человека, DAS> отвечающих за одну и ту же вещь. Согласен, что это не всегда возможно.
+1
DAS> 3. Кол-во менеджеров среднего звена должно быть минимальным. То есть, DAS> кол-во должностей между стажером и главой компании должно быть DAS> минимальным. В Oracle, когда я там работал — таких ступеней было 5. То DAS> есть, от любого стажера, только что принятого на работу до Ларри было не DAS> больше 5 руководителей. Это в фирме из 75 000 человек (до покупки Sun).
+1
DAS> И по моим наблюдениям, в фирмах, где высшее руководство не поощряет DAS>интриги — их нет.
+1
PS: Сори что не подтверждаю свои слова примерами из жизни. Придумывать из воздуха не хочется а искать, если честно, лень . Однако я уверен что для каждого утверждения есть примеры как подтверждающие его, так и опровергающие — ибо не все так однозначно как я описал
. Однако я уверен что для каждого утверждения есть примеры как подтверждающие его, так и опровергающие — ибо не все так однозначно как я описал 
