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

M>когда я говорил про что "говорит что нужно времени в эн раз больше" это было далеко не в 2 раза больеш... а минимум в 3.. а то и 5ть

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

M>а вот и хрен.. ну кто? кто определит? если сама оценка трудоёмкости задачи иногда сложнее (т.е. дороже) решения самой задачи

Отслеживать адекватность оценки должны руководители, но оценивать должен сам программист. Ну вот посудите сами, если он на перекраску кнопки из зеленого в синий просит 8 часов, то вопрос о квалификации, производительности, эффективности и проч. снимается сразу.

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

>>> Но даже если лид не отслеживает этот процесс, то динамика показателя (монотонное повышение, понижение или колебание на одном уровне) может это сделать самостоятельно.

M>хм.. и через сколько ЛЕТ.. этот график покажет тенденцию? 1, 2, 3 ?

3-месячного испытатльного срока вполне достаточно.

M>НО создавая эту тему думал может всетаки прогресс дошел и до этого и придумали что-то такое эдакое..
Пока индустрия производства ПО не перейдет из стадии кустарной ручной разработки на стадию автоматической сборки, придется относится к рабочим данной технологии соответственно. Разработки в данном направлении ведутся. Наиболее перспективной мне видится вот эта

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

V_S>>Забудь.
V_S>>Если программист — (со)владелец фирмы, то ему причитается доля прибыли пропорционально его доле в уставном капитале, независимо от всех остальных факторов. Если же программист — просто наемный служащий, то ему причитается зарплата — hourly rate, оклад..., поскольку он просто продает 8 часов своего времени в день работодателю за фиксированную цену, и насколько эффективно используются эти 8 часов — не его проблемы, а забота работодателя.

M>спасибо. теперь многое стало ясно в таком ракурсе.

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

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

KPI для продавцов очень простой — процент от оборота.
KPI сисадмина — допустим, состоит из нескольких компонент (выдумываю на ходу — что для нас наиболее важно в его работе). Нет отказов сети и сервисов за месяц + 50 баксов. Нет задержек более дня по реакции на запросы пользователей — еще +100 баксов.

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

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

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

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

M>>НО создавая эту тему думал может всетаки прогресс дошел и до этого и придумали что-то такое эдакое..
FJ>Пока индустрия производства ПО не перейдет из стадии кустарной ручной разработки на стадию автоматической сборки, придется относится к рабочим данной технологии соответственно. Разработки в данном направлении ведутся. Наиболее перспективной мне видится вот эта

ок.. спасибо.. лянем..

спасибо.. было очень интересно читать.

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

V_S>Если же программист — просто наемный служащий, то ему причитается зарплата — hourly rate, оклад..., поскольку он просто продает 8 часов своего времени в день работодателю за фиксированную цену, и насколько эффективно используются эти 8 часов — не его проблемы, а забота работодателя.

Суровая правда жизни... Но, очевидно, не вся. В такую модель отношений между работником и нанимателем очень сложно вписать, например, такие вырожденные случаи: работник не делает за эти 8 часов ничего полезного; работник за 8 часов приносит пользы столько же, сколько все остальные вместе взятые.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Здравствуйте, Vlad_SP, Вы писали:

V_S>>Если же программист — просто наемный служащий, то ему причитается зарплата — hourly rate, оклад..., поскольку он просто продает 8 часов своего времени в день работодателю за фиксированную цену, и насколько эффективно используются эти 8 часов — не его проблемы, а забота работодателя.

ПК>Суровая правда жизни... Но, очевидно, не вся. В такую модель отношений между работником и нанимателем очень сложно вписать, например, такие вырожденные случаи: работник не делает за эти 8 часов ничего полезного; работник за 8 часов приносит пользы столько же, сколько все остальные вместе взятые.

Все хорошо вписывается.
В первом случае работник слишком дорого обходится фирме (получает деньги при нулевом выхлопе).
Какое-то время это прокатит (что не сстрашно) и это время зависит исключительно от работодателя.

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

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

ПК>>например, такие вырожденные случаи: работник не делает за эти 8 часов ничего полезного; работник за 8 часов приносит пользы столько же, сколько все остальные вместе взятые.

B>Все хорошо вписывается.
B>В первом случае работник слишком дорого обходится фирме (получает деньги при нулевом выхлопе).
B>Какое-то время это прокатит (что не сстрашно) и это время зависит исключительно от работодателя.

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

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

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

Здравствуйте, Павел Кузнецов, Вы писали:

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

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

В принципе можно придумать навороченную систему,
по котороя я бы до обеда зарабатывал 500 баксов,
потому что очень плодотворно поработал, а после обеда получился бы ноль,
потому что проторчал в RSDN. Но смысла в этом не много...

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

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

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

