Здравствуйте, 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 завязанных на разнообразные формальные метрики.

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

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

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

И наконец, напомню:
— Есть ли способы управления женщинами?
— Да, два. Но оба не работают.

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

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

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

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

B>>А в какой мере это касается финансовой стороны?
B>>Для чего именно вам нужна оценка производительности программистов?

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

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

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

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

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

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

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

M>как можно измерить производительность программиста, реально ли это?
M>какие понятия и единицы измерения для этого используются?

Выбирайте по вкусу: рабочее время, SLOC, закрытые запросы (взвешенные по важности и сложности), субъективная оценка руководителя проекта

M>ясное дело что а не все ли равно.. но когда дело касается финансовой стороны, то это необходимо подсчитать.. но как?

Ничего из этого толком не работает.

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

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

но если не считать её никак то есть всего один существенный минус и он может быть решающим

по поиску. нашол один хороший пост

http://www.rsdn.ru/Forum/?mid=1505942

Автор: genre
Дата: 25.11.05

других не нашол.

denis miller,

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

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

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

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

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

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

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

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

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

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

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

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

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

Да, и?

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

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

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

M>ясное дело что а не все ли равно.. но когда дело касается финансовой стороны, то это необходимо подсчитать.. но как?

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

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

B>А в какой мере это касается финансовой стороны?
B>Для чего именно вам нужна оценка производительности программистов?

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

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

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

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

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

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

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

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

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

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

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

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

Be Agile!

Здравствуйте, 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. Да и часть фокуса у них неизбежно находится за пределами команды, т.к. их полезность оценивается полезностью команды для других команд и компании вцелом.

как можно измерить производительность программиста, реально ли это?
возможно ли это в принципе?
если да, то как?
какие понятия и единицы измерения для этого используются?

ссылки, книги, статьи, блоги на эту тему?

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

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

SS>Выбирайте по вкусу: рабочее время,

даже незнаю в каких областях разработки это эффективно... наверное в какой-то нетворческой..

>>SLOC,

вообще бред имхо..

>>закрытые запросы (взвешенные по важности и сложности),

вот это интересно... но кто как и чем будет мерить это?

>>субъективная оценка руководителя проекта

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

SS>Ничего из этого толком не работает.

да.. увы..

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

M>вот в том и сложность.. что оценка то субьетивная.. а сумма денег.. часовой рейти или зп — объективная цифра на данны момент времени..

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

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

>>>закрытые запросы (взвешенные по важности и сложности),

M>вот это интересно... но кто как и чем будет мерить это?

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

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

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

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

>>>>закрытые запросы (взвешенные по важности и сложности),

M>>вот это интересно... но кто как и чем будет мерить это?

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

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

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

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

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

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

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

в этом и дилемма..

короче нда

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

B>И получится так, что "несложные" вещи, которые однако делать надо,
B>никто делать не захочет, потому что за них денег мало дают...

Так и получается. А ведь Минздрав предупреждал.

...– Знаете, почему некоторые направления становятся общественно значимыми? — спросил Костёрыч. — Потому что ими никто не занимается. Вот для примера… Общественно значимая работа — мусорщик. Если бы все жители города свои пакеты с мусором сразу на свалку выносили за шестой километр, то и мусорщик не был бы общественно значим.

(С) А.Иванов "Блудо и мудо"

Здравствуйте, Magz, Вы писали:
>>>закрытые запросы (взвешенные по важности и сложности),
M>вот это интересно... но кто как и чем будет мерить это?

Чтобы можно было мерить, часто используют не просто "запрос", а "минимальное тестируемое требование".
От продукта к продукту оно конечно будет разное, но внутри одного продукта обычно более-менее одинаково.

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

M>как можно измерить производительность программиста, реально ли это?

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

Для программистов преимущество использования данного показателя состоит в в том, он сам может реально на него влиять и поэтому можно ожидать лояльного отношения к нему [показателю]. Он не сможет жаловаться на отсутсвие справедливости в мире: согласие на выполнение задач он дал, трудоемкость оценил сам (предполагаю, что в подавляющем большинстве проектов используется agile-методологии).

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

