baxton_ulf wrote:
> Здравствуйте, Michael_E_Smrinov, Вы писали:
>
> 0rc>>Предлаю считать строчки кода. Это реально работает
> M_E>Не думаю. Если ты пишешь больше кода, это не значит, что у тебя производительность или качество выше.
>
> а как на счет: 1/"ко-во строк кода"?

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

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

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

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

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

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

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

Это не метрика, так что тут и ломать нечего. Это необъективная "экспертная оценка".

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

M_E>Уважаемые опытные коллеги, мне необходима ваша помощь в вопросе мотивации разработчиков.

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

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

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

Пишу по памяти. Поэтому без четких формул. Если нужны делали — спрашивайте по мылу.

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

V_S>>А зачем? Какова конечная цель поднятия этой самой мифической "производительности труда"?
M_E>Ну тут сразу несколько целей.
M_E>1. Чтобы не расхолаживать коллектив. Если разработчики будут работать хуже то удовлетворенность пользователей и клиентов будет снижаться, и в результате компания будет терять свои конкурентные преимущества.

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

M_E>2. Соответственно, чтобы повысить объем выполняемых работ, через это предоставить больше сервиса пользователям и клиентам.

А может вопрос поставить так: "сколько нам нужно новых человеко-ресурсов, чтобы удовлетворить потребности клиентов"?

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

.....


я девелопер со стажем, тимлид итп...

Человек когда идет на работу — заинтересован в деньгах!, +в интересном проекте или учебе — повышении квалификации, новым технологиям. Боязнь прогаммиста потерять один (или комбинацию) из этих факторов (и затруднение с находкой замены — другой подобной или лучшей работы) и есть наилучшая мотивация. Программисты работающие у вас согласились работать именно из-за одной из этих вещей. Со стажем интерес к работе пропадает, проект кажется менее интересным, опыт повышается, легче найти новое место, ...ессно надо что-то менять. Помагает:
— ПРЯНИК: "подогрев" этих же факторов в разумной мере.
— ПЛЕТКА: предупреждение о увольнении и увольнение в тяжелых случаях особо отстающих.
Контроль и оценку кому пряника, а кому плеткой, не знаю как у вас, но я со своей позиции тимлида вижу на 100%. Ну а теперь дело за малым — начальнику раздать тимлидам ограниченное кол-во плеток и побольше пряников

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

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


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


Ищете мартышек, самозабвенно работающих за связку бананов? Звучит как-то так...

A>P.S. Прошу прощения за сумбурное изложение
Отличное, заметим, изложение