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

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

а) Перфекционизм.
Человек не просто выполняет задание, а выполняет его не на пять, а "на шесть". Т.е. — сказано, реализовать фичу. Реально там экран кода на Си. Человек же начинает писать абстрактные интерфейсы, наследовать от них на всякий случай несколько разных имплементаций (хотя 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>Приглашаю всех внести свой вклад в тему.
С Удовольствием.

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

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

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

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

AF> Руководитель то не девелопер. Он может быть просто не в состоянии адекватно оценить нужно или не нужно было тратить на задачу столько времени.

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

AF> В итоге получаем, что даже для руководством маленькой группой нужен гений, а для руководством большой — сверх человек.

а не надо все и вся контролировать — это выглядит (как вариант) как тотальное недоверие или поиск зацепок\компромата на сотрудника для последующего полоскания при удобном случае перед командой\руководством (дабы не обошел по карьерной лестнице или просто про запас)

быть электровеником тоже не нужно, просто нужно или быть техспецом или иногда спрашивать такого человека о ситуации в команде не только с проблемными и отличившимися ребятами, а и с бойцами невидимого фронта\рабочими лошадками: темпераменты разные, один без похвалы скисает, другой после нагоняя только раскочегаривается. Один раз-два стерпит неоценку усилий или отмечание успехов соседа который просто не забывает уделить внимание своего рода PR самого себя при не лучшем кач-ве объеме работы, другой c типом хар-ра "вулкан" может 3 года копить а потом ни с того ни с сего таааакое выплеснуть...

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

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

ага, красиво, не согласиться и не поверить невозможно
и не увлечься если тебе еще нет 25 тоже

если у вас в 20 лет не вызывают горячее одобрение либерально-радикальные идеи, значит у вас нет сердца.
если в 40 лет вы еще не стали консерватором, значит у вас нет мозгов (с) Черчилль

Кстати я согласен несмотря на иронию

наверное все стараются, но тут легче сказать чем сделать, даже при полном искреннем желании (благими намерениями...)

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

разве нет?!

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

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

Но и Максим не зря запустил тему, хорошо видно что гладко все только на бумаге.

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

S>Я бы добавил еще е:
S>склонение руководства к использованию техологий, которые либо бесполезны в данном проекте и для фирмы, либо вообще вредны, однако позволяют конкретному девелоперу за счет оплаченного рабочего времени изучить "модную" технологию. основная ель — пополнение собстенного "портфолио", позволяющего найти более высокооплачиваемую работу.

Обычно скорее наоборот -- налицо незнание технологий в компаниях занимающихся разработкой софта -- т.к. руководство не желает тратиться на "эти новомодные штучки". Типа -- инженер, высшее образование есть -- сам разбереться (а в планы время на самостоятельное разбирательство естественно никто не включал .
В качестве примера -- использование (точнее неиспользования) object-persistent frameworks и вообще laers в проектах, где велик риск изменения бизнес-логики. Я так знаю одну такую контору, которая кричит что подразделения по разработке софта (пишут на Java) убыточно. А присмотреться к проектам -- то сами выдумывают системы класса a-la Message Queue, то бизнес-логику в JSP засаживают ... а спрашиваешь про Hibirnate или WebSphere MQ и пр. -- оказывается, что и не слышали ..., а если и слышали -- то как в анекдоте:
-- Почему вы пилите тупой и ржавой пилой -- это ж неудобно и медленно?
-- Дык некогда точить -- пилить надо!

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

DAN>Часто встречается. решение: 1. объяснить человеку что разработка ПО это компромисс.
Правильное решение.

DAN>если не понимает применять административный ресурс: работа по вечерам и выходным (чтобы уложиться в сроки) здорово отрезвляет.
На мой взгляд, неверный ход. Проблему не решит, а новых проблем создаст предостаточно.
Никогда нельзя решать проблемы за счет личного времени сотрудников!
А если вы предлагаете оплачивать эти самые вечера и выходные, то некоторые девелоперы могут использовать это для увеличения своего заработка (пояснения, думаю, не нужны).

MSS>а) Перфекционизм.

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

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

MSS>г) Интриги.

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

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

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

IMHO, все эти факторы показывают, что существуют проблемы в менеджменте.
1. Я считаю, что в команде не достигнуто общего видения целей компании/проекта и понимания того, что нужно делать, как и когда для того, чтобы сделать все на высшем уровне и в заданые сроки + с определенным функционалом. Донесение целей и политики в руках менеджера проекта или Team Leader'a, который сможет транслировать слова бизнес-директора в разумы технических личностей.
Проработанный и донесенный до ВСЕХ членов стратегический план развития и цели проекта напрямую влияют на уменьшение влияния факторов, которые Вы указали.
2. Второй момент — это кадровая политика. На динамические в развитии проекты не стоит брать на место девелопера супер-гуру технаря. Таких людей я бы группировал в отдел Research, который разрабатывает обособленные концепции, а потом уж их применять в конкреитных проектах (High-Tech). А вот девелоперов с задатками менеджеров ("бизнес-девелоперов") бросал бы на динамику проекта.

DAN>>если не понимает применять административный ресурс: работа по вечерам и выходным (чтобы уложиться в сроки) здорово отрезвляет.
H>На мой взгляд, неверный ход. Проблему не решит, а новых проблем создаст предостаточно.
H>Никогда нельзя решать проблемы за счет личного времени сотрудников!
H>А если вы предлагаете оплачивать эти самые вечера и выходные, то некоторые девелоперы могут использовать это для увеличения своего заработка (пояснения, думаю, не нужны).
Я ж написал "если не понимает" (что ПО это компромисс).
Естественно требование выйти вечером/в субботу должно сопровождаться примерно следующим объяснением: "есть требования, есть планы, есть сроки. То что ты сделал навредило проекту с одной стороны, ты нарушил требования/планы, будь добр ущерб который ты проекту нанес устрани."

С другой стороны у PMа не так уж много рычагов воздействия на разработчика. У нас например системы штрафов не существует, а некоторым просто объяснять — не действует.

У нас оплачиваются переработки, но это совсем другая история: проверяется чем человек в это время занимался и оплачивается только если он грубо говоря за 50 часов в неделю сделал больше чем сделал бы за 40.

A>IMHO, все эти факторы показывают, что существуют проблемы в менеджменте.
Не стоит забывать что мотивация менеджеров и мотивация девелоперов — две большие разницы.
Девелопер может просто напросто игнорировать, то что ему будут рассказывать про "общее видение целей компании/проекта" и т.п., особенно если это выльется для него в лишний гемморой (например timesheet-ы вести, или все исключения тестировать)

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

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

A>>IMHO, все эти факторы показывают, что существуют проблемы в менеджменте.
DAN>Не стоит забывать что мотивация менеджеров и мотивация девелоперов — две большие разницы.
DAN>Девелопер может просто напросто игнорировать, то что ему будут рассказывать про "общее видение целей компании/проекта" и т.п., особенно если это выльется для него в лишний гемморой (например timesheet-ы вести, или все исключения тестировать)

Для того чтобы не игнорировали нужно правильно доносить. А если человек игнорирует — значит ему наплевать на компанию, а соответсвенно сотрудников, в которой он работает. Он одиночка и не командный игрок! Вы считаете это нормальным?

DAN>Насчет кадровой политики — а насколько часто вы можете это себе позволить? В смысле вот этих туда, вот этих сюда? Это надо иметь много людей, много _разных_ проектов, и много кандидатов, чтобы было при отборе из кого выбирать. Это реально?

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

A>Для того чтобы не игнорировали нужно правильно доносить. А если человек игнорирует — значит ему наплевать на компанию, а соответсвенно сотрудников, в которой он работает. Он одиночка и не командный игрок! Вы считаете это нормальным?
К сожалению жизнь не делится на черное и белое. И идеальные сотрудники (как и идеальное начальство) встречаются крайне редко.
Поэтому нужен контроль, нужны методы имени товарища Пряника, разработанные совместно с товарищем Кнутом, timesheet-ы, code review и т.п.

Если бы все было так просто, то все проблемы решались бы примерно следующим образом:
PM: — "ребята! пишите код без багов!"
Dev: — "Хорошо!"
QA: понуро уходят писать заявление об увольнении.

Или:
PM: — "доношу до вашего сведения, код надо писать без багов!"
DEV:- "хорошо!"
PM (через два дня): — у тебя баг в коде! Уволен!

DAN>>Насчет кадровой политики — а насколько часто вы можете это себе позволить? В смысле вот этих туда, вот этих сюда? Это надо иметь много людей, много _разных_ проектов, и много кандидатов, чтобы было при отборе из кого выбирать. Это реально?
A>Один человек в разные моменты времени может выполнять несколько ролей. Сегодня он по плану разрабатывает, а завтра reseach'ем занимается. Главное таких людей найти!
Далеко не всегда компания может потянуть найм таких высококвалифицированных разработчиков. Это опять же из разряда "лучше быть богатым и здоровым, чем бедным и больным"

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

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

