Комментарии 140
Спасибо. Положил корпоративную вики, чтобы сотрудники ознакомились.
Начиная мыслить стратегически, человек зачастую теряет способность мыслить тактически.
Единственным мерилом качества работы сотрудника является то, насколько хорошо он делает то, что должен делать. Начальники руководят, архитекторы проектируют, кодеры реализуют. А у вас все в одну кучу.
Единственным мерилом качества работы сотрудника является то, насколько хорошо он делает то, что должен делать. Начальники руководят, архитекторы проектируют, кодеры реализуют. А у вас все в одну кучу.
А насколько он хорошо делает то, что должен делать? Может он недостаточно хорошо делает свою работу? Может на его место стоит взять человека, который лучше справится с задачей?
Для этого есть люди опытные, которые могут оценить и качество кода, и время разработки, и красоту архитектуры. По конкретным критериям конкретного проекта, за который они отвечают, а не по этим, абстрактным.
Я, например, видел совершенно вырвиглазные решения в проектах, где требовалась скорость работы. Там красота кода не нужна и на архитектуру все плевать хотели. А вот в компонентном — архитектура имеет огромное значение.
Замечу, что вы платите сотруднику за то, что он выполняет свою работу, а не наполняет корпоративную вики клевыми статейками на тему асинхронных многопоточных лямбд.
Я, например, видел совершенно вырвиглазные решения в проектах, где требовалась скорость работы. Там красота кода не нужна и на архитектуру все плевать хотели. А вот в компонентном — архитектура имеет огромное значение.
Замечу, что вы платите сотруднику за то, что он выполняет свою работу, а не наполняет корпоративную вики клевыми статейками на тему асинхронных многопоточных лямбд.
Статья не про то, как написать идеальный код или как оценить потом идеальность кода. Статья про эффективность работника. Он может быть сверхопытным, может нарисовать с закрытыми глазами архитектуру любого проекта, может написать идеальный код, но быть «уставшим». Кто оценит качество его работы? Какова его эффективность для компании? Деньги платят не за код, деньги платят за то, что программист делает продукт, который потом продается, а от продаж он получает свою долю обратно. Так вот с точки зрения управления, абсолютно неважно, кто именно работает, важно насколько эффективно трудовые ресурсы конвертируются в денежные.
Максимизация прибыли, минимизация затрат. Про вторую часть и идет речь в данной статье.
Максимизация прибыли, минимизация затрат. Про вторую часть и идет речь в данной статье.
У каждого человека, если что, есть должностные обязанности. Это то, о чем всегда забывают в программистских фирмах. И они — это то, за что платят деньги.
А еще есть разделение труда. Отличный архитектор не обязательно будет хорошим системщиком или прикладником. И наоборот. Глупо сажать сеньюра за код, который можно поручить джуниору. И в этом ничего не умеющий и не понимающий джуниор, выполняя простые задачки, экономит компании деньги. И пофиг, что он не развивается и не подсказывает другим эффективные алгоритмы.
В любом случае, для всех инженерных специальностей допустима только субъективная относительная оценка.
А еще есть разделение труда. Отличный архитектор не обязательно будет хорошим системщиком или прикладником. И наоборот. Глупо сажать сеньюра за код, который можно поручить джуниору. И в этом ничего не умеющий и не понимающий джуниор, выполняя простые задачки, экономит компании деньги. И пофиг, что он не развивается и не подсказывает другим эффективные алгоритмы.
В любом случае, для всех инженерных специальностей допустима только субъективная относительная оценка.
И? Есть должностные обязанности, есть разделение труда… И что? Это все как-то должно перечеркнуть все то, что я говорил?
Если вам захочется применять свои собственные оценки эффективности работника, да Бог с вами, применяйте! Но я никогда не буду сажать работника за код, чтобы тот оценивал его красоту или сложность. Это бесполезное занятие, по моему мнению.
Если вам захочется применять свои собственные оценки эффективности работника, да Бог с вами, применяйте! Но я никогда не буду сажать работника за код, чтобы тот оценивал его красоту или сложность. Это бесполезное занятие, по моему мнению.
У вас code review не делается вообще?
Он делается настолько часто, насколько часто вносятся изменения в продукт. Т.е. постоянно. Хотя что его там делать, внимание нужно уделить только отдельным кусочкам, все остальное сильно стандартизировано.
Тогда в чем проблема? Человек, который делает code review, должен уметь оценивать качество этого кода. Оценка этого человека и является мерилом качества — одним из параметров эффективности работника. Основным, замечу. Все остальное — саморазвитие, помощь товарищам и прочее, это мишура, которой хороший работник вовсе не обязан обладать.
Именно это я и имел ввиду, когда говорил о начальниках.
Именно это я и имел ввиду, когда говорил о начальниках.
Если вы работника расцениваете сугубо как станок, то мне жаль вашу компанию.
нужно уходить от субъективных оценок…
Ведь кто может с точностью сказать, что человек, который проверяет мой код — не в доле со мной… Он говорит, что я хорошо пишу, я получаю больше ЗП, он получает откат…
А вот объективные критерии такого не допустят… ибо он должен обосновать, что я хорошо пишу… причем в цифрах…
цифры — это единственное, что поддается счёту…
Ведь кто может с точностью сказать, что человек, который проверяет мой код — не в доле со мной… Он говорит, что я хорошо пишу, я получаю больше ЗП, он получает откат…
А вот объективные критерии такого не допустят… ибо он должен обосновать, что я хорошо пишу… причем в цифрах…
цифры — это единственное, что поддается счёту…
Посчитайте эффективность своего труда в цифрах.
Если бы я мог — был бы уже миллинером… вопрос не такой простой, как кажется…
Вы, как, автор этой статьи, это прекрасно понимаете…
Я лишь говорю, что не должно быть субъективной оценки… всё надо приводить к каким-то цифрам… а потом сравнивать со средними…
Около 2х лет назал был задача оценить труд «компьютерного мастера по вызову»… не могу раскрыть коммерческую тайну, как это было сделано, однако удалось создать систему, при которой его работа приводиться к чистым цифрам, далее не составило труда вывести среднее по компании и выяснить кто работает хорошо, а кто плохо…
Потом при субъективной проверке качества она практически совпадала с тем, что говорила эта система… при этом прослеживая статистику, можно было с точностью до месяца сказать — когда сотрудник испортился и начал оставлять свой телефон, вместо визитки фирмы…
Вы, как, автор этой статьи, это прекрасно понимаете…
Я лишь говорю, что не должно быть субъективной оценки… всё надо приводить к каким-то цифрам… а потом сравнивать со средними…
Около 2х лет назал был задача оценить труд «компьютерного мастера по вызову»… не могу раскрыть коммерческую тайну, как это было сделано, однако удалось создать систему, при которой его работа приводиться к чистым цифрам, далее не составило труда вывести среднее по компании и выяснить кто работает хорошо, а кто плохо…
Потом при субъективной проверке качества она практически совпадала с тем, что говорила эта система… при этом прослеживая статистику, можно было с точностью до месяца сказать — когда сотрудник испортился и начал оставлять свой телефон, вместо визитки фирмы…
Абстрагируйте свой опыт и поделитесь, многие будут благодарны
если абстрактно — то самое сложное — это понять, что же является результатом работы данного сотрудника… что должно произойти, если он хорошо выполнил свою работу и что должно произойти, если плохо… затем подсчитать количество таких случаев и сравнить со среднем по отделу/фирме… однако такой способ работает только когда есть достаточное число сотрудников (не меньше 5)… иначе не вычислить среднее…
Да, я согласен. Нужно уходить от субъективных оценок. А еще нужно наконец реализовать Демона Максвелла, изобрести вечный двигатель первого рода и превысить скорость света хотя бы в два раза.
Да, и в каких единицах измеряется «хорошо»?
Не очень в теме, а разве какой-нибудь метод вроде balance scorecard не пробовали применить к оценке труда разработчиков?
Генератор идей работает эффективнее. :) Если я буду использовать чужие наработки, то я не буду понимать некоторых телодвижений, почему их надо делать, или наоборот, почему их не надо делать.
Я недостаточно точно сформулировал вопрос. Я скорее интересовался не Вашим опытом, сколько существованием в мире такой практики как оценка труда разработчиков на основе группы сбалансированных показателей. Вы что-нибудь слышали об этом?
Суть в том, что мне, как менеджеру, не имеющему серьезного опыта в разработке, хочется больше понимать о том, что представляет собой труд разработчика, и по каким критериям его оценивать. Полагаю, что Вы привели только часть из таких критериев.
Также было бы интересно узнать, как можно оценить уровень абстракции мышления. Есть ли абсолютные показатели?
Суть в том, что мне, как менеджеру, не имеющему серьезного опыта в разработке, хочется больше понимать о том, что представляет собой труд разработчика, и по каким критериям его оценивать. Полагаю, что Вы привели только часть из таких критериев.
Также было бы интересно узнать, как можно оценить уровень абстракции мышления. Есть ли абсолютные показатели?
Про группу сбалансированных показателей читал очень давно, но, скрее всего, она не впечатлила меня, так как про нее не осталось ни одной зацепки в памяти кроме смутных воспоминаний.
Могу сказать одно, что если про нее не трубят на каждом углу, значит в ней что-то не то.
Про труд разработчика тяжело что-то рассказать в одном посте. Это что-то сродни творчеству, которое требует не таланта рисовать, а таланта оперировать логическими сущностями, абстракциями…
Чтобы оценить уровень абстракции мышления, достаточно задать задачу из реального мира и посмотреть, насколько качественно ее опишет разработчик. Например, описать бизнес-процесс компании. :) Или описать процесс сборки табуретки.
Больший уровень абстракции будет у того, кто сможет изменить без особых проблем описание бизнес-процесса компании на тот же процесс сборки табуретки.
Могу сказать одно, что если про нее не трубят на каждом углу, значит в ней что-то не то.
Про труд разработчика тяжело что-то рассказать в одном посте. Это что-то сродни творчеству, которое требует не таланта рисовать, а таланта оперировать логическими сущностями, абстракциями…
Чтобы оценить уровень абстракции мышления, достаточно задать задачу из реального мира и посмотреть, насколько качественно ее опишет разработчик. Например, описать бизнес-процесс компании. :) Или описать процесс сборки табуретки.
Больший уровень абстракции будет у того, кто сможет изменить без особых проблем описание бизнес-процесса компании на тот же процесс сборки табуретки.
BSC для оценки труда разработчика? Вообще не из той оперы.
Вообще-то вместо вот таких придуманных невнятных показателей, которые придуманы в статье давно уже существуют известные и проверенные методики. И называются они TSP/PSP (Team Software Process/Personal Software Process).
Почитайте на досуге, прежде чем изобретать велосипеды…
Вообще-то вместо вот таких придуманных невнятных показателей, которые придуманы в статье давно уже существуют известные и проверенные методики. И называются они TSP/PSP (Team Software Process/Personal Software Process).
Почитайте на досуге, прежде чем изобретать велосипеды…
Статью не читал, т.к. имею проверенное опытом мнение. Хороший работник — человек, выполняющий ожидания-требования руководителя. Эти требования должны быть адекватными, но это уже оценка руководителя. Итак, дал задачу закрутить 150 гаек человеку, закрутил — молодец, не закрутил — нет (закрутить реально и другие люди закручивают регулярно). Как, когда — малое значение. Дал сформированной команде задание построить токарный станок за 1 квартал, сделали — молодцы, не сделалы — все уроды (особенно, менеджеры, если вовремя не проинформировали). Ожидания — результат. Ожидание — отсутствие результата, значит, либо ожидания неадекватные (см. выше), либо вот он, плохой работник в IT.
Все остальные «более узкие» критерии рушатся об частности и лишь усложняют жизнь тому, кто этим вопросом должен заниматься (HR-рулевой и, чуть выше, генерал).
Стоило прочитать топик прежде чем давать комментарии.
Хороший работник и эффективный работник — разные понятия. Работник может быть хорошим, но неэффективным.
— Итак, дал задачу закрутить 150 гаек человеку, закрутил — молодец, не закрутил — нет
— (закрутить реально и другие люди закручивают регулярно).
Это смотря какие гайки крутить. Самые большие гайки весят около 5 тонн и чуть меньше полутора метров в диаметре. Некоторые начальники не обращают внимания на такие детали. Ну гайка и гайка…
— (закрутить реально и другие люди закручивают регулярно).
Это смотря какие гайки крутить. Самые большие гайки весят около 5 тонн и чуть меньше полутора метров в диаметре. Некоторые начальники не обращают внимания на такие детали. Ну гайка и гайка…
> Как, когда — малое значение
супер-работник неплопно закрутит аж 300 гаек — вот молодец, да?
супер-работник неплопно закрутит аж 300 гаек — вот молодец, да?
Это называется «плановая экономика»… такие эксперименты со страной уже проводились :)
Выполнил план — молодец, не выполнил — плохой сотрудник…
Выполнил план — молодец, не выполнил — плохой сотрудник…
> Чем больше кода создает работник, при минимальных временных затратах, тем более эффективный работник. Все это хорошо, но это не работает.
Более того, работник тем эффективнее, чем меньше кода он создаёт для решения эквивалентной задачи с эквивалентным качеством.
Более того, работник тем эффективнее, чем меньше кода он создаёт для решения эквивалентной задачи с эквивалентным качеством.
«эквивалентным качеством» чего? Кода или решения…
если кода, то соглашусь… а если качество решения — то не всегда…
решение может быть качественным, коротким, но абсолютно не читабельным…
особенно, когда используется оператор «a?b:c»
это существенно усложняет восприятие кода другим человеком…
так что тут длина кода — не показатель… или бинарный код, например :))
если кода, то соглашусь… а если качество решения — то не всегда…
решение может быть качественным, коротким, но абсолютно не читабельным…
особенно, когда используется оператор «a?b:c»
это существенно усложняет восприятие кода другим человеком…
так что тут длина кода — не показатель… или бинарный код, например :))
Проблема еще в том что руководители зачастую сами люди не сведущие в технических вопросах, и они не могут понять много ошибок делается или мало. Насколько сложная задача выполняется, и каково адекватное время ее выполнения. Очень трудно установить какую-то норму в данных вопросах.
И по поводу велосипедов вопрос спорный… стоит ли отбирать у них эту возможность. Многие люди любят делать велосипеды, особенно я. Но это часто идет в ущерб проекту, т.к. на велосипед тратится время. Да и не всегда велосипед является оправданным, т.к. его надо поддерживать самостоятельно.
И по поводу велосипедов вопрос спорный… стоит ли отбирать у них эту возможность. Многие люди любят делать велосипеды, особенно я. Но это часто идет в ущерб проекту, т.к. на велосипед тратится время. Да и не всегда велосипед является оправданным, т.к. его надо поддерживать самостоятельно.
P.S. собсна я обо всем об этом давно уже подумал очень серьезно… и пришел к выводу что лучше работать сдельно. Ибо повременная оплата ведет к тому что заказчик считает что он много платит и мало получает, а работник думает что много работает и мало получает. В результате заказчик превращается в контрол-фрика, а работник старается побольше тунеядствовать чтоб повысить тем самым реальную стоимость своего времени.
А все программисты выполняют задачи с разной скоростью. Например я могу сделать за неделю нечто очень крутое, то что некоторые будут делать несколько месяцев. Однако, бывает очень трудно доказать заказчику свою уникальность и обосновать соответственную стоимость своего времени.
А все программисты выполняют задачи с разной скоростью. Например я могу сделать за неделю нечто очень крутое, то что некоторые будут делать несколько месяцев. Однако, бывает очень трудно доказать заказчику свою уникальность и обосновать соответственную стоимость своего времени.
Без велосипедов трудно понять, что делаешь не так. Процесс создания велосипеда помогает понять ход мыслей того, кто его до тебя изобрел.
Свой велосипед бывает предпочтительнее чужого космического челнока. Задачи бывают разные — иногда надо лишь съездить в соседнюю деревню.
А изучать код чужого велосипеда после изобретения своего — как читать «Откровение». А уж ездить — так с первого отталкивания.
А изучать код чужого велосипеда после изобретения своего — как читать «Откровение». А уж ездить — так с первого отталкивания.
Мой небольшой вариант оценки: (все пункты через некоторое время совместной работы несложно проставить по 10 баллам)
1. Самостоятельность (насколько часто задает вопросы, с которыми мог разобраться сам?)
2. Качество кода (тут придется заглядывать в код)
3. Умение Видеть простые решения (то самое, абстрактное мышление). Тут естественно оценка будет либо относительно себя, либо относительно лучшего кодера в группе.
4. Ну и при исполнении прежних трех пунктов, уже можно замерять скорость выполнения задач :)
Чуть не забыл еще пару пунктов.
Нужно еще умение предвидеть потенциальные глюки кода, и писать сразу с учетом. Был у меня человек, который исправлял код раз в месяц (менялись условия), как оказалось не пытаясь решить проблему более глобально, чтобы раз, и навсегда.
И желательно, чтобы человек старался таки оценить производительность кода. Видел иногда аццкие перлы…
1. Самостоятельность (насколько часто задает вопросы, с которыми мог разобраться сам?)
2. Качество кода (тут придется заглядывать в код)
3. Умение Видеть простые решения (то самое, абстрактное мышление). Тут естественно оценка будет либо относительно себя, либо относительно лучшего кодера в группе.
4. Ну и при исполнении прежних трех пунктов, уже можно замерять скорость выполнения задач :)
Чуть не забыл еще пару пунктов.
Нужно еще умение предвидеть потенциальные глюки кода, и писать сразу с учетом. Был у меня человек, который исправлял код раз в месяц (менялись условия), как оказалось не пытаясь решить проблему более глобально, чтобы раз, и навсегда.
И желательно, чтобы человек старался таки оценить производительность кода. Видел иногда аццкие перлы…
По первому пункту есть замечание. Такая самостоятельность пересекается с изобретением велосипедов, особенно это касается новых людей в команде, которые не знают используемого инструментария. Грубый пример — для валидации формы в браузере новичок может начать писать свои JS скрипты или использовать какой-то «левый» (по отношению к команде) фреймворк/библиотеку, пускай его метод даже более эффективный, но он приведёт к потери эффективности команды в целом. Сам неоднократно слышал от более опытных коллег на новых местах: «а ты чего там возишься целый день? делов-то на пару часов» — «вот кодю то-то и то-то» — «блин, у нас же для это либа есть, кочущая из проекта в проект, тебе что, не сказали, когда задание давали? спросил бы „
Так что когда вообще не задают вопросов — тоже не очень хорошо, т. к. боязнь задать вопрос (вдруг оценят эффективность плохо) ведёт к дублированию кода, если не в проекте, так в фирме
Так что когда вообще не задают вопросов — тоже не очень хорошо, т. к. боязнь задать вопрос (вдруг оценят эффективность плохо) ведёт к дублированию кода, если не в проекте, так в фирме
Значит для новичков это правило стоить исключить. Но через квартал\полгода уже более менее самостоятельные должны быть? (при условии, что в курсе, что происходит в проекте). Ну и да, под этим словом я не вкладываю самостоятельное решение действительно важных вещей.
То, что вы рассказываете, результат недостаточного информационного обмена. Если бы его не кидали как на амбразуру кодить, а предварительно уделили ему внимание, то такая ситуация не случилась бы.
В моём случае внимание уделяли, но вот один пункт запамятовали.
С новичком это частный случай. Вообще имел в виду ситуацию о которой не давно был пост на хабре: что лучше — спросить у гуру или рыть самому. В плане самосовершенствования, конечно, лучше самому, а вот в плане экономической эффективности команды в целом всё не так однозначно, причём рассматривать надо и краткосрочный период, и долгосрочную перспективу, да расставить между ними приоритеты. Когда дедлайны поджимают, то самостоятельное решение проблемы может быть неприемлемо, даже если оно дешевле.
С новичком это частный случай. Вообще имел в виду ситуацию о которой не давно был пост на хабре: что лучше — спросить у гуру или рыть самому. В плане самосовершенствования, конечно, лучше самому, а вот в плане экономической эффективности команды в целом всё не так однозначно, причём рассматривать надо и краткосрочный период, и долгосрочную перспективу, да расставить между ними приоритеты. Когда дедлайны поджимают, то самостоятельное решение проблемы может быть неприемлемо, даже если оно дешевле.
НЛО прилетело и опубликовало эту надпись здесь
Сложную тему вы затронули. Далеко не всегда и везде это подойдет. Все предложенные вами метрики возможно хороши только тогда, когда менеджер может оценивать и понимать их (вот вы понимаете?). В остальных случаях — это также бесполезно, как и считать KLOC.
Так что тема не раскрыта, на мой взгляд.
Так что тема не раскрыта, на мой взгляд.
Проблема данных показателей в их туманности, расплывчатости и субъективности.
Все должно быть просто, ясно и понятно.
А здесь?
Как вы объясните работнику: я тебе не повышаю зарплату, потому что у тебя нет абстрактного мышления? Поставьте себя на место работника. Каково было бы услышать такое?
Или: я тебе урезаю премию, потому, что ты не распространяешь полезную информацию в коллективе?
Нахер, нахер такого работодателя…
Все должно быть просто, ясно и понятно.
А здесь?
Как вы объясните работнику: я тебе не повышаю зарплату, потому что у тебя нет абстрактного мышления? Поставьте себя на место работника. Каково было бы услышать такое?
Или: я тебе урезаю премию, потому, что ты не распространяешь полезную информацию в коллективе?
Нахер, нахер такого работодателя…
Если вы ищите причины не повышать работникам зарплату, то я такого не делаю. Потому что для повышения зарплаты есть такая замечательная вещь, как вовремя сделанная работа или коммерческий успех тех фич, которые сделал работник. В моей команде работники работают, а не в носу ковыряются. Им есть за что повышать зарплату всегда.
> «Агрессивные»… жадно впитывают знания, учатся, пробуют, делают ошибки,
> За ошибки работников компания платит из собственного кармана, а это потом отражается на благосостоянии самих же работников.
Если за ошибки больно наказывают, то агрессивным быть опасно ибо не допускает ошибок только тот кто ничего не делает. Особенно когда напишешь продукт с ошибкой идет штраф, а если не напишешь то компании каюк (грубо говоря).
> За ошибки работников компания платит из собственного кармана, а это потом отражается на благосостоянии самих же работников.
Если за ошибки больно наказывают, то агрессивным быть опасно ибо не допускает ошибок только тот кто ничего не делает. Особенно когда напишешь продукт с ошибкой идет штраф, а если не напишешь то компании каюк (грубо говоря).
Ну метрик вы так и не предложили. Если брать количество ошибок за метрику (что неявно следует), то мне достаточно меньше работать и я буду делать меньше ошибок.
Тех кто тащит за собой коллектив действительно мало и их часто не хватает. Однако в хорошей команде все роли сбалансированы. Есть тот, кто берет на себя критику идей, есть просто хорошие исполнители, без которых генератор идей бесполезен. Они все нужны.
А быстро доработку можно делать и просто вставляя патчи. Код будет деградировать, в итоге мы огребем проблемы в будущем.
Тех кто тащит за собой коллектив действительно мало и их часто не хватает. Однако в хорошей команде все роли сбалансированы. Есть тот, кто берет на себя критику идей, есть просто хорошие исполнители, без которых генератор идей бесполезен. Они все нужны.
А быстро доработку можно делать и просто вставляя патчи. Код будет деградировать, в итоге мы огребем проблемы в будущем.
А метрик нет. В этом вся соль.
Если быстрая доработка была один раз, второй, код продеградировал, то каждая последующая доработка будет все менее эффективной. Это и требовалось доказать.
А быстро доработку можно делать и просто вставляя патчи. Код будет деградировать, в итоге мы огребем проблемы в будущем.
Если быстрая доработка была один раз, второй, код продеградировал, то каждая последующая доработка будет все менее эффективной. Это и требовалось доказать.
Метрики скорее вредны, чем бесполезны — программисты легко их фальсифицируют.
Обычно любое из приведенных качеств при его использовании достаточно сильно увеличивает сроки разработки. Всегда приходится искать компромисс между тем, что хочется и тем, что надо.
При экстремальном программировании начальные большие сроки считаются нормальным явлением. Мы иногда переделываем 80% работы после того, как прошли рубеж 80% срока выполнения. Это необходимо делать, иначе никто пользоваться костылями не будет.
А НЕ использование увеличивает сроки еще больше, потому что без головы сам собой получается многослойный говнокод.
Я-то в курсе, но вот начальство не понимает такой простой истины. Как результат — ПО работает, но в код смотреть стыдно. Где успеваю — там переписываю нормально. Благо, когда пишу «основу» — упорно игнорирую требование «ускориться». Это и есть компромисс. Мелкие доп. задачи можно писать как угодно — в случае надобности они также быстро переписываются, а базовый функционал делаю как надо.
Насчет «работает» у тестеров, внедренцев и заказчика обычно другое
мнение.
И вот когда «типа работает у меня на машине если ничего не менять» переходит в реально заваленные сроки и угрозу потери клиента — начальство (а оно тоже бывает неглупое и заинтересованное) вполне может прозреть.
мнение.
И вот когда «типа работает у меня на машине если ничего не менять» переходит в реально заваленные сроки и угрозу потери клиента — начальство (а оно тоже бывает неглупое и заинтересованное) вполне может прозреть.
К счастью, в данном случае «работает» означает, что оно именно работает. Но, imho, при разработке на заказ, а не для внутренних нужд, при наличии хоть какого-то опыта коммерческого использования собственного ПО руководство обычно более адекватно относится к подобным вещам — иначе на рынке не выжить будет. Хотя встречаются и исключения.
По-моему, вы напутали причину со следствием, анализируете не результат, а предпосылки результата.
Вы написали список качеств, которые влияют на эффективность.
Но ведь между качествами и эффективностью лежит самое главное — непосредственно работа, реализация всех этих качеств.
В 19м веке платили больше тому, кто больше сделал, а не тому, кто сильнее, выше.
Вы написали список качеств, которые влияют на эффективность.
Но ведь между качествами и эффективностью лежит самое главное — непосредственно работа, реализация всех этих качеств.
В 19м веке платили больше тому, кто больше сделал, а не тому, кто сильнее, выше.
То было в 19м веке, когда не было интеллектуального труда.
Представьте, что вы тренер по баскетболу. Будете ли вы в команду набирать людей, у которых рост 1.50? Я думаю, что нет. Вы отберете высоких и будете уже среди них выбирать тех, кто приводит к маскимальной эффективности команды в целом. Так и тут. Нужно подбирать тех людей, которые заведомо имеют больше шанс на успех в будущем.
Представьте, что вы тренер по баскетболу. Будете ли вы в команду набирать людей, у которых рост 1.50? Я думаю, что нет. Вы отберете высоких и будете уже среди них выбирать тех, кто приводит к маскимальной эффективности команды в целом. Так и тут. Нужно подбирать тех людей, которые заведомо имеют больше шанс на успех в будущем.
Я буду набирать в команду людей, которые забивают, выдают результативные передачи, подбирают мяч после отскока и т.д. Посмотрите на Российскую женскую сборную по волейболу, там разрыв в росте немаленький.
Да блин. Вы опять и кругом неправы. Набор — это херня, мы же говорим о способах оценки эффективности! Вы что же, в баскетбольной команде будуте платить зарплату пропорционально росту? Или все-таки по результатам игр?
Да блин. Вы опять и кругом неправы. Набор — это херня, мы же говорим о способах оценки эффективности! Вы что же, в баскетбольной команде будуте платить зарплату пропорционально росту? Или все-таки по результатам игр?
Конечно я кругом и во всем неправ. Напишите опровержение всем моим постулатам в виде отдельной статьи.
:)
Вы путаете зарплату и эффективность. Зарплата является следствием эффективности, а не причиной ее. Слабая эффективность команды приводит к низким экономическим показателям компании, и, как следствие, низкой зарплате.
:)
Вы путаете зарплату и эффективность. Зарплата является следствием эффективности, а не причиной ее. Слабая эффективность команды приводит к низким экономическим показателям компании, и, как следствие, низкой зарплате.
прошу прощения за вопрос не по теме — а в какой программе рисуются эти белые человечки, представленные в начале статьи. В последнее время часто на них натыкаюсь — мне стало интересно, их в чем-то клепают или это просто совпадение
Хороший, эффективный и пр. пр. пр. работник это тот который искренне и всей душей убежден, что в мире существует только два мнения — Начальника и… глупое —
Хрущев.
Хрущев.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Заблуждений? У вас есть что-то лучше? Расскажите нам, будет интересно всем.
Кто не работает, тот никогда не ошибается.
Само собой. Только сказали же «меньше ошибок», а не «без ошибок». Например, у нас у одного товарища тикеты часто возвращаются по 2-3 раза — имхо, признак.
Эхх, Джоел уже столько на эту тему всего написал...
Если кто-то еще не читал, крайне рекомендую. Ссылка на список переведенных статей.
Если кто-то еще не читал, крайне рекомендую. Ссылка на список переведенных статей.
НЛО прилетело и опубликовало эту надпись здесь
То есть если в ТЗ нет, например, требований на разделение кода и данных, а так же валидацию пользовательских данных, и один работник решил её одной простынёй смеси php, html, css и js кода, а другой реализовал хотя бы простейшую модульность (инклуды для настроек, для бд и т. п.) и шаблонизатор (на тех же инклудах), предотвратил в коде хотя бы sql инъекции, вынес css и js в отдельные файлы, но сделал это чуть медленнее первого (хотя бы за счёт написания «лишних» include и т. п. ) вы решите, что первый более эффективный и, скажем, поднимете ему зарплату? O_o
НЛО прилетело и опубликовало эту надпись здесь
Жаль не были вы моим работодателем лет 10 назад, я б вам простыней накодил :D
Меньше ошибок — более эффективный работник
Споры вызывает уже это. По нескольким причинам.
1) Ошибка ошибке рознь. Пропустил точку в статическом тексте в разделе «О компании» — это одно. Неправильно пропиcать ту же точку в значении курса доллара — это другое.
2) Про одну одну и ту же ошибочную ситуацию один тестер может сказать что это одна ошибка. Другой может сказать что их сто штук. Нампример, ошибка в футере страницы сайта. А страниц этих — стопятьсот :D
И вообще. Тут проблема не столько в работниках. Сама работа программиста подразумевает что баги есть и будут. И с этим бесполезно бороться при помощи дисциплинарных методов — лишь хуже будет.
Абстрагируйтесь от конкретики. Нет разницы какая ошибка, она либо есть, либо ее нет. Если есть, это не значит, что работник не эффективен, это вообще ничего не значит, потому что значение появляется только тогда, когда берется некий промежуток времени, на котором собирается статистика ошибок. И чем статистика лучше, тем эффективнее труд человека.
> Меньше ошибок — более эффективный работник
Петя сдал пузырьковую сортировку, а Вася — систему распознавания изображений. Петя сделал 1 ошибку, а Вася 3. Выходит Петя гораздо более эффективный работник. Конечно, скажете, результаты нужно поделить на сложность задачи. А как Вы ее количественно определите?
Или другой вариант: Вася написал алгоритм, а Петя использовал готовую библиотеку. У обоих по одной ошибке. Но Вася вмиг исправил, а Петя сказал, что отрапортавал об ошибке и будет ждать новой версии библиотеки.
> Тем более эффективный работник, чем больше он распространяет полезную информацию в коллективе
Есть такая категория людей — пиздуны. Они есть в любом коллективе. Они могут распространяться о высоких технологиях, о всех новинках, вычитанных на хабре, быть в курсе последних новостей. Могут охаивать архитектуру проекта или выбранную методологию работы и создавать впечатление мудрых и знающих специалистов. Но практическая ценность от этих людей — абсолютный ноль. Они как правило реально сами не в состоянии ничего сделать. Самый простой способ распознать пиздуна — спросить его как сделать какую-нибудь нетривиальную задачу. Если Вы в ту же секунду получаете нескончаемый поток идей, и уверения, что реализовать все это не стоит большого труда, то перед вами типичный пиздун.
> Генераторы идей много раз эффективнее потребителей идей
См. выше. Пиздун генерирует идеи исключительно для того, чтобы кто-то другой их делал. Реальную ценность представляет человек, который способен аргументировать свои идеи с практической точки зрения, и помимо этого обладать чувством внутренней эстетичности чтоли, минималистичности. Если человек изначально настроен, что свои идеи он будет реализовывать сам, то его решение получится проще и изящнее. Тогда как проект пиздуна с самого начала обрастет всевозможным количеством модных библиотек и фреймворков, и из каждой он будет использовать ровно по одной функции.
> Чем более абстрактное мышление, тем эффективнее работник
Сильный уровень абстракций и стремление к универсальности приводит к ошибке овердизайна. Когда Вася изобретает кучу абстрактных интерфейсов и UML схем, Петя просто влоб пишет компонент, который реализует задачу. Этим страдают большинство профессиональных программистов, пытающихся писать reusable код. Нужно понимать, что в 90% случаев новая задача все-равно потребует специфического решения, и все абстракции пойдут коту под хвост.
> Эффективность работника прямо пропорциональна его самомотивации
Я бы сказал, не прямо пропорциональна, а экспоненциально ))
> Чем быстрее работники выполняют доработку кода, тем они эффективнее
Да, но не всегда. Для новой задачи Петя сделал «как надо»: наследовал интерфейс, модифицировал Factory, создал новую имплементацию на базе старой. А Вася в коде поставил один дополнительный if. Вася справился быстрее. Но со временем количество if-ов в васином коде стало расти. Ошибки стали появляться чаще, а доработки все дольше… Думаю понятно, что надо смотреть не само время, а динамику.
Петя сдал пузырьковую сортировку, а Вася — систему распознавания изображений. Петя сделал 1 ошибку, а Вася 3. Выходит Петя гораздо более эффективный работник. Конечно, скажете, результаты нужно поделить на сложность задачи. А как Вы ее количественно определите?
Или другой вариант: Вася написал алгоритм, а Петя использовал готовую библиотеку. У обоих по одной ошибке. Но Вася вмиг исправил, а Петя сказал, что отрапортавал об ошибке и будет ждать новой версии библиотеки.
> Тем более эффективный работник, чем больше он распространяет полезную информацию в коллективе
Есть такая категория людей — пиздуны. Они есть в любом коллективе. Они могут распространяться о высоких технологиях, о всех новинках, вычитанных на хабре, быть в курсе последних новостей. Могут охаивать архитектуру проекта или выбранную методологию работы и создавать впечатление мудрых и знающих специалистов. Но практическая ценность от этих людей — абсолютный ноль. Они как правило реально сами не в состоянии ничего сделать. Самый простой способ распознать пиздуна — спросить его как сделать какую-нибудь нетривиальную задачу. Если Вы в ту же секунду получаете нескончаемый поток идей, и уверения, что реализовать все это не стоит большого труда, то перед вами типичный пиздун.
> Генераторы идей много раз эффективнее потребителей идей
См. выше. Пиздун генерирует идеи исключительно для того, чтобы кто-то другой их делал. Реальную ценность представляет человек, который способен аргументировать свои идеи с практической точки зрения, и помимо этого обладать чувством внутренней эстетичности чтоли, минималистичности. Если человек изначально настроен, что свои идеи он будет реализовывать сам, то его решение получится проще и изящнее. Тогда как проект пиздуна с самого начала обрастет всевозможным количеством модных библиотек и фреймворков, и из каждой он будет использовать ровно по одной функции.
> Чем более абстрактное мышление, тем эффективнее работник
Сильный уровень абстракций и стремление к универсальности приводит к ошибке овердизайна. Когда Вася изобретает кучу абстрактных интерфейсов и UML схем, Петя просто влоб пишет компонент, который реализует задачу. Этим страдают большинство профессиональных программистов, пытающихся писать reusable код. Нужно понимать, что в 90% случаев новая задача все-равно потребует специфического решения, и все абстракции пойдут коту под хвост.
> Эффективность работника прямо пропорциональна его самомотивации
Я бы сказал, не прямо пропорциональна, а экспоненциально ))
> Чем быстрее работники выполняют доработку кода, тем они эффективнее
Да, но не всегда. Для новой задачи Петя сделал «как надо»: наследовал интерфейс, модифицировал Factory, создал новую имплементацию на базе старой. А Вася в коде поставил один дополнительный if. Вася справился быстрее. Но со временем количество if-ов в васином коде стало расти. Ошибки стали появляться чаще, а доработки все дольше… Думаю понятно, что надо смотреть не само время, а динамику.
Петя сдал пузырьковую сортировку, а Вася — систему распознавания изображений. Петя сделал 1 ошибку, а Вася 3. Выходит Петя гораздо более эффективный работник. Конечно, скажете, результаты нужно поделить на сложность задачи. А как Вы ее количественно определите?
Результат работы Пети принес компании 1000 продаж, а ошибка Васи принесла отказ одного очень важного клиента, который мог сделать 10 000 продаж сразу.
Или другой вариант: Вася написал алгоритм, а Петя использовал готовую библиотеку. У обоих по одной ошибке. Но Вася вмиг исправил, а Петя сказал, что отрапортавал об ошибке и будет ждать новой версии библиотеки
Учитывайте последний пункт. Петя менее эффективный чем Вася.
Есть такая категория людей ....
… чем больше он распространяет полезную информацию в коллективе
См. выше.
См. выше.
Сильный уровень абстракций и стремление к универсальности приводит к ошибке овердизайна.
Не приводит, если все понимают, то допускать такой ситуации нельзя. Зачем брать крайний вариант? Перегибы палки вносят негатива больше, чем недогибы. Если работник не понимает, про что речь, и приходится думать за него своей головой, то ценность такого работника стремится к нулю.
> Результат работы Пети принес компании 1000 продаж, а ошибка Васи принесла отказ одного очень важного клиента, который мог сделать 10 000 продаж сразу.
А это уже Ваши косяки как менеджера, ибо Вы неправильно оценили риски во втором случае. Нужно было не Васю отчитывать за ошибки, а поставить Колю на тестинг и заложить это в цену. Профессионалы в покере тем и отличаются, что могут сыграть на любой карте, а не сетовать, что фулхауса на руках нету.
Я думаю, с такой жесткой и нечеловечной системой оценки качеств Вы быстро потеряете весь адекватный персонал.
Работник эффективный, если:
1. Адекватен в суждениях, имеет свою точку зрения и может аргументировать
2. Хочет работать, чего-то достичь и чему-то научиться
3. Всегда имеет профессиональные интересы сверх того, что требует текущий проект
4. Ответственный за порученную работу
Количественно никак не меряется.
А это уже Ваши косяки как менеджера, ибо Вы неправильно оценили риски во втором случае. Нужно было не Васю отчитывать за ошибки, а поставить Колю на тестинг и заложить это в цену. Профессионалы в покере тем и отличаются, что могут сыграть на любой карте, а не сетовать, что фулхауса на руках нету.
Я думаю, с такой жесткой и нечеловечной системой оценки качеств Вы быстро потеряете весь адекватный персонал.
Работник эффективный, если:
1. Адекватен в суждениях, имеет свою точку зрения и может аргументировать
2. Хочет работать, чего-то достичь и чему-то научиться
3. Всегда имеет профессиональные интересы сверх того, что требует текущий проект
4. Ответственный за порученную работу
Количественно никак не меряется.
Это не мои косяки. Это я к тому, что ошибка имеет стоимость для компании. И сказать однозначно, что одна ошибка страшнее другой невозможно.
Кто вам сказал, что я оцениваю так заработную плату работника? Меня может спокойно удовлетворять недостаточно эффективный работник, если он не требует большой оплаты труда. Он может дорасти до адекватного работника и получить больше плюшек от компании.
Кто вам сказал, что я оцениваю так заработную плату работника? Меня может спокойно удовлетворять недостаточно эффективный работник, если он не требует большой оплаты труда. Он может дорасти до адекватного работника и получить больше плюшек от компании.
Есть такая категория людей — пиздуны. Они есть в любом коллективе. Они могут распространяться о высоких технологиях, о всех новинках, вычитанных на хабре, быть в курсе последних новостей. Могут охаивать архитектуру проекта или выбранную методологию работы и создавать впечатление мудрых и знающих специалистов. Но практическая ценность от этих людей — абсолютный ноль. Они как правило реально сами не в состоянии ничего сделать. Самый простой способ распознать пиздуна — спросить его как сделать какую-нибудь нетривиальную задачу. Если Вы в ту же секунду получаете нескончаемый поток идей, и уверения, что реализовать все это не стоит большого труда, то перед вами типичный пиздун.
Фух, я сначала испугался, но на последнем предложении успокоился :D.
По-моему, Вы свои собственные представления об идеальном сферическом программисте в вакууме перекладываете на реальную жизнь, что надо делать всегда с большой осторожностью. По-моему, пытаться строить макдональдсы из программистов и вводить какие-то странные показатели эффективности глупо, т.к. это приведет к тому, что люди начнут работать не ради создания продукта, а ради достижения показателей эффективности.
А кто сказал, что эти показатели эффективности должны обязательно монетизироваться? Вы монетизируйте продукт, а не труд человека.
Так вы же собираетесь оценивать людей по введенным Вами критериям эффективности. Значит, люди будут подстраивать свою активность под них, т.к. захотят, чтобы Вы их хорошо оценивали. И не факт, что это приведет к росту полезной отдачи от них.
Вообще, мне кажется, вводить метрики для оценки людей творческих профессий — достаточно бессмысленная задача. Лучше всего работает простая «вертикаль власти» — каждый начальник оценивает своих подчиненных по неформализуемой совокупности факторов.
Вообще, мне кажется, вводить метрики для оценки людей творческих профессий — достаточно бессмысленная задача. Лучше всего работает простая «вертикаль власти» — каждый начальник оценивает своих подчиненных по неформализуемой совокупности факторов.
Сложная тема, и не просто местами субъективная, а полностью субъективная, поэтому как только появляется вопрос: а кто и как будет оценивать результаты работы сотрудника, проще и, вероятно, правильнее всего отвечать: я и по моим собственным (пусть и субъективным) метрикам — и обсуждению это не подлежит. Эффективность работы сотрудника ИТ-области — величина интегральная, это и скорость разработки и эффективность кода, количество ошибок, абстрактность мышления, умение решать задачи, да много чего еще можно перечислять. Но никакие объективные метрики не дадут нам точной оценки, потому что ИТ — сама по себе нематериальная область, любая метрика имеет свои способы накрутки. И в итоге получается, что субъективные методы оценки будут более объективными…
Именно!
Предлагаю обновить, с позволения maxz, топик с добавлением этого прекрасного рассуждения. Ваша идея в таком случае становится еще более понятной и связной.
Давным давно было установлено, что хороший программист тот, который моется не реже двух раз в неделю.
Прочитал. Спасибо.
Надо создать блог «Учись управлять» и этот топик туда переместить.
Надо создать блог «Учись управлять» и этот топик туда переместить.
Будет сиротливо болтаться? Лучше пусть в стартапах будет, там это более насущная проблема.
Мне статья очень понравилась! В точку! Может в России как-то по другому (я на западе работаю), но все моменты описанные автором, четко отслеживаются в нашей компании. Спасибо за хорошую статью. Положил в закладки, отправил друзьям :)
Непонятно, как соотносятся «Чем более абстрактное мышление» и «Чем более простыми абстракциями оперирует человек». А в целом мысли хорошие.
Что не так? Можно на примерах?
о_О
Я думал, это вы мне пример приведёте, в котором чем более абстрактное мышление, тем эти сами абстракции проще.
Я считаю, что чем более развито абстрактное мышление, тем более сложные абстракции можно использовать. «Можно», конечно, не значит, «обязательно», но мне как-то противоположная корреляция виделась.
Я думал, это вы мне пример приведёте, в котором чем более абстрактное мышление, тем эти сами абстракции проще.
Я считаю, что чем более развито абстрактное мышление, тем более сложные абстракции можно использовать. «Можно», конечно, не значит, «обязательно», но мне как-то противоположная корреляция виделась.
Извините, не понял вопроса. Приведу конечно же.
Допустим, есть задача описать документооборот некой компании. Если пришел документ А, то начать процедуру Р1, если следом приходит документ Б, то начать процедуру Р2. Если наступил некий таймаут или пришел документ В, то нужно запустить процедуру Р3.
Обычный программист со слабым уровнем абстракции просто напишет некий скрипт, который бы проверял эти все условия, наличие документов, и так далее.
Программист, который более силен в абстракциях, заметит закономерности, что есть некие события: приход документа или срабатывание таймаута. События имеют входящие параметры и исходящие параметры. Входящими параметрами может быть документ или время, исходящими — новое состояние системы или новый документ. И так далее развивая мысль до бесконечности.
Так понятнее?
Допустим, есть задача описать документооборот некой компании. Если пришел документ А, то начать процедуру Р1, если следом приходит документ Б, то начать процедуру Р2. Если наступил некий таймаут или пришел документ В, то нужно запустить процедуру Р3.
Обычный программист со слабым уровнем абстракции просто напишет некий скрипт, который бы проверял эти все условия, наличие документов, и так далее.
Программист, который более силен в абстракциях, заметит закономерности, что есть некие события: приход документа или срабатывание таймаута. События имеют входящие параметры и исходящие параметры. Входящими параметрами может быть документ или время, исходящими — новое состояние системы или новый документ. И так далее развивая мысль до бесконечности.
Так понятнее?
На эту тему туча информации есть у HR отделов. Правда на российском ИТ-рынке эта тема ещё пока в зародыше.
Кратко оценка происходит через
1) должностные инструкции — которые регулярно пересматриваются и являются договором между фирмой и работником — выполняются они или нет
2) профессиональный профиль — это очень большая тема ранжировки навыков и по ней отслеживают уровень и эффективность
3) компетенции — профилево-независимые навыки
Это система с большим количеством букв, но по ней лихо можно показать ожидания фирмы от сотрудника, и померять его эффективность. И нужно помнить, что эффективность определяется не абстрактными характеристиками, а соответствием (как это не банально звучит) занимаемой должности. А должность определяется фирмой, которая выстраивает определенные ожидания. Если человек удовлетворяет ожиданиям фирмы в этой определенной должности — эффективность хорошая, если больше или меньше — тут вступают механизмы как это поправить (для первого случая повышение, для второго — дополнительное обучение или пинка под попу).
Но самое главное в этом. Что есть самый главный хак — быть contributor'ом в систему/фирму, а остальное приложится :) что это означает? Это означает — интересовать об ожиданиях фирмы по отношению к себе, стремиться 100% их оправдать. Как механизм роста — это расширение своего impact («влияние»… по русски оттенок получается не очень). Но это тоже тема отдельного разговора.
Вот в общем, где-то так. Книг не знаю, ссылок тоже. Только на опыте. Если интересно, могу поднять эту тему в «аджайл подкасте» (agilepod.ru), если интресно — можно обсудить (стучитесь — skype:denis_miller)
Кратко оценка происходит через
1) должностные инструкции — которые регулярно пересматриваются и являются договором между фирмой и работником — выполняются они или нет
2) профессиональный профиль — это очень большая тема ранжировки навыков и по ней отслеживают уровень и эффективность
3) компетенции — профилево-независимые навыки
Это система с большим количеством букв, но по ней лихо можно показать ожидания фирмы от сотрудника, и померять его эффективность. И нужно помнить, что эффективность определяется не абстрактными характеристиками, а соответствием (как это не банально звучит) занимаемой должности. А должность определяется фирмой, которая выстраивает определенные ожидания. Если человек удовлетворяет ожиданиям фирмы в этой определенной должности — эффективность хорошая, если больше или меньше — тут вступают механизмы как это поправить (для первого случая повышение, для второго — дополнительное обучение или пинка под попу).
Но самое главное в этом. Что есть самый главный хак — быть contributor'ом в систему/фирму, а остальное приложится :) что это означает? Это означает — интересовать об ожиданиях фирмы по отношению к себе, стремиться 100% их оправдать. Как механизм роста — это расширение своего impact («влияние»… по русски оттенок получается не очень). Но это тоже тема отдельного разговора.
Вот в общем, где-то так. Книг не знаю, ссылок тоже. Только на опыте. Если интересно, могу поднять эту тему в «аджайл подкасте» (agilepod.ru), если интресно — можно обсудить (стучитесь — skype:denis_miller)
ИМХО, как-то слишком «сферично-вакумно» :)
Смахивает на статью по выбору щенков или котят (сам в шоке откуда такие ассоциации).
Смахивает на статью по выбору щенков или котят (сам в шоке откуда такие ассоциации).
Бывают два типа работников: «уставшие» и «агрессивные»
Прикольно! Я пол-года могу быть «уставшим», а потом пол-года «агрессивным» :)
Прикольно! Я пол-года могу быть «уставшим», а потом пол-года «агрессивным» :)
Если вы стали «уставшим», то обратно дороги нет. Значит вы не уставший, вы слабоагрессивный
На мой взгляд, ситуация несколько перекликается с тестом Тьюринга по ИИ, где интеллект определяется через другой интеллект, по сути — крайне субъективно, ввиду наличия отсутствия объективных критериев.
Так и здесь — для оценки работника нужен другой работник, иногда называемый начальником :)
Хороший работник виден начальнику и так, невооруженным статистикой глазом. Ведь зачастую крайне важны такие вещи как мотивация, коммуникабельность, способность позитивно вести себя в конфликтных ситуациях, энтузиазм, в конце концов, а как это все объективно измерить?
Иными словами, хочешь узнать, кто лучший в конкретном подразделении — спроси у начальника подразделения.
Так и здесь — для оценки работника нужен другой работник, иногда называемый начальником :)
Хороший работник виден начальнику и так, невооруженным статистикой глазом. Ведь зачастую крайне важны такие вещи как мотивация, коммуникабельность, способность позитивно вести себя в конфликтных ситуациях, энтузиазм, в конце концов, а как это все объективно измерить?
Иными словами, хочешь узнать, кто лучший в конкретном подразделении — спроси у начальника подразделения.
Как сильно все зависит от конкретной задачи!
В моем случае, самыми эффективными программистами оказались фрилансеры.
Но для определенных задач они станут не эффективны.
И вопрос — для чего вам мерить эффективность?
В моем случае, самыми эффективными программистами оказались фрилансеры.
Но для определенных задач они станут не эффективны.
И вопрос — для чего вам мерить эффективность?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Способы оценки эффективности работника