Rivalry2

HTML Diff

1 added 1 removed

Original 2026-01-01

Modified 2026-02-21

1 <a>#статьи</a>

2 <ul><li>5 июл 2022</li>

3 <li>0</li>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

19 Изображение: Public DomainЛегко прогнозировать результат, когда на условном заводе 30 человек нарезают одинаковые болты на одинаковых станках. Если 29 из них сделали по 500 болтов, а один - только 400, к нему, наверное, возникнут вопросы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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