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

Итак. Какие мы знаем проблемы в психологии взаимоотношений руководства с девелоперами, которые могут выйти боком?

а) Перфекционизм.
Человек не просто выполняет задание, а выполняет его не на пять, а "на шесть". Т.е. — сказано, реализовать фичу. Реально там экран кода на Си. Человек же начинает писать абстрактные интерфейсы, наследовать от них на всякий случай несколько разных имплементаций (хотя extensibility в этом месте от него не требовали), ну и так далее.

Вред: срыв сроков, овердизайн, зачастую снижается способность системы к поддержке (просто лишний код).
Подсознательные заморочки: желание доказать руководству, что крут, иногда с подтекстом "а ты, руководитель, не знаешь того, что знаю я".

б) Неряшливость.

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

Вред: увеличение риска багов, особенно интеропов и работоспособности "на краю" требуемого функционала. Увеличение риска скрытых багов, которые будут найдены много позже бета-тестирования. Усложнение саппорта — зачастую правка баги требует переписывания с нуля "по уму".
Подсознательные заморочки: "просили быстрее — нате, получите, а что качество будет хуже — так я же вас предупреждал". Зачастую это попытка сложить с себя ответственность в условиях сильного прессинга. В некоторых запущенных случаях человек еще и гордится этим — на тему "я умею быстро решать реальные задачи". Быстро и плохо.

в) Проблемы с концентрацией внимания.

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

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

Подсознательная заморочка: "я самый умный и делаю то, что нужно мне, а то, что нужно вам, я буду делать нехотя спустя рукава".

г) Интриги.

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

Вред: ухудшение отношений в коллективе, снижение контроля работодателя за принимаемыми решениями.
Подсознательная мотивация: "я самый умный, и потому должен иметь более высокий статус, чем имею сейчас. И во всяком случае мое мнение самое важное".

Не так и плохо, если человек реально толков. Ему можно дать фронт работ, где он сможет проявить себя. Но в коллективных мероприятиях с таким человеком тяжело.

д) Подковерные игры.

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

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

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

ИМХО, конечно, но вот это пункт д) — уже на грани прямого повода к увольнению, а то и просто повод.

Ну вот примерно так.

Приглашаю всех внести свой вклад в тему.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Предлагаю открыть эту тему. Как мне кажется, она играет огромную роль в управлении проектами. Как мне кажется — не меньшую, нежели наличие или отсутствие метрик в разработке например, успешные проекты без метрик — это не редкость, крах компании из-за отсутствия метрик — редкость, а крах компании или провал проекта из-за вот этих проблем — да легко.

MSS>Итак. Какие мы знаем проблемы в психологии взаимоотношений руководства с девелоперами, которые могут выйти боком?

Забавно... во всех этих пунктах я узнал себя.

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

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

Что делать "проблемному" девелоперу? Честно говоря, не знаю...

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Предлагаю открыть эту тему. Как мне кажется, она играет огромную роль в управлении проектами. Как мне кажется — не меньшую, нежели наличие или отсутствие метрик в разработке например, успешные проекты без метрик — это не редкость, крах компании из-за отсутствия метрик — редкость, а крах компании или провал проекта из-за вот этих проблем — да легко.

согласен на 100%, это очень важный момент

MSS>Итак. Какие мы знаем проблемы в психологии взаимоотношений руководства с девелоперами, которые могут выйти боком?

<...>

MSS>Приглашаю всех внести свой вклад в тему.

е) Неадекватная оценка ситуации кем-либо в паре начальник-подчиненный

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

Вред: Не получая своего рода адекватной обратной связи, сотрудник просто теряет желание вкладывать в проект душу, хотя качество кода возмжно и останется на приемлемом уровне или даже выше среднего уровне, но для компании тут мне кажется убыток прямой и весьма серьезный может получиться (можно назвать это даже упущенная выгода? человек выдает значительно меньше 100% от своих возможностей, что то из серии д) — "раз меня никто не ценит, работаю строго по КЗОТ".
)