DAN>>>если не понимает применять административный ресурс: работа по вечерам и выходным (чтобы уложиться в сроки) здорово отрезвляет.
H>>На мой взгляд, неверный ход. Проблему не решит, а новых проблем создаст предостаточно.
H>>Никогда нельзя решать проблемы за счет личного времени сотрудников!
H>>А если вы предлагаете оплачивать эти самые вечера и выходные, то некоторые девелоперы могут использовать это для увеличения своего заработка (пояснения, думаю, не нужны).
DAN>Я ж написал "если не понимает" (что ПО это компромисс).
DAN>Естественно требование выйти вечером/в субботу должно сопровождаться примерно следующим объяснением: "есть требования, есть планы, есть сроки. То что ты сделал навредило проекту с одной стороны, ты нарушил требования/планы, будь добр ущерб который ты проекту нанес устрани."
Наверно, я неверно расставил акценты. Меня поразило с какой простотой ответ "работать внеурочно" вы использовали для решения проблемы (два упоминания на пять пунктов) причем в довольно бескомпромисной форме. Ведь человеку предлагается по сути всего один вариант решения — поработать внеурочно сейчас и не отходя от кассы — если я правильно понял. А если мы говорим о ситуации, когда срыв плана оказался довольно ощутимым, нужно сначала разобратся, чьи действия/бездействия к этому привели. РМ или тимлид должны знать плюсы и минусы своих разработчиков и принимать привентивные меры дабы не допускать таких ситуаций. Не нужно об этом забывать.

DAN>С другой стороны у PMа не так уж много рычагов воздействия на разработчика. У нас например системы штрафов не существует, а некоторым просто объяснять — не действует.
Возможно, тогда это не те люди, которые вам нужны на проекте? Возможно такого человека лучше подключить к проекту, где его особенности будут на пользу проекту + проводить ненавязчивое (полуофициальное), так сказать, "перепостроение" мышления.

H>Наверно, я неверно расставил акценты. Меня поразило с какой простотой ответ "работать внеурочно" вы использовали для решения проблемы (два упоминания на пять пунктов) причем в довольно бескомпромисной форме. Ведь человеку предлагается по сути всего один вариант решения — поработать внеурочно сейчас и не отходя от кассы — если я правильно понял.
Я наверное тоже неверно расставил акценты. Внеурочная работа по приказу это крайне редкое явление. Крайняя мера. Кранее этой меры может быть только увольнение. Потому как в большинстве случаев команда вменяемая.

Расскажите, пожалуйста, с вашей стороны как поступать в такой гипотетической ситуации:
1. Есть требования, планы и сроки. Сроки жесткие. Грубо говоря речь идет о том чтобы хотя бы успеть закончить основные фичи.
2. Разработчик в курсе вышеперечисленных условий.
3. Разработчик вместо основного функционала занимается рющечками. Ну вот очень хочется ему такую фичу сделать. Или вместо забивания костыля (а иногда и такое приходится делать из расчета переделать в следующей версии) затевает рефакторинг на полпроекта.
4. То что он сделал надо:
— ревьювить,
— тестировать,
— документировать.
Грубо говоря день работы такого девелопера стоит проекту:
1 день его работы + 1 день который он должен был потраить на совсем другое + 0.5 дня работы тестера + 0.25 дня на ревью + 0.25 дня на документирования = 3 человеко/дня.

Ваши действия в данной ситуации? Объяснить еще раз? А потом еще раз? за 3 таких объяснения набегает грубо говоря 2 недели.

DAN>>С другой стороны у PMа не так уж много рычагов воздействия на разработчика. У нас например системы штрафов не существует, а некоторым просто объяснять — не действует.
H>Возможно, тогда это не те люди, которые вам нужны на проекте? Возможно такого человека лучше подключить к проекту, где его особенности будут на пользу проекту + проводить ненавязчивое (полуофициальное), так сказать, "перепостроение" мышления.
К сожалению у меня нет возможности с легкостью перемещать человека из команды в команду из проекта в проект. Решающую роль тут играет порог вхождения, технические скиллы и т.п.
К тому же я не совсем понимаю как перфекционизм может проявляться в одном проекте и не проявляться в другом? (это было первое упоминание)

Ситуация когда человек проводит время в ЖЖ — это просто саботаж (это было второе упоминание).
Ваши действия в данном случае?

savaDAN wrote:
>
> 3. Разработчик вместо основного функционала занимается рющечками. Ну вот
> очень хочется ему такую фичу сделать. Или вместо забивания костыля (а
> иногда и такое приходится делать из расчета переделать в следующей
> версии) затевает рефакторинг на полпроекта.
> 4. То что он сделал надо:
> — ревьювить,
> — тестировать,
> — документировать.

Заставить откатывать такие изменения.

Mikhail

>> 4. То что он сделал надо:
>> — ревьювить,
>> — тестировать,
>> — документировать.

K>Заставить откатывать такие изменения.
Это тоже несомненно используется. но день тем не менее потерян.

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

H>>Наверно, я неверно расставил акценты. Меня поразило с какой простотой ответ "работать внеурочно" вы использовали для решения проблемы (два упоминания на пять пунктов) причем в довольно бескомпромисной форме. Ведь человеку предлагается по сути всего один вариант решения — поработать внеурочно сейчас и не отходя от кассы — если я правильно понял.
DAN>Я наверное тоже неверно расставил акценты. Внеурочная работа по приказу это крайне редкое явление. Крайняя мера. Кранее этой меры может быть только увольнение. Потому как в большинстве случаев команда вменяемая.
Такое отношение вполне поддерживаю.

DAN>Расскажите, пожалуйста, с вашей стороны как поступать в такой гипотетической ситуации:
DAN>1. Есть требования, планы и сроки. Сроки жесткие. Грубо говоря речь идет о том чтобы хотя бы успеть закончить основные фичи.
DAN>2. Разработчик в курсе вышеперечисленных условий.
DAN>3. Разработчик вместо основного функционала занимается рющечками. Ну вот очень хочется ему такую фичу сделать. Или вместо забивания костыля (а иногда и такое приходится делать из расчета переделать в следующей версии) затевает рефакторинг на полпроекта.
DAN>4. То что он сделал надо:
DAN> — ревьювить,
DAN> — тестировать,
DAN> — документировать.
DAN>Грубо говоря день работы такого девелопера стоит проекту:
DAN>1 день его работы + 1 день который он должен был потраить на совсем другое + 0.5 дня работы тестера + 0.25 дня на ревью + 0.25 дня на документирования = 3 человеко/дня.
DAN>Ваши действия в данной ситуации? Объяснить еще раз? А потом еще раз? за 3 таких объяснения набегает грубо говоря 2 недели.
О ситуации с такими условиями мне сложно говорить с уверенностью (слава Богу пока жил без них).
Тут нужно оговорить два варианта: говорим о программисте, работающем на проекте довольно давно, и о новичке на проекте/в организации (на испытательном сроке).
В обоих случаях руководитель виновен на 50%.
В первом случае, если такие ситуации начали проявлятся некоторое времени назад, нужно проанализировать почему их не было ранее. Если проявляются всё время работы в фирме — нужно было внимательнее смотреть на работу человека во время испытательного срока (ошибка руководителя).
Во втором случае при отсутсвии реакции нужно раставатся.

DAN>>>С другой стороны у PMа не так уж много рычагов воздействия на разработчика. У нас например системы штрафов не существует, а некоторым просто объяснять — не действует.
H>>Возможно, тогда это не те люди, которые вам нужны на проекте? Возможно такого человека лучше подключить к проекту, где его особенности будут на пользу проекту + проводить ненавязчивое (полуофициальное), так сказать, "перепостроение" мышления.
DAN>К сожалению у меня нет возможности с легкостью перемещать человека из команды в команду из проекта в проект. Решающую роль тут играет порог вхождения, технические скиллы и т.п.
Типичная проблема для многих оргенизаций

DAN>К тому же я не совсем понимаю как перфекционизм может проявляться в одном проекте и не проявляться в другом? (это было первое упоминание)
Рискну выразить предположение, что причиной подобного поведения при реализации задания является неудовлетворенность программиста. Есть люди, которые довольно плохо себя чувсвуют при жостких условия работы, люди любящие креатив. Им для раскрытия своего потенциала необходимо больше свободы действий. В такой ситуации полностью раскрывается их потенциал.
При "разборе полетов" будет не лишним выянить это.
З.Ы. Сам такой. Был в аналогичной ситуации: работа нудная, креатива никакого, вот от скуки и пришел к подобной ситуауции. Проблему решил сменой работы. В итоге я доволен, бывший работодатель тоже не в обиде.

DAN>Ситуация когда человек проводит время в ЖЖ — это просто саботаж (это было второе упоминание).
DAN>Ваши действия в данном случае?
Узнать, чего человеку не хватает. Если просто разгильдяй — нужно увольнять при первой же возможности (имеется в виду, что это может быть нецелесообразно именно в данный момент при нехватке ресурсов). Если же есть какое-то внутренне недовольство, но вполне/частично обоснованое — попытатся решить.

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

