63. Почасовая оценка труда и продуктивность программистов

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

Весь этот разговор должен строиться вокруг справедливой оплаты. Почему Василий зарабатывает $2000 в месяц, а Геннадий $5000? Очевидно, Геннадий более продуктивен. Он приносит больше пользы своей компании. И вот тут мы упираемся в самый интересный и сложный вопрос — а как измерить приносимую пользу? Как измерить продуктивность программиста?

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

Довольно легко измерить продуктивность рабочего, совершающего однотипное действие. Василий делать 200 операций в день, а Геннадий 500. Геннадий молодец и получает в 2.5 раза больше. Давайте добавим сложности и возьмем команду пожарных. Василий и Геннадий тушат одинаковое количество пожаров в месяц, работают одинаковое количество времени, как оценить их продуктивность? Тут можно сравнивать команды друг с другом, но как измерить индивидуальную продуктивность пожарного? По количеству спасенных людей? Ну так себе метрика. И давайте возьмем группу ученых в НИИ. Как оценить индивидуальную продуктивность Василия, которые уже месяц не может придумать модель для описания взаимодействия белков риновируса с новым препаратом, и Геннадия, который давно написал программу и ждет от Василия модель, чтобы вставить куда надо? У меня нет ответа на этот вопрос.

Мы не умеем честно и справедливо измерять продуктивность ученых, учителей и программистов. Поэтому многие пытаются заменить эту неопределенность чем-то очень простым, очень понятным, и _в корне неправильным _— рабочими часами. Ну а что? Введем два числа:

• рейт, который будет оценкой способностей (скилов) человека
• часы работы, которые хоть как-то можно измерить

И будем все это умножать, получая оценку продуктивности, пользы и, соответственно, зарплату.

У этой простой и понятной модели есть всего одна проблема — она плохо работает для разработки ПО. Предположим, что мы можем с приемлемой точностью оценить способности человека (хотя это не так). Но вот что мы совершенно точно не можем — это предсказывать и измерять время задачи. Проблема в сложности задач и в ошибке оценки времени на их выполнение. В разработке софта ошибки велики.

Например, Василий потратил 40 часов на фичу. Насколько она сложная? Это неизвестно. Возможно, Николай сделал бы ее за 20 часов, просто потому что у него был похожий прошлый опыт. Или у него настроение на этой неделе лучше. Или он просто ничем не болеет. Или он недавно был в отпуске и чувствует прилив сил. Или он знает одну фишку языка, которая позволила избежать сложного бага, на который Василий потратил 8 часов. А насколько эта фича полезная? Тут вообще можно тушить свет и расходиться — мы это выясним очень нескоро. Или даже никогда.

Очевидный вывод, что вы можете довольно комфортно использовать часы работы для оценки продуктивности разработчика при решении относительно несложных задач. Я думаю, что это естественным образом сказывает на характере задач, с которыми сталкивается большинство аутсорсеров. Цепочка такая: Мы меряем продуктивность временем → это работает только для простых и средних задач → мы берем только простые и средние задачи.

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

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

• Требование быть в офисе в определенное время (нельзя прийти в 12, ведь тогда менеджеру будет сложнее контролировать время Василия)
• Система учета входа в офис и выхода из офиса (нам нужно знать, сколько раз Василий опоздал)
• Система контроля рабочего времени самим сотрудником (пусть Василий сам нам объяснит, чем он занимался и сколько времени потратил)
• Системы автоматического слежения за открытыми приложениями (а не слишком ли часто Геннадий заходит в фейсбук, прочитать последний лонгрид?)
• Видеонаблюдение (а не слишком ли часто Василий ходит пить кофе и курить?)
• Индивидуальные KPI (ну мы же должны знать, сколько задач закрыл Геннадий за последний месяц)

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

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

Работа в такой модели мешает развитию личности. Я работал пару лет с учетом времени, и потом сложно, черт возьми, избавиться от всего этого говна. Ты как-то незаметно привыкаешь, втягиваешься и перестаешь понимать, как вообще может быть иначе? Модель почасовой оплаты изменяет твое сознание и потом все сложнее и сложнее оттолкнутся от дна и куда-то выплыть. Тактически вы можете заработать денег, но стратегически это плохой путь.

Учет времени формирует иллюзию контроля. Это попытка обуздать неопределенность, поместив ее в простую модель. Но в нашей индустрии неопределенность нужно принять и научиться с ней жить.