Comments 44
По пункту 3 полностью с Вами согласен.
«Когда вы поднимаетесь слишком высоко, наполненный абстракциями, вы задыхаетесь из-за отсутствия кислорода. Иногда мыслители просто не знают, когда остановиться, и они создают абсурдные, всеобъемлющие, высокоуровневые картины устройства вселенной, которые являются хорошими и изящными, но фактически не означают вообще ничего.» Дж.Спольски
Лучше и не скажешь.
«Когда вы поднимаетесь слишком высоко, наполненный абстракциями, вы задыхаетесь из-за отсутствия кислорода. Иногда мыслители просто не знают, когда остановиться, и они создают абсурдные, всеобъемлющие, высокоуровневые картины устройства вселенной, которые являются хорошими и изящными, но фактически не означают вообще ничего.» Дж.Спольски
Лучше и не скажешь.
Можно сказать: KISS. По сути дела — о том же.
Про уровни абстракции тут думаю разночтения просто. Можно использовать абстрактное мышление, чтобы городить кучу абстрактных классов, а можно это же мышление использовать во благо, ища простые пути, обобщая задачи в поставленной проблеме. Эффективно обобщая, исключая создание лишних сущностей.
Исчерпывающе этот вопрос освещён в книге «Руководство Джоэла Спольски по подбору программистов и управлению ими». Некоторые из материалов книги доступны в блоге автора книги, в том числе по-русски.
Вообще, я согласен с таким мнением: целью программной разработки является решение бизнес-задач клиента.
Поэтому оплата должна быть привязана только к этому критерию: решена задача или нет.
Правильным подходом является оценка работы всей команды проекта целиком. Лидер же проекта должен быть уполномочен сам принимать решения о вкладе и об эффективности того или иного участника.
В реальной жизни польза от участия человека в команде измеряется даже не его личным результатом, а тем, как он влияет на результативность команды вцелом. То есть программист Вася может быть мега-гуру, но он так гнобит других участников, что у тех опускаются руки, появляется куча ошибок и усиливается желание уволиться. А вот юная тестировщица Маша не блещет числом найденных ошибок, зато она так разговаривает с программистами, что те потом два дня работают с КПД 150%.
Бремя объективной оценки личного вклада участников целиком и полностью ложится на менеджера низшего звена — непосредственного начальника конечных исполнителей. Он сам уже может по совокупности формальных параметров и личных наблюдений делать выводы. При этом, конечно, полезным будет наличие максимально детальной статистики, включающей формальные показатели разработчиков. Но напрямую (по формуле) увязывать оплату труда с этими показателями ни в коем случае нельзя — реальная жизнь всегда разнообразнее любой модели.
Поэтому оплата должна быть привязана только к этому критерию: решена задача или нет.
Правильным подходом является оценка работы всей команды проекта целиком. Лидер же проекта должен быть уполномочен сам принимать решения о вкладе и об эффективности того или иного участника.
В реальной жизни польза от участия человека в команде измеряется даже не его личным результатом, а тем, как он влияет на результативность команды вцелом. То есть программист Вася может быть мега-гуру, но он так гнобит других участников, что у тех опускаются руки, появляется куча ошибок и усиливается желание уволиться. А вот юная тестировщица Маша не блещет числом найденных ошибок, зато она так разговаривает с программистами, что те потом два дня работают с КПД 150%.
Бремя объективной оценки личного вклада участников целиком и полностью ложится на менеджера низшего звена — непосредственного начальника конечных исполнителей. Он сам уже может по совокупности формальных параметров и личных наблюдений делать выводы. При этом, конечно, полезным будет наличие максимально детальной статистики, включающей формальные показатели разработчиков. Но напрямую (по формуле) увязывать оплату труда с этими показателями ни в коем случае нельзя — реальная жизнь всегда разнообразнее любой модели.
1. за то время что другие делают одну задачу — я сделаю 5.
за то время что один человек делает одну задачу мне мои 5 раз вернут тестеры( с жуткими багами )
результат:
я — 2-3 задачи за интервал + куча потереных нервных клеток у тестеров
сосед — одну задача, 100% рабочая версия.
3+5. Надо было доработать немного код( примерно на 3 часа работы )
Доработал, посмотреть, стер, переписал базовый фрейворк, еще раз стер, переписал, запустил, подумал.
Прошло пять месяцев. На выходе идеальная конфетка.
Но из-за одного модуля были переписаны практически все остальные.
Хотя, если честно, это того стоило
К томуже быстрая и немного «дерганая» моя работа сильно расширяет кругозор :)
за то время что один человек делает одну задачу мне мои 5 раз вернут тестеры( с жуткими багами )
результат:
я — 2-3 задачи за интервал + куча потереных нервных клеток у тестеров
сосед — одну задача, 100% рабочая версия.
3+5. Надо было доработать немного код( примерно на 3 часа работы )
Доработал, посмотреть, стер, переписал базовый фрейворк, еще раз стер, переписал, запустил, подумал.
Прошло пять месяцев. На выходе идеальная конфетка.
Но из-за одного модуля были переписаны практически все остальные.
Хотя, если честно, это того стоило
К томуже быстрая и немного «дерганая» моя работа сильно расширяет кругозор :)
Посчитаем?
«я — 2-3 задачи за интервал + куча потереных нервных клеток у тестеров
сосед — одну задача, 100% рабочая версия.»
Т.е. ваш сосед — в одиночку делает 1 задачу за интервал времени, в то время как вы вместе с тестерами (судя по множественному числу, их ещё и не один) делаете 2 задачи. И того, эффективность соседа 1:1=1, ваша — 2:3=2/3.
Увы, ваш подход неэффективен, если важна стоимость продукта, а не время разработки.
«я — 2-3 задачи за интервал + куча потереных нервных клеток у тестеров
сосед — одну задача, 100% рабочая версия.»
Т.е. ваш сосед — в одиночку делает 1 задачу за интервал времени, в то время как вы вместе с тестерами (судя по множественному числу, их ещё и не один) делаете 2 задачи. И того, эффективность соседа 1:1=1, ваша — 2:3=2/3.
Увы, ваш подход неэффективен, если важна стоимость продукта, а не время разработки.
тестеры дешевле.
и они тестят всеравно чем програмеры програмят
и они тестят всеравно чем програмеры програмят
и по времени работы кажется тоже неэффективен.
100% рабочая сферическая версия в вакууме единожды приемочно оттестированная пусть будет эталоном…
Тогда «я — 2-3 задачи за интервал + куча потереных нервных клеток у тестеров» — где куча потерянных нрвных клеток -хотя бы однократное повторение сферического в вакууме тестирования (* на число задач) плюс время на локализацию/фиксирование/перепроверку касяков, коими кишат задачи и непонятно до каких пор кишить будут.
Управиться в срок с задачей возможно, если только «отдраивать» ее будет вся королевская более дешевая рать…
Остальные задачи на тестирование получается нервно курят в уголках…
Это все в защиту тестеров от monkey testing))Обязательно поправьте, если не права.
И еще, меньшее количество очевидных ошибок у хорошего тестера порождает желание изобретать более хитрые способы их искать, а у разработчиков какое-то чувство ответственности…
То, что все это должно быть без фанатизма (как нечистоплотность кода так и его вылизанность)-тут с автором сложно поспорить.
100% рабочая сферическая версия в вакууме единожды приемочно оттестированная пусть будет эталоном…
Тогда «я — 2-3 задачи за интервал + куча потереных нервных клеток у тестеров» — где куча потерянных нрвных клеток -хотя бы однократное повторение сферического в вакууме тестирования (* на число задач) плюс время на локализацию/фиксирование/перепроверку касяков, коими кишат задачи и непонятно до каких пор кишить будут.
Управиться в срок с задачей возможно, если только «отдраивать» ее будет вся королевская более дешевая рать…
Остальные задачи на тестирование получается нервно курят в уголках…
Это все в защиту тестеров от monkey testing))Обязательно поправьте, если не права.
И еще, меньшее количество очевидных ошибок у хорошего тестера порождает желание изобретать более хитрые способы их искать, а у разработчиков какое-то чувство ответственности…
То, что все это должно быть без фанатизма (как нечистоплотность кода так и его вылизанность)-тут с автором сложно поспорить.
Думаю критерии эффективности (личной, не team-work) это:
E = m/c
где,
m — количество полностью законченных фич (в предварительно человеко-часах, по предварительной оценке всей комманды)
c — количество реально потраченного времени на эти фичи. Учитывая написание, текстирование, дебаггинг и рефакторинг (когда через пол-года вдруг поломалось от всяких побочных эффектов).
В итоге, фактически, получается отношение оценочного времени к фактическому. Эффективность при этом должна стремиться к единице. Выше/ниже будет если оценки комманды всегда завышены/занижены, но это тоже показательно.
Team-working я предлагаю не учитывать, так как чем этот критерий выше, тем ниже личная эффективность. Кроме того это не S.M.A.R.T. показатель, как и скажем чувство юмора, которое тоже важно в комманде.
Правда чтобы формула выше работала, необходимо чтобы один человек отвечал за одну фичу. Но по-моему это так и должно быть: придумал сомнительную архитектуру? доказал с пеной у рта? — ну и мучайся сам. Потратишь много времени — упадет эффективность, а значит (например) снизится зарплата. Возможно это неэффективно с точки зрения результата, но зато позволяет впоследствие видеть кому стоит поручать сложные решения, а кому нет.
E = m/c
где,
m — количество полностью законченных фич (в предварительно человеко-часах, по предварительной оценке всей комманды)
c — количество реально потраченного времени на эти фичи. Учитывая написание, текстирование, дебаггинг и рефакторинг (когда через пол-года вдруг поломалось от всяких побочных эффектов).
В итоге, фактически, получается отношение оценочного времени к фактическому. Эффективность при этом должна стремиться к единице. Выше/ниже будет если оценки комманды всегда завышены/занижены, но это тоже показательно.
Team-working я предлагаю не учитывать, так как чем этот критерий выше, тем ниже личная эффективность. Кроме того это не S.M.A.R.T. показатель, как и скажем чувство юмора, которое тоже важно в комманде.
Правда чтобы формула выше работала, необходимо чтобы один человек отвечал за одну фичу. Но по-моему это так и должно быть: придумал сомнительную архитектуру? доказал с пеной у рта? — ну и мучайся сам. Потратишь много времени — упадет эффективность, а значит (например) снизится зарплата. Возможно это неэффективно с точки зрения результата, но зато позволяет впоследствие видеть кому стоит поручать сложные решения, а кому нет.
По-моему, вполне можно было, подсократив, поместить в качестве ответа на исходный топик
Хотя желание организовать что-то по типу переписки Энгельса с Каутским тоже понять можно :)
Хотя желание организовать что-то по типу переписки Энгельса с Каутским тоже понять можно :)
Не работника лечить нужно через «оценку эффективности», а процесс. Если много ошибок — значить среда создана соответствующая. И не руки рубить нужно — а голову лечить :)
Ну влияет процесс (и глобальное потепление, и мировой кризис, и цены на ред булл) на эффективность, а какой смысл его рассматривать в данном случае? Он в команде на всех одинаково влияет.
Предлагаю отличать процесс разработки в ИТ от глобальных изменений.
То что, кто-то выдаёт меньше кода говорит лишь о пробелах знаний в контекте проекта. И совершенно никак не характеризуют личность. Оценка производительности — это попытка посчитать личность, а отсюда — привет мотивации, так как в команде кто-то будет лучше, кто-то хуже. Мы создаём оценкой «внутренний», совершенно невидимый и неосозноваемый конфликт на ровном месте. Кстати, крики оппонентов, что такого конфликта нет лишь доказывает, что этот конфликт очень скрыт. И не каждый его просто так расскроет во враждебной для себя команде (где меряют и потом ещё и начинают давить — мол повышай производительность).
Можно это интерпретировать как «сам дурак» (что часто делается) и плюс навешать ярлык «мы оценили твою эффективность — ты лузер». А можно задаться вопросом — почему? В ИТ за десятилетия выработаны разнообразные практики как улучшать культуру разработки, которая приводит к выравниванию производительности инженеров в любом проекте. Конечно, некоторые навыки требуют практики, чтобы их получить — но это стратегичекий шаг и здравствуй ситуационный менеджмент, коучинг, менторство, парное программирование и Agile.
То что, кто-то выдаёт меньше кода говорит лишь о пробелах знаний в контекте проекта. И совершенно никак не характеризуют личность. Оценка производительности — это попытка посчитать личность, а отсюда — привет мотивации, так как в команде кто-то будет лучше, кто-то хуже. Мы создаём оценкой «внутренний», совершенно невидимый и неосозноваемый конфликт на ровном месте. Кстати, крики оппонентов, что такого конфликта нет лишь доказывает, что этот конфликт очень скрыт. И не каждый его просто так расскроет во враждебной для себя команде (где меряют и потом ещё и начинают давить — мол повышай производительность).
Можно это интерпретировать как «сам дурак» (что часто делается) и плюс навешать ярлык «мы оценили твою эффективность — ты лузер». А можно задаться вопросом — почему? В ИТ за десятилетия выработаны разнообразные практики как улучшать культуру разработки, которая приводит к выравниванию производительности инженеров в любом проекте. Конечно, некоторые навыки требуют практики, чтобы их получить — но это стратегичекий шаг и здравствуй ситуационный менеджмент, коучинг, менторство, парное программирование и Agile.
>Ну и в заключении, как только вы начнете платить программисту
…
>Ну и в заключении:
Как Вы всех пересажать-то стремитесь…
…
>Ну и в заключении:
Как Вы всех пересажать-то стремитесь…
1) Меньше ошибок — более эффективный работник.
Не было сказанно, что ошибок не будет.
Во первых программист должен писать тесты — для функционала его библиотеки и обязательно сам пробежаться полностью по функционалу хотя-бы один раз перед передачей на тест. 50% ошибок будут удаленны СРАЗУ, а не через тестера.
Ну а то, что могут возникнуть ошибки при заливке 2 Гб — это само-собою уже проблема совсем другого порядка — этим действительно должен заниматься тестер.
2) www.artlebedev.ru/kovodstvo/sections/148/ — прочтите.
4) Нахрена нужны компании I и G сотрудники, которые не мотивированны? Или вы считаете, что много денег достаточно, чтобы человек стал самомотивирован? Да, он пойдет, если предложат хорошие деньги. Но я уверен, что туда берут специалистов, которые желают саморазвиваться и реализовываться на новых проектах.
Не было сказанно, что ошибок не будет.
Во первых программист должен писать тесты — для функционала его библиотеки и обязательно сам пробежаться полностью по функционалу хотя-бы один раз перед передачей на тест. 50% ошибок будут удаленны СРАЗУ, а не через тестера.
Ну а то, что могут возникнуть ошибки при заливке 2 Гб — это само-собою уже проблема совсем другого порядка — этим действительно должен заниматься тестер.
2) www.artlebedev.ru/kovodstvo/sections/148/ — прочтите.
4) Нахрена нужны компании I и G сотрудники, которые не мотивированны? Или вы считаете, что много денег достаточно, чтобы человек стал самомотивирован? Да, он пойдет, если предложат хорошие деньги. Но я уверен, что туда берут специалистов, которые желают саморазвиваться и реализовываться на новых проектах.
2) www.artlebedev.ru/kovodstvo/sections/148/ — прочтите.
Разве там о программистах речь? Здесь зачастую на первый план выходят другие правила (инициатива трахает инициатора — например). Особенно если цель поставлена чётко и недвусмысленно — тупо удовлетворить заказчика не занимаясь при этом никакой самодеятельностью.
>Особенно если цель поставлена чётко и недвусмысленно — тупо удовлетворить заказчика не занимаясь при этом никакой самодеятельностью.
А какая интересно еще бывает цель? Если заказчик доволен, то и исполнителю воздается соответственно, корреляция довольно хорошая. Вот если исполнитель начинает помимо тупого удовлетворения заказчика еще и интеллектуально удовлетворять себя, тут возможны нюансы :)
А какая интересно еще бывает цель? Если заказчик доволен, то и исполнителю воздается соответственно, корреляция довольно хорошая. Вот если исполнитель начинает помимо тупого удовлетворения заказчика еще и интеллектуально удовлетворять себя, тут возможны нюансы :)
Предугадывание будущих пожеланий заказчика один из таких нюансов :) Имхо, стоит делать функциональность приложения малой кровью расширяемой, даже если этого нет в ТЗ, зато когда заказчик захочет добавить фичу не надо будет переписывать всё с нуля, то есть или предложить заказчику более выгодные условия по сравнению с конкурентами, которым надо будет всё писать с нуля, а вам только фичу реализовать, ну или впарить заказчику, что всё надо будет переделывать с нуля, а фактически заниматься только реализацией фичи :)
Программисты решают свои задачи. Я по несколько раз иногда решаю одну и туже задачу (на разных проектах) и каждый раз совершенствую код и решение, используя новые пути решения, делая код более ясным, прозрачным и красивым. Как раз и превнося в код смысл.
Думаю речь не о деньгах (про деньги ничего не сказано), а именно о мотивации — одно дело работать в стартапе, решая традиционные по большому счёту задачи (большинство стартапов, пиарящихся на хабре, это, по-моему, прежде всего идея (плюс юзабилити и дизайн), техническая реализация (движок) как таковая сложности не представляет особой, много кода — может быть, но вот алгоритмизация, по-моему, тривиальна), а совсем другое — во всемирно известном гиганте и заниматься не «натягиванием вёрстки», а чем-то граничащим с научными исследованиями. По-моему, достаточная мотивация при равных объективных (уровень зп, соцпакет и т. д.) условиях работы.
Вы оцениваете работников… А какие усилия Вы сами приложили, как руководитель, чтобы у ваших подчиненных были лучше условия и соответственно отдача труда? Сменили одного программиста на другого?
Как-то я так и не понял как же оценивать эффективность работника… :)
Упомянутый мной Спольски, по этому поводу написал достаточно много, и в целом я с ним согласен.
Вам нужны толковые люди, умеющие делать дело. И если у них будет высокая внутренняя мотивация, то вы получите лучшую команду в мире.
Уже был пример выше в коментах, про тестировщицу. Я приведу еще один.
У меня на одном из предыдущих мест работы был в подчинении программист, который писал достаточно мало кода, но он постоянно исследовал новые технологии, предлагал оригинальные решения, да в конце концов своей заинтересованностью он сплачивал команду. Вот как оценить его эффективность?
Вам нужны толковые люди, умеющие делать дело. И если у них будет высокая внутренняя мотивация, то вы получите лучшую команду в мире.
Уже был пример выше в коментах, про тестировщицу. Я приведу еще один.
У меня на одном из предыдущих мест работы был в подчинении программист, который писал достаточно мало кода, но он постоянно исследовал новые технологии, предлагал оригинальные решения, да в конце концов своей заинтересованностью он сплачивал команду. Вот как оценить его эффективность?
А надо ли? Особенно если планирование бюджетов находится на уровне «э… пусть все будут работать по 8 часов в день, а мы будем им платить по ставке». Т.е. когда компании в принципе не способны подсчитать стоимость отдельных действий и оценить их влияние на результат.
Доказательство от обратного. Если бы компании могли бы это сделать (и речь сдесь не только об ИТ), то понятия 8-ми часового рабочего дня, для работников не связанных с обеспечением непрерывности бизнеса (продавцы, поддержка и т.д.), просто не существовало бы уже.
Существует огромный дефицит систематизации самой организации труда и я не вижу как можно было бы решить задачу для отдельных её (организации) частей. Поэтому попытки оценить эффективность в рамках неэффективной организации труда будут неуниверсальны.
Доказательство от обратного. Если бы компании могли бы это сделать (и речь сдесь не только об ИТ), то понятия 8-ми часового рабочего дня, для работников не связанных с обеспечением непрерывности бизнеса (продавцы, поддержка и т.д.), просто не существовало бы уже.
Существует огромный дефицит систематизации самой организации труда и я не вижу как можно было бы решить задачу для отдельных её (организации) частей. Поэтому попытки оценить эффективность в рамках неэффективной организации труда будут неуниверсальны.
Я не понял: в пункте 2 «Генераторы идей много раз эффективнее потребителей идей» вы вроде как обосновали неэффективность генераторов, здесь вы похвалили генератора. Каково же, всё-таки, ваше мнение?
Моё мнение: в команде (небольшой) обязательно должен быть один генератор и один гуру. Остальные могут быть середнячками, «твёрдыми троешниками». Эти два человека будут тащить весь проект, создавая его костяк. «Мясо» будут добавлять троешники. Причём генератор и гуру дополняют друг друга. Генератор вносит «возмущения» в процесс разработки, гуру служит фильтром, сглаживая их. Стандартный процесс эволюции систем.
Моё мнение: в команде (небольшой) обязательно должен быть один генератор и один гуру. Остальные могут быть середнячками, «твёрдыми троешниками». Эти два человека будут тащить весь проект, создавая его костяк. «Мясо» будут добавлять троешники. Причём генератор и гуру дополняют друг друга. Генератор вносит «возмущения» в процесс разработки, гуру служит фильтром, сглаживая их. Стандартный процесс эволюции систем.
К чему это я? Да все к тому, что вы заплатите программисту в 2-3 раза больше за проведенное тестирование, чем человеку отвечающему только за тестирование.
Разрешите по этому поводу не согласится. Это из п. 1. Если платить тестировщикам наравне с разработчиками (я как тестер, понятное дело, решительно за такую уравниловку), то это уже не будет аргументом. Никто не ждёт от разработчиков, что они будут тратить время на профессинальное тестирование. Но сделать какие-то проверки по работоспособности написаного всё-таки надо. Иначе, как тут уже писали, получается несколько итераций и в результате — взамен лишнего потраченого полу-часа/часа одного разработчика, тратиться куча времени на тестирование, оформление дефектов, пересборки продукта и тд. А хуже всего, что автор кода за это время выпадает из контектса и вполне возможно уже окучивает совсем другую часть проекта.
И поверьте, нам тестерам намного приятнее работать с аккуратными разработчиками, чем с теми, кто считает, что есть специальные (низкооплачиваемые — почему?) люди, которым можно спихнуть — пусть ищут.
Разрешите по этому поводу не согласится. Это из п. 1. Если платить тестировщикам наравне с разработчиками (я как тестер, понятное дело, решительно за такую уравниловку), то это уже не будет аргументом. Никто не ждёт от разработчиков, что они будут тратить время на профессинальное тестирование. Но сделать какие-то проверки по работоспособности написаного всё-таки надо. Иначе, как тут уже писали, получается несколько итераций и в результате — взамен лишнего потраченого полу-часа/часа одного разработчика, тратиться куча времени на тестирование, оформление дефектов, пересборки продукта и тд. А хуже всего, что автор кода за это время выпадает из контектса и вполне возможно уже окучивает совсем другую часть проекта.
И поверьте, нам тестерам намного приятнее работать с аккуратными разработчиками, чем с теми, кто считает, что есть специальные (низкооплачиваемые — почему?) люди, которым можно спихнуть — пусть ищут.
Еще кстати про оценку эффективности. Я писал такой вариант для тестировщиков, но и для разработчиков подойдёт.
CTRL+Enter
Спросите у ваших тестеров чей код они хотят тестировать. Например: написать анонимно три фамилии програмистов. Увидете — выберут лучших (самых эффективных, если хотите) — как в детстве когда во дворе в футбол играли.
Вы думаете тестировщикам нравится когда много багов? Конечно же нет. Нравится когда все работает хорошо.
Спросите у ваших тестеров чей код они хотят тестировать. Например: написать анонимно три фамилии програмистов. Увидете — выберут лучших (самых эффективных, если хотите) — как в детстве когда во дворе в футбол играли.
Вы думаете тестировщикам нравится когда много багов? Конечно же нет. Нравится когда все работает хорошо.
ещё никто и никогда не сумел найти формулу оценки производительности програмистов, хотя и очень многие пытались.
Проблема состоит в частности в том что программисты в виды особенностей профессии очен хорошо умеют оптимизировать всевозможные метрики.
если начислятъ зарплату по строкам кода — ну тут получится куча г. очень большая куча.
если по кол-ству починенных багов — сначала багов наваяют, потом будут чинить
если обратно кол-ству найденных багов, будут до хрипоты спорить с тестерами или принимать баги на починку «из под полы», без занесения в тракер. либо тратиь невменяемо много времени на тестинг, заменяя собой QA.
и т.д. и т.п.
задача в принципе не решаема. еффективность не может быть оценена никакой формулой.
но, это не всё!
монгие исследования показали что так назывармый «performance based compensation» т.е. оплата по производительности, даже если удается каким-то образом устроить (бонусы за вовремя зданный проект и т.д.), обыйно приводит к потере мотивации у работников. По тем-же исследованиям лучшей мотивацией служат увлекательная работа и оценка окружающих.
Проблема состоит в частности в том что программисты в виды особенностей профессии очен хорошо умеют оптимизировать всевозможные метрики.
если начислятъ зарплату по строкам кода — ну тут получится куча г. очень большая куча.
если по кол-ству починенных багов — сначала багов наваяют, потом будут чинить
если обратно кол-ству найденных багов, будут до хрипоты спорить с тестерами или принимать баги на починку «из под полы», без занесения в тракер. либо тратиь невменяемо много времени на тестинг, заменяя собой QA.
и т.д. и т.п.
задача в принципе не решаема. еффективность не может быть оценена никакой формулой.
но, это не всё!
монгие исследования показали что так назывармый «performance based compensation» т.е. оплата по производительности, даже если удается каким-то образом устроить (бонусы за вовремя зданный проект и т.д.), обыйно приводит к потере мотивации у работников. По тем-же исследованиям лучшей мотивацией служат увлекательная работа и оценка окружающих.
Рад, что моя тема заставляет людей задуматься :)
Sign up to leave a comment.
Re: Способы оценки эффективности работника