Авторский знак программиста, или Как оценить труд разработчиков

Как оценить вклад работника

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

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

Ненормированный рабочий день

Есть и еще один аспект почасовой оплаты. Для программистов, тестировщиков, аналитиков, руководителей проектов ненормированный рабочий день обычно входит в стандартные условия труда. Поэтому из всех разновидностей почасовой оплаты для них применяется именно тарифная система. То есть за переработки работодатели обычно не платят. Вместе с тем именно в России переработки считаются обычным делом, а некоторые особенно «эффективные» менеджеры хвастаются тем, что их сотрудники работают по 12–18 часов в день. Чем они хвастаются совершенно непонятно, потому как нормальный человек не может долго работать в таком режиме без существенной угрозы для своего физического и психического здоровья. Так что советую не спешить устраиваться на работу к тем начальникам, которые уже на собеседовании активно интересуются отношением к переработкам. Руководитель, не способный нормально организовать работу и не жалеющий своих подчиненных, просто профнепригоден.

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

Система сбалансированных показателей

Примитивность тарифной оплаты давно стала понятна, поэтому практически повсеместно используется система показателей — KPI (Key Performance Indicator), на основании которой осуществляется оценка и мотивация сотрудников.

Система сбалансированных показателей (далее — ССП) на основе KPI была сформулирована Нортонам и Капланом для того, чтобы уйти от оценки компании только по финансовым показателям. Ведь по природе своей финансы имеют интегральный смысл. Значение прибыли или дохода в конкретный момент времени мало что говорит о действительном состоянии компании. Нортон и Каплан определили четыре области показателей — объединенные в систему, они показывают не только текущее состояние компании, но и то, как она будет функционировать в дальнейшем. Эти области, как известно, финансовая перспектива, клиентская перспектива, процессная перспектива и перспектива обучения и развития персонала. Баланс между показателями многозначен: тут и монетарные, и немонетарные величины, стратегические и оперативные характеристики, оценка прошлого и прогноз будущих результатов.

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

С моей точки зрения, мода на KPI принесла и продолжает приносить больше вреда, чем пользы. Вот некоторые причины.

Очень трудно разработать действенную ССП и практически невозможно декомпозировать показатели до уровня отдельного сотрудника. По крайней мере я ни разу подобного не встречала.

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

В заключение сошлюсь на один из принципов качества Эдварда Деминга, которые хотя и менее известны, чем его цикл PDCA (Plan-Do-Check-Act), но не менее полезны: «Уничтожайте потребность в массовых проверках и инспекции как способе достижения качества, прежде всего путем «встраивания» качества в продукцию. Требуйте статистических свидетельств «встроенного» качества, как в процессе производства, так и при закупках». Если вы спросите, как это осуществимо при разработке ИС, то отвечу, что, например, методики Скрам и Канбан дают практические ответы на этот вопрос.

СБП для разработчиков

Давайте посмотрим на один из примеров системы метрик, объединяющий вполне популярные показатели и претендующий на сбалансированность для оценки труда разработчиков.

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

Качество кода. Может быть измерено с помощью таких показателей, как количество ошибок или багов в коде (выявленных за определенный промежуток времени), соответствие стандартам кодирования (хорошо, когда они есть!), уровень документирования кода, в частности, наличие или отсутствие комментариев в коде (но надо еще проверить качество документации и комментариев), гибкостью ПО, в частности наличие и количество настраиваемых переменных и т. д. Хотя эта характеристика несомненно важнее, все описанные показатели могут ее определить только косвенно. Даже количество багов характеризует как минимум качество работы аналитика, программиста и тестировщика. А отсутствие багов может быть вызвано как хорошей работой программиста, так и плохой тестировщика. И считать количество выявленных багов нужно на всем жизненном цикле использования разработанного кода. Не скажу, что это невозможно. Но кто и когда так оценивает работу программистов?

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

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

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

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

А разработка ИС несомненно дело творческое на любой стадии: при разработке требований, проектировании ИС, разработке и конструировании ИС, тестировании ИС и, наконец, поддержке, обслуживании и эксплуатации.

Как же быть? Предлагаю немного помечтать.

Как может помочь авторский знак

Известно, что любой автор может иметь авторский знак и отмечать им все свои публикации. Придумано это было в конце XIX века для классификации печатных изданий и сортировки книг одной тематики по алфавиту. В России авторский знак применяется с начала XX века.

А что, собственно, мешает создать авторский знак для программистов, тестировщиков, аналитиков, уникальным образом их характеризующий? Тогда для разработанных ими систем можно было бы четко определить создателей. Одновременно можно учитывать качество ИС на всем периоде их эксплуатации. Поскольку для большинства ИС используются автоматизированные системы управления проблемами, можно учитывать качество работы тех или иных специалистов. Например, если выявлен баг в коде, то это ошибка и программиста, и тестировщика, проверяющего данный код. Если выявлена ошибка в требованиях, то это ошибка аналитика, а если в архитектуре — то архитектора. Таким образом, имея, с одной стороны, систему привязки ИС и даже отдельных ее компонентов к создателям, с другой — классификацию проблем, мы получим объективную картину качества работы специалистов ИТ. Хороша такая система тем, что никто не должен осуществлять контроль и, следовательно, вносить свои субъективные оценки и тратить свое время. Сделав систему авторских знаков открытой, можно получить ясную картину квалификации специалистов и использовать ее, в частности, при найме и обучении специалистов.

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

А это необходимо для современного уровня использования ИТ. В эпоху цифровой трансформации предприятия жизненно зависят от ИС, создаваемых совместным трудом аналитиков, архитекторов, разработчиков, тестировщиков и других участников процесса создания и эксплуатации ИС. Обеспечить прозрачность их работы — значит повысить их ответственность и, следовательно, это позволит создавать ИС, на которые смогут положиться компании в своей деятельности. Так что, хотя мы пока только мечтаем об этом, придется все же создать прозрачную и объективную систему оценки качества ИТ-специалистов. Авторские знаки — один из подходов. Предложите свой!