Re: Способы оценки эффективности работника

    Для комментария к топику многовато, поэтому, с вашего позволения отвечу топиком.

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


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

    1. Меньше ошибок — более эффективный работник
    Данный постулат выдвигает идею: программист не делающий ошибок (экстраполяция требования меньше ошибок), выгоден компании. Вам рассказать кто не делает ошибок? (Ну если интересно, то сюда).
    Теперь, посмотрим с экономической точки зрения. Например, вы как разработчики реализуете метод загрузки файла на веб-сервер. Вы проверили базовые вещи: загрузка пустого файла, загрузка маленького файла, загрузка файла чуть побольше. И передали в отдел тестирования. Где специалист по тестированию проверил, как отрабатывает форма загрузку файла размером 2 ГБ. Проверяет он на каналах 10Мб/с, 2 Мб/с, 1Мб/с, 0.5Мб/с. Рассказать сколько это займет времени? А добавьте к этому проверку обрывов связи, отработку переполнения хранилища и много чего еще. К чему это я? Да все к тому, что вы заплатите программисту в 2-3 раза больше за проведенное тестирование, чем человеку отвечающему только за тестирование. Да, программист должен проводить тестирование методом «белого ящика»! Но программист который переходит разумные границы в этом вопросе — зло. Кстати, вот это тоже вспомнилось [1]. Ну и в заключении, как только вы начнете платить программисту за то что у него мало ошибок, он договориться с тестировщиком, а премию они поделят.

    2. Генераторы идей много раз эффективнее потребителей идей
    Здесь, даже как-то стыдно отвечать… Вот как Вам кажется, кто для вашей компании лучше, человек генерирующий в час 100 идей, загорающийся ими, увлекающий за собой… Но также быстро остывающий и перекидывающийся на следующую идею. Или сотрудник, генерирующий в год, может быть одну стоящую идею, но доводящий ее до реализации.
    Ну а «Потому что им интересно изобретать велосипеды, и ни в коем случае нельзя отбирать у них эту возможность. » — даже и не знаю… В ВУЗе, в исследовательском центре, в отделе тестирования… Но разработчик изобретающий велосипеды в рамках коммерческого проекта, в большинстве случаев — зло. [2]

    3. Чем более абстрактное мышление, тем эффективнее работник
    Мне встречались пару раз «архитекторы», превращавшие простую абстракцию из двух уровней наследования, в иерархии классов уровней на 5-7. И оно вам действительно надо? Рекомендую почитать [3].

    4. Эффективность работника прямо пропорциональна его самомотивации
    Тут я согласен с самомотивацией. Это та мотивация которая требует расти дальше. Но вот с выводом о том где надо работать… В корне не согласен. Человек «агрессивный», по версии автора, стремится работать в стартапе. Вот, ведь все читающие эту статью, стремятся к расширению кругозора, получению новых идей, может быть и противоречащих вашим убеждениям (т.е. обладающие самомотивацией), но… Перед вами лежит два предложения: поработать в стартапе (сайт, с гениальной идеей, от вас требуется его разработать MySql+Php) и в Intel (разработка компилятора для параллельного языка программирования). Чье предложение вы примите? В качестве еще одного примера, как компания на букву G повышает уровень самомотивации своих работников, настоящих и будущих — [4].

    5. Чем быстрее работники выполняют доработку кода, тем они эффективнее
    +1

    Ну и в заключении:
    У каждого человека есть определенный кругозор. Когда этот кругозор сужается до бесконечно малого — он обращается в точку. Именно тогда человек и начинает говорить, что это и есть его «точка зрения». Эдвин Гилберт

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

    Использованная литература
    1. Victor435. Тестирование ПО: как объяснить руководителю, что 2 х 2=4?
    2. HighOctane. Десять советов начинающим программистам совет №6
    3. Джоэль Спольски. Не дайте Астронавтам Архитектуры вас запугать
    4. http://kitya.livejournal.com/188574.html
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 44

      0
      По пункту 3 полностью с Вами согласен.

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

      Лучше и не скажешь.
        0
        Можно сказать: KISS. По сути дела — о том же.
          0
          Да, я считаю Спольски талантливым. Вы это имеете в виду?
            0
            А я не знаю кто это. Но с высказался он очень хорошо:)
          +3
          Про уровни абстракции тут думаю разночтения просто. Можно использовать абстрактное мышление, чтобы городить кучу абстрактных классов, а можно это же мышление использовать во благо, ища простые пути, обобщая задачи в поставленной проблеме. Эффективно обобщая, исключая создание лишних сущностей.
            0
            Абсолютно верно подмечено. Именно это и имеется в виду. Не понимаю, почему все скатываются к перегибанию палки.
          0
          Исчерпывающе этот вопрос освещён в книге «Руководство Джоэла Спольски по подбору программистов и управлению ими». Некоторые из материалов книги доступны в блоге автора книги, в том числе по-русски.
            +2
            Вообще, я согласен с таким мнением: целью программной разработки является решение бизнес-задач клиента.
            Поэтому оплата должна быть привязана только к этому критерию: решена задача или нет.

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

            В реальной жизни польза от участия человека в команде измеряется даже не его личным результатом, а тем, как он влияет на результативность команды вцелом. То есть программист Вася может быть мега-гуру, но он так гнобит других участников, что у тех опускаются руки, появляется куча ошибок и усиливается желание уволиться. А вот юная тестировщица Маша не блещет числом найденных ошибок, зато она так разговаривает с программистами, что те потом два дня работают с КПД 150%.

            Бремя объективной оценки личного вклада участников целиком и полностью ложится на менеджера низшего звена — непосредственного начальника конечных исполнителей. Он сам уже может по совокупности формальных параметров и личных наблюдений делать выводы. При этом, конечно, полезным будет наличие максимально детальной статистики, включающей формальные показатели разработчиков. Но напрямую (по формуле) увязывать оплату труда с этими показателями ни в коем случае нельзя — реальная жизнь всегда разнообразнее любой модели.
            –1
            1. за то время что другие делают одну задачу — я сделаю 5.
            за то время что один человек делает одну задачу мне мои 5 раз вернут тестеры( с жуткими багами )
            результат:
            я — 2-3 задачи за интервал + куча потереных нервных клеток у тестеров
            сосед — одну задача, 100% рабочая версия.

            3+5. Надо было доработать немного код( примерно на 3 часа работы )
            Доработал, посмотреть, стер, переписал базовый фрейворк, еще раз стер, переписал, запустил, подумал.
            Прошло пять месяцев. На выходе идеальная конфетка.
            Но из-за одного модуля были переписаны практически все остальные.

            Хотя, если честно, это того стоило

            К томуже быстрая и немного «дерганая» моя работа сильно расширяет кругозор :)
              0
              Посчитаем?
              «я — 2-3 задачи за интервал + куча потереных нервных клеток у тестеров
              сосед — одну задача, 100% рабочая версия.»

              Т.е. ваш сосед — в одиночку делает 1 задачу за интервал времени, в то время как вы вместе с тестерами (судя по множественному числу, их ещё и не один) делаете 2 задачи. И того, эффективность соседа 1:1=1, ваша — 2:3=2/3.

              Увы, ваш подход неэффективен, если важна стоимость продукта, а не время разработки.
                0
                тестеры дешевле.
                и они тестят всеравно чем програмеры програмят
                  0
                  намного ли дешевле?.по зарплате два хороших тестера = 1 программер
                    0
                    Приравнивая тестеров к дворникам вы допускаете одну очень большую ошибку. Тестер знает про продукт больше чем программер, как бы не парадоксально звучало данное утверждение
                      0
                      да нет, с этим я согласен — 70% доработок приходит именно со стороны тестеров
                    0
                    и по времени работы кажется тоже неэффективен.
                    100% рабочая сферическая версия в вакууме единожды приемочно оттестированная пусть будет эталоном…

                    Тогда «я — 2-3 задачи за интервал + куча потереных нервных клеток у тестеров» — где куча потерянных нрвных клеток -хотя бы однократное повторение сферического в вакууме тестирования (* на число задач) плюс время на локализацию/фиксирование/перепроверку касяков, коими кишат задачи и непонятно до каких пор кишить будут.
                    Управиться в срок с задачей возможно, если только «отдраивать» ее будет вся королевская более дешевая рать…
                    Остальные задачи на тестирование получается нервно курят в уголках…

                    Это все в защиту тестеров от monkey testing))Обязательно поправьте, если не права.

                    И еще, меньшее количество очевидных ошибок у хорошего тестера порождает желание изобретать более хитрые способы их искать, а у разработчиков какое-то чувство ответственности…

                    То, что все это должно быть без фанатизма (как нечистоплотность кода так и его вылизанность)-тут с автором сложно поспорить.
                  0
                  Думаю критерии эффективности (личной, не team-work) это:

                  E = m/c

                  где,
                  m — количество полностью законченных фич (в предварительно человеко-часах, по предварительной оценке всей комманды)
                  c — количество реально потраченного времени на эти фичи. Учитывая написание, текстирование, дебаггинг и рефакторинг (когда через пол-года вдруг поломалось от всяких побочных эффектов).

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

                  Team-working я предлагаю не учитывать, так как чем этот критерий выше, тем ниже личная эффективность. Кроме того это не S.M.A.R.T. показатель, как и скажем чувство юмора, которое тоже важно в комманде.

                  Правда чтобы формула выше работала, необходимо чтобы один человек отвечал за одну фичу. Но по-моему это так и должно быть: придумал сомнительную архитектуру? доказал с пеной у рта? — ну и мучайся сам. Потратишь много времени — упадет эффективность, а значит (например) снизится зарплата. Возможно это неэффективно с точки зрения результата, но зато позволяет впоследствие видеть кому стоит поручать сложные решения, а кому нет.
                    0
                    E = mc^2

                    Было б здорово!
                    +1
                    По-моему, вполне можно было, подсократив, поместить в качестве ответа на исходный топик

                    Хотя желание организовать что-то по типу переписки Энгельса с Каутским тоже понять можно :)
                      0
                      Не работника лечить нужно через «оценку эффективности», а процесс. Если много ошибок — значить среда создана соответствующая. И не руки рубить нужно — а голову лечить :)
                        0
                        Ну влияет процесс (и глобальное потепление, и мировой кризис, и цены на ред булл) на эффективность, а какой смысл его рассматривать в данном случае? Он в команде на всех одинаково влияет.
                          +1
                          Предлагаю отличать процесс разработки в ИТ от глобальных изменений.

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

                          Можно это интерпретировать как «сам дурак» (что часто делается) и плюс навешать ярлык «мы оценили твою эффективность — ты лузер». А можно задаться вопросом — почему? В ИТ за десятилетия выработаны разнообразные практики как улучшать культуру разработки, которая приводит к выравниванию производительности инженеров в любом проекте. Конечно, некоторые навыки требуют практики, чтобы их получить — но это стратегичекий шаг и здравствуй ситуационный менеджмент, коучинг, менторство, парное программирование и Agile.
                        +1
                        >Ну и в заключении, как только вы начнете платить программисту

                        >Ну и в заключении:
                        Как Вы всех пересажать-то стремитесь…
                          0
                          Эх, вот вроде читаешь, читаешь, а все равно такие ляпы.
                          А вы говорите программы без тестирования.
                            0
                            Все баги не выловишь — некоторые приходится описывать в документации:)
                          0
                          1) Меньше ошибок — более эффективный работник.

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

                          Ну а то, что могут возникнуть ошибки при заливке 2 Гб — это само-собою уже проблема совсем другого порядка — этим действительно должен заниматься тестер.

                          2) www.artlebedev.ru/kovodstvo/sections/148/ — прочтите.

                          4) Нахрена нужны компании I и G сотрудники, которые не мотивированны? Или вы считаете, что много денег достаточно, чтобы человек стал самомотивирован? Да, он пойдет, если предложат хорошие деньги. Но я уверен, что туда берут специалистов, которые желают саморазвиваться и реализовываться на новых проектах.
                            0
                            2) www.artlebedev.ru/kovodstvo/sections/148/ — прочтите.


                            Разве там о программистах речь? Здесь зачастую на первый план выходят другие правила (инициатива трахает инициатора — например). Особенно если цель поставлена чётко и недвусмысленно — тупо удовлетворить заказчика не занимаясь при этом никакой самодеятельностью.
                              0
                              >Особенно если цель поставлена чётко и недвусмысленно — тупо удовлетворить заказчика не занимаясь при этом никакой самодеятельностью.

                              А какая интересно еще бывает цель? Если заказчик доволен, то и исполнителю воздается соответственно, корреляция довольно хорошая. Вот если исполнитель начинает помимо тупого удовлетворения заказчика еще и интеллектуально удовлетворять себя, тут возможны нюансы :)
                                0
                                Предугадывание будущих пожеланий заказчика один из таких нюансов :) Имхо, стоит делать функциональность приложения малой кровью расширяемой, даже если этого нет в ТЗ, зато когда заказчик захочет добавить фичу не надо будет переписывать всё с нуля, то есть или предложить заказчику более выгодные условия по сравнению с конкурентами, которым надо будет всё писать с нуля, а вам только фичу реализовать, ну или впарить заказчику, что всё надо будет переделывать с нуля, а фактически заниматься только реализацией фичи :)
                                0
                                Программисты решают свои задачи. Я по несколько раз иногда решаю одну и туже задачу (на разных проектах) и каждый раз совершенствую код и решение, используя новые пути решения, делая код более ясным, прозрачным и красивым. Как раз и превнося в код смысл.

                                0
                                Думаю речь не о деньгах (про деньги ничего не сказано), а именно о мотивации — одно дело работать в стартапе, решая традиционные по большому счёту задачи (большинство стартапов, пиарящихся на хабре, это, по-моему, прежде всего идея (плюс юзабилити и дизайн), техническая реализация (движок) как таковая сложности не представляет особой, много кода — может быть, но вот алгоритмизация, по-моему, тривиальна), а совсем другое — во всемирно известном гиганте и заниматься не «натягиванием вёрстки», а чем-то граничащим с научными исследованиями. По-моему, достаточная мотивация при равных объективных (уровень зп, соцпакет и т. д.) условиях работы.
                                  0
                                  Спасибо, именно это я и пытался сказать своим примером.
                                +3
                                Вы оцениваете работников… А какие усилия Вы сами приложили, как руководитель, чтобы у ваших подчиненных были лучше условия и соответственно отдача труда? Сменили одного программиста на другого?

                                  0
                                  Совершенно согласен.

                                  Лечить нужно голову (в данном контексте, я подразумеваю руководителя команды). Автор неоднократно подчеркивает — ищу суперменов. А инструмент поиска — отсеивать неудачников прекрываясь абстрактными понятиями «оценки производительности».
                                  0
                                  Как-то я так и не понял как же оценивать эффективность работника… :)
                                    0
                                    Упомянутый мной Спольски, по этому поводу написал достаточно много, и в целом я с ним согласен.
                                    Вам нужны толковые люди, умеющие делать дело. И если у них будет высокая внутренняя мотивация, то вы получите лучшую команду в мире.
                                    Уже был пример выше в коментах, про тестировщицу. Я приведу еще один.
                                    У меня на одном из предыдущих мест работы был в подчинении программист, который писал достаточно мало кода, но он постоянно исследовал новые технологии, предлагал оригинальные решения, да в конце концов своей заинтересованностью он сплачивал команду. Вот как оценить его эффективность?
                                      0
                                      А надо ли? Особенно если планирование бюджетов находится на уровне «э… пусть все будут работать по 8 часов в день, а мы будем им платить по ставке». Т.е. когда компании в принципе не способны подсчитать стоимость отдельных действий и оценить их влияние на результат.

                                      Доказательство от обратного. Если бы компании могли бы это сделать (и речь сдесь не только об ИТ), то понятия 8-ми часового рабочего дня, для работников не связанных с обеспечением непрерывности бизнеса (продавцы, поддержка и т.д.), просто не существовало бы уже.

                                      Существует огромный дефицит систематизации самой организации труда и я не вижу как можно было бы решить задачу для отдельных её (организации) частей. Поэтому попытки оценить эффективность в рамках неэффективной организации труда будут неуниверсальны.
                                        0
                                        Я не понял: в пункте 2 «Генераторы идей много раз эффективнее потребителей идей» вы вроде как обосновали неэффективность генераторов, здесь вы похвалили генератора. Каково же, всё-таки, ваше мнение?

                                        Моё мнение: в команде (небольшой) обязательно должен быть один генератор и один гуру. Остальные могут быть середнячками, «твёрдыми троешниками». Эти два человека будут тащить весь проект, создавая его костяк. «Мясо» будут добавлять троешники. Причём генератор и гуру дополняют друг друга. Генератор вносит «возмущения» в процесс разработки, гуру служит фильтром, сглаживая их. Стандартный процесс эволюции систем.
                                      0
                                      К чему это я? Да все к тому, что вы заплатите программисту в 2-3 раза больше за проведенное тестирование, чем человеку отвечающему только за тестирование.

                                      Разрешите по этому поводу не согласится. Это из п. 1. Если платить тестировщикам наравне с разработчиками (я как тестер, понятное дело, решительно за такую уравниловку), то это уже не будет аргументом. Никто не ждёт от разработчиков, что они будут тратить время на профессинальное тестирование. Но сделать какие-то проверки по работоспособности написаного всё-таки надо. Иначе, как тут уже писали, получается несколько итераций и в результате — взамен лишнего потраченого полу-часа/часа одного разработчика, тратиться куча времени на тестирование, оформление дефектов, пересборки продукта и тд. А хуже всего, что автор кода за это время выпадает из контектса и вполне возможно уже окучивает совсем другую часть проекта.

                                      И поверьте, нам тестерам намного приятнее работать с аккуратными разработчиками, чем с теми, кто считает, что есть специальные (низкооплачиваемые — почему?) люди, которым можно спихнуть — пусть ищут.
                                        0
                                        Я таких «разработчиков» увольнял, увольняю и буду увольнять. Они тратят средства компании на собственную невнимательность, лень, недосыпы и так далее.
                                        0
                                        Еще кстати про оценку эффективности. Я писал такой вариант для тестировщиков, но и для разработчиков подойдёт.
                                          0
                                          CTRL+Enter

                                          Спросите у ваших тестеров чей код они хотят тестировать. Например: написать анонимно три фамилии програмистов. Увидете — выберут лучших (самых эффективных, если хотите) — как в детстве когда во дворе в футбол играли.

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

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

                                          если начислятъ зарплату по строкам кода — ну тут получится куча г. очень большая куча.

                                          если по кол-ству починенных багов — сначала багов наваяют, потом будут чинить

                                          если обратно кол-ству найденных багов, будут до хрипоты спорить с тестерами или принимать баги на починку «из под полы», без занесения в тракер. либо тратиь невменяемо много времени на тестинг, заменяя собой QA.

                                          и т.д. и т.п.

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

                                          но, это не всё!

                                          монгие исследования показали что так назывармый «performance based compensation» т.е. оплата по производительности, даже если удается каким-то образом устроить (бонусы за вовремя зданный проект и т.д.), обыйно приводит к потере мотивации у работников. По тем-же исследованиям лучшей мотивацией служат увлекательная работа и оценка окружающих.
                                            +1
                                            Рад, что моя тема заставляет людей задуматься :)
                                              0
                                              Так ведь и я о том же! Люди думайте. сравнивайте, анализируйте, набивайте, у конце концов шишки, и постоянно растите над собой.

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

                                            Самое читаемое