Ребята, вы какую-то нетого говорите

Зачем учитвать производительность? Да просто вы не доверяете свои людям. Тут копать в другую сторону нужно.

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

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

Так что просьте это бесполезнное занятие. И не тратье на него деньги заказчика.

Be Agile!

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

DM>Зачем учитвать производительность?

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

DM>>Зачем учитвать производительность?
ПК>Для честности. Иначе не вполне ясно, как может работник расчитывать на рост вознаграждения с ростом приносимой пользы.
1) А у него не просто спросить, что ему нужно, чтобы он приносил больше пользы?
2) А как может разработчик вашу честность проверить?
3) Это проблема доверия. Вы просто не доверяете своему программисту. При таком подходе мало кто будет хорошо работать.

Это напоминает стиль менеджмента "пряника и кнута". Кнутом — подчинённых, пряник ем сам.

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

DM>>>Зачем учитвать производительность?

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

DM>1) А у него не просто спросить, что ему нужно, чтобы он приносил больше пользы?

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

DM>2) А как может разработчик вашу честность проверить?

Благодаря открытости и участия всех членов команды в процессе взаимного review.

DM>3) Это проблема доверия. Вы просто не доверяете своему программисту.

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

DM>>>>Зачем учитвать производительность?
ПК>>>Для честности. Иначе не вполне ясно, как может работник расчитывать на рост вознаграждения с ростом приносимой пользы.
DM>>1) А у него не просто спросить, что ему нужно, чтобы он приносил больше пользы?
ПК>Чтобы рассуждать о больше/меньше, нужно иметь хоть какое-то представление о том, сколько приносится сейчас, не так ли?
А как честность и количество строк увязываются?

Если проблема поделить возросшую прибыль — можете со мной поделиться

DM>>2) А как может разработчик вашу честность проверить?
ПК>Благодаря открытости и участия всех членов команды в процессе взаимного review.
Ну если всё так отрыто — то и так видно участие каждого. Или не всё открыто?
А как происходят review?

DM>>3) Это проблема доверия. Вы просто не доверяете своему программисту.
ПК>1) Интересно, на чем основано данное мнение?
Желанием "посчитать", то есть проконтролировать. Когда я доверяю что-то делать я не контролирую его результат.
Я точно знаю, что он сделает качественно и максимум отдачи. Поэтому если вы хотите "считать" — вы ОЧЕНЬ сильно не доверяете.

ПК>2) Отчего в данном пункте я отделен от программиста, который к тому же назван моим? Я точно так же стремлюсь к тому, чтобы остальные в команде периодически пытались оценить приносимую мной команде пользу, и работаю на то, чтоб эта оценка была в мою пользу...
А зачем?

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

DM>>>>>Зачем учитвать производительность?
ПК>>>>Для честности. Иначе не вполне ясно, как может работник расчитывать на рост вознаграждения с ростом приносимой пользы.
DM>>>1) А у него не просто спросить, что ему нужно, чтобы он приносил больше пользы?
ПК>>Чтобы рассуждать о больше/меньше, нужно иметь хоть какое-то представление о том, сколько приносится сейчас, не так ли?

DM>А как честность и количество строк увязываются?

А откуда взялось количество строк? Об этом, по-моему, и речи не было. LOCs, сами по себе, вообще, утопия для измерения полезности деятельности разработчиков, а тестировщиков -- и подавно. К сожалению, как автоматизировать оценку полезности, я не знаю.

DM>Если проблема поделить возросшую прибыль — можете со мной поделиться

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

DM>>>2) А как может разработчик вашу честность проверить?
ПК>>Благодаря открытости и участия всех членов команды в процессе взаимного review.
DM>Ну если всё так отрыто — то и так видно участие каждого. Или не всё открыто?

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

DM>А как происходят review?

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

DM>>>3) Это проблема доверия. Вы просто не доверяете своему программисту.
ПК>>1) Интересно, на чем основано данное мнение?
DM>Желанием "посчитать", то есть проконтролировать. Когда я доверяю что-то делать я не контролирую его результат.
DM>Я точно знаю, что он сделает качественно и максимум отдачи. Поэтому если вы хотите "считать" — вы ОЧЕНЬ сильно не доверяете.

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

ПК>>2) Отчего в данном пункте я отделен от программиста, который к тому же назван моим? Я точно так же стремлюсь к тому, чтобы остальные в команде периодически пытались оценить приносимую мной команде пользу, и работаю на то, чтоб эта оценка была в мою пользу...

DM>А зачем?

