Здравствуйте, Michael_E_Smrinov, Вы писали:
M_E>Не могли бы вы помочь мне сформировать более-менее пригодную систему мотивации? M_E>Как видите, у нас не вполне проектная деятельность — т.е. у нас нет как таковой сдачи проекта заказчику, после которой можно раздавать бонусы.
M_E>Соответственно, хотелось бы сформировать систему, которая побуждала бы разработчиков работать более эффективно и качественно.
[...]
M_E>В литературе упоминается, система мотивации должна быть привязана к целям компании. Но у нас условия таковы, что существует фиксированный фонд оплаты труда, который не особо зависит от результатов деятельности компании. Его, конечно, можно менять, но это достаточно длительный процесс и он не зависит от итогов работы за какой-то период короткий — например, за месяц.
Иными словами, ты ищешь способ заставить людей работать всё лучше и лучше, но при этом внешние условия меняться никак не будут? Это сон? Или очередной поиск способа найти результат деления x/0? А, я знаю. Это — вечный двигатель!
Заруби на носу и передай это руководству: должна быть экономически выразимая обратная связь между усилиями разработчиков продукта и теми условиями, в которых они будут жить. Иначе все эти поощрительные системы в виде 3-х копеек после code review и почётного вымпела "самый быстрый Гонсалес" на монитор будут цирком и профанацией. Если руководство это не понимает, то это очень большая проблема. Лучшее, что можно здесь посоветовать — не мешать людям (внимание, читать дословно) минимизировать время, затрачиваемое на работу в рамках времени, допустимого ходом проекта. Например, на подпроект отводится неделя. Управились за пару дней. Ещё три дня — гуляем, рубимся в Counter Strike, читаем форумы, изучаем технологии, переписываем другие куски по своему вкусу, левачим и т.п. Раз зарплата не меняется, то хоть свободное время будет.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re: Предлагаю мотивировать не количество, а качество работы
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[4]: Предлагаю мотивировать не количество, а качество рабо
Здравствуйте, The Lex, Вы писали:
TL>>>4) В прицнипе, манагеры сюда могут еще много чего добавить — на то они и манагеры... G>>Я бы попросил.
TL>Типа, а хороших манагеров назовем "лидами"...
Хороших манагеров назовём номинально: руководителями. Зачем на хороших людей нехорошие эпитеты вешать?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Vlad_SP, Вы писали:
V_S>Вот ты пишешь, (16.06.08 14:48) что "как-то надо поднимать производительность труда". Ты считаешь текущую производительность низкой? Как ты ее измерил? За какой период? Каков разброс данных и доверительный интервал полученной тобою цифры? Какую цифру производительности ты считал бы "нормальной"? А "высокой"? Откуда взяты эти цифры? Чем обоснованы?
Увы, сейчас это на уровне общих наблюдений и сравнения работы разных членов команды. Особых цифр нет.
Т.е. я вижу, что одни люди стараются, а другие любят похалявить. Т.е. даже не просто работать мало, тратя время не на рабочие вопросы, а может быть просто работаю недостаточно внимательно, допуская недоделки и т.п.
Но проблема не в том, чтобы тех, кто любит похалявить, призвать к ответу. Я бы хотел сделать так, чтобы у них не было такого желания — похалявить, а было желание поработать.
Что считать нормальной и высокой производительностью — это тоже пока на уровне ощущений.
Т.е. я вижу, что один человек работает хорошо, старается. А другой так, как придется.
V_S>На самом деле, ответы на эти вопросы — ключевые в твоей деятельности. Это — определение цели деятельности и критериев ее достижения. Только потом можно разрабатывать и обсуждать способых достижения. "Ни один ветер не будет попутным для корабля, не знающего, куда ему плыть." (Луций Анней Сенека)
Здесь я с тобой согласен, да.
Как думаешь, как их, эти цели, можно более-менее формально сформулировать?
Здравствуйте, Michael_E_Smrinov, Вы писали:
M_E>Увы, сейчас это на уровне общих наблюдений и сравнения работы разных членов команды. Особых цифр нет. M_E>Т.е. я вижу, что одни люди стараются, а другие любят похалявить. Т.е. даже не просто работать мало, тратя время не на рабочие вопросы, а может быть просто работаю недостаточно внимательно, допуская недоделки и т.п.
Значит, таков стиль их работы. Будет чуть больше работы тестерам — ничего страшного. Значит, эти члены команды работают, в конечном итоге, медленнее других.
M_E>Но проблема не в том, чтобы тех, кто любит похалявить, призвать к ответу. Я бы хотел сделать так, чтобы у них не было такого желания — похалявить, а было желание поработать.
Это невозможно. Немедленно заканчивай даже думать о подобных вещах, пока у тебя не случилось жестокого разочарования в людях.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, Michael_E_Smrinov, Вы писали:
M_E>>Но проблема не в том, чтобы тех, кто любит похалявить, призвать к ответу. Я бы хотел сделать так, чтобы у них не было такого желания — похалявить, а было желание поработать.
ГВ>Это невозможно. Немедленно заканчивай даже думать о подобных вещах, пока у тебя не случилось жестокого разочарования в людях.
ну почему
было такое религиозное течение — кальвинисты
и вообще в протестантской системе ценностей труд приравнен к религиозному служению
IMHO
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, Michael_E_Smrinov, Вы писали:
M_E>>Но проблема не в том, чтобы тех, кто любит похалявить, призвать к ответу. Я бы хотел сделать так, чтобы у них не было такого желания — похалявить, а было желание поработать.
ГВ>Это невозможно. Немедленно заканчивай даже думать о подобных вещах, пока у тебя не случилось жестокого разочарования в людях.
слова "раб" и "работа" однокоренные только в восточноевропейских языках
причина — повторное усиление крепостничества в европейских странах модели догоняющего развития в тот период, когда оно начало разрушаться в передовых европейских странах
то есть то, автор вопроса хочет, добиться в принципе можно, но нужно тщательно подбирать коллектив по менталитету
крайности в принципе две
1. набрать "роботов" и двигаться по японской модели
2. набрать "американцев" и "европейцев", для которых труд является ценностью, и которые понимают смысл выражения "радость труда"
Здравствуйте, Michael_E_Smrinov, Вы писали:
M_E> Я бы хотел сделать так, чтобы у них не было такого желания — похалявить, а было желание поработать.
Уфф! Сними розовые очки. Welcome to the real world, fellow!
Либо ты их поставишь в такие экономические условия, которые неизбежно вызовут у них желание поработать, чтобы заработать. Либо — никак. Ну посуди сам — нафига зря напрягаться, если зарплата все равно одна и та же? А ФОТ у вас фиксированный и не меняется — 16.06.08 12:40.
А для того, чтобы создать экономические условия, стимулирующие эффективный и производительный труд, у тебя сейчас элементарно нет исходных данных, — нет точки отсчета сейчас и "плановой" точки, скажем, через полгода. Разве не так?
Кстати, отталкиваясь от первого сообщения, совершенно непонятно, есть ли у тебя реальные рычаги воздействия на ситуацию. Читай пост Геннадия Васильева от 18.06.08 20:01 и попытайся пободаться с руководством.
Здравствуйте, Vlad_SP, Вы писали:
V_S>Уфф! Сними розовые очки. Welcome to the real world, fellow! V_S>Либо ты их поставишь в такие экономические условия, которые неизбежно вызовут у них желание поработать, чтобы заработать. Либо — никак. Ну посуди сам — нафига зря напрягаться, если зарплата все равно одна и та же? А ФОТ у вас фиксированный и не меняется — 16.06.08 12:40.
Да, все так. В этом-то и проблема.
V_S>А для того, чтобы создать экономические условия, стимулирующие эффективный и производительный труд, у тебя сейчас элементарно нет исходных данных, — нет точки отсчета сейчас и "плановой" точки, скажем, через полгода. Разве не так?
Да, согласен.
Я думаю необходимо выразить текущую ситуация в каких-то цифрах, проанализировать их, если это возможно.
Вопрос только в каких.
Сейчас я могу подсчитать для каждого разработчика количество найденных ошибок, кол-во исправленных ошибок, кол-во выполненных задач, кол-во фейленных задач, кол-во строк C# (SQL не могу). Для тестировщиков могу подсчитать сколько ошибок они нашли, сколько проверили.
Возможно, этого будет достаточно для начала. Или нет?
Можно что-то еще?
Я, правда, пока не уверен, как на основе этих значений можно сформулировать план на пол года.
V_S>Кстати, отталкиваясь от первого сообщения, совершенно непонятно, есть ли у тебя реальные рычаги воздействия на ситуацию. Читай пост Геннадия Васильева от 18.06.08 20:01 и попытайся пободаться с руководством.
Вот именно. Никаких сейчас реальных рычагов, кроме личного примера и уговоров, нет.
Здравствуйте, Michael_E_Smrinov, Вы писали:
V_S>>А для того, чтобы создать экономические условия, стимулирующие эффективный и производительный труд, у тебя сейчас элементарно нет исходных данных, — нет точки отсчета сейчас и "плановой" точки, скажем, через полгода. Разве не так? M_E>Да, согласен. M_E>Я думаю необходимо выразить текущую ситуация в каких-то цифрах, проанализировать их, если это возможно. M_E>Вопрос только в каких.
Цифры получить нетрудно. Вся наука о метриках тебе в помощь. Остаётся неясным, что именно ты хочешь получить из этих цифр.
M_E>Сейчас я могу подсчитать для каждого разработчика количество найденных ошибок, кол-во исправленных ошибок, кол-во выполненных задач, кол-во фейленных задач, кол-во строк C# (SQL не могу). Для тестировщиков могу подсчитать сколько ошибок они нашли, сколько проверили. M_E>Возможно, этого будет достаточно для начала. Или нет? M_E>Можно что-то еще?
Можно всё, что хочешь, хоть количество нажатий на клавиши делённое на время, проведённое за компьютером.
M_E>Я, правда, пока не уверен, как на основе этих значений можно сформулировать план на пол года.
Сначала нужно разобраться с тем, план чего именно ты собираешься строить. Если это план по "повышению валовой выработки строк кода", то остаётся только сожалеть. Если план развития продукта — это другое дело.
V_S>>Кстати, отталкиваясь от первого сообщения, совершенно непонятно, есть ли у тебя реальные рычаги воздействия на ситуацию. Читай пост Геннадия Васильева от 18.06.08 20:01 и попытайся пободаться с руководством. M_E>Вот именно. Никаких сейчас реальных рычагов, кроме личного примера и уговоров, нет.
Смотри, фокус вот в чём. Люди на самом деле работают c приблизительно одинаковым темпом на всём протяжении своей трудовой деятельности. Вариации возможны, но в основном — незначительные и касаются тех, кто только начинает работать, т.е., примерно с опытом 1-3 года. Дальше максимум, который можно выжать — заставить людей отдавать работе больше времени, но здесь тоже пережимать опасно. Соответственно, лучшее, что ты как руководитель проекта можешь сделать, это, разумеется, ни в коем случае не подхлёстывать и прочим образом стимулировать "безошибочный код", а только расставить людей так, чтобы на выходе получился приемлемого качества продукт в приемлемые сроки. То есть, раздать соответствующие обязанности и контролировать их выполнение. Это и называется "организовать процесс". Дальше читай Гапертона, он много и по делу пишет.
Ну и ещё добавлю, что самый действенный способ ускорения разработки продукта — разработать и/или подобрать библиотеки, языки и технологии, соответствующие вашему проекту. Никакими "воспитательными практиками", стимуляциями, мотивациями аналогичного результата ты не добьёшься.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
> Смотри, фокус вот в чём. Люди на самом деле работают c приблизительно одинаковым темпом на всём протяжении своей трудовой деятельности. Вариации возможны, но в основном — незначительные и касаются тех, кто только начинает работать, т.е., примерно с опытом 1-3 года.
Здравствуйте, grosborn, Вы писали:
>> Смотри, фокус вот в чём. Люди на самом деле работают c приблизительно одинаковым темпом на всём протяжении своей трудовой деятельности. Вариации возможны, но в основном — незначительные и касаются тех, кто только начинает работать, т.е., примерно с опытом 1-3 года.
G>Сам-то понял что сказал?
Да, неточно выразился. Я имею в виду примерно следующее.
1. Зрелый специалист работает с приблизительно одинаковым темпом после своего, условно говоря, "становления". Под словом "темп" я имею в виду некую линейную характеристику, например, число строк или число ошибок за период времени. Здесь, конечно, будет разброс в зависимости от сложности задачи.
Естественно, если сама задача и средства её решения хорошо знакомы, то темп будет примерно одинаковым.
2. Изменения в этом показатели возможны пока специалист ещё "начинающий". Здесь, думаю, понятно — он чего-то боится, чего-то не знает, где-то регулярно и где-то долго думает, и т.п.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Michael_E_Smrinov, Вы писали:
M_E>>Я думаю необходимо выразить текущую ситуация в каких-то цифрах, проанализировать их, если это возможно.
Ну хорошо, выразишь ты ситуацию в цифрах. Любых. Неважно, что именно это будет, — хоть, как пишет Геннадий Васильев, "количество нажатий на клавиши, деленное на время, проведенное за компьютером". Дальше — что? Поскольку "реальных рычагов, кроме личного примера и уговоров, нет", могу предсказать реакцию разработчиков: "Начальник? Иди ты на..., начальник!"
Кроме этого, мне кажется, что если у тебя сейчас 17 разработчиков (18.06.08 15:47), то, если ты пытаешься управлять ими всеми сам — это ошибка. Ты просто физически не сможешь эффективно управлять таким количеством подчиненных. Не говоря уж о контроле ("сейчас это на уровне общих наблюдений").
> 1. Зрелый специалист работает с приблизительно одинаковым темпом после своего, условно говоря, "становления". Под словом "темп" я имею в виду некую линейную характеристику, например, число строк или число ошибок за период времени. Здесь, конечно, будет разброс в зависимости от сложности задачи. > > Естественно, если сама задача и средства её решения хорошо знакомы, то темп будет примерно одинаковым.
Нда? Странно... Таких примеров практически не встречал.
V_S>Кроме этого, мне кажется, что если у тебя сейчас 17 разработчиков (18.06.08 15:47), то, если ты пытаешься управлять ими всеми сам — это ошибка. Ты просто физически не сможешь эффективно управлять таким количеством подчиненных. Не говоря уж о контроле ("сейчас это на уровне общих наблюдений").
Нет, у меня 17 человек, но из них только 8 непосредственно разработчиков — остальные тестировщики, тех. саппорт и пр.
А так — да, конечно, 17-тью невозможно самому управлять.
Здравствуйте, grosborn, Вы писали:
G>Нда? Странно... Таких примеров практически не встречал.
Я знаю, что звучит это странно. Честно говоря, когда измерил — сам удивился. Ради интереса попробуй сам сделать такие же замеры (скажем — KLOC/Day на интервале в неделю, а лучше — месяц).
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
> G>Нда? Странно... Таких примеров практически не встречал. > > Я знаю, что звучит это странно. Честно говоря, когда измерил — сам удивился. Ради интереса попробуй сам сделать такие же замеры (скажем — KLOC/Day на интервале в неделю, а лучше — месяц).
А ну тогда понятно откуда такое неверное представление. Замерил за неделю — не изменилось, теперь в полной уверенности, что до конца жизни программист будет с такой производительностью работать. И вроде бы как исчезает необходимость темплейты учить или методики разрабатывать.
И у вас задачи разве не требуют каких-то мыслительных усилий? Разве не бывает так, что не можешь чего-то придумать с первого раза или проработать алгоритм качественно?
Здравствуйте, grosborn, Вы писали:
>> Я знаю, что звучит это странно. Честно говоря, когда измерил — сам удивился. Ради интереса попробуй сам сделать такие же замеры (скажем — KLOC/Day на интервале в неделю, а лучше — месяц). G>А ну тогда понятно откуда такое неверное представление. Замерил за неделю — не изменилось, ...
Я оговорился. Не "на интервале", а "с интервалом".
G>...теперь в полной уверенности, что до конца жизни программист будет с такой производительностью работать. И вроде бы как исчезает необходимость темплейты учить или методики разрабатывать.
Это-то здесь при чём? Темплейты не так уж и влияют на LOC/Day.
G>И у вас задачи разве не требуют каких-то мыслительных усилий? Разве не бывает так, что не можешь чего-то придумать с первого раза или проработать алгоритм качественно?
Человек же не всё время только и делает, что выдумывает шаблонные конструкции и глубоко продумывает алгоритмы, правильно? Он их ещё отлаживает, время от времени пишет документацию, где-то пишет код попроще, и т.п. Потому и метрики снимаются с некоторым интервалом.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Gaperton, Вы писали:
G>Добрый совет. Лучше делай не так. Заведи рассылку check-in, и напиши робота, который будет посылать туда письма при каждом коммите в репозиторий. В письме должен быть комментарий к коммиту, список файлов, ссылка на веб-интерфейс чтобы посмотреть пофайловые диффы. А еще — хорошо если робот посчитает новые/измененные/удаленные/все в сумме строки кода, без пустых, комментариев, и фигурных скобок. Чтоб был виден характер и объем изменений.
G>Эта рассылка полезна много чем. Во первых, конечно, ты видишь "поток работ", и тебя это успокаивает. Во-вторых, заинтересованным личностям удобно смотреть диффы. В третьих — им также виден объем изменений, и подсистемы, над которыми идет работа.
Вот этот совет мне очень понравился. Надо будет так и сделать.