Замечали, как это бывает? В команду приходит новенький джуниор. У него полно свободного времени, он всё время пишет код, задачи закрываются одна за другой, и его прогресс растёт как на дрожжах. А потом смотришь на своего опытного сеньора или тимлида. Весь день в совещаниях, постоянно отвлекается на какие‑то вопросы, а в Jira на нём висит всего пара задач, которые он делает уже несколько недель.
И закрадывается мысль: «А не зря ли он получает свою зарплату?».
Я, как project‑менеджер, сам так думал, пока не понял, что работу опытного специалиста надо оценивать не по количеству строк кода, а по общему результату. Сегодня мы разберем этот миф по полочкам.
Два разных мира: как выглядит день джуна и сеньора
Представим себе типичный день, как в том анекдоте. Это хорошо показывает суть проблемы.
День Junior Developer:
10:00 — Пятиминутка (15 мин.)
10:15 — Кодит
11:00 — Задал короткий вопрос коллеге (15 мин.)
11:15 — Кодит
12:00 — Обед (30 мин.)
12:30 — Кодит
15:00 — Ревью кода (30 мин.)
15:30 — Перерыв
16:00 — Кодит
18:00 — Конец рабочего дня
Итог: Примерно 6.5 часов чистого кодинга. Продуктивность налицо, всё видно.
День Senior Developer / Tech Lead:
10:00 — Пятиминутка (15 мин.)
10:15 — Помог коллеге решить проблему (15 мин.)
10:30 — Совещание с продакт‑менеджером (30 мин.)
11:00 — Ответил на срочный вопрос в чате (15 мин.)
11:15 — Ответил на вопрос от начальства (15 мин.)
11:30 — Ревью кода и обучение джунов (30 мин.)
12:00 — Обед (30 мин.)
12:30 — Помощь новичку / обсуждение проекта (1 час)
13:30 — Исправил ошибку на проде (15 мин.)
13:45 — Помог еще одному коллеге (15 мин.)
14:00 — Обсуждение стратегии с архитектором (30 мин.)
14:30 — Пишет техзадание на новый проект (1 час)
15:30 — Уточняет детали с PM (15 мин.)
15:45 — Опять помогает по задаче (15 мин.)
16:00 — Наконец‑то! Кодит свои задачи (1.5 часа с перерывами)
18:15 — Конец рабочего дня
Итог: Примерно 1.5 часа кодинга. Кажется, что человек недорабатывает. Но давайте посмотрим внимательнее.
Как 20 минут работы сеньора экономят 7 часов работы команды
Главное для опытного специалиста — не его личная продуктивность, а эффективность всей команды. Он больше не просто делатель, он помогает другим работать.
Смотрите сами:
У Светы сложный баг. Она может копаться в нём 3 часа, а может спросить у сеньора и решить проблему за 5 минут.
Паша не понимает, как работает какой‑то модуль. Он может потратить целый день, чтобы разобраться, или получить объяснение от тимлида за 10 минут.
Простая математика: 20 минут, потраченные сеньором, экономят 7+ часов работы всей команды. Это выгодно для бизнеса.
Невидимая работа — это:
Архитектура и планирование: Те самые техзадания, которые помогают команде не потратить месяцы на неправильную разработку.
Обучение и ревью кода: Развитие джунов и мидлов, предотвращение ошибок.
Решение сложных проблем: Без этого команда может биться над задачей целыми днями.
Общение: Перевод требований бизнеса на технический язык и наоборот.
Устранение проблем: Он быстро решает критические проблемы, пока они не стали катастрофой.
Что делать руководителю? Как оценивать невидимую работу?
Если вы руководите командой, то ваша задача — не заставлять сеньора больше кодить, а оценивать его реальный вклад и создавать комфортные условия для работы.
1. Смотрите не на количество, а на результат.
Не нужно оценивать всех по количеству закрытых задач. Вместо этого спросите:
Насколько быстрее стала работать команда благодаря его помощи?
Насколько меньше стало критических ошибок после его ревью кода?
Сколько проблем он помог решить на прошлой неделе?
Как быстро новые сотрудники вливаются в проект благодаря его обучению?
2. Берегите его время.
Ваш сеньор — самый ценный ресурс. Ваша задача — его защищать.
Не зовите его на все совещания подряд. Его время должно быть использовано максимально эффективно.
Дайте ему спокойно работать над проектом. Ему нужно время подумать, не ждите быстрых ответов в чате.
3. Доверяйте ему.
Он лучше вас знает, как распорядиться своим временем. Дайте ему свободу.
Что может сделать сам senior‑разработчик?
Конечно, нельзя просто отгородиться от команды. Но можно сделать процесс более удобным для всех.
Выделяйте время на час кода. Пусть все знают, что в это время вас лучше не трогать.
Собирайте совещания в первой половине дня, чтобы вторую половину дня посвятить работе.
Выделяйте время на ответы в Slack/почте. Например, 15 минут каждый час. Отключите уведомления в остальное время. Люди привыкнут, что вы отвечаете не сразу, но всегда отвечаете.
Вывод для менеджера
Ваш опытный разработчик или тимлид, который кажется бездельником, на самом деле — двигатель вашей команды. Он пишет не так много кода, потому что он помогает другим писать этот код быстрее, качественнее и с меньшим количеством ошибок.
Не смотрите на его календарь и количество коммитов. Оценивайте его успех по успеху всей команды. Ваша задача — не контролировать каждую его минуту, а создать условия, в которых он сможет максимально помогать другим.
А что вы думаете? Сталкивались ли вы с этим в своей практике? Как вы оцениваете работу своих опытных специалистов?
Комментарии (25)
Lewigh
06.09.2025 12:02Я, как project‑менеджер, сам так думал, пока не понял, что работу опытного специалиста надо оценивать не по количеству строк кода, а по общему результату.
Подскажите, а до того как Вы это поняли, как оценивали собственную работу?
По количеству созвонов в день? Если созвонов было мало, не задумывались:«А не зря ли я получает свою зарплату?»
Или Вам зарплату не за созвоны платят все-таки? А если так то откуда мысли про то что кому то зарплату должны за строчки кода платить?
sibirrr Автор
06.09.2025 12:02До этого я оценивал свою работу по тому, насколько проект движется к цели и доволен ли заказчик. Количество созвонов это только инструмент, а не результат. Мысль о «зарплате за строки кода» — это распространённый когнитивный сдвиг, когда мы пытаемся измерить сложную работу простыми, но неправильными метриками.
CloudlyNosound
06.09.2025 12:02"Миф о ленивом сеньоре" с указанной в статье точки зрения - это миф.
Ленивый сеньор - это тот, кто скидывает все свои задачи тем, у кого он сам же их может принять или не принять. А потом активно тормозит тех, кому он эти задачи скинул. Если они их ему не вернули (не все знают, что так можно). Во всех трекерах у такого наибурнейшая деятельность и есть на кого всех собак спустить. Короче, это тот, кого начальство в лени и не заподозрит.
sunnybear
06.09.2025 12:02Интересно, как вы собираетесь отвечать на вопрос в условиях повышения продуктивности команды после включения сеньора: "Насколько меньше стало критических ошибок после его ревью кода?"
Ошибок-то, может, и больше станет...Есть неплохая метрика: процент/скорость закрытия задач командой, в среднем. Она может описывать, в том числе, эффект от сеньора.
sibirrr Автор
06.09.2025 12:02Вы правы. Если команда в среднем стала закрывать задачи быстрее и с меньшим количеством реворков - это во многом и есть результат работы сеньора.
shchepin
06.09.2025 12:02Докажите сначала, что это не корреляция, а причинно-следственная связь. Настоящая причина может быть в том, что вы наняли сеньора, и наконец-то перестали заниматься микроменеджментом (ох уж этот чайка-менеджеры)
Voloshka
06.09.2025 12:02Интересная статья и дискуссия. Очень понравилось про птиц, которые поют ночью, чтобы их не заглушали машины и с одной стороны я с этими соглашусь. А с другой- я просыпаюсь в 4.30 утра. Сама. Каждый день.
Мне проще и удобнее поработать именно с 5-7 утра, когда все спят и никто не отвлекает. Знаю разработчиков, которые совы и до 11 вечера им не думается. В рабочее время они занимаются руководством и админом, а ночью начинают кодить. Хорошо это или плохо- не знаю, но асинхронная коммуникация и работа из дома дают нам такую возможность ь и почему бы этим не пользоваться?
Я стараюсь учитывать биологические часы в своей команде, не всегда конечно получается. А с другой стороны, чаще всего разработчики срочно нужны когда что-то поломалась и не работает, текущие задачи запланированы и снесли сдаются в срок с документацией- то хоть во сколько пусть делают
tkutru
Ровно наоборот. Обычно первые 4 часа рабочего дня более продуктивны, по естественным причинам - меньше усталость, голова свежее и т.д.
Так что первую половину дня таки лучше посвятить непосредственно разработке, а длительное балабольство отложить на вторую.
baldr
Это очень индивидуально. Я раньше, когда работал в офисе, за собой замечал, что с утра думается хуже, чаще отвлекаюсь на новости, чаще хожу за кофе.. А вот ближе к вечеру кодинг вдруг идёт лучше и, вроде бы, уже пора домой собираться, а я в самом разгаре фигачу..
tkutru
Я же писал не конкретно про утро, а про начало рабочего дня. У кого-то режим вполне "совиный" (и другие варианты: плохо выспался, с похмелья и т.п.), тогда и эффективная работа начинаться будет отнюдь не с утра.
А так, наилучшая бодрость, активность ума достигается именно в первые часы после пробуждения.
И наоборот, чем ближе время ко сну, тем хуже соображаешь.
DarkTiger
Увы, не получится. Именно в первой половине дня ПМ получает массу срочных задач от руководства и заказчиков, и сваливает это на головы лидов. Что страшно вредит разработке, но, к сожалению, иначе нельзя.
tkutru
Так это проблема ПМа или разработчиков?
DarkTiger
Мы обсуждаем тему в контексте техлидов. А чем ближе инженер к верхушке иерархии, тем сильнее на нем отражаются срочные проблемы, требующие фикса.
Пример: "на новом релизе у 20% пользователей перестала работать аутентификация" - это проблема чисто ПМа, или разработчиков, особенно техлидов, это тоже затронет?
tkutru
Это проблема низкой инженерной культуры, где положили болт на процессы, тесты, планирование релизов, бюджета, код-ревью и т.д. Проблема того, кто распределяет бюджет. В общем случае, это не разработчики.
DarkTiger
Вы совершенно правы, но не все работают в условном Майкрософте.
Поэтому не «в общем случае», а «в идеальном случае»
sibirrr Автор
Суть не в том, чтобы строго следовать расписанию, а в том, чтобы сознательно планировать день, выделяя блоки и на глубокую работу, и на помощь команде. Идеальный баланс у каждого свой, главное - чтобы он был.
sibirrr Автор
Пиковая продуктивность у многих приходится на первую половину дня. Идеальный план дня учитывает индивидуальные ритмы специалистов и максимизирует эффективность команды.
Viacheslav01
Вот только менеджерам тоже кажется, что первая половина дня она продуктивнее )
Давно заметил, что лучше всего работаю ночью, когда никто не мешает, задача может висеть долго и прогресс будет минимальным, днем все время кто то приходит, омсобо буйные еще и встречи пытаюстся ставить по самым мелочным вопросом. А ночью лафа никто не трогает, беда только в том, что к вечеру обычно уже выжат рванным днем как лемон.
tkutru
Надо избавляться от раздражителей, ИМХО. Вот эти подстройки:
> лучше всего работаю ночью, когда никто не мешает
часто появляются от того, что вы не выстроили оптимальный режим работы для себя. Например, работаете в месте, где вас готовы "поставить раком" лишь бы удовлетворить хотелки очередного малокомпетентного начальника, спрашивающего "как дела?" каждый час.
И вы не один такой. В больших городах птицы, которые обычно бодрствуют днём, начали бодрствовать ночью, чтобы их трели и песнопения не загулашись гулом автомобилей.