A>>Для того чтобы не игнорировали нужно правильно доносить. А если человек игнорирует — значит ему наплевать на компанию, а соответсвенно сотрудников, в которой он работает. Он одиночка и не командный игрок! Вы считаете это нормальным?
DAN>К сожалению жизнь не делится на черное и белое. И идеальные сотрудники (как и идеальное начальство) встречаются крайне редко.
DAN>Поэтому нужен контроль, нужны методы имени товарища Пряника, разработанные совместно с товарищем Кнутом, timesheet-ы, code review и т.п.

DAN>Если бы все было так просто, то все проблемы решались бы примерно следующим образом:
DAN>PM: — "ребята! пишите код без багов!"
DAN>Dev: — "Хорошо!"
DAN>QA: понуро уходят писать заявление об увольнении.

DAN>Или:
DAN>PM: — "доношу до вашего сведения, код надо писать без багов!"
DAN>DEV:- "хорошо!"
DAN>PM (через два дня): — у тебя баг в коде! Уволен!

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

Кроме того, начинать всегда лучше с себя. Если у менеджера в голове бардак то как он сможет ясно и чётко донести до девелоперов цели их работы и расставить приоритеты? Это всё равно что ожидать от пьяного в стельку глубокого стратегического мышления. Менеджер сам должен ясно и чётко предствалять себе — чего он хочет, каковы его цели, что он хочет получить от каждого из девелоперов, расставить приоритеты (и уметь быстро соображать в меняющихся обстоятельствах). Вот тогда он сможет и донести свою мысль до разработчиков и убедиться в том, что его правильно поняли.

DAN>>>Насчет кадровой политики — а насколько часто вы можете это себе позволить? В смысле вот этих туда, вот этих сюда? Это надо иметь много людей, много _разных_ проектов, и много кандидатов, чтобы было при отборе из кого выбирать. Это реально?
A>>Один человек в разные моменты времени может выполнять несколько ролей. Сегодня он по плану разрабатывает, а завтра reseach'ем занимается. Главное таких людей найти!
DAN>Далеко не всегда компания может потянуть найм таких высококвалифицированных разработчиков. Это опять же из разряда "лучше быть богатым и здоровым, чем бедным и больным"
Тогда ей нуджно ставить подходящих людей (квалифицированы они или же просто хорошо соображают) на ключевые позиции и наделять их адекватными полномочиями.
Или вы надеетесь, что компания целиком состоящая из людей, которые не квалифицированы или плохо соображают — что они делают — сможет вести себя эффективно и адекватно — в том числе и по отношению к процессу разработки?

DAN>PS: т.е. мне в рамках данного топика куда как интересней услышать как обычного (среднестатистического) разработчика убедить работать хорошо, а то что с классными разработчиками все будет классно — никто не сомневается.
Ставить его в условия, когда он будет в тонусе и ясно и чётко доносить до него, что нужно сделать — обязательно выслушивая его и помогая ему использовать его творческий потенциал так, что бы это сочеталость с интересами бизнеса — теми результатами, которые желательно было бы получить.

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

DAN>Ситуация когда человек проводит время в ЖЖ — это просто саботаж (это было второе упоминание).
Ты уверен, что можно находиться "в потоке" 5*8?

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

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

+1 Согласен, и даже более того, я бы сказал основную

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

Я думаю дело не в подробном анализе каждой проблемы. Роль человека, чтоящего над девелоперами, имхо, похожа во многом на роль тренера в команде (для примера футбольной). Одным из главных качеств, как на мой взгляд, является умение оценить вклад каждого человека в проект, умение провести с ним беседу и настроить в нужном ключе, поддержание рабочей атмосферы, которую легко нарушить, но нелегко воссоздать. А мотивация она у каждого своя. Кому-то денег, кому-то интересные задачи, кому-то 31 день оплачиваемого отпуска, кому-то вермя на реализацию своих идей. Это тоже надо понимать и предоставлять.

Вот, как мне кажется, отличный пример психологической мотивации:

Был случай, когда Демьяненко, Бессонов и еще кто-то приехали на базу сборной в несколько помятом состоянии. Лобановский вызвал их, дал, как говорится, на орехи. А на установке Валерий Васильевич сказал: "А повязочку, Толя, придется отдать Ринату Дасаеву". Демьяненко был готов сквозь землю провалиться. Далее Лобановский продолжил: "Кстати, Толя, ты на какой позиции сегодня играешь?". — "Левого защитника, Васильич".- "Нет, Толя, ты сегодня будешь играть левого защитника, полузащитника и нападающего". Демьяненко вышел — и забил гол.
После матча Лобановский сказал: "Толя, такой ты мне нравишься. Ринатик, верни повязку".

P. S. Ты случаем в Киевском Динамо не подрабатываешь в свобное время?

DAN>>Ситуация когда человек проводит время в ЖЖ — это просто саботаж (это было второе упоминание).
SC>Ты уверен, что можно находиться "в потоке" 5*8?
Нет конечно.
Но быть не в потоке можно тоже по разному: можно книжки по ИТ читать, можно RSDN (опять же много полезного), а можно например на love.mail.ru или irc тусоваться.
А вообще, если человек работает, успевает по планам и т.п. — пусть себе делает что хочет, как хочет и когда хочет.
Единственно в чем он теряет это в перспективе/карьерном росте, но это уже личное дело каждого.

Цель.
На многочисленных мозговых штормах я заметил странную особенность человеческого сознания уходить от решения конкретного вопроса, и тогда приходиться «спускать» разработчиков на землю словами: а что это нам даст, а приблизит ли это нас к цели, а собственно, кто-то помнит, зачем мы здесь собрались?
Итак, господа разработчики и руководители проектов, давайте определимся с целью данного обсуждения. Что же мы хотим получить в результате? После изучения всего вышесказанного позволю себе сделать вывод: обсудить некоторые тезисы, которые не совсем совпадают с нашим собственным представлением. Это все здорово, но как-то размыто. Поэтому предлагаю более реальную цель: ответить себе на два вопроса, чем я хочу заниматься и ради кого я работаю?
Термины.
Если я говорю хороший разработчик, хороший руководитель – то это обозначает, что люди адекватны (логическое мышление, ответственность и т.п.) и люди заинтересованный в результате (материальное и моральное удовлетворение).
Проект – бывают разные, большие и не очень, критичные и так себе, поэтому предлагаю под эти термином понимать временной континуум примерно в 1 год, когда основная часть усилий команды тратиться на создание ПО для конкретного рынка или заказчика.
Руководитель проекта. Прежде все я имею в виду руководителей софтверных проектов с типичными обязанностями менеджера (планирование, координация, контроль, обучение, риски, коммуникации и т.п.). Сфера ИТ включает в себя так же системное администрирование, у этой сферы своя специфика, во многом не совпадающая с софтверной, поэтому руководство админами здесь не упоминается.
Самое главное правило. Правило дающее ответ на вопрос «ради кого я работаю?».

Суть.
Сколько нужно времени на взращивание хорошего разработчика? Я имею в виду человека пришедшего на работу по окончанию ВУЗа (или же на последнем курсе) и имеющего базовые представления в программировании. В большинстве своем это 2 года. Пол года на то чтобы человек определился, куда он попал и чего от него ждут. Еще пол года на совершенствование знаний и навыков. Добавим к этому еще год и получим хорошего разработчика. Да, бывают исключения… но редко.
А сколько времени необходимо на выращивание руководителя проекта? Отвечу – 10 лет. Скорее всего, услышу много возражений, и правильно! Только для того, чтобы понимать, что ты все еще плохой руководитель необходимо потратить несколько лет. Все же я попробую обосновать цифру: 1 год – полный нуль, 2 – ага, я руковожу людьми, я принимаю решения, на мне огромная ответственность. 3..4 – совершенствование знаний, 5..6 – проект = команда, учимся работать с людьми, 7-10 – зрелость, опыт. За это время руководитель успевает поработать в среднем в 7 проектах. Что не так уж и много, но вполне достаточно чтобы в 35 лет осознать, что появился опыт, что люди и проекты бывают разные и каждому случаю нужен свой индивидуальный подход. И что серебряной пули не существует.
Не зря я задавал вопрос о времени. Ни какие книги, ни какие курсы не дадут того, что даст опыт. Опыт = время. Время = жизнь (ВАША жизнь!). Итак, определяйтесь, хотите ли вы стать руководителем (конечно же хорошим) или все же остаться хорошим разработчиком.
Тезисы.
Все же высказанные выше мысли (на форуме) задели и меня, поэтому попытаюсь ответить на них.