подобная же история когда сотрудник делает "хороший\нормальный" на его взгляд код, а босс "(не)обоснованно придирается и лажает", т.е. не может убеить сотрудника что у него проблемы. Тут начинает назревать конфликт, который рано или поздно проявится (в зависимости от темпераментов и обстоятельств)

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

D>Забавно... во всех этих пунктах я узнал себя.

Я отчасти писал с себя, отчасти — с коллег, и успешных, и провальных (одно увольнение за другим). Собирательный образ.

D>Думаю, что все эти проблемы связаны с естественной человеческой потребностью в самовыражении.

Да. Вопрос о том, где надо поставить ей границы, чтобы не мешало делу.

>И возникать они могут, когда руководство относится к девелоперам, как к ресурсу, лишенному индивидуальности.

Не является ли злоупотребление методиками из PMной литературы — вот именно этим?

>Либо когда некий "проблемный" девелопер уже имел ранее опыт подобного к нему отношения, и, как следствие, выработал безопасный для себя стереотип поведения.

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

Собственно, у амеров (в отличие от России) — вообще вся национальная традиция воспитания детей и подростков — на максимум эффективности в благоприятной среде. В России же скорее — на выживание в жесткой.

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

Впрочем, это офф.

D>Что делать руководству? Думаю, что в качестве профилактики может помочь банальное "поощрять инициативность и давать больше свободы девелоперам в принятии решений". Возможно, данная стратегия может "вылечить" и "проблемных" девелоперов в не сильно запущенных случаях.

А конкретика? на уровне "описание проблемы — методы решения успешные — методы решения провальные"?

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Приглашаю всех внести свой вклад в тему.
Классная книга "Человеческий фактор" ДеМарко, Листер. Рекомендую.

Здравствуйте, Maxim S. Shatskih,

Отличная картина типичных проблем.
Наверно, нет простого ответа, как простимулировать работников трудитсья с энтузиазмом.
Мне кажется, что во моногом все определяется личными качествами руководителя. Есть харизма/нет харизмы,
хотя какие-то качества можно и нужно в себе вырабатывать, хотя бы стремиться к этому.
Вопрос, можно ли выработать умение вести за собой.
Гуляя с ребенком, я смотрю на детей, — выделяются явные "заводилы", "тихони", "плаксы" и т.д..
Вспоминая свою детскую компанию, школьных и институтских друзей и однокашников я могу сказать, что распределение ролей в принципе не меняется. Важно найти свое место.


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

http://russian.joelonsoftware.com/Articles/FireAndMotion.html
"
Многие мои дни проходят примерно так: 1) прийти на работу; 2) проверить почту, полазить по сети и т.д.; 3) решить что я мог бы пообедать прежде чем начать работать; 4) вернуться с обеда; 5) проверить почту, полазить по сети и т.д.; 6) окончательно решить что пора взяться за работу; 7) проверить почту, полазить по сети и т.д.; 8) опять решить что, действительно пора поработать; 9) запустить чёртов редактор; и 10) безостановочно писать код, пока я не осознаю что уже полвосьмого. "


В общем-то рецепт прост. Пришел на работу — начинай работать. От ощущения, что ты провел день не зря, больше удовольствия, чем от безделья.
Возможно, внедрение такой мысли кого-то и выличит.

Успехов!

Здравствуйте, Maxim S. Shatskih, Вы писали:

[]

Добавлю еще пункт:

Потеря интереса к выполняемой работе

Причины:
1. Опытному девелоперу поручают рутиную работу, которую может сделать любой менее опытный девелопер.
2. Девелоперу поручают работу, сложность которой, значительно превышает его квалификацию.
3. Систематическое неукладывание в сроки.
4. Сворачивание работ по направлению, которое было интересно девелоперу и которому было уделено значительное время.

Следствия:
1. Девелоперу интереснее играть в игрушки, общаться в форумах и аське, чем работать.
2. Возможны конфликты девелопера с руководством
3. Возможно увольнение девелопера в другую организацию

