Пользователь
0,0
рейтинг
16 августа 2010 в 23:38

Управление → Способы оценки эффективности работника

Многие менеджеры сталкиваются с одной очень занимательной проблемой в IT-сфере. И имя этой проблеме — оценка эффективности работника. Еще пол столетия назад такая задача не вызывала приступов мигрени и паники у руководителей или экономистов, потому что все было просто. Работник закрутил 50 гаек — плохо, закрутил 150 гаек — великолепно! Но пришла революция информационных технологий, и оценка эффективности стала краеугольным камнем.

image

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



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

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

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

Новый взгляд на вещи


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

Меньше ошибок — более эффективный работник

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

Тем более эффективный работник, чем больше он распространяет полезную информацию в коллективе

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

Генераторы идей много раз эффективнее потребителей идей

Работники, которые могут самостоятельно генерировать идеи, на мой взгляд, самые ценные работники. Им не нужно писать детальных ТЗ, не нужно скрупулезно пояснять отличие одного подхода от другого, и почему стоит выбирать другой путь, а не тот, который они где-то прочитали. Эти работники придумают 10 способов решения нетривиальных задач, и найдут 10 причин, почему каждый из них не будет работать. Они тащат за собой весь коллектив и не боятся трудностей. Потому что им интересно изобретать велосипеды, и ни в коем случае нельзя отбирать у них эту возможность.

Чем более абстрактное мышление, тем эффективнее работник

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

Эффективность работника прямо пропорциональна его самомотивации

Бывают два типа работников: «уставшие» и «агрессивные». «Уставшие» работники стремятся как можно меньше делать и как можно больше получать денег. Им не интересно ни развиваться, ни изучать что-то новое. Усталость их не от того, что на них взвалили много работы, или они неэффективно распределяли свое время, и приходилось перерабатывать. Их усталость от потери интереса или мотивации в работе.

«Агрессивные» наоборот, стараются как можно бытсрее пройти путь обучения, развития, становления, чтобы получить доступ к еще большему количеству ресурсов, чтобы развиваться, развиваться, развиваться. Они жадно впитывают знания, учатся, пробуют, делают ошибки, и над ними не нужно выстраивать пирамиду менеджеров, чтобы подстегивать к работе. «Уставшие» стараются найти работу в больших компаниях, где эффект от их работы не виден вообще. «Агрессивные» находят себя в стартапах, маленьких компаниях, потому что там проще получать все, что им требуется.

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

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

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

UPD: Перенес статью в более подходящий раздел. Спасибо andreycha
Александр @s0rr0w
карма
46,7
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

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

Самое читаемое Управление