Показатель считаю весьма и весьма объективным. Достаточно посмотреть на оный у junior и senior-программеров.

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

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

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

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

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

M>>как можно измерить производительность программиста, реально ли это?

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

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

как такой расклад?

основная загвоздка — нельзя задание поменрить минимальным эталоном и тем самым в итоге измезить скокрость разных программеров..

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

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

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

M>>>как можно измерить производительность программиста, реально ли это?

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

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

Этот подход не очень выгоден программеру. Дело в том, что он не может совсем уж точно оценить время работы: иногда он заканчивает быстрее, чем планировал, иногда запаздывает. Предположим, он действительно сделал 8 часовую задачу за 4 часа, а остальное время халявил. Но примерно с такой же вероятность 4-часовая задача может превратится в 8-часовую. Если преположить, что трудоемкость всех задач, выполненных в реальности быстрее, будет выравниться, то очевидно, что с течением времени показатель отношения реальной трудоемкости к запланированной будет монотонно возрастать, а это уже индикатор раздолбайства. Описанный Вами вид "мошенничества" мог может иметь место только в том случае, если программер закладывает на задачу непропорционально большой буфер, но заметить этот факт квалифицированным лидом не составит труда. Но даже если лид не отслеживает этот процесс, то динамика показателя (монотонное повышение, понижение или колебание на одном уровне) может это сделать самостоятельно.

M>как такой расклад?

M>основная загвоздка — нельзя задание поменрить минимальным эталоном и тем самым в итоге измезить скокрость разных программеров..

Условный коеффициент полезности программера может выглядеть следующим образом: С = П*Т*К, где
П — наш показатель,
Т — запланированная трудоемкость,
К — коэффициент сложности работы.
Придумывать сложные формулы в текущих реалиях нет абсолютно никакого смысла. Увы, индустрия разработки ПО не достигла такого степени автоматизации, чтобы для неё можно было бы применять точные формулы, специфичные для конвейерного производства. Яркий пример бесполезности такого занятия можно наблюдать, например, в компании CBOSS, руководство которой очень любит придумывать извращенные формулы для подсчета всевозможных показателей впоть до уровня меритократичности сотрудника.

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

FJ>Этот подход не очень выгоден программеру. Дело в том, что он не может совсем уж точно оценить время работы: иногда он заканчивает быстрее, чем планировал, иногда запаздывает. Предположим, он действительно сделал 8 часовую задачу за 4 часа, а остальное время халявил. Но примерно с такой же вероятность 4-часовая задача может превратится в 8-часовую. Если преположить, что трудоемкость всех задач, выполненных в реальности быстрее, будет выравниться, то очевидно, что с течением времени показатель отношения реальной трудоемкости к запланированной будет монотонно возрастать, а это уже индикатор раздолбайства.

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

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

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

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

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

FJ>Условный коеффициент полезности программера может выглядеть следующим образом: С = П*Т*К, где
FJ>П — наш показатель,
FJ>Т — запланированная трудоемкость,
FJ>К — коэффициент сложности работы.
FJ>Придумывать сложные формулы в текущих реалиях нет абсолютно никакого смысла. Увы, индустрия разработки ПО не достигла такого степени автоматизации, чтобы для неё можно было бы применять точные формулы, специфичные для конвейерного производства. Яркий пример бесполезности такого занятия можно наблюдать, например, в компании CBOSS, руководство которой очень любит придумывать извращенные формулы для подсчета всевозможных показателей впоть до уровня меритократичности сотрудника.

согласен. я о том же.прямую и даже приблизительно прикинуть невозможно.. только косвенно.. 10ю и более факторами оценки..

НО создавая эту тему думал может всетаки прогресс дошел и до этого и придумали что-то такое эдакое..

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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 часов — не его проблемы, а забота работодателя".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ПК>А откуда взялось количество строк? Об этом, по-моему, и речи не было. 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!