Чтобы с помощью вот такой вот обратной связи убедиться, что то, что я делаю, действтительно помогает, а не только мне так кажется. Эдакое приемочное тестирование вместо того, чтобы полагаться "на авось". Правда, чем выше уровень человека, тем чувствительнее он сам к эффектам своей деятельности. Т.е. senior'у подобные review нужны меньше, и дают меньше информации. Team Leads получают еще меньше, т.к. просто кожей должны ощущать проблемы команды и оценивать результаты своего вмешательства в происходящее с гораздо большей регулярностью, чем можно позволить себе проводить reviews. Да и часть фокуса у них неизбежно находится за пределами команды, т.к. их полезность оценивается полезностью команды для других команд и компании вцелом.

ПК>А откуда взялось количество строк? Об этом, по-моему, и речи не было. LOCs, сами по себе, вообще, утопия для измерения полезности деятельности разработчиков, а тестировщиков -- и подавно. К сожалению, как автоматизировать оценку полезности, я не знаю.
А может не нужна эта полезность? а?

DM>>Если проблема поделить возросшую прибыль — можете со мной поделиться
ПК>Речь идет примерно о следующем. Скажем, за год зарплаты на рынке подросли, да и люди, если люди перспективные, и все в команде происходит нормально, тоже выросли. Для выравнивания зарплат в группе с рынком нужно только исследование последнего. А вот для того, чтобы оценить, на сколько пора поднимать компенсацию каждому в группе, нужно будет внимательно посмотреть на то, что он делает.
Всем одинково на процент инфляции + 5-15% годовых. Думаю выше крыши и все будут довольны, никакой дескриминации.

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

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

Кстати, мне интересно — как происходит у вас ревью.

DM>>Я точно знаю, что он сделает качественно и максимум отдачи. Поэтому если вы хотите "считать" — вы ОЧЕНЬ сильно не доверяете.
ПК>К сожалению, такой гармонии достичь не получается, т.к. на практике каждый делает с разными качеством и эффективностью. Соответственно, выйдет элементарно нечестно по отношению к тем, у кого получается лучше, если результаты их труда оцениваются наравне с теми, у кого получается не так хорошо.
А можно как-то сделать не с денежной точки зрения, а с практической/методологической, чтобы качество и эффективность у всех была суперская?


ПК>>>2) Отчего в данном пункте я отделен от программиста, который к тому же назван моим? Я точно так же стремлюсь к тому, чтобы остальные в команде периодически пытались оценить приносимую мной команде пользу, и работаю на то, чтоб эта оценка была в мою пользу...
DM>>А зачем?
ПК>Чтобы с помощью вот такой вот обратной связи убедиться, что то, что я делаю, действтительно помогает, а не только мне так кажется. Эдакое приемочное тестирование вместо того, чтобы полагаться "на авось". Правда, чем выше уровень человека, тем чувствительнее он сам к эффектам своей деятельности. Т.е. senior'у подобные review нужны меньше, и дают меньше информации. Team Leads получают еще меньше, т.к. просто кожей должны ощущать проблемы команды и оценивать результаты своего вмешательства в происходящее с гораздо большей регулярностью, чем можно позволить себе проводить reviews. Да и часть фокуса у них неизбежно находится за пределами команды, т.к. их полезность оценивается полезностью команды для других команд и компании вцелом.

Ничего не понял Всё как-то абстрактно-абстрактно
Как я понял
1) хочется обратной связи от других
2) хочется получить адекватную оценку своих действий
3) совсем не понятно, почему сениору не нужные ревью (может мы о разном говорим, расскажите о то что это такое у вас)
4) а тим-лиды -- вообще вымирующий слой по вашему описанию
5) а чем это тим-лид занимается, раз он так мало проводит время с командой?
6) кстати у всех есть желание сделать качественный продукт, а команду Dream Team?

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


Wanna quality? Be Agility!

denis miller,

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

DM>Всем одинково на процент инфляции + 5-15% годовых. Думаю выше крыши и все будут довольны, никакой дескриминации.

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

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

DM>А можно как-то сделать не с денежной точки зрения, а с практической/методологической, чтобы качество и эффективность у всех была суперская?

"Суперская" эффективность для senior -- одно, для junior -- совсем другое. Для оценки того, кто где находится, и нужно смотреть на то, что у кого получается. Если есть альтернативные идеи, кроме "всем одинаково" -- с удовольствием выслушаю.

DM>3) совсем не понятно, почему сениору не нужные ревью (может мы о разном говорим, расскажите о то что это такое у вас)

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

DM>4) а тим-лиды -- вообще вымирующий слой по вашему описанию

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

DM>5) а чем это тим-лид занимается, раз он так мало проводит время с командой?

А это откуда взялось-то?

DM>6) кстати у всех есть желание сделать качественный продукт, а команду Dream Team?

Да, и?

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

Что-то релевантность вопросов и реплик начинает снижаться до уровня, где общение продолжать хочется все меньше, меньше...