Комментарии (141)

  • +2
    Спасибо. Положил корпоративную вики, чтобы сотрудники ознакомились.
    • +41
      Поднимайте теперь, а то знакомиться не с чем =)
  • +9
    Начиная мыслить стратегически, человек зачастую теряет способность мыслить тактически.

    Единственным мерилом качества работы сотрудника является то, насколько хорошо он делает то, что должен делать. Начальники руководят, архитекторы проектируют, кодеры реализуют. А у вас все в одну кучу.
    • +1
      А насколько он хорошо делает то, что должен делать? Может он недостаточно хорошо делает свою работу? Может на его место стоит взять человека, который лучше справится с задачей?
      • +4
        Для этого есть люди опытные, которые могут оценить и качество кода, и время разработки, и красоту архитектуры. По конкретным критериям конкретного проекта, за который они отвечают, а не по этим, абстрактным.

        Я, например, видел совершенно вырвиглазные решения в проектах, где требовалась скорость работы. Там красота кода не нужна и на архитектуру все плевать хотели. А вот в компонентном — архитектура имеет огромное значение.

        Замечу, что вы платите сотруднику за то, что он выполняет свою работу, а не наполняет корпоративную вики клевыми статейками на тему асинхронных многопоточных лямбд.
        • +4
          Статья не про то, как написать идеальный код или как оценить потом идеальность кода. Статья про эффективность работника. Он может быть сверхопытным, может нарисовать с закрытыми глазами архитектуру любого проекта, может написать идеальный код, но быть «уставшим». Кто оценит качество его работы? Какова его эффективность для компании? Деньги платят не за код, деньги платят за то, что программист делает продукт, который потом продается, а от продаж он получает свою долю обратно. Так вот с точки зрения управления, абсолютно неважно, кто именно работает, важно насколько эффективно трудовые ресурсы конвертируются в денежные.

          Максимизация прибыли, минимизация затрат. Про вторую часть и идет речь в данной статье.
          • +1
            У каждого человека, если что, есть должностные обязанности. Это то, о чем всегда забывают в программистских фирмах. И они — это то, за что платят деньги.

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

            В любом случае, для всех инженерных специальностей допустима только субъективная относительная оценка.
            • 0
              И? Есть должностные обязанности, есть разделение труда… И что? Это все как-то должно перечеркнуть все то, что я говорил?

              Если вам захочется применять свои собственные оценки эффективности работника, да Бог с вами, применяйте! Но я никогда не буду сажать работника за код, чтобы тот оценивал его красоту или сложность. Это бесполезное занятие, по моему мнению.
              • +1
                У вас code review не делается вообще?
                • +1
                  Он делается настолько часто, насколько часто вносятся изменения в продукт. Т.е. постоянно. Хотя что его там делать, внимание нужно уделить только отдельным кусочкам, все остальное сильно стандартизировано.
                  • 0
                    Тогда в чем проблема? Человек, который делает code review, должен уметь оценивать качество этого кода. Оценка этого человека и является мерилом качества — одним из параметров эффективности работника. Основным, замечу. Все остальное — саморазвитие, помощь товарищам и прочее, это мишура, которой хороший работник вовсе не обязан обладать.

                    Именно это я и имел ввиду, когда говорил о начальниках.
                    • +1
                      Если вы работника расцениваете сугубо как станок, то мне жаль вашу компанию.
                      • +2
                        Работник и сам себя неплохо рассмотрит. Главное — не мешать ему развиваться. Можно даже стимулировать. Но не делать из побочных вещей фетиш. Если работник хочет работать как станок — у него есть на это право.
                    • 0
                      нужно уходить от субъективных оценок…
                      Ведь кто может с точностью сказать, что человек, который проверяет мой код — не в доле со мной… Он говорит, что я хорошо пишу, я получаю больше ЗП, он получает откат…
                      А вот объективные критерии такого не допустят… ибо он должен обосновать, что я хорошо пишу… причем в цифрах…
                      цифры — это единственное, что поддается счёту…
                      • –1
                        Посчитайте эффективность своего труда в цифрах.
                        • +2
                          Если бы я мог — был бы уже миллинером… вопрос не такой простой, как кажется…
                          Вы, как, автор этой статьи, это прекрасно понимаете…
                          Я лишь говорю, что не должно быть субъективной оценки… всё надо приводить к каким-то цифрам… а потом сравнивать со средними…
                          Около 2х лет назал был задача оценить труд «компьютерного мастера по вызову»… не могу раскрыть коммерческую тайну, как это было сделано, однако удалось создать систему, при которой его работа приводиться к чистым цифрам, далее не составило труда вывести среднее по компании и выяснить кто работает хорошо, а кто плохо…
                          Потом при субъективной проверке качества она практически совпадала с тем, что говорила эта система… при этом прослеживая статистику, можно было с точностью до месяца сказать — когда сотрудник испортился и начал оставлять свой телефон, вместо визитки фирмы…
                          • 0
                            Абстрагируйте свой опыт и поделитесь, многие будут благодарны
                            • 0
                              если абстрактно — то самое сложное — это понять, что же является результатом работы данного сотрудника… что должно произойти, если он хорошо выполнил свою работу и что должно произойти, если плохо… затем подсчитать количество таких случаев и сравнить со среднем по отделу/фирме… однако такой способ работает только когда есть достаточное число сотрудников (не меньше 5)… иначе не вычислить среднее…
                      • 0
                        Да, я согласен. Нужно уходить от субъективных оценок. А еще нужно наконец реализовать Демона Максвелла, изобрести вечный двигатель первого рода и превысить скорость света хотя бы в два раза.
    • +1
      Да, и в каких единицах измеряется «хорошо»?
      • –2
        В «начальниках».

        Если начальник компетентен и говорит, что хорошо — значит хорошо.

        А компетентность начальника оценивается выше, и так до генерального.

        А если генеральный некомпетентен — то все эти «хорошо» можно выкинуть в помойку.
        • +4
          Это можно расценивать в качестве отсутствия ответа на вопрос?
          • –6
            Если вы не видите ответа — это еще не значит, что его нет. Возможно, он на самом деле есть, но вы его просто не видите.
            • 0
              Тогда прошу растолковать, про что идет речь.
              • –1
                Чуть выше растолковал.
  • 0
    Не очень в теме, а разве какой-нибудь метод вроде balance scorecard не пробовали применить к оценке труда разработчиков?
    • +1
      Генератор идей работает эффективнее. :) Если я буду использовать чужие наработки, то я не буду понимать некоторых телодвижений, почему их надо делать, или наоборот, почему их не надо делать.
      • 0
        Я недостаточно точно сформулировал вопрос. Я скорее интересовался не Вашим опытом, сколько существованием в мире такой практики как оценка труда разработчиков на основе группы сбалансированных показателей. Вы что-нибудь слышали об этом?

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

        Также было бы интересно узнать, как можно оценить уровень абстракции мышления. Есть ли абсолютные показатели?
        • 0
          Про группу сбалансированных показателей читал очень давно, но, скрее всего, она не впечатлила меня, так как про нее не осталось ни одной зацепки в памяти кроме смутных воспоминаний.

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

          Про труд разработчика тяжело что-то рассказать в одном посте. Это что-то сродни творчеству, которое требует не таланта рисовать, а таланта оперировать логическими сущностями, абстракциями…

          Чтобы оценить уровень абстракции мышления, достаточно задать задачу из реального мира и посмотреть, насколько качественно ее опишет разработчик. Например, описать бизнес-процесс компании. :) Или описать процесс сборки табуретки.
          Больший уровень абстракции будет у того, кто сможет изменить без особых проблем описание бизнес-процесса компании на тот же процесс сборки табуретки.
        • +1
          BSC для оценки труда разработчика? Вообще не из той оперы.

          Вообще-то вместо вот таких придуманных невнятных показателей, которые придуманы в статье давно уже существуют известные и проверенные методики. И называются они TSP/PSP (Team Software Process/Personal Software Process).
          Почитайте на досуге, прежде чем изобретать велосипеды…
  • –2
    Статью не читал, т.к. имею проверенное опытом мнение. Хороший работник — человек, выполняющий ожидания-требования руководителя. Эти требования должны быть адекватными, но это уже оценка руководителя. Итак, дал задачу закрутить 150 гаек человеку, закрутил — молодец, не закрутил — нет (закрутить реально и другие люди закручивают регулярно). Как, когда — малое значение. Дал сформированной команде задание построить токарный станок за 1 квартал, сделали — молодцы, не сделалы — все уроды (особенно, менеджеры, если вовремя не проинформировали). Ожидания — результат. Ожидание — отсутствие результата, значит, либо ожидания неадекватные (см. выше), либо вот он, плохой работник в IT.
    • –4
      Все остальные «более узкие» критерии рушатся об частности и лишь усложняют жизнь тому, кто этим вопросом должен заниматься (HR-рулевой и, чуть выше, генерал).
    • +2
      Стоило прочитать топик прежде чем давать комментарии.
    • +2
      Хороший работник и эффективный работник — разные понятия. Работник может быть хорошим, но неэффективным.
    • +15
      — Итак, дал задачу закрутить 150 гаек человеку, закрутил — молодец, не закрутил — нет
      — (закрутить реально и другие люди закручивают регулярно).

      Это смотря какие гайки крутить. Самые большие гайки весят около 5 тонн и чуть меньше полутора метров в диаметре. Некоторые начальники не обращают внимания на такие детали. Ну гайка и гайка…
    • +3
      > Как, когда — малое значение
      супер-работник неплопно закрутит аж 300 гаек — вот молодец, да?
      • 0
        А потом корабль или самолет развалятся в движении. Фигня, главное быстро проект сдали
    • +1
      Это называется «плановая экономика»… такие эксперименты со страной уже проводились :)
      Выполнил план — молодец, не выполнил — плохой сотрудник…
  • +3
    > Чем больше кода создает работник, при минимальных временных затратах, тем более эффективный работник. Все это хорошо, но это не работает.

    Более того, работник тем эффективнее, чем меньше кода он создаёт для решения эквивалентной задачи с эквивалентным качеством.
    • 0
      «эквивалентным качеством» чего? Кода или решения…
      если кода, то соглашусь… а если качество решения — то не всегда…
      решение может быть качественным, коротким, но абсолютно не читабельным…
      особенно, когда используется оператор «a?b:c»
      это существенно усложняет восприятие кода другим человеком…
      так что тут длина кода — не показатель… или бинарный код, например :))
      • 0
        Это вопрос соблюдения стандартов кодирования и оформления кода в фирме, а если стандарты не соблюдаются, значит код не качественный по определению.
  • 0
    Проблема еще в том что руководители зачастую сами люди не сведущие в технических вопросах, и они не могут понять много ошибок делается или мало. Насколько сложная задача выполняется, и каково адекватное время ее выполнения. Очень трудно установить какую-то норму в данных вопросах.

    И по поводу велосипедов вопрос спорный… стоит ли отбирать у них эту возможность. Многие люди любят делать велосипеды, особенно я. Но это часто идет в ущерб проекту, т.к. на велосипед тратится время. Да и не всегда велосипед является оправданным, т.к. его надо поддерживать самостоятельно.
    • 0
      P.S. собсна я обо всем об этом давно уже подумал очень серьезно… и пришел к выводу что лучше работать сдельно. Ибо повременная оплата ведет к тому что заказчик считает что он много платит и мало получает, а работник думает что много работает и мало получает. В результате заказчик превращается в контрол-фрика, а работник старается побольше тунеядствовать чтоб повысить тем самым реальную стоимость своего времени.

      А все программисты выполняют задачи с разной скоростью. Например я могу сделать за неделю нечто очень крутое, то что некоторые будут делать несколько месяцев. Однако, бывает очень трудно доказать заказчику свою уникальность и обосновать соответственную стоимость своего времени.
    • +2
      Без велосипедов трудно понять, что делаешь не так. Процесс создания велосипеда помогает понять ход мыслей того, кто его до тебя изобрел.
    • 0
      Свой велосипед бывает предпочтительнее чужого космического челнока. Задачи бывают разные — иногда надо лишь съездить в соседнюю деревню.

      А изучать код чужого велосипеда после изобретения своего — как читать «Откровение». А уж ездить — так с первого отталкивания.
  • +2
    Мой небольшой вариант оценки: (все пункты через некоторое время совместной работы несложно проставить по 10 баллам)
    1. Самостоятельность (насколько часто задает вопросы, с которыми мог разобраться сам?)
    2. Качество кода (тут придется заглядывать в код)
    3. Умение Видеть простые решения (то самое, абстрактное мышление). Тут естественно оценка будет либо относительно себя, либо относительно лучшего кодера в группе.
    4. Ну и при исполнении прежних трех пунктов, уже можно замерять скорость выполнения задач :)

    Чуть не забыл еще пару пунктов.
    Нужно еще умение предвидеть потенциальные глюки кода, и писать сразу с учетом. Был у меня человек, который исправлял код раз в месяц (менялись условия), как оказалось не пытаясь решить проблему более глобально, чтобы раз, и навсегда.
    И желательно, чтобы человек старался таки оценить производительность кода. Видел иногда аццкие перлы…
    • 0
      По первому пункту есть замечание. Такая самостоятельность пересекается с изобретением велосипедов, особенно это касается новых людей в команде, которые не знают используемого инструментария. Грубый пример — для валидации формы в браузере новичок может начать писать свои JS скрипты или использовать какой-то «левый» (по отношению к команде) фреймворк/библиотеку, пускай его метод даже более эффективный, но он приведёт к потери эффективности команды в целом. Сам неоднократно слышал от более опытных коллег на новых местах: «а ты чего там возишься целый день? делов-то на пару часов» — «вот кодю то-то и то-то» — «блин, у нас же для это либа есть, кочущая из проекта в проект, тебе что, не сказали, когда задание давали? спросил бы „

      Так что когда вообще не задают вопросов — тоже не очень хорошо, т. к. боязнь задать вопрос (вдруг оценят эффективность плохо) ведёт к дублированию кода, если не в проекте, так в фирме
      • 0
        Значит для новичков это правило стоить исключить. Но через квартал\полгода уже более менее самостоятельные должны быть? (при условии, что в курсе, что происходит в проекте). Ну и да, под этим словом я не вкладываю самостоятельное решение действительно важных вещей.
        • 0
          Совсем исключить тоже нельзя, чтоб на каждый чих не отвлекали, но какой-то ослабляющий коэффициент надо иметь в виду.
      • +1
        То, что вы рассказываете, результат недостаточного информационного обмена. Если бы его не кидали как на амбразуру кодить, а предварительно уделили ему внимание, то такая ситуация не случилась бы.
        • 0
          В моём случае внимание уделяли, но вот один пункт запамятовали.

          С новичком это частный случай. Вообще имел в виду ситуацию о которой не давно был пост на хабре: что лучше — спросить у гуру или рыть самому. В плане самосовершенствования, конечно, лучше самому, а вот в плане экономической эффективности команды в целом всё не так однозначно, причём рассматривать надо и краткосрочный период, и долгосрочную перспективу, да расставить между ними приоритеты. Когда дедлайны поджимают, то самостоятельное решение проблемы может быть неприемлемо, даже если оно дешевле.
          • 0
            Лично я бы, перед тем, как что-то делать, пошел искать аналоги в коде. Пусть лучше будет два одинаково плохих места, которых легко найти в коде, чем две совершенно разные реализации
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Это книга?
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Почитал отрывки, да, стоит почитать. Спасибо!
  • +2
    Сложную тему вы затронули. Далеко не всегда и везде это подойдет. Все предложенные вами метрики возможно хороши только тогда, когда менеджер может оценивать и понимать их (вот вы понимаете?). В остальных случаях — это также бесполезно, как и считать KLOC.
    Так что тема не раскрыта, на мой взгляд.
    • 0
      Вторую статью писать? Люди требуют примеров из жизни, я их выкладывать не хочу, потому что в них каждый работник найдет себя. Правда глаза будет резать, начнется такое…
  • +6
    Проблема данных показателей в их туманности, расплывчатости и субъективности.
    Все должно быть просто, ясно и понятно.
    А здесь?
    Как вы объясните работнику: я тебе не повышаю зарплату, потому что у тебя нет абстрактного мышления? Поставьте себя на место работника. Каково было бы услышать такое?
    Или: я тебе урезаю премию, потому, что ты не распространяешь полезную информацию в коллективе?
    Нахер, нахер такого работодателя…
    • 0
      Если вы ищите причины не повышать работникам зарплату, то я такого не делаю. Потому что для повышения зарплаты есть такая замечательная вещь, как вовремя сделанная работа или коммерческий успех тех фич, которые сделал работник. В моей команде работники работают, а не в носу ковыряются. Им есть за что повышать зарплату всегда.
      • 0
        А если менеджмент провалился на продаже перспективных фич, и денег на повышение зарплаты нет, а повышать есть за что — будете доставать деньги из собственного кармана?
        Ведь такой провал не означает, что работник схалтурил.
        • 0
          Наша задача не найти кто виноват в сложившейся ситуации, а понять, как не допускать таких ситуаций вообще. Да, это может быть ошибка менеджмента, и тогда менеджер из своего кармана будет кормить работника.
  • 0
    > «Агрессивные»… жадно впитывают знания, учатся, пробуют, делают ошибки,
    > За ошибки работников компания платит из собственного кармана, а это потом отражается на благосостоянии самих же работников.
    Если за ошибки больно наказывают, то агрессивным быть опасно ибо не допускает ошибок только тот кто ничего не делает. Особенно когда напишешь продукт с ошибкой идет штраф, а если не напишешь то компании каюк (грубо говоря).
    • 0
      Инициатива не наказуема. Никогда. Это аксиома в нашей компании. Именно поэтому мы гораздо агрессивнее наших конкурентов.
  • +2
    Ну метрик вы так и не предложили. Если брать количество ошибок за метрику (что неявно следует), то мне достаточно меньше работать и я буду делать меньше ошибок.

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

    А быстро доработку можно делать и просто вставляя патчи. Код будет деградировать, в итоге мы огребем проблемы в будущем.
    • 0
      А метрик нет. В этом вся соль.

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

      Если быстрая доработка была один раз, второй, код продеградировал, то каждая последующая доработка будет все менее эффективной. Это и требовалось доказать.
    • +2
      Метрики скорее вредны, чем бесполезны — программисты легко их фальсифицируют.
      • 0
        В точку! Каждый будет стремиться делать меньше, и получать за это больше.
        • 0
          Еще хуже — самые работоспособные будут максимизировать метрики в ущерб всему остальному, т.е. собственно работе.
          В результате помимо уменьшения пользы получим еще и прямой вред.
  • 0
    Обычно любое из приведенных качеств при его использовании достаточно сильно увеличивает сроки разработки. Всегда приходится искать компромисс между тем, что хочется и тем, что надо.
    • +1
      При экстремальном программировании начальные большие сроки считаются нормальным явлением. Мы иногда переделываем 80% работы после того, как прошли рубеж 80% срока выполнения. Это необходимо делать, иначе никто пользоваться костылями не будет.
      • 0
        Ну, на то оно и ЭП.
    • +2
      А НЕ использование увеличивает сроки еще больше, потому что без головы сам собой получается многослойный говнокод.
      • 0
        Я-то в курсе, но вот начальство не понимает такой простой истины. Как результат — ПО работает, но в код смотреть стыдно. Где успеваю — там переписываю нормально. Благо, когда пишу «основу» — упорно игнорирую требование «ускориться». Это и есть компромисс. Мелкие доп. задачи можно писать как угодно — в случае надобности они также быстро переписываются, а базовый функционал делаю как надо.
        • 0
          Насчет «работает» у тестеров, внедренцев и заказчика обычно другое
          мнение.
          И вот когда «типа работает у меня на машине если ничего не менять» переходит в реально заваленные сроки и угрозу потери клиента — начальство (а оно тоже бывает неглупое и заинтересованное) вполне может прозреть.
          • 0
            К счастью, в данном случае «работает» означает, что оно именно работает. Но, imho, при разработке на заказ, а не для внутренних нужд, при наличии хоть какого-то опыта коммерческого использования собственного ПО руководство обычно более адекватно относится к подобным вещам — иначе на рынке не выжить будет. Хотя встречаются и исключения.
  • 0
    По-моему, вы напутали причину со следствием, анализируете не результат, а предпосылки результата.

    Вы написали список качеств, которые влияют на эффективность.
    Но ведь между качествами и эффективностью лежит самое главное — непосредственно работа, реализация всех этих качеств.
    В 19м веке платили больше тому, кто больше сделал, а не тому, кто сильнее, выше.
    • 0
      То было в 19м веке, когда не было интеллектуального труда.
      Представьте, что вы тренер по баскетболу. Будете ли вы в команду набирать людей, у которых рост 1.50? Я думаю, что нет. Вы отберете высоких и будете уже среди них выбирать тех, кто приводит к маскимальной эффективности команды в целом. Так и тут. Нужно подбирать тех людей, которые заведомо имеют больше шанс на успех в будущем.
      • +1
        Я буду набирать в команду людей, которые забивают, выдают результативные передачи, подбирают мяч после отскока и т.д. Посмотрите на Российскую женскую сборную по волейболу, там разрыв в росте немаленький.

        Да блин. Вы опять и кругом неправы. Набор — это херня, мы же говорим о способах оценки эффективности! Вы что же, в баскетбольной команде будуте платить зарплату пропорционально росту? Или все-таки по результатам игр?
        • 0
          Конечно я кругом и во всем неправ. Напишите опровержение всем моим постулатам в виде отдельной статьи.
          :)
          Вы путаете зарплату и эффективность. Зарплата является следствием эффективности, а не причиной ее. Слабая эффективность команды приводит к низким экономическим показателям компании, и, как следствие, низкой зарплате.

  • 0
    прошу прощения за вопрос не по теме — а в какой программе рисуются эти белые человечки, представленные в начале статьи. В последнее время часто на них натыкаюсь — мне стало интересно, их в чем-то клепают или это просто совпадение
    • –1
      Скорее всего 3dmax. Но могу и ошибаться.
  • 0
    Хороший, эффективный и пр. пр. пр. работник это тот который искренне и всей душей убежден, что в мире существует только два мнения — Начальника и… глупое —
    Хрущев.
  • +1
    «Меньше ошибок — более эффективный работник»

    — Кто не работает, тот никогда не ошибается.

    «Тем более эффективный работник, чем больше он распространяет полезную информацию в коллективе»

    — Кто не работает, тот учит.

    Ну и так далее… На каждое из ваших заблуждений можно подобрать народную поговорку, имхо.
    • +1
      А я побежал работать…
    • 0
      Заблуждений? У вас есть что-то лучше? Расскажите нам, будет интересно всем.
    • 0
      Кто не работает, тот никогда не ошибается.

      Само собой. Только сказали же «меньше ошибок», а не «без ошибок». Например, у нас у одного товарища тикеты часто возвращаются по 2-3 раза — имхо, признак.
      • 0
        Меня однажды так вывели из себя. Человек правил А, ломал Б. Правил Б, ломал А. Правил А… Это просто издевательство какое-то было.
        • 0
          Как решали проблему? Уволили?
          • 0
            Конечно, зачем держать человека, который не заинтересован работать?
  • +1
  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      То есть если в ТЗ нет, например, требований на разделение кода и данных, а так же валидацию пользовательских данных, и один работник решил её одной простынёй смеси php, html, css и js кода, а другой реализовал хотя бы простейшую модульность (инклуды для настроек, для бд и т. п.) и шаблонизатор (на тех же инклудах), предотвратил в коде хотя бы sql инъекции, вынес css и js в отдельные файлы, но сделал это чуть медленнее первого (хотя бы за счёт написания «лишних» include и т. п. ) вы решите, что первый более эффективный и, скажем, поднимете ему зарплату? O_o
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Жаль не были вы моим работодателем лет 10 назад, я б вам простыней накодил :D
          • НЛО прилетело и опубликовало эту надпись здесь
            • 0
              Мне надо было написать «Жаль не были вы моим работодателем лет 10 назад и не поручали создание простых сайтов, я б вам простыней накодил»?
              • НЛО прилетело и опубликовало эту надпись здесь
                • 0
                  Про сайты я пример привёл, но да, не важно. Смысл вопроса был в том, что если в ТЗ не указано говнокодить или нет и один сотрудник быстро говнокодит, а другой лишь _чуть_ медленнее_ кодит, то какой эффективнее.

                  — А поговнокодить? — Ну, ежели постараться — можно и поговнокодить
  • 0
    Меньше ошибок — более эффективный работник


    Споры вызывает уже это. По нескольким причинам.

    1) Ошибка ошибке рознь. Пропустил точку в статическом тексте в разделе «О компании» — это одно. Неправильно пропиcать ту же точку в значении курса доллара — это другое.
    2) Про одну одну и ту же ошибочную ситуацию один тестер может сказать что это одна ошибка. Другой может сказать что их сто штук. Нампример, ошибка в футере страницы сайта. А страниц этих — стопятьсот :D

    И вообще. Тут проблема не столько в работниках. Сама работа программиста подразумевает что баги есть и будут. И с этим бесполезно бороться при помощи дисциплинарных методов — лишь хуже будет.
    • 0
      Абстрагируйтесь от конкретики. Нет разницы какая ошибка, она либо есть, либо ее нет. Если есть, это не значит, что работник не эффективен, это вообще ничего не значит, потому что значение появляется только тогда, когда берется некий промежуток времени, на котором собирается статистика ошибок. И чем статистика лучше, тем эффективнее труд человека.
  • +4
    > Меньше ошибок — более эффективный работник
    Петя сдал пузырьковую сортировку, а Вася — систему распознавания изображений. Петя сделал 1 ошибку, а Вася 3. Выходит Петя гораздо более эффективный работник. Конечно, скажете, результаты нужно поделить на сложность задачи. А как Вы ее количественно определите?

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

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

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

    > Чем более абстрактное мышление, тем эффективнее работник
    Сильный уровень абстракций и стремление к универсальности приводит к ошибке овердизайна. Когда Вася изобретает кучу абстрактных интерфейсов и UML схем, Петя просто влоб пишет компонент, который реализует задачу. Этим страдают большинство профессиональных программистов, пытающихся писать reusable код. Нужно понимать, что в 90% случаев новая задача все-равно потребует специфического решения, и все абстракции пойдут коту под хвост.

    > Эффективность работника прямо пропорциональна его самомотивации
    Я бы сказал, не прямо пропорциональна, а экспоненциально ))

    > Чем быстрее работники выполняют доработку кода, тем они эффективнее
    Да, но не всегда. Для новой задачи Петя сделал «как надо»: наследовал интерфейс, модифицировал Factory, создал новую имплементацию на базе старой. А Вася в коде поставил один дополнительный if. Вася справился быстрее. Но со временем количество if-ов в васином коде стало расти. Ошибки стали появляться чаще, а доработки все дольше… Думаю понятно, что надо смотреть не само время, а динамику.
    • 0
      Петя сдал пузырьковую сортировку, а Вася — систему распознавания изображений. Петя сделал 1 ошибку, а Вася 3. Выходит Петя гораздо более эффективный работник. Конечно, скажете, результаты нужно поделить на сложность задачи. А как Вы ее количественно определите?

      Результат работы Пети принес компании 1000 продаж, а ошибка Васи принесла отказ одного очень важного клиента, который мог сделать 10 000 продаж сразу.

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

      Учитывайте последний пункт. Петя менее эффективный чем Вася.

      Есть такая категория людей ....

      … чем больше он распространяет полезную информацию в коллективе

      См. выше.

      См. выше.

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

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

      • 0
        > Результат работы Пети принес компании 1000 продаж, а ошибка Васи принесла отказ одного очень важного клиента, который мог сделать 10 000 продаж сразу.

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

        Работник эффективный, если:
        1. Адекватен в суждениях, имеет свою точку зрения и может аргументировать
        2. Хочет работать, чего-то достичь и чему-то научиться
        3. Всегда имеет профессиональные интересы сверх того, что требует текущий проект
        4. Ответственный за порученную работу

        Количественно никак не меряется.
        • 0
          Это не мои косяки. Это я к тому, что ошибка имеет стоимость для компании. И сказать однозначно, что одна ошибка страшнее другой невозможно.

          Кто вам сказал, что я оцениваю так заработную плату работника? Меня может спокойно удовлетворять недостаточно эффективный работник, если он не требует большой оплаты труда. Он может дорасти до адекватного работника и получить больше плюшек от компании.
    • 0
      Есть такая категория людей — пиздуны. Они есть в любом коллективе. Они могут распространяться о высоких технологиях, о всех новинках, вычитанных на хабре, быть в курсе последних новостей. Могут охаивать архитектуру проекта или выбранную методологию работы и создавать впечатление мудрых и знающих специалистов. Но практическая ценность от этих людей — абсолютный ноль. Они как правило реально сами не в состоянии ничего сделать. Самый простой способ распознать пиздуна — спросить его как сделать какую-нибудь нетривиальную задачу. Если Вы в ту же секунду получаете нескончаемый поток идей, и уверения, что реализовать все это не стоит большого труда, то перед вами типичный пиздун.

      Фух, я сначала испугался, но на последнем предложении успокоился :D.
  • 0
    По-моему, Вы свои собственные представления об идеальном сферическом программисте в вакууме перекладываете на реальную жизнь, что надо делать всегда с большой осторожностью. По-моему, пытаться строить макдональдсы из программистов и вводить какие-то странные показатели эффективности глупо, т.к. это приведет к тому, что люди начнут работать не ради создания продукта, а ради достижения показателей эффективности.
    • 0
      А кто сказал, что эти показатели эффективности должны обязательно монетизироваться? Вы монетизируйте продукт, а не труд человека.
      • 0
        Так вы же собираетесь оценивать людей по введенным Вами критериям эффективности. Значит, люди будут подстраивать свою активность под них, т.к. захотят, чтобы Вы их хорошо оценивали. И не факт, что это приведет к росту полезной отдачи от них.

        Вообще, мне кажется, вводить метрики для оценки людей творческих профессий — достаточно бессмысленная задача. Лучше всего работает простая «вертикаль власти» — каждый начальник оценивает своих подчиненных по неформализуемой совокупности факторов.
        • +1
          Классическая вертикаль власти — очень затратная штука. Мало того, вертикаль стирает грани между эффективным и неэффективным работником.
  • +2
    Сложная тема, и не просто местами субъективная, а полностью субъективная, поэтому как только появляется вопрос: а кто и как будет оценивать результаты работы сотрудника, проще и, вероятно, правильнее всего отвечать: я и по моим собственным (пусть и субъективным) метрикам — и обсуждению это не подлежит. Эффективность работы сотрудника ИТ-области — величина интегральная, это и скорость разработки и эффективность кода, количество ошибок, абстрактность мышления, умение решать задачи, да много чего еще можно перечислять. Но никакие объективные метрики не дадут нам точной оценки, потому что ИТ — сама по себе нематериальная область, любая метрика имеет свои способы накрутки. И в итоге получается, что субъективные методы оценки будут более объективными…
    • +1
      Именно!
      • 0
        Предлагаю обновить, с позволения maxz, топик с добавлением этого прекрасного рассуждения. Ваша идея в таком случае становится еще более понятной и связной.
        • 0
          Если позволит, добавлю
  • +4
    Давным давно было установлено, что хороший программист тот, который моется не реже двух раз в неделю.
  • 0
    Прочитал. Спасибо.
    Надо создать блог «Учись управлять» и этот топик туда переместить.
    • 0
      Будет сиротливо болтаться? Лучше пусть в стартапах будет, там это более насущная проблема.
      • 0
        «Управление проектами»?
        • 0
          Это лучше. Перенесу пожалуй.
      • +1
        Ну тогда название топика нужно изменить с добавлением «при работе над стартапами». Вы же в целом проблематику освещаете, зачем ссужать её до стартапов. Программисты, кодеры, дизайнеры, архитекторы, управляющие проектами не только в стартапах работают.
  • 0
    Мне статья очень понравилась! В точку! Может в России как-то по другому (я на западе работаю), но все моменты описанные автором, четко отслеживаются в нашей компании. Спасибо за хорошую статью. Положил в закладки, отправил друзьям :)
    • 0
      Не за что. Рад, что пригодилось.
  • 0
    Непонятно, как соотносятся «Чем более абстрактное мышление» и «Чем более простыми абстракциями оперирует человек». А в целом мысли хорошие.
    • 0
      Что не так? Можно на примерах?
      • 0
        о_О
        Я думал, это вы мне пример приведёте, в котором чем более абстрактное мышление, тем эти сами абстракции проще.
        Я считаю, что чем более развито абстрактное мышление, тем более сложные абстракции можно использовать. «Можно», конечно, не значит, «обязательно», но мне как-то противоположная корреляция виделась.
        • 0
          Извините, не понял вопроса. Приведу конечно же.
          Допустим, есть задача описать документооборот некой компании. Если пришел документ А, то начать процедуру Р1, если следом приходит документ Б, то начать процедуру Р2. Если наступил некий таймаут или пришел документ В, то нужно запустить процедуру Р3.

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

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

          Так понятнее?
          • 0
            да, но хочется более понятого примера )
            • 0
              Что для вас кнопка? Обычная кнопка на интерфейсе?
  • 0
    На эту тему туча информации есть у HR отделов. Правда на российском ИТ-рынке эта тема ещё пока в зародыше.
    Кратко оценка происходит через
    1) должностные инструкции — которые регулярно пересматриваются и являются договором между фирмой и работником — выполняются они или нет
    2) профессиональный профиль — это очень большая тема ранжировки навыков и по ней отслеживают уровень и эффективность
    3) компетенции — профилево-независимые навыки

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

    Но самое главное в этом. Что есть самый главный хак — быть contributor'ом в систему/фирму, а остальное приложится :) что это означает? Это означает — интересовать об ожиданиях фирмы по отношению к себе, стремиться 100% их оправдать. Как механизм роста — это расширение своего impact («влияние»… по русски оттенок получается не очень). Но это тоже тема отдельного разговора.

    Вот в общем, где-то так. Книг не знаю, ссылок тоже. Только на опыте. Если интересно, могу поднять эту тему в «аджайл подкасте» (agilepod.ru), если интресно — можно обсудить (стучитесь — skype:denis_miller)
    • 0
      лучше пост по результатам и с выводами
  • +1
    ИМХО, как-то слишком «сферично-вакумно» :)
    Смахивает на статью по выбору щенков или котят (сам в шоке откуда такие ассоциации).
  • 0
    Бывают два типа работников: «уставшие» и «агрессивные»
    Прикольно! Я пол-года могу быть «уставшим», а потом пол-года «агрессивным» :)
    • 0
      Если вы стали «уставшим», то обратно дороги нет. Значит вы не уставший, вы слабоагрессивный
      • 0
        У меня это зависит от задач, если мутотень беспросветная в горах говнокода, то я «уставший», подумывающий стать опять «агрессивным», но уже на новом месте работы ;)

        А потом херак — новый проект, финансовые предложения от «которых я не могу отказаться», и я снова «агрессивный». И так уже 9 лет.
        • 0
          Вы точно не уставший. Поверьте.
          • 0
            аргументируйте пжлст
            • 0
              Человек все еще стремится к чему-либо.
  • +1
    На мой взгляд, ситуация несколько перекликается с тестом Тьюринга по ИИ, где интеллект определяется через другой интеллект, по сути — крайне субъективно, ввиду наличия отсутствия объективных критериев.

    Так и здесь — для оценки работника нужен другой работник, иногда называемый начальником :)

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

    Иными словами, хочешь узнать, кто лучший в конкретном подразделении — спроси у начальника подразделения.
  • 0
    Как сильно все зависит от конкретной задачи!

    В моем случае, самыми эффективными программистами оказались фрилансеры.
    Но для определенных задач они станут не эффективны.

    И вопрос — для чего вам мерить эффективность?
    • 0
      Чтобы минимизировать затраты и максимизировать прибыль. Основная цель — минимизация затрат на разработку. Это можно делать многими способами, и один из них заключается в том, чтобы работник выдавал более качественный результат.

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