Старший iOS-разработчик «ВКонтакте»: я не встречал эффективной системы KPI и OKR

Евгений Ёлчев

---

Старший iOS-разработчик во «ВКонтакте». Работал фулстеком, бэкендером и DevOps-инженером, руководил отделом мобильной разработки, три года преподавал iOS-разработку в GeekBrains, был деканом факультета. Состоит в программном комитете конференции Podlodka iOS Crew, ведёт YouTube-канал с видеоуроками по Flutter. В Twitter пишет под ником @tygeddar.

---

Ссылки

Я работаю на удалёнке давно, а почти весь остальной мир — чуть больше двух лет. С началом пандемии многие менеджеры начали переживать: а как теперь контролировать людей? На самом деле — так же, как и раньше в офисе: никак :)

Кого мы хотим обмануть?

Да, возможно, для кого-то это тайна, но в офисе никто никого не контролирует. Я проработал там шесть лет — и постоянно, и редкими наездами. Видел, как ребята спокойно приходили и уходили когда хотели, опаздывали или пропадали на два часа на обеде. Никто это не отслеживал.

Вы возразите: мол, теперь с этим строго — турникет фиксирует время прихода и ухода, количество часов, проведённых на рабочем месте. Так-то оно так — но ведь даже в офисе за вами всё равно не следят каждую секунду. Можно зависнуть в зоне с PlayStation, спортивном зале, в конце концов — просто весь день просидеть в опенспейсе, болтая с коллегой о тачках или концерте любимой группы. И никакой начальник в это время за спиной стоять не будет.

Удалёнка в этом плане ничем не отличается. Нужно контролировать объём задач, качество и скорость их выполнения, причём индивидуально для каждого сотрудника. Всё остальное — разговоры ни о чём.

Как я был под колпаком

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

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

Ещё бывают трекеры, которые делают скриншоты монитора с определённой периодичностью — например, каждые 10 минут. Скажем, пришло вам сообщение в Telegram, открыли вы его, чтобы прочитать, — и на этот момент пришёлся скриншот. Всё — считается, что эти 10 минут вы не работали, а в «телеге» зависали. Попробуйте потом доказать, что вы не верблюд.

Некоторые ещё пытаются отслеживать, насколько активно вы стучите по клавиатуре. Это совсем тяжёлый случай: больше всего времени нормальный кодер тратит на обдумывание, которое ни одним счётчиком не посчитаешь!

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

Время — это не деньги

Легко прогнозировать результат, когда на условном заводе 30 человек нарезают одинаковые болты на одинаковых станках. Если 29 из них сделали по 500 болтов, а один — только 400, к нему, наверное, возникнут вопросы.

С программистами так не получится. Задачи у всех разные, у каждой своя сложность и объём, и часто заранее неизвестно, сколько времени они займут.

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

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

Второй вроде справлялся, но всем казалось, что он филонит: у него всегда очень сильно затягивались сроки. Каждый раз что-то случалось и он переносил дедлайн: обещал сделать вечером, потом опять переносил. Я не мог подойти и прямо спросить, не обманывает ли он нас, — это было бы некорректно. Мы обсудили проблему с менеджером и одним из коллег. Выяснилось, что там, где обычно достаточно нескольких часов, у него уходило два дня. Но при этом у него всегда находились убедительные причины: он подробно показывал, что и когда он делал.

Я понаблюдал за ним пару ещё недель и понял, что он реально медленный — либо очень хорошо притворяется. Но при этом он постоянно что-то делал, над чем-то думал, пробовал какие-то варианты. В общем, мы решили, что он просто low-performer, — и смирились с этим.

Agile — это честно и понятно

В Agile несколько систем оценки, но самая адекватная — стори-пойнты.

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

Допустим, вы сделали простую задачу за четыре часа. Смотрите на следующую — и понимаете, что она займёт в пять раз больше времени. Так на глаз вы распределяете стори-пойнты и определяете скорость команды.

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

Почему KPI и OKR не работают

KPI, OKR — это уже не столько об эффективности, сколько о премировании и постановке целей. Но я ещё ни разу не видел, чтобы где-то была ясная, логичная, понятная всем система: всегда всё сводилось к странным, умозрительным и непонятно кем придуманным показателям.

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

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

В другой компании была ещё более запутанная система точек роста. Например, одной из таких точек было ведение документации — притом что на проекте был отдельный аналитик, отвечавший за этот вопрос. Можно было, конечно, прийти к нему, попытаться что-то за него написать, хотя это странно: трудно представить себе кодера, который хотел бы дорасти до аналитика. Скорее наоборот — это аналитики стремятся стать разработчиками. В итоге все сидели и придумывали, что бы такого сделать, чтобы это засчитали как достигнутую цель. Рисовали никому не нужные схемки, диаграммки — короче, тратили время впустую.

Когда я работал на железной дороге, у нас внедряли тойотовскую систему 5S. Одним из условий было: работники должны предлагать определённое количество собственных рацпредложений в месяц. Была специальная система, где эти предложения регистрировались. Чего там только не было — бред полнейший. Вам нужно план закрыть, а вы начинаете вместо этого какую-то ерунду выдумывать.

Заключение

Разработчикам автоматизированные системы оценки эффективности и продуктивности скорее вредят. Если хотите, чтобы они приносили пользу, нужны чёткие критерии измерения. А таких я ни разу не встречал.

Кроме того, эти системы почти всегда легко ломаются. Допустим, решили вы покрыть проект тестами. Цель хорошая, и даже метрика есть — скажем, процент покрытия. Казалось бы, включите и смотрите: растёт — хорошо, вы двигаетесь к цели. Но тесты можно писать по-разному. Можно налепить за час на коленке кучу тестов и поднять coverage на 20% — но толку от них будет ноль. А можно кропотливо делать один действительно хороший тест — но ваш coverage будет всего 1%. Теперь вопрос: какой вариант вы предпочтёте, если от этих дурацких процентов зависит ваша премия?