ЗЫ. В целом, затронутая тема интересна, но очень сложна.
Поэтому, сходу тяжело систематизировать все возможные варианты.
Был бы рад рекомендациям по литературе.

_D>ЗЫ. В целом, затронутая тема интересна, но очень сложна.
_D>Поэтому, сходу тяжело систематизировать все возможные варианты.
_D>Был бы рад рекомендациям по литературе.

Хм...
Peopleware насколько я помню не рассматривает конфликтные ситуации.

недавно рекомендовали Herding cats
вроде бы ее даже перевели на русский.

Еще есть "Программируем командный дух" by Мак-Карти Д.

К сожалению ничего из вышеперечисленного кроме Peopleware не читал.

Здравствуйте, _Dinosaur, Вы писали:

_D>Потеря интереса к выполняемой работе

_D>Причины:
_D>1. Опытному девелоперу поручают рутиную работу, которую может сделать любой менее опытный девелопер.

Вот здесь я не согласен. Не столько с самим пунктом, сколько с его постановкой. Безусловно, рутинная работа вызывает потерю интереса. Но не факт, что менее опытный девелопер будет более охотно ее решать, чем более опытный. На мой взгляд, подобное разделение работ как раз и чревато возникновением описываемых психологических проблем у менее опытных сотрудников.

MSS>Предлагаю открыть эту тему. Как мне кажется, она играет огромную роль в управлении проектами. Как мне кажется — не меньшую, нежели наличие или отсутствие метрик в разработке например, успешные проекты без метрик — это не редкость, крах компании из-за отсутствия метрик — редкость, а крах компании или провал проекта из-за вот этих проблем — да легко.
Позвольте высказаться по всей проблеме в целом:
1. В большинстве случаев IT-people достаточно самомотивирован. Нам нравится наша работа. Мы получаем кайф от того что ее делаем. Это несомненно большой плюс. Следовательно основные меры в области peopleware должны быть направлены на то чтобы не мешать разработчику эффективно работать (тобишь чтобы он, выражаясь по модному, "был в потоке").

2. Оставшаяся часть (для которых работа это не главное, но работать надо) к счастью достаточно интеллектуальна чтобы с ней можно было договориться "по хорошему". Если работодатель вменяем: ставит разумные сроки, платит нормальную зарплату и т.п. разработчик будет честно отрабатывать свои 5х80, а больше от него и не нужно.

3. Совсем маленькая часть: лентяи, скандалисты, непризнанные гении — в принципе можно и их использовать на благо, но имхо проще уволить.

А теперь по пунктам.

MSS>а) Перфекционизм.
MSS>Человек не просто выполняет задание, а выполняет его не на пять, а "на шесть". Т.е. — сказано, реализовать фичу. Реально там экран кода на Си. Человек же начинает писать абстрактные интерфейсы, наследовать от них на всякий случай несколько разных имплементаций (хотя extensibility в этом месте от него не требовали), ну и так далее.
Часто встречается. решение: 1. объяснить человеку что разработка ПО это компромисс. если не понимает применять административный ресурс: работа по вечерам и выходным (чтобы уложиться в сроки) здорово отрезвляет.

MSS>б) Неряшливость.
Имхо неизлечимое качество. уволнять.

MSS>в) Проблемы с концентрацией внимания.
как правило проявляется когда человек недоволен своими взаимоотношениями с начальством.
Решения: выявлять и беседовать (оговорка: если тем не менее работает 5х8 — все хорошо, пусть сидит себе в ЖЖ дальше). Заставлять оставаться по вечерам и субботам чтобы успеть по планам.

MSS>г) Интриги.
MSS>Превращение совещаний и вообще почти всего общения с руководством в средство конкуренции с коллегами, ради повышения собственного карьерного статуса.
К счастью почти не работает в ИТ т.к. начальство обычно профессионалы и для того чтобы стать начальником сначала надо стать лушим.
По этой же самой причине кстати в ИТ практически не получил распространение такой излюбленный метод всех "карьеристов" как ж...лизание.