О восприятии.
Восприятие руководителем людей в команде как "винтиков". Каюсь, грешен. Сам однажды не сдержавшись, высказал такое своему разработчику. Хотя нет, не каюсь, в той ситуации это было сказано по делу и поделом. Поверьте, когда разработчик увольняется и при это называет в качестве причины «лидер заставлял исправлять баги», сдерживаться не хочется (но это классика звездной болезни, а о таких тут не говорят).
Конечно же, когда я говорю о «винтиках», то имею в виду, прежде всего себя. Ребята, я ваш руководитель, но я ничем не отличаюсь от вас, я в той же самой упряжке. Работа может нравиться и не нравиться (так же как и профессия), но если ты «подписался» ее сделать, то старайся оставлять эмоции за дверью офиса. И не трать энергию на самоедство или демотивацию, она еще пригодиться для выполнения рутинной работы.

Об истоках и харизме.
Откуда берутся руководители проектов? Как верно было замечено это бывшие хорошие разработчики. Из личного опыта могу судить, что приходящие из других сфер могут ужиться в команде при одном условии: архитектор или лидер разработки заменит ему личный опыт программирования. Нужна ли руководителю харизма и лидерские качества? Да, но зависит от команды. В любом случае, отношения в команде необходимо выстраивать таким образом, чтобы люди работали, а не ждали лидера или милашку. Есть предположение, что при определенной направленности (желании и работе над собой) и то и другое со временем вырабатывается. Судить самому тяжело. Спрошу у команды ( ).

О руководстве, общении.
Не хочу долго распространяться, поэтому коротко. Правило №1: прежде чем менять людей – измени себя. Правило №2: единственный способ снять или предупредить конфликт – общение. Считайте, что общение это часть обучения команды (так же как обучение новой технологии), которое обязан поддерживать руководитель.

Об ответственности.
Тоже кратко. Каждый член команды должен знать: сколько времени ты забираешь у команды (опоздания, личные обстоятельства и пр.), столько она имеет право забрать у тебя. (и при этом не имеет смысла четко подсчитывать по минутам, себе дороже).

О поощрении инициативы и большей свободе для разработчика.
Поощрения – каждому свое, но в 95% случаев это деньги. По собственному опыту могу судить, что никакие социальные программы не прокатывают. Бесплатные обеды и медицинская страховка со спортзалом практически не влияют на принятие решения о смене места работы. Предполагаю, что связано это с двумя факторами: (1) дикий рынок, всегда найдется только что открытый оффшор который срочно, за любые деньги набирает разработчиков; (2) моральный дискомфорт, когда кто-то за туже или худшую работу получает больше. По первому фактору могу лишь сказать, что ходят слухи, что цена производства ПО в Киеве уже выше, чем в Индии. По второму, социальная программа действительно делает ЗП выше, вопрос только на сколько?
Для решения проблем с инициативой необходимо приветствовать идеи. Например, в моей команде все знают: принимаются все идеи даже самые безумные. Здесь важно два момента: (1) ни одна не должна потеряться; (2) человек получит аргументированный ответ, почему его идея хороша или плоха. Не проблема так же, давать разработчику выпустить пар, то есть пусть некоторое время потратит на реализацию своей идеи и сам убедиться хорошо это или плохо. Руководитель в любом случае выигрывает.
Ну и конечно старое доброе правило: хвали прилюдно, ругай с глазу на глаз.

О без умном (это не опечатка) поощрении.
Помните: что поощряем то и имеем. При этом поощрением может случить и безмолвное согласие с безобразием или боязнь ранить чувства человека. Правда – лучшая политика.

О команде и защите.
Я руководитель проекта. Я работаю в команде. Команда = продукт. Благополучие команды = благополучие продукта = благополучие руководителя. Поэтому старайтесь защищать команду в целом и каждого его члена от негативных сторонних влияний. Например, от непроизводственных отделов, от высшего руководства, от заказчика. Отдела кадров, вместо того чтобы отправить своего сотрудника к вам вызывает ваших по одному для подписи какой-то бумаги. Отдел маркетинга задолбал вашего аналитика. Сделайте так, чтобы никто и ничто не причиняло беспокойства вашим ребятам. Люди должны максимально концентрироваться на работе и задача руководителя гарантировать это.

О компании.
Забудьте о компании. Разве вам мало проблем в команде и проблем с заказчиком? Лучшей заботой о компании будет вовремя сданный проект.

Вывод.
Создается впечатление, что рвение разработчиков в «начальство» – это пережиток совковского восприятия мира в стиле «я начальник — значит я крутой» (там немного другая поговорка, но смысл такой). Поверьте старому украинцу, быть руководителем – это не круто, это ГЕМОРОЙ.

Но выбор за вами и помните две вещи:
---------------
(1) Чем бы вы ни занимались необходимо стать лучшим. А чтобы стать лучшим необходимо любить свою работу.
(2) Нельзя быть хорошим программистом и хорошим руководителем – это не совместимо. Или ты руководишь или управляешь. Одно из двух. Как только ты начинаешь программировать — ты перестаешь руководить. Как только перестаешь руководить – начинается хаос. Если стали на стезю руководителя, не сворачивайте и не оборачивайтесь. Программист умер – да здраствует руководитель!
-------------------------------

Ну и последняя фраза, которая должна запомниться (Штирлиц обещал).
Конечно же, в таком маленьком эссе не возможно описать все, всего его много (помните про 10 лет). Но главное должно запомниться мы не только работаем с людьми, но и РАДИ ЛЮДЕЙ. Итак, самое главное правило:
МЫ РАБОТАЕМ ДЛЯ ЛЮДЕЙ


Литература:
"Человеческий фактор" ДеМарко, Листер.
"Программируем командный дух" by Мак-Карти
«Человеческий фактор в программировании» Лари Константин

AF>Ставить его в условия, когда он будет в тонусе и ясно и чётко доносить до него, что нужно сделать — обязательно выслушивая его и помогая ему использовать его творческий потенциал так, что бы это сочеталость с интересами бизнеса — теми результатами, которые желательно было бы получить.

Красиво сказал, нужно записать, а лучше в книге по компетенции менеджеров ИТ-проектов!

VAB>Но и Максим не зря запустил тему, хорошо видно что гладко все только на бумаге.
Что от бумаги, что от обсуждения толк будет лишь в том случае, если суметь применить идеи на практике.
По-моему устраивать обсуждение исходя из предпосылки "на практике это не применимо, потому, что..." несколько странно
Как раз интереснее всего (с моей точки зрения) будет обсудить — что и как можно сделать именно в реальных (а не идеализированных — книжных) условиях, обменяться опытом, поэкспериментировать и расказать о результатах

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

DAN>С другой стороны у PMа не так уж много рычагов воздействия на разработчика. У нас например системы штрафов не существует, а некоторым просто объяснять — не действует.
Это как объяснять
Кроме того если человек "не понимает" — возможно, что у него есть мотив не понимать. Возможно он хочет делать что-то другое или не понял, зачем это надо.

DAN>У нас оплачиваются переработки, но это совсем другая история: проверяется чем человек в это время занимался и оплачивается только если он грубо говоря за 50 часов в неделю сделал больше чем сделал бы за 40.
Тут есть сложность. Кто определяет сроки. Если сам разработчик — это одно (да и в этом случае он может ошибаться), если же кто-то за него — то на выходных работать должны как минимум оба. Продуктивность то у всех разная. Кроме того частенько бывает ситуация, что менеджер просто не видит "мелких" деталей, которые возникают при реализации его гениальных замыслов и не понимает "что там делать столько времени"

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

VAB>>Но и Максим не зря запустил тему, хорошо видно что гладко все только на бумаге.
AF>Что от бумаги, что от обсуждения толк будет лишь в том случае, если суметь применить идеи на практике.
AF>По-моему устраивать обсуждение исходя из предпосылки "на практике это не применимо, потому, что..." несколько странно
я не говорил что неприменимо — но в такой формулировке красивой был изложен тезис что напомнило что-то из серии "А давайте чтобы мир во всем мире!". Связи с реальностью немного захотелось добавить — и добавил в пред сообщении

AF>Как раз интереснее всего (с моей точки зрения) будет обсудить — что и как можно сделать именно в реальных (а не идеализированных — книжных) условиях, обменяться опытом, поэкспериментировать и расказать о результатах
Хорошо, но тут не бывает совета на все случаи, тогда надо описывать хотя бы паттерн — по типу как сделал Максим — и пытаться к нему подобрать оптимальный ключик? Второй момент — люди работают с людьми. Возможно поднаторевшие в науке психологии могут описать харизму лидера каким-то прототипом а-ля "Наполеон", оцифровать характер по их классификации и потом оперировать этими терминами, но я тут не силен. Просто сложно не зная коллектива давать советы — точнее давать их легко, но не факт что они будут нужны\применимы

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

---

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

Конкретные реально работающие способы могут быть:

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

— четкий критерий проверки достигнута ли цель (есс-но цели для sales & QA будут разные, но всегда есть одна глобальная — принести прибыль): например, продать в этом году миллион лицензий продукта или продать на миллион рублей или пройти сертификацию по СММ уровня такого то

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

