Старший iOS-разработчик «ВКонтакте»: я не встречал эффективной системы KPI и OKR
2026-02-21 11:06 Diff
https://skillbox.ru/media/code/starshiy-iosrazrabotchik-vkontakte-ya-ne-vstrechal-effektivnoy-sistemy-kpi-i-okr/

#статьи

  • 5 июл 2022
  • 0

Иллюзия контроля: как оценивают эффективность разработчиков и есть ли толк от такой оценки.

Иллюстрация: Colowgee для Skillbox Media

Журналист, коммерческий автор и редактор. Пишет про IT, цифровой маркетинг и бизнес.
Сайт: darovska.com.

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

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

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

Кадр: мультипликационный сериал «Симпсоны»

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

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

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

Изображение: Public Domain

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

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

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

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

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

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

Изображение: Public Domain

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

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

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

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

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

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

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

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

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

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

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

Кадр: фильм «Властели́н колец: Братство Кольца»

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

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

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

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

Часто говорят, что таким образом нам, разработчикам, дают точки роста. Но одно дело, когда вы джун: всё вокруг незнакомо и вы ни в чём не разбираетесь. А если у вас на проекте 15 разных технологий и вы понимаете все 15, то что — учить 16-ю? Хорошо, если будет куда её приткнуть. А если нет?

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

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

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

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

Бесплатный курс по Python ➞
Мини-курс для новичков и для опытных кодеров. 4 крутых проекта в портфолио, живое общение со спикером. Кликните и узнайте, чему можно научиться на курсе. Смотреть программу