MSS>Не так и плохо, если человек реально толков. Ему можно дать фронт работ, где он сможет проявить себя. Но в коллективных мероприятиях с таким человеком тяжело.
Отдельный комментарий: отношения с командой важнее чем гениальность одного исполнителя. Т.е. если человек конфликтен его лучше изолировать от команды, а если не получится — уволить.

MSS>д) Подковерные игры.
См. комментарий к пункту г.

_D>1. Опытному девелоперу поручают рутиную работу, которую может сделать любой менее опытный девелопер.
в большинстве своем программирование это рутина. Или вы не разу не разрабатывали приложения в которых все было известно от начала и до конца и нужно просто сесть и написать.

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

Здравствуйте, dshe, Вы писали:


dshe> Но не факт, что менее опытный девелопер будет более охотно ее решать, чем более опытный.

Согласен, не факт. Вопрос в том, какого сотрудника выберет руководитель для выполнения этой работы.

dshe>На мой взгляд, подобное разделение работ как раз и чревато возникновением описываемых психологических проблем у менее опытных сотрудников.

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

Здравствуйте, Maxim S. Shatskih, Вы писали:


MSS>а) Перфекционизм.
MSS>Человек не просто выполняет задание, а выполняет его не на пять, а "на шесть". Т.е. — сказано, реализовать фичу. Реально там экран кода на Си. Человек же начинает писать абстрактные интерфейсы, наследовать от них на всякий случай несколько разных имплементаций (хотя extensibility в этом месте от него не требовали), ну и так далее.
MSS>Вред: срыв сроков, овердизайн, зачастую снижается способность системы к поддержке (просто лишний код).
MSS>Подсознательные заморочки: желание доказать руководству, что крут, иногда с подтекстом "а ты, руководитель, не знаешь того, что знаю я".

"Солдат без команды -- дурак" (с) А. Лебедь. Давая задачу -- нужно пояснять что такое good enough в понимании дающего задачу. Иначе -- у каждого свое понимание. Второй момент для систем автоматизации бизнеса -- когда прорабатываются требования и делается дизайн ... и это все валидируется -- то можно минимизировать этот вред.
Второй момент -- такое желание возинкает в основном только при работе по найму -- когда эти же люди делают "свои" проекты (свой маленький бизнес) -- такое желание возникает редко -- ибо отвечаешь непосредственно перед заказчиком.

MSS>б) Неряшливость.

MSS>Прямая противоположность пункту "а". Пишется минимум, чтоб заработало вот здесь и сейчас на машине девелопера. Зачастую используются недокументированные фичи платформы, которых лучше бы не трогать.

MSS>Вред: увеличение риска багов, особенно интеропов и работоспособности "на краю" требуемого функционала. Увеличение риска скрытых багов, которые будут найдены много позже бета-тестирования. Усложнение саппорта — зачастую правка баги требует переписывания с нуля "по уму".
MSS>Подсознательные заморочки: "просили быстрее — нате, получите, а что качество будет хуже — так я же вас предупреждал". Зачастую это попытка сложить с себя ответственность в условиях сильного прессинга. В некоторых запущенных случаях человек еще и гордится этим — на тему "я умею быстро решать реальные задачи". Быстро и плохо.

Чтобы использовать недокументированные функции -- нужно еще их знать . Можно назвать это "стилем XP" -- когда делается максимально просто. Главное не забывать про рефакторинг .

MSS>в) Проблемы с концентрацией внимания.
MSS>Пустой треп (типа как тут или — хуже того — в ЖЖ), качание и инсталляция разных софтов "на поиграться", или не имеющая отношения к работе захватывающая и лично очень значимая для сотрудника деятельность — например, активное участие в организации ролевой игры путем трепа по аське или на форумах
MSS>Про вред писать не буду даже. К счастью, лечится оргвыводами в народе называется словом "оболтус". Известное слабое место людей с шизоидным складом характера, которые могут иметь прекрасно пригодные для работы в девелопменте мозги.
MSS>Подсознательная заморочка: "я самый умный и делаю то, что нужно мне, а то, что нужно вам, я буду делать нехотя спустя рукава".

