Многие менеджеры сталкиваются с одной очень занимательной проблемой в IT-сфере. И имя этой проблеме — оценка эффективности работника. Еще пол столетия назад такая задача не вызывала приступов мигрени и паники у руководителей или экономистов, потому что все было просто. Работник закрутил 50 гаек — плохо, закрутил 150 гаек — великолепно! Но пришла революция информационных технологий, и оценка эффективности стала краеугольным камнем.
Давайте разберемся, что к чему. Допустим, у нас есть абстрактный IT-работник, очень сильно смахивающий на программиста, который будет создавать не менее абстрактный продукт в некой компании таких же абстрактных работников. Первое, что сделал бы оценщик середины 19 века, это вывел вполне четкие показатели труда. И были бы это время и количество кода. Чем больше кода создает работник, при минимальных временных затратах, тем более эффективный работник. Все это хорошо, но это не работает.
А не работает это потому, что сложность задач разная. Одну задачу можно решать две недели, вторую 15 минут. Ага, значит нам надо изменять формулу оценки. Давайте возьмем некий коэффициент сложности задачи будем умножать на него количество кода. Чем больше сложного кода за меньший промежуток времени делает работник, тем он эффективнее. Формулировка отличная, только за более длительный промежуток времени работник может выполнять две легкие задачи, две тяжелые, одну средней сложности. Это серьезно понижает его эффективность, судя по формулировке.
Как бы мы не пытались ходить вокруг да около, толк от этих рассчетов будет нулевым. Проблема кроется в показателях. Если время еще можно использовать, то количество кода — нет. Это вообще не показатель эффективности.
Многие компании, на заре развития IT-отрасли, пытались платить за количество строк, которые написал программист. Кто-то смекнул, что писать можно работающую лабуду с ужасным количеством лишнего кода. Деньги за количество символов платят, а не за качество или эффективность кода.
Лично для меня показатели эффективности работника совершенно другие. Некоторые из них носят субъективный характер, и я это не отрицаю.
Чем меньше ошибок допускает работник в работе, тем более качественный его труд. Качество кода легко превращается в удовольствие пользователей, которые могут выбрать ваш продукт именно за этот показатель. Второй плюс качественного кода заключается в минимизации затрат на поддержку, тестирование и прочее. Да, человек не идеален, но если он не протестировал самостоятельно результаты своего труда, а уже отрапортовал о завершении работы, то его лень приведет к целой цепочке неэффективных телодвижений в компании. За ошибки работников компания платит из собственного кармана, а это потом отражается на благосостоянии самих же работников.
В команде разработчиков всегда должен происходить информационный обмен. Работники должны делиться между собой полезной информацией об удобных конструкциях кода или приемах, об удачной реализации какого-то функционала, о новых технологиях, о результатах своих исследований, о проблемах и их решениях… Если человек не генерирует информацию, он перестает быть эффективным работником, так как его знания не помогают другим. Это не касается новичков в команде, но даже новички могут создавать положительный информационный фон.
Работники, которые могут самостоятельно генерировать идеи, на мой взгляд, самые ценные работники. Им не нужно писать детальных ТЗ, не нужно скрупулезно пояснять отличие одного подхода от другого, и почему стоит выбирать другой путь, а не тот, который они где-то прочитали. Эти работники придумают 10 способов решения нетривиальных задач, и найдут 10 причин, почему каждый из них не будет работать. Они тащат за собой весь коллектив и не боятся трудностей. Потому что им интересно изобретать велосипеды, и ни в коем случае нельзя отбирать у них эту возможность.
Чем более простыми абстракциями оперирует человек, тем проще задачи он может решать. Умение управлять сложными абстракциями приводит к потрясающему эффекту. Для такого человека перестает быть важным язык программирования, инструменты, подходы, алгоритмы. Любая, даже сложнейшая система, для него не будет представлять никакой сложности, потому что он умеет смотреть в корень, а не на ботву. Обычно, такие люди становятся архитекторами ПО, разрабатывают спецификации, занимаются аналитикой.
Бывают два типа работников: «уставшие» и «агрессивные». «Уставшие» работники стремятся как можно меньше делать и как можно больше получать денег. Им не интересно ни развиваться, ни изучать что-то новое. Усталость их не от того, что на них взвалили много работы, или они неэффективно распределяли свое время, и приходилось перерабатывать. Их усталость от потери интереса или мотивации в работе.
«Агрессивные» наоборот, стараются как можно бытсрее пройти путь обучения, развития, становления, чтобы получить доступ к еще большему количеству ресурсов, чтобы развиваться, развиваться, развиваться. Они жадно впитывают знания, учатся, пробуют, делают ошибки, и над ними не нужно выстраивать пирамиду менеджеров, чтобы подстегивать к работе. «Уставшие» стараются найти работу в больших компаниях, где эффект от их работы не виден вообще. «Агрессивные» находят себя в стартапах, маленьких компаниях, потому что там проще получать все, что им требуется.
Потому что они как минимум предусмотрели масштабируемость кода, реализовали на качественном уровне сам код, используя понятные конструкции и названия переменных, могут быстро читать «чужой» код, создали предсказуемую и понятную архитектуру, в которой легко делать отладку. Столь простая характеристика может рассказать о коде гораздо больше, чем количество строк в единицу времени.
Это не все методы оценки, но именно эти я использую для отбора персонала и для оценки эффективности работы компании. Надеюсь, что и вам пригодится.
UPD: Перенес статью в более подходящий раздел. Спасибо andreycha
Давайте разберемся, что к чему. Допустим, у нас есть абстрактный IT-работник, очень сильно смахивающий на программиста, который будет создавать не менее абстрактный продукт в некой компании таких же абстрактных работников. Первое, что сделал бы оценщик середины 19 века, это вывел вполне четкие показатели труда. И были бы это время и количество кода. Чем больше кода создает работник, при минимальных временных затратах, тем более эффективный работник. Все это хорошо, но это не работает.
А не работает это потому, что сложность задач разная. Одну задачу можно решать две недели, вторую 15 минут. Ага, значит нам надо изменять формулу оценки. Давайте возьмем некий коэффициент сложности задачи будем умножать на него количество кода. Чем больше сложного кода за меньший промежуток времени делает работник, тем он эффективнее. Формулировка отличная, только за более длительный промежуток времени работник может выполнять две легкие задачи, две тяжелые, одну средней сложности. Это серьезно понижает его эффективность, судя по формулировке.
Как бы мы не пытались ходить вокруг да около, толк от этих рассчетов будет нулевым. Проблема кроется в показателях. Если время еще можно использовать, то количество кода — нет. Это вообще не показатель эффективности.
Многие компании, на заре развития IT-отрасли, пытались платить за количество строк, которые написал программист. Кто-то смекнул, что писать можно работающую лабуду с ужасным количеством лишнего кода. Деньги за количество символов платят, а не за качество или эффективность кода.
Новый взгляд на вещи
Лично для меня показатели эффективности работника совершенно другие. Некоторые из них носят субъективный характер, и я это не отрицаю.
Меньше ошибок — более эффективный работник
Чем меньше ошибок допускает работник в работе, тем более качественный его труд. Качество кода легко превращается в удовольствие пользователей, которые могут выбрать ваш продукт именно за этот показатель. Второй плюс качественного кода заключается в минимизации затрат на поддержку, тестирование и прочее. Да, человек не идеален, но если он не протестировал самостоятельно результаты своего труда, а уже отрапортовал о завершении работы, то его лень приведет к целой цепочке неэффективных телодвижений в компании. За ошибки работников компания платит из собственного кармана, а это потом отражается на благосостоянии самих же работников.
Тем более эффективный работник, чем больше он распространяет полезную информацию в коллективе
В команде разработчиков всегда должен происходить информационный обмен. Работники должны делиться между собой полезной информацией об удобных конструкциях кода или приемах, об удачной реализации какого-то функционала, о новых технологиях, о результатах своих исследований, о проблемах и их решениях… Если человек не генерирует информацию, он перестает быть эффективным работником, так как его знания не помогают другим. Это не касается новичков в команде, но даже новички могут создавать положительный информационный фон.
Генераторы идей много раз эффективнее потребителей идей
Работники, которые могут самостоятельно генерировать идеи, на мой взгляд, самые ценные работники. Им не нужно писать детальных ТЗ, не нужно скрупулезно пояснять отличие одного подхода от другого, и почему стоит выбирать другой путь, а не тот, который они где-то прочитали. Эти работники придумают 10 способов решения нетривиальных задач, и найдут 10 причин, почему каждый из них не будет работать. Они тащат за собой весь коллектив и не боятся трудностей. Потому что им интересно изобретать велосипеды, и ни в коем случае нельзя отбирать у них эту возможность.
Чем более абстрактное мышление, тем эффективнее работник
Чем более простыми абстракциями оперирует человек, тем проще задачи он может решать. Умение управлять сложными абстракциями приводит к потрясающему эффекту. Для такого человека перестает быть важным язык программирования, инструменты, подходы, алгоритмы. Любая, даже сложнейшая система, для него не будет представлять никакой сложности, потому что он умеет смотреть в корень, а не на ботву. Обычно, такие люди становятся архитекторами ПО, разрабатывают спецификации, занимаются аналитикой.
Эффективность работника прямо пропорциональна его самомотивации
Бывают два типа работников: «уставшие» и «агрессивные». «Уставшие» работники стремятся как можно меньше делать и как можно больше получать денег. Им не интересно ни развиваться, ни изучать что-то новое. Усталость их не от того, что на них взвалили много работы, или они неэффективно распределяли свое время, и приходилось перерабатывать. Их усталость от потери интереса или мотивации в работе.
«Агрессивные» наоборот, стараются как можно бытсрее пройти путь обучения, развития, становления, чтобы получить доступ к еще большему количеству ресурсов, чтобы развиваться, развиваться, развиваться. Они жадно впитывают знания, учатся, пробуют, делают ошибки, и над ними не нужно выстраивать пирамиду менеджеров, чтобы подстегивать к работе. «Уставшие» стараются найти работу в больших компаниях, где эффект от их работы не виден вообще. «Агрессивные» находят себя в стартапах, маленьких компаниях, потому что там проще получать все, что им требуется.
Чем быстрее работники выполняют доработку кода, тем они эффективнее
Потому что они как минимум предусмотрели масштабируемость кода, реализовали на качественном уровне сам код, используя понятные конструкции и названия переменных, могут быстро читать «чужой» код, создали предсказуемую и понятную архитектуру, в которой легко делать отладку. Столь простая характеристика может рассказать о коде гораздо больше, чем количество строк в единицу времени.
Это не все методы оценки, но именно эти я использую для отбора персонала и для оценки эффективности работы компании. Надеюсь, что и вам пригодится.
UPD: Перенес статью в более подходящий раздел. Спасибо andreycha
