Клуб директоров

21
лет

928
директоров

6107
статей



Как оценить эффективность работы программиста

Как оценить эфФективность работы программиста

Компьютерный код* - это латынь XXI века

Виталик Бутерин, русский программист, 1994

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

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

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

Как бы мы ни пытались ходить вокруг да около, толк от этих расчетов будет нулевым. Проблема кроется в показателях. Если в их качестве время еще можно использовать, то количество кода - нет. Оно вообще не имеет отношения к эффективности. Хотя многие компании на заре развития IT-отрасли попадались на эту уловку: они платили за количество строк, которые написали программисты. Но последние быстро смекнули, что писать можно работающую лабуду с ужасным количеством лишнего кода: деньги же платят за количество символов, а не за качество или эффективность кода.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник: Александр s0rr0w https://habr.com/ru/post/101906/


* Компьютерный код (также исходный код) - текст компьютерной программы на каком-либо языке программирования, который может быть прочтёе человеком.

** Количество строк кода (англ. Source Lines of Code - SLOC) - это метрика программного обеспечения, используемая для измерения его объема с помощью подсчета количества строк в тексте исходного кода. Идея использовать строки кода в качестве метрики объема компьютерных программ восходит к 50-м годам XX века, когда наиболее часто используемыми языками были Фортран, Ассемблер и Кобол. Основным механизмом ввода программ в компьютер были перфокарты и перфолента, причем на одной карте (одном кадре перфоленты) кодировалась одна строка кода. Будучи объектом физического мира, они (перфокарты/кадры перфоленты, а следовательно, и строки кода) легко поддавались пересчету. Кроме того, пачка перфокарт, составляющая программу, обладала вполне видимым объемом, по которому менеджеры могли судить о производительности труда программистов.


Для получения контактных данных
(email, телефон и адрес),
зарегистрируйтесь


Комментарии к статье. Напишите свой комментарий первым.

Введите цифры на картинке