— объективные метрики везде где можно. Обязанности не должны в основной массе меряться субъективными критериями иначе их невозможно будет проверить и это лиюо прямой путь к одному из паттернов Максима, либо к моему дополнению что либо босс либо сотрудник будет неадекватен. По объективным критериям зависимость от личной симпатии уменьшается и соотв уменьшается вероятность сотруднику свалить критику шефа на "необъективность и потому что я ему ж не лижу как мой сосед". по этому поводу я писал здесь кстати: Re[6]: C# job in Spb

Автор: Valerio
Дата: 15.02.05

— аттестация преследует 2 цели — проверить что достигнуто по плану с пред аттестации (с применением объективных критериев, а не субъективных!) и наметить аналогичный план на след период. План должен включатьчтото типа таблички: цель, что сделать чтобы ее достигнуть, как проверить что цель достигнута,дата\подпись как аттестуемого так и тех кто аттестует, копия док-та у каждой стороны чтобы потом небыло разборок про "а на берегу ты мне обещал...". Одно дело если боссу не кажется что сотрудник был инициативным, другое дело если было обцее правило по отделу — 3 одобренных разпредложения в квартал — это значит что все-таки сотрудник инициативный. И легко проверяется по итогам квартала — нет возможности быть недовольным, если не внес 3 толковых предложения. Правда слождее в этой схеме будет тем, кто привык горлом и мельтешением ежедневным на обеде перед глазами шефа статус "инициативного" нарабатывать.

— корпоративный ящик idea@acme.com + назначить ответственного (а лучше несколько человек скажем тех экспертов ответственных за тех идеи, и т.п.) за проверку почты в нем и роутинг на ответственных лиц с автором идеи в Сс + жесткие сроки на ответы скажем в течении 3х дней по орг вопросами и неделю на тех инновацию. Реакция может быть и такой что "идея принята и будет рассмотрена после приезда главного на собрании после такого числа", чтобы автор идеи не гадал дошло ли письмо, читали ли его и т.п. В принципе тут на базе всяких Lotus Notes или новых технологий из Офиса даже можно замутить машину состояний и позволять отслеживать запросы как авторам так и ответственным лицам, но это только для больших компаний. Возможно есть коммерческие продукты или системы управления требованиями можно какие-то присобачить сюда. Итог этого пункта — человек получает обратную связь, по крайней мере шанс быть услышанным не только своим непосредственным боссом (который может потом его идею выдать за свою или просто единолично счесть ее ненужной), а вплоть до высшего руководства, которого иногда и в лицо то не знает. За принятые идеи поощрять материально и как минимум публичной благодарностью с отмечанием авторства.

— заинтересовать материально в общем успехе по итогам проекта\фин года, при этом четко сформулировав критерии ДО наступления события итог проекта\года и сделав прозрачным способ проверки этого сотрудниками. Не работает к сожалению для рядовых сотрудников в большинстве случаев, ибо проблемы и с прозрачносью и с формулировкой критериев ДО (все равно проверить бухгалтерию конторы никто не даст кому-то из QA). В маленьких командах напарников-основателей стартапов по определению все позиции ключевые. На западе давно это решили через систему опционов\акций и там таким образом проблема с прозрачностью попроще — ибо не руководство компании решает какие цифры показать коллективу, а сколько взять себе. У нас тоже постепенно компании вроде SW-Soft начинают внедрять эти технологии, насколько мне известно — жаль что опять это недоступно бойцам невидимого фронта, только относительно ключевым фигурам в компании и возможно каким-то ветеранам.

Это сходу, пока думаю зватит? Комментарии, добавления?

DAN>>С другой стороны у PMа не так уж много рычагов воздействия на разработчика. У нас например системы штрафов не существует, а некоторым просто объяснять — не действует.
AF>Это как объяснять
AF>Кроме того если человек "не понимает" — возможно, что у него есть мотив не понимать. Возможно он хочет делать что-то другое или не понял, зачем это надо.
Какой-то крайне общий и отвлеченный ответ получился. Т.е. непонятно что с ним делать.

Я в общем-то осознаю, что если человек не делает то что ему говорят, значит он считает что это неправильно.
А вот тут уже начинаются варианты в зависимости от которых применяется разное лекарство.
Например (это не совсем касается предыдущего моего поста, скорее анализ почему "не понимают"):
1. человек не компетентен, т.е. просто не понимает почему именно так. Классический пример: неопытный программист считает что пока в его программе не найдутся баги — багов нет, опытный программист считает, что пока в его программе не будут найдены и устранены все баги — они там есть (извиняюсь за недословную цитату) — иногда область некомпетенции может быть достаточно обширна, чтобы все объяснять потребуется даже не день — в таком случае имеет смысл дать ссылку на книжку и сказать "пока поверь мне на слово".
2. человек видит только часть картины, в то время как полная картина совсем другая — опять же или ссылка на книжку, или просто сказать "делай так, потому что я лицо принимающее решение".
Понимаю, что ни 1 ни 2 не самый лучший вариант, по хорошему у разработчика должен быть ментор который им будет заниматься, но на практике к сожалению это не позволяют сроки, бюджет проекта и т.п.
Заставлять переделывать в таком случае ессно грех.

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

Ваши варианты, мнения по поводу вышесказанного.

DAN>>У нас оплачиваются переработки, но это совсем другая история: проверяется чем человек в это время занимался и оплачивается только если он грубо говоря за 50 часов в неделю сделал больше чем сделал бы за 40.
AF>Тут есть сложность. Кто определяет сроки. Если сам разработчик — это одно (да и в этом случае он может ошибаться), если же кто-то за него — то на выходных работать должны как минимум оба. Продуктивность то у всех разная. Кроме того частенько бывает ситуация, что менеджер просто не видит "мелких" деталей, которые возникают при реализации его гениальных замыслов и не понимает "что там делать столько времени"
Вы не так поняли. Это со сроками никак не вяжется. если менеджер просит выйти поработать в субботу потому что планы были херовые — эта переработка оплачивается в любом случае. Если человек хочет добровольно поработать в субботу (а к концу проекта он всегда горит , поэтому такое желание только welcome) — это тоже оплачивается, если человек написал код который по результатам ревью признан непригодным — не оплачивается. если слишком много багов и они ляповые (off by one error или обработка ошибок хромает) — тоже не оплачивается. Ну и т.п.
В общем и целом система не идеальна, но это имхо лучше чем вообще не оплачиваемый овертайм

VAB>Конкретные реально работающие способы могут быть:
Вопрос к Валерию и к общественности: а окупит ли себя введение всего перечисленного в предыдущем сообщении? Или не получится ли так, что после внедрения всех этих вкусностей не останется денег на хорошую зарплату разработчикам, из-за чего они все разбегутся по другим конторам? И не получится ли так, что пустив эти доп. средства на повышение зарплаты выше уровня рынка в компанию при активности HR-ов постепенно стекутся лучшие люди, из-за чего контора станет работать на порядок лучше чем высокомотивированные середняки?

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

VAB>>Конкретные реально работающие способы могут быть:
DAN>Вопрос к Валерию и к общественности: а окупит ли себя введение всего перечисленного в предыдущем сообщении? Или не получится ли так, что после внедрения всех этих вкусностей не останется денег на хорошую зарплату разработчикам, из-за чего они все разбегутся по другим конторам? И не получится ли так, что пустив эти доп. средства на повышение зарплаты выше уровня рынка в компанию при активности HR-ов постепенно стекутся лучшие люди, из-за чего контора станет работать на порядок лучше чем высокомотивированные середняки?

Хороший вопрос, но времени развить тему нет прямо сейчас. Пока напишу только по поводу следующей ситуации: Допустим ср-ва есть, но весьма ограниченны. Я не думаю что невозможно внедрить ВСЕ упомянутые мной вкусности даже в начинающих стартапах без больших ср-в\инвестиций.

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

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

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

— провести аттестацию можно и в 30 мин на листике бумаги глаз на глаз — не обязательно загружать этой волокитой HR отдел особенно если его нет и весь коллектив 2 человека . Это просто как расписка при заеме денег — друзьям в принципе она не нужна.... но до определенного размера суммы! В любом случае с такой распиской жить проще потом и легко разобраться в случае конфликтов, а не опереровать формулировками "я помню мне сказали что..." и "я такого не говорил а имел ввиду что...". Цена вопроса гораздо меньше чем долгое убеждение штата компании на политзанятиях, что они работают в крутой фирме и как они должны быть счастливы что строят Нью-Васюки — это по определению более долго, ибо чтобы закрепилось в мозгах требует поторения не менее 100 раз в неделю

— корпоративный ящик не требует вложений. Обязанность по его просматриванию может совмещаться кем-то, а в совсем маленьких проектах просто предложения имеют свойство забываться после озвучивания соседу — лучше привить практику оформления всех идей либо на ящик либо приспособить систему хоть контроля версий — иметь документ ideas.doc и в него коммиттать появляющееся... денег не надо опять

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