Не лечится обычно. Только операция .

MSS>г) Интриги.
MSS>Превращение совещаний и вообще почти всего общения с руководством в средство конкуренции с коллегами, ради повышения собственного карьерного статуса.
MSS>Подсознательная мотивация: "я самый умный, и потому должен иметь более высокий статус, чем имею сейчас. И во всяком случае мое мнение самое важное".
MSS>Не так и плохо, если человек реально толков. Ему можно дать фронт работ, где он сможет проявить себя. Но в коллективных мероприятиях с таким человеком тяжело.

О ... это вопрос сложный -- т.к. и действительно грамотных людей могут совершенно спокойно "зажимать" в конторе. Тут делается сильное предположение, что коллеги этого человека -- само совершенство. И не имеют комплексов и желания самим стать боссами .


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

Здорово, когда цель компании сформулирована и доведена до всех .

А вообще в
Желание работать

Автор: ykk
Дата: 18.05.05

все написано

Здравствуйте, dshe, Вы писали:

_D>>Причины:
_D>>1. Опытному девелоперу поручают рутиную работу, которую может сделать любой менее опытный девелопер.
D>Вот здесь я не согласен. Не столько с самим пунктом, сколько с его постановкой. Безусловно, рутинная работа вызывает потерю интереса. Но не факт, что менее опытный девелопер будет более охотно ее решать, чем более опытный. На мой взгляд, подобное разделение работ как раз и чревато возникновением описываемых психологических проблем у менее опытных сотрудников.

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

Здравствуйте, Maxim S. Shatskih, Вы писали:

D>>Думаю, что все эти проблемы связаны с естественной человеческой потребностью в самовыражении.

MSS>Да. Вопрос о том, где надо поставить ей границы, чтобы не мешало делу.

>>И возникать они могут, когда руководство относится к девелоперам, как к ресурсу, лишенному индивидуальности.

MSS>Не является ли злоупотребление методиками из PMной литературы — вот именно этим?

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

D>>Что делать руководству? Думаю, что в качестве профилактики может помочь банальное "поощрять инициативность и давать больше свободы девелоперам в принятии решений". Возможно, данная стратегия может "вылечить" и "проблемных" девелоперов в не сильно запущенных случаях.

MSS>А конкретика? на уровне "описание проблемы — методы решения успешные — методы решения провальные"?

Думаю хороший ответ дал на это Генри Форд в своей книге Моя жизнь, мои достижения.
Если в кратце — то работать с людьми — показывать им связь между их действиями и деньгами, которые на этом зарабатывает/теряет компания, рассматривая их как партнёров по бизнесу, пусть младших — но партнёров.

Здравствуйте, Valery A. Boronin, Вы писали:

VAB>Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>>Предлагаю открыть эту тему. Как мне кажется, она играет огромную роль в управлении проектами. Как мне кажется — не меньшую, нежели наличие или отсутствие метрик в разработке например, успешные проекты без метрик — это не редкость, крах компании из-за отсутствия метрик — редкость, а крах компании или провал проекта из-за вот этих проблем — да легко.

VAB>согласен на 100%, это очень важный момент

MSS>>Итак. Какие мы знаем проблемы в психологии взаимоотношений руководства с девелоперами, которые могут выйти боком?

VAB><...>

MSS>>Приглашаю всех внести свой вклад в тему.

VAB>е) Неадекватная оценка ситуации кем-либо в паре начальник-подчиненный

VAB>Допустим сотрудник сделал уникальную\классную (пусть на его взгляд даже) работу и не получил не то что бонуса\повышения, а хотя бы поощрения словом от тех кто реально в курсе его работы (а если это не его босс то кто?). Есс-но в любой работе можно найти к чему придраться, но также и можно (при желании) найти и за что похвалить.

Согласен. Людей нужно хвалить и поддерживать.
Однако тут вполне может быть вариант a) — когда код на 6+, но на два месяца позже срока... Тут нужно сначала похвалить за великолепную работу, а потом отдельно оценить её последствия.

VAB>Вред: Не получая своего рода адекватной обратной связи, сотрудник просто теряет желание вкладывать в проект душу, хотя качество кода возмжно и останется на приемлемом уровне или даже выше среднего уровне, но для компании тут мне кажется убыток прямой и весьма серьезный может получиться (можно назвать это даже упущенная выгода? человек выдает значительно меньше 100% от своих возможностей, что то из серии д) — "раз меня никто не ценит, работаю строго по КЗОТ".
VAB>)

VAB>подобная же история когда сотрудник делает "хороший\нормальный" на его взгляд код, а босс "(не)обоснованно придирается и лажает", т.е. не может убеить сотрудника что у него проблемы. Тут начинает назревать конфликт, который рано или поздно проявится (в зависимости от темпераментов и обстоятельств)

VAB>посему надо чтобы была обратная связь, а не только спустил таймлайн сверху и проверяешь результат

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

Здравствуйте, AndreyFedotov, Вы писали:

AF>Согласен. Людей нужно хвалить и поддерживать.
AF>Однако тут вполне может быть вариант a) — когда код на 6+, но на два месяца позже срока... Тут нужно сначала похвалить за великолепную работу, а потом отдельно оценить её последствия.

согласен, о том и писал.

только к приведеному примеру есть ремарка: а где был руководитель эти 2 мес? его в таком случае стоит тоже оценить за такие последствия.

VAB>>посему надо чтобы была обратная связь, а не только спустил таймлайн сверху и проверяешь результат

AF>Обратная связь должна быть в обе стороны. Если работник делает нечто, что никому не нужно — игнорируя мнение руководства — проку так же не будет.
это у Маскима описано было, лень смотреть в каком случае
а у себя я недаром начал фразой
е) Неадекватная оценка ситуации кем-либов паре начальник-подчиненный
т.е. именно это и имел ввиду что обратная связь должна быть двусторонней, наверное стоило это отдельно выделить, что сейчас и делаю

Здравствуйте, Valery A. Boronin, Вы писали:

VAB>Здравствуйте, AndreyFedotov, Вы писали:

AF>>Согласен. Людей нужно хвалить и поддерживать.
AF>>Однако тут вполне может быть вариант a) — когда код на 6+, но на два месяца позже срока... Тут нужно сначала похвалить за великолепную работу, а потом отдельно оценить её последствия.

VAB>согласен, о том и писал.

VAB>только к приведеному примеру есть ремарка: а где был руководитель эти 2 мес? его в таком случае стоит тоже оценить за такие последствия.

Согласен. Но это скорее теория. На практике если реализовать идею о "большем доверии к девелоперам" как раз таки примерно месяца на два и можно дело затянуть перед цугундером...

VAB>>>посему надо чтобы была обратная связь, а не только спустил таймлайн сверху и проверяешь результат

AF>>Обратная связь должна быть в обе стороны. Если работник делает нечто, что никому не нужно — игнорируя мнение руководства — проку так же не будет.
VAB>это у Маскима описано было, лень смотреть в каком случае
VAB>а у себя я недаром начал фразой
VAB>е) Неадекватная оценка ситуации кем-либов паре начальник-подчиненный
VAB>т.е. именно это и имел ввиду что обратная связь должна быть двусторонней, наверное стоило это отдельно выделить, что сейчас и делаю

Руководитель то не девелопер. Он может быть просто не в состоянии адекватно оценить нужно или не нужно было тратить на задачу столько времени. Сразу предвижу два наиболее популярных возражения. "Поставьте руководителем того, кто разбирается в разрабоке" или "руководитель может привлечь для оценки того, кто разбирается". Однако и то и другое — это как раз та самая командно-контроллирующая модель, которую так радует собравшиехся, как девелоперы, так и менеджеры.
В её основе мысль о том, что есть "мудрый" (или не очень) менеджер, который должен контроллировать каждый шаг девелоперов, указывать им правильный путь и возвращать на него, если эти неразумные с него собьются. В свою очередь у менеджеров есть свой менеджер — повыше рангом и т.д. Всем красивая идея. Есть у неё правда несколько существенных недостатков. Во-первых всё проконтроллировать нельзя. Во-вторых для того, что бы полноценно контроллировать разработчиков, менеджер должен знать и уметь в разработке — больше. В итоге получаем, что даже для руководством маленькой группой нужен гений, а для руководством большой — сверх человек.
Такая ситуация воникает, если мы пытаемся ограничивать степени свободы людей — будь то менеджеры или сотрудники, пытаясь разными способами (путём инструкций или рапоряжений) добиться того, что бы они действовали единственно правильным образом (о том, что он может быть вовсе и не правилен я вообще умолчу). Неявным образом подразумевается, что наши партнёры (менеджеры, сотрудники) не в состоянии сами правильно понять что и как нужно делать и даже не в состоянии понять нас — и тем более реализовать это оптимальным образом (а иначе зачем проверять их или сковывать кучей инструкций?).
Однако есть и другой путь. Он состоит в том, что бы доводить до людей цели, которые они преследуют, учитывать их мнение и вовлекать в процесс принятия решений. То есть строить отношения таким образом, что бы каждый человек на фирме видел себя частью единого целого, а так же видел — какую цель преследует его деятельность и для чего она нужна. Опыт компаний, которые реализовали подобный подход на практике показывает, что это наиболее креативный и эффективный путь, поскольку люди действуют добиваясь целей согласованных с целями компании, своей команды и т.д. Конечно, по-прежнему есть риск ошибиться и цена ошибки может быть велика. Но, по скольку в целом большинство людей работают согласованно (с целями компании) и, как правило, чаще всего инициативы дают положительный результат, общая эффективность системы в целом — гораздо выше. Особенно если учесть, что в командно-контроллирующей модели очень многие, а иногда — большинство — работают против компании, приследуя какие угодно цели, кроме тех, что нужны бизнесу...

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Предлагаю открыть эту тему. Как мне кажется, она играет огромную роль в управлении проектами. Как мне кажется — не меньшую, нежели наличие или отсутствие метрик в разработке например, успешные проекты без метрик — это не редкость, крах компании из-за отсутствия метрик — редкость, а крах компании или провал проекта из-за вот этих проблем — да легко.

Максим, было очень приятно увидеть ваше сообщение на форуме! Дело в том, что я давно интересуюсь вопросами
мотивации в IT-среде (программисты, тестировщики).
Это очень здорово, что вы составили классификацию.
Сам я работаю менеджером проектов и все пункты встречал/встречаю каждый день. Имею и техническое и психологическое
образование. В настоящее время пытаюсь активно применять психологические знания/навыки в управлении.
К сожалению "проектного" образования у меня нету, но удалось перенять опыт управления по PIM BOK стандарту у
старшего коллеги (и по статусу и по опыту). К сожалению то, что увидел — "кнут и пряник", "кнут" для программиста,
а "пряник" — дял менеджера Эта метода хоть и работает (для бизнеса), но совершенно "нечеловенча".
С удовольствием приму участие в беседе по этой теме.
И приглашаю всех интересующихся проблематикой на сайт "IT по-человечески", который сделан для программистов, менеджеров, психологов и всех, кого волнуют вопросы "мета-уровня": что такое профессия программиста, менеджера, какие навыки, знания и умения требуются от человека, как сохранить физическое и душевное здоровье при работе с компьютером, etc. — IT по-человечески.
Также приглашаю всех заинтересованных на форум: Форум сайта IT по-человечески.

MSS>Приглашаю всех внести свой вклад в тему.
С Удовольствием.