Сейчас я вижу что оптимистичный вариант развития компании планирующей не стать однодневкой вряд ли возможен без серьезных инвестиций (хотя бы на ЗП выше средней по отрасли на срок проекта * на Pi для аккумулирования лучших кадров, которые как известно решают все).

Собственно даже Google начинался с заема 100,000 баксов на прокупку старых винтов у одного богатого еврея Ну это неважно, важно что просто команда энтузиастов работаюзих днем в приличных компаниях а по вечерам\ночам\выходным пишущих нечто свое заранее в неравных условиях стоит и этот случай стоит рассматривать не в этом форуме, а в shareware.business. Но идеи выше применимы и там, как я показал выше — главное не думать что успех проекта целиком зависит от успеха на технической стороне.

VAB>Хороший вопрос, но времени развить тему нет прямо сейчас. Пока напишу только по поводу следующей ситуации: Допустим ср-ва есть, но весьма ограниченны. Я не думаю что невозможно внедрить ВСЕ упомянутые мной вкусности даже в начинающих стартапах без больших ср-в\инвестиций.
Под средствами также стоит рассматривать время которое будет тратить менеджер. Написать роадмап это не сложно и необходимо, совершенно с вами согласен, а вот мерить метрики и проводить аттестатцию уже значительно больше времени занимает. Впрочем все реализуемо, вопрос в том насколько это даст реальную отдачу.
Позвольте прокомментировать по пунктам.

VAB>- накропать цели на 6 мес\год возможно и без общегодового собрания компании, можно и на кухне написать, главное в этом док-те чтобы за деревьями лес не потерять потом. Цена близка к нулю
Нужно. Однако что это даст в смысле мотивации конкретному девелоперу? Только наверное спокойствие: "начальство знает куда нас вести". С другой стороны стоит быть осторожным с цифрами, т.к. возможна даже демотивация: "эти сволочи бабки загребают лопатой — миллионы копий продают, а я тут на 600 зеленых в месяц горбачусь". Впрочем это тема совсем отдельного разговора.

VAB>- объективные метрики тоже не требуют вложений, достаточно потратить пару часов на обсуждении с той же командой единомышленников и родить критерии с которыми все согласятся и далее соотв работают по этому своду внутренних правил, деньги тут нужны только на оплату времени сотрудников занятых на собрании. В компаниях побольше конечно тут стоит подумать получше, но тоже не сильно ресурсоемкое дело.
Уточните пожалуйста что вы понимаете под метриками? Я так понимаю речь идет о неких корпоративных правилах о скажем качестве кода и т.п.?
Что это даст с точки зрения мотивации?

VAB>- провести аттестацию можно и в 30 мин на листике бумаги глаз на глаз — не обязательно загружать этой волокитой HR отдел особенно если его нет и весь коллектив 2 человека .
По хорошему нужно строить career plan, иначе опять возможна демотивация: "я такой крутой по аттестатам, а мне денег нифига не платят/фигней всякой заставляют заниматься".
Т.е. аттестация ради самой аттестации имхо бессмыслена.
Что касается career plan-а: к сожалению тоже не все гладко: так или иначе развитие сотрудника зависит от развития команды в целом и в результате запросто можно человека "обломать" — не дали денег заказчики, продукт продается хуже чем ожидалось и т.п. Может быть более разумных/достаточным будет: появилась потребность в новом начальнике — отобрал самого перспективного/подходящего — его назначил.

VAB>В любом случае с такой распиской жить проще потом и легко разобраться в случае конфликтов, а не опереровать формулировками "я помню мне сказали что..." и "я такого не говорил а имел ввиду что...".
Опять, каким образом это повысит мотивацию?
VAB>Цена вопроса гораздо меньше чем долгое убеждение штата компании на политзанятиях, что они работают в крутой фирме и как они должны быть счастливы что строят Нью-Васюки — это по определению более долго, ибо чтобы закрепилось в мозгах требует поторения не менее 100 раз в неделю
Имхо на ИТ-people это вообще не действует склад характера не тот.

VAB>- корпоративный ящик не требует вложений. Обязанность по его просматриванию может совмещаться кем-то, а в совсем маленьких проектах просто предложения имеют свойство забываться после озвучивания соседу — лучше привить практику оформления всех идей либо на ящик либо приспособить систему хоть контроля версий — иметь документ ideas.doc и в него коммиттать появляющееся... денег не надо опять
Делали общий анонимный ящик — за год работы ни одного сообщения
ideas.doc для каждого проекта существует, но там больше фичи для самого проекта, чем общие пожелания по процессу.
Опять же эти предложения удобней в bugtracking системе вести.

VAB>- в итоге самое главное — заинтересовать материально и вот сюда нужны деньги. инвестиции тут помогают пережить трудное время на старте, ибо когда проетк финансируется из своего кармана — тут и жена одного из партнеров может оказаться самым большим неучтенным риском... такое сложнее просчитывается чем что либо еще
Вот! И это ключевое имхо! К сожалению зарплата среднего разработчика все таки слишком далека чтобы думать о чем-то еще. В смысле чтобы зарплата не была решающим аргументов. Следовательно, стоит ли затевать весь сыр бор, если соседняя контора поставив на 20% бОльшую зарплату заберет разработчика с потрохами? Хотя то что вы выше перечислили скорее улучшает процесс, нежели мотивирует.
Вот с менеджерами нужен уже более тонкий подход...

VAB>Сейчас я вижу что оптимистичный вариант развития компании планирующей не стать однодневкой вряд ли возможен без серьезных инвестиций (хотя бы на ЗП выше средней по отрасли на срок проекта * на Pi для аккумулирования лучших кадров, которые как известно решают все).
Скорее тут лучше работает (да и на практике чаще встречается) подход когда начинает работать небольшая команда профессионалов на перспективу: станем большой конторой, будем все в шоколаде.

VAB>Но идеи выше применимы и там, как я показал выше — главное не думать что успех проекта целиком зависит от успеха на технической стороне.
Не целиком, но предопределяющее.
Я собственно что хотел сказать всеми этими постами: нет смысла активизироваться на мотивации девелоперов если процесс не поставлен, нет заказчика/идеи.

Т.е. хорошо мотивированный девелопер работающий на коленке без требований, без багтрекинга, планов, SCM систем и т.п. будет все равно работать хуже чем человек работающий за деньги но с хорошо поставленным процессом. И вся мотивация у него испарится когда он будет вручную мержить код нескольких человек или получит по башке от менеджера за то что забыл пофиксить баг, о котором тот ему вчера в курилке говорил
А по моему хоть и небогатому, но все же опыту большинство компаний даже находящихся в москве похвастать хорошо поставленным процессом не могут. СММ3 компании по пальцам пересчитать можно. А уж СММ5 по моему вообще всего две компании — Luxsoft и CQG.

Т.е. проблема психологической мотивации для большинства компаний преждевременна или не имеет большого значения.

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

VAB>>Хороший вопрос, но времени развить тему нет прямо сейчас. Пока напишу только по поводу следующей ситуации: Допустим ср-ва есть, но весьма ограниченны. Я не думаю что невозможно внедрить ВСЕ упомянутые мной вкусности даже в начинающих стартапах без больших ср-в\инвестиций.
DAN>Под средствами также стоит рассматривать время которое будет тратить менеджер. Написать роадмап это не сложно и необходимо, совершенно с вами согласен, а вот мерить метрики и проводить аттестатцию уже значительно больше времени занимает. Впрочем все реализуемо, вопрос в том насколько это даст реальную отдачу.

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

VAB>>- накропать цели на 6 мес\год возможно и без общегодового собрания компании, можно и на кухне написать, главное в этом док-те чтобы за деревьями лес не потерять потом. Цена близка к нулю
DAN>Нужно. Однако что это даст в смысле мотивации конкретному девелоперу? Только наверное спокойствие: "начальство знает куда нас вести". С другой стороны стоит быть осторожным с цифрами, т.к. возможна даже демотивация: "эти сволочи бабки загребают лопатой — миллионы копий продают, а я тут на 600 зеленых в месяц горбачусь". Впрочем это тема совсем отдельного разговора.

Про ЗП важно — но при прочих равных когда все в порядке в компании на лишнии 100 уе никто не бросится.

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

Одно дело когда ты недоволен потому что тебе кажется что тебя не оценили\не любят\не понимают и другое когда как я сказал по возмоности объективные (=порверяемые легко кем угодно) критерии действуют. Тут сложнее быть недовольным кем-то кроме себя — раз ты правила знаешь и согласился с ними когда-то.

И увереннось что нач-во знает что делает а не сборище балбесов которое вызывает резкое согласие с тезисом "у нас каждая кухарка может управлять страной а уж я то всяко лучше знаю что делать чем новый хрен с горы (босс Петя) до прихода к нам торговавший лесом и думающий тока о новых тачках + нихрена не парящий в нашем деле" и желание сменить обстановку даже с потерей 100 уе!

VAB>>- объективные метрики тоже не требуют вложений, достаточно потратить пару часов на обсуждении с той же командой единомышленников и родить критерии с которыми все согласятся и далее соотв работают по этому своду внутренних правил, деньги тут нужны только на оплату времени сотрудников занятых на собрании. В компаниях побольше конечно тут стоит подумать получше, но тоже не сильно ресурсоемкое дело.
DAN>Уточните пожалуйста что вы понимаете под метриками? Я так понимаю речь идет о неких корпоративных правилах о скажем качестве кода и т.п.?

нет, я имел в своем сообщении прежде всего не технические моменты!
под объективными метриками я привел пример с инициативностью, а термин пошел от моего давнего сообщения Re[6]: C# job in Spb

Автор: Valerio
Дата: 15.02.05

не путать с метриками о которых проповедует Gaperton

Кстати правила на качество кода — трудновато ввести будет
а вот на стиль кодирования — да, полезно (но не всегда оправданно штрафовать за несоблюдение)

DAN>Что это даст с точки зрения мотивации?
это даст как я выше заметил уверенность что ты работаешь в компании профи, а это стоит дорогого ИМХО. соотв неявно это даст мотивацию и поможет избежать ужасов в заглавии ветки

VAB>>- провести аттестацию можно и в 30 мин на листике бумаги глаз на глаз — не обязательно загружать этой волокитой HR отдел особенно если его нет и весь коллектив 2 человека .
DAN>По хорошему нужно строить career plan, иначе опять возможна демотивация: "я такой крутой по аттестатам, а мне денег нифига не платят/фигней всякой заставляют заниматься".
есс-но человек который удовлетворил условиям Individual expectation agreement (у нас так это называется) рассчитывает что это найдет материальное выражение — и об этом я уже писал, это само сабой иначе не будет работать. просто одно дело когда нач-к в зависимости от своего настроения выдает бонусы и когда ты сам можешь прийти и сказать — вот бумага, вот я все сделал — получите, распишитесь. Если нач-к это знает, он сам ответственнее будет с людьми себя вести, иначе сотрудник легко покажет все то же самое боссу повыше и тут уже не будет ситуации когда слово сотрудника против слова ПМа перед боссом повыше, который априори склонен доверять все же ПМу.

DAN>Т.е. аттестация ради самой аттестации имхо бессмыслена.
не спорю

DAN>Что касается career plan-а: к сожалению тоже не все гладко: так или иначе развитие сотрудника зависит от развития команды в целом и в результате запросто можно человека "обломать" — не дали денег заказчики, продукт продается хуже чем ожидалось и т.п. Может быть более разумных/достаточным будет: появилась потребность в новом начальнике — отобрал самого перспективного/подходящего — его назначил.

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

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

VAB>>Цена вопроса гораздо меньше чем долгое убеждение штата компании на политзанятиях, что они работают в крутой фирме и как они должны быть счастливы что строят Нью-Васюки — это по определению более долго, ибо чтобы закрепилось в мозгах требует поторения не менее 100 раз в неделю
DAN>Имхо на ИТ-people это вообще не действует склад характера не тот.
действует хоть и вызывает отторжение ИТ-people
тем не менее молодых меньше не становится и пока они это пройдут кто-то на них покатается... а иногда ситуации безвыходные, что вынуждены скрепя забуами матерые профи соглашаться. Это жизнь. но это не принесет стабильности — нормальные кадры утекут как тока так сразу в нормальное место

VAB>>- корпоративный ящик не требует вложений. Обязанность по его просматриванию может совмещаться кем-то, а в совсем маленьких проектах просто предложения имеют свойство забываться после озвучивания соседу — лучше привить практику оформления всех идей либо на ящик либо приспособить систему хоть контроля версий — иметь документ ideas.doc и в него коммиттать появляющееся... денег не надо опять
DAN>Делали общий анонимный ящик — за год работы ни одного сообщения

В Новософте (немного о Новософте у меня тут: Re[5]: О роли HR

Автор: Valerio
Дата: 06.10.04

) это работало, правда после усилий описанных выше — по прозрачности запросов и гарантированном времени отклика со стороны ответственных лиц.

DAN>ideas.doc для каждого проекта существует, но там больше фичи для самого проекта, чем общие пожелания по процессу.
DAN>Опять же эти предложения удобней в bugtracking системе вести.
да, приспособить можно что угодно, я вариант с CVS просто первый пришедший в голову из простых привел

VAB>>- в итоге самое главное — заинтересовать материально и вот сюда нужны деньги. инвестиции тут помогают пережить трудное время на старте, ибо когда проетк финансируется из своего кармана — тут и жена одного из партнеров может оказаться самым большим неучтенным риском... такое сложнее просчитывается чем что либо еще
DAN>Вот! И это ключевое имхо! К сожалению зарплата среднего разработчика все таки слишком далека чтобы думать о чем-то еще. В смысле чтобы зарплата не была решающим аргументов. Следовательно, стоит ли затевать весь сыр бор, если соседняя контора поставив на 20% бОльшую зарплату заберет разработчика с потрохами? Хотя то что вы выше перечислили скорее улучшает процесс, нежели мотивирует.
выше

DAN>Вот с менеджерами нужен уже более тонкий подход...
суть та же

VAB>>Сейчас я вижу что оптимистичный вариант развития компании планирующей не стать однодневкой вряд ли возможен без серьезных инвестиций (хотя бы на ЗП выше средней по отрасли на срок проекта * на Pi для аккумулирования лучших кадров, которые как известно решают все).
DAN>Скорее тут лучше работает (да и на практике чаще встречается) подход когда начинает работать небольшая команда профессионалов на перспективу: станем большой конторой, будем все в шоколаде.
все так начинают\говорят. но когда начинается шоколад часто оказывается что один работал больше всех, а его не оценили и т.п. Я просто пишу все это для того чтобы такие ситуации было легче разруливать — для этого загодя приготовиться.

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

DAN>Я собственно что хотел сказать всеми этими постами: нет смысла активизироваться на мотивации девелоперов если процесс не поставлен, нет заказчика/идеи.
если нет закачика\идеи = нет работы, то действительно говорить не о чем

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

DAN>А по моему хоть и небогатому, но все же опыту большинство компаний даже находящихся в москве похвастать хорошо поставленным процессом не могут. СММ3 компании по пальцам пересчитать можно. А уж СММ5 по моему вообще всего две компании — Luxsoft и CQG.
процесс ради процесса... им это нужно самое глаавное потому что они уже вышли на этот уровень и им маркетинг надо наводить, я думаю.

DAN>Т.е. проблема психологической мотивации для большинства компаний преждевременна или не имеет большого значения.
не согласен Предлагаю завернуть на пост Максима в начало ветки: Психологические проблемы мотивации девелоперов.

Автор: Maxim S. Shatskih
Дата: 22.08.05

откуда это берется если есть практически в каждой компании\команде? И почему дажеко не везде с этим вообще пытаются бороться, а не то что справляются?

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

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

Это точно...

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

ППКС.

Моя неприязнь к "научному прожект-менеджменту" — основана вот именно на этом.

AF>Если в кратце — то работать с людьми — показывать им связь между их действиями и деньгами

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

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

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

То есть? Руководитель два месяца не интересовался статусом?

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

Я бы сказал так. Нужна трехзвенная архитектура. Бизнес-руководитель (в мелкой компании это гендиректор). Технический руководитель, который есть профессиональный девелопер по опыту работу, но способен мыслить бизнес-категориями. И сами девелоперы.

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

DAN>Вопрос к Валерию и к общественности: а окупит ли себя введение всего перечисленного в предыдущем сообщении? Или не получится ли так, что после внедрения всех этих вкусностей не останется денег на хорошую зарплату разработчикам, из-за чего они все разбегутся по другим конторам? И не получится ли так, что пустив эти доп. средства на повышение зарплаты выше уровня рынка в компанию при активности HR-ов постепенно стекутся лучшие люди, из-за чего контора станет работать на порядок лучше чем высокомотивированные середняки?

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

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

Как мне кажется, эта нехитрая схема очень хорошо работает.

VAB>- провести аттестацию можно и в 30 мин на листике бумаги глаз на глаз — не

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

Аттестация не расматривается ни как мотиватор, ни как какой бы то ни было еще инструмент.

И еще. Насчет объективных метрик. Если эта метрика становится сложной — человек перестает понимать интуитивно, что именно и как именно влияет на его зарплату, и потому как мотиватор она работать перестает.

B>Мне кажется, что во моногом все определяется личными качествами руководителя. Есть харизма/нет харизмы,

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

B>Гуляя с ребенком, я смотрю на детей, — выделяются явные "заводилы", "тихони", "плаксы" и т.д..

А еще есть и те, что испытывают отвращение к любым "заводилам". Как правило такие люди оседают в коллективах, где нет "заводил". Если же он есть — то данный человек становится "антилидером", а "антилидер" в персонале компании — вредно.

B>Многие мои дни проходят примерно так: 1) прийти на работу; 2) проверить почту, полазить по сети и т.д.; 3) решить что я мог бы пообедать прежде чем начать работать; 4) вернуться с обеда; 5) проверить почту, полазить по сети и т.д.; 6) окончательно решить что пора взяться за работу; 7) проверить почту, полазить по сети и т.д.; 8) опять решить что, действительно пора поработать; 9) запустить чёртов редактор; и 10) безостановочно писать код, пока я не осознаю что уже полвосьмого. "[/i]

Ага, бывает у многих.

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

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

_D>2. Девелоперу поручают работу, сложность которой, значительно превышает его квалификацию.

Так это ж челлендж! Могучий мотиватор! Развитие! вот только со сроками тут нельзя давить.

_D>3. Систематическое неукладывание в сроки.

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

_D>4. Сворачивание работ по направлению, которое было интересно девелоперу и которому было уделено значительное время.

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

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

Качество кода падает.

Пример. Анисимович в Abbyy. Очень жесткий руководитель. Но он всегда был категорически против переработки сотрудников, работы в выходные и по ночам. "Написанный в таких условиях код потом невозможно понять, и он пойдет на выбор" — говорил он.

DAN>Но быть не в потоке можно тоже по разному: можно книжки по ИТ читать, можно RSDN (опять же много полезного), а можно например на love.mail.ru

ооо! это да. Я не знаю большей помойки в русской сети, чем этот сайт.

S>склонение руководства к использованию техологий, которые либо бесполезны в данном проекте и для фирмы, либо вообще вредны, однако позволяют конкретному девелоперу за счет оплаченного рабочего времени изучить "модную" технологию. основная ель — пополнение собстенного "портфолио", позволяющего найти более высокооплачиваемую работу.

О! Это любимое просто! Особенно в этом вопросе OLE DB прославилось

Лечится наличием толкового техдиректора. Именно не PMа (PMа как раз на это можно "развести"), а техдиректора (т.е. девелопера по опыту работы).

Впрочем, этим занимаются не только девелоперы, но и выходцы из, например, ПиАра и околоITшной журналистики. Они судят по новым технологиям — по глянцевым журналам.

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

A>Для того чтобы не игнорировали нужно правильно доносить. А если человек игнорирует — значит ему наплевать на компанию, а соответсвенно сотрудников, в которой он работает. Он одиночка и не командный игрок! Вы считаете это нормальным?

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

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

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

Прошу прощения. Имелось в виду — "на выброс".

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

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

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

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

AL>- разработчику даются интересные для него задачи. По крайней мере, интерес может быть связан с тем, что придется осваивать что-то новое, полезное для раработчика в будущем;

Если есть такая возможность — то конечно.

AL>- работа разработчика ни в коем случае не фрагментируется;

Опять же — если есть возможность, но надо, ой надо, возможность надо почти любой ценой изыскивать.

AL>Про деньги и командный дух не говорю. Про деньги -- потому что, по моим наблюдениям, деньги для квалифицрованного разработчика не есть самоцель и никак не стимул.

Я бы сказал — они должны быть адекватными

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

VAB>>- провести аттестацию можно и в 30 мин на листике бумаги глаз на глаз — не

MSS>Вообще говоря, серьезные HR понимают аттестацию как средство отсева худших, нужно для структур с конкретно совковым прошлым (и совковым же персоналом).
хорошо, слово аттестация было выбрано не совсем верно, но я упоминал еще вот что

VAB>> есс-но человек который удовлетворил условиям Individual expectation agreement (у нас так это называется)

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

MSS>Аттестация не расматривается ни как мотиватор, ни как какой бы то ни было еще инструмент.

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

И как я уже писал, мне довелось поработать в системе где было из скажем 12 вот таких оцениваемых непосредственным нач-ком параметров необъективных 10. Объективных было 2 — кол-во отработанных часов и кол-во отработанных часов сверхурочно. Ну еще был более-менее понятный параметр — успевает ли человек по таймлайну двигаться. Остальные были типа "инициативность" и ставились целиком по усмотрению нач-ка, соотв и интуитивно я перестал понимать эти метрики практически сразу после их прочтения, с тех пор стараюсь избегать таких методов. В итоге такие вещи вырождаются в проставление нормальным ПМом всей группе прочерка по этому параметру дабы не раздувать конфликты внутри группы по типу описанных выше. Но в таком случае это просто лишний параметр ни на что не влияющий, т.е. пользы — 0, а вред может быть от некорректного использования.

VAB>по мне так гораздо сложнее понять почему одного человека считают инициативным и замечательным парнем (т.е. понятно что, потому что он вместе с шефом увлекается дзюдо к

ИМХО инициативность вообще не есть ценное качество в software development (кроме очень серьезных, стратегических позиций).

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

MSS>ИМХО инициативность вообще не есть ценное качество в software development (кроме очень серьезных, стратегических позиций).

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

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

MSS>Это снизит и халявность работы "новичков". "Ветераны" же заинтересованы в данной компании по определению — потому как доплата — и потому тоже халявить не станут.

Максим, ситуация: "ветеран" в своей области, 10+ лет стажа по специальности, устроился на новую работу. На новой работе он "новичек".

Возвращаясь к психологическим моментам: старожилы с новой работы высказывают мнение типа "нуууу ишь захотел ЗП какую, поработай-ка сначала как мы тут лет 5! А потом пусть ему поднимут до нашего уровня и мы с этим еще как-то согласимся." Но как насчет того что пока эти старожилы повышали свою ЗП здесь, "новичек" тоже не спал а впахивал будь здоров, зарабатывая опыт и квалификацию (возможно даже выше чем у старожилов)?

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

VAB>Максим, ситуация: "ветеран" в своей области, 10+ лет стажа по специальности, устроился на новую работу. На новой работе он "новичек".

VAB>Возвращаясь к психологическим моментам: старожилы с новой работы высказывают мнение типа "нуууу ишь захотел ЗП какую, поработай-ка сначала как мы тут лет 5! А потом пусть ему поднимут до нашего уровня и мы с этим еще как-то согласимся." Но как насчет того что пока эти старожилы повышали свою ЗП здесь, "новичек" тоже не спал а впахивал будь здоров, зарабатывая опыт и квалификацию (возможно даже выше чем у старожилов)?

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

Кстати, рынок труда для таких "ветеранов" очень узок.

VAB>Причем про квалификацию старожилы не упоминают, а помнят хорошо как раз про свою выслугу лет и меряют именно по этому греющему их души показателю.

Ну это само собой, если старожил так и не стал серьезным профессионалом — то с ним конкретно расстаются, ибо это простейший вариант.

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

MSS>Давай с другой стороны зайдем. Зачем руководителю той компании брать на работу такого ветерана, неужто из своих поднять некого? Поднять из своих — по ряду причин всегда проще.
именно в силу того, что поднять из своих — не получится, по-крайней мере не потратив несколько лет Или например взамен (потенциально) уходящего другого специалиста могут искать.

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

MSS>Кстати, рынок труда для таких "ветеранов" очень узок.
это точно, но зато есть шанс получить адекватную оплату за свою "редкость"

VAB>>Причем про квалификацию старожилы не упоминают, а помнят хорошо как раз про свою выслугу лет и меряют именно по этому греющему их души показателю.

MSS>Ну это само собой, если старожил так и не стал серьезным профессионалом — то с ним конкретно расстаются, ибо это простейший вариант.

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

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

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

AF>>Если в кратце — то работать с людьми — показывать им связь между их действиями и деньгами

MSS>Многие девелоперы хотели бы иметь стабильный рыночный оклад, не нервничать, не дергаться, и тихо-спокойно заниматься умным и приносящим удовольстие.

MSS>Подачками их не мотивируешь. Подачками мотивируется психология рвачества, которая хороша, например, у сэйлов, но не всегда хороша у девелопера.

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

Hi,

MSS>Многие девелоперы хотели бы иметь стабильный рыночный оклад, не нервничать, не дергаться, и тихо-спокойно заниматься умным и приносящим удовольстие.

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

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

MSS>Подачками их не мотивируешь. Подачками мотивируется психология рвачества, которая хороша, например, у сэйлов, но не всегда хороша у девелопера.

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

Mikhail

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

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

Для т.н. "обычных" кадров рыночная ставка является элементом
гигиены. Для кадров с торговым бекграундом элементом гигиены
является превышение их ставки над среднерыночной.

Mikhail

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

DAN>>Но быть не в потоке можно тоже по разному: можно книжки по ИТ читать, можно RSDN (опять же много полезного), а можно например на love.mail.ru

MSS>ооо! это да. Я не знаю большей помойки в русской сети, чем этот сайт.

OFFTOP: их примерно 200 таких помоек. Точно таких. Потому как love.ramble.ru love.mail.ru и еще куча других сайтов это на самом деле один общий сайт.