Когда я был разработчиком, мне казалось, что оценивать задачи просто. Я знал код, понимал проект и верил, что 40-часовая неделя — надёжная рамка, в которую помещается всё нужное. 

Реальность быстро показала обратное. В каждом спринте оставались незакрытые задачи, сроки сдвигались, а чувство «я где-то ошибся» становилось постоянным фоном — даже если работал честно и много.

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

Со временем мои оценки стали точнее. Но став тимлидом, я понял простую вещь: проблема не в людях и не в оценках.

Проблема — в самой модели планирования. Мы пытаемся работать внутри недели, которой в реальности не существует. Давайте разберёмся, почему планы продолжают срываться, даже если команда работает добросовестно и что с этим делать.

---

Почему планы срываются

Если команда работает честно и без саботажа, почему же планы регулярно разъезжаются? Особенно обидно, когда по ощущениям «все вкалывали», а результат выглядит так, будто половина команды всю неделю отдыхала.

Причина проста: планы строятся вокруг условной цифры «40 часов в неделю» и набора задач в трекере. Но реальная неделя разработчика устроена иначе: в ней много того, что в план не попадает — или попадает в сильно упрощённом виде.

Что на самом деле съедает время:

• Митинги. Планирование, стендапы, созвоны — даже короткие встречи регулярно сбивают фокус.

• Код-ревью. Качественный анализ чужого кода занимает значительную часть времени.

• Баги и техдолг. Инциденты на проде, сбои в работе компонент всегда возникают не вовремя.

• Поддержка коллег. Подсказать, посмотреть лог, помочь с окружением — мелочи, которые быстро складываются в часы.

На бумаге всё выглядит аккуратно: оценки есть, суммарные часы сходятся. В реальности же значительная часть недели уходит на то, что формально не считается задачами.

Поэтому планы срываются не потому, что люди «не тянут». А потому что сама модель планирования опирается на представление о «чистом времени», которого в реальности нет.

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

Что такое фокус-фактор простыми словами

Фокус-фактор — это ответ на простой вопрос: сколько времени у вас действительно остаётся на задачи из бэклога, если учесть всё остальное, что происходит в рабочей неделе.

Представить его проще всего так. У вас есть неделя. Из неё вычитаются встречи, ревью, баги, поддержка, переключения контекста — и остаётся время, которое можно потратить на плановые задачи. Доля этого времени и есть ваш фокус-фактор.

Если ещё короче:

• фокус-фактор 0.5 — примерно половина недели уходит на задачи;

• 0.7 — уже очень высокий уровень;

• 1.0 — встречается только в теории, но не в живой разработке.

Фокус-фактор помогает понять реальную загрузку и видеть, сколько времени команда может вкладывать в плановые задачи. Это отправная точка для честного планирования и разговоров о процессах. Теперь разберёмся, как посчитать свой фокус-фактор.

Считаем фокус-фактор

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

Статичные активности: повторяются из периода в период

Это предсказуемые элементы рабочей недели — они есть у любой команды:

• регулярные встречи: стендапы, планирование, груминг, ретро, демо, синки;

• оценка задач и обсуждения по бэклогу;

• код-ревью — входящие и исходящие.

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

Динамичные активности: меняются от периода к периоду

Это то, что нужно актуализировать на регулярной основе:

• поддержка;

• помощь коллегам и взаимодействие с соседними командами;

• дежурства, собеседования, менторство;

• изменение фактического количества рабочих часов (выходные, DayOff, сокращенные дни).

В какие-то недели есть собеседования, в какие-то появилось потребность в менторстве, а в какие-то ничего такого нет. Это нормально: именно они делают фокус-фактор величиной, которая всегда немного «плавает».

Пошаговый мануал

Допустим, у нас есть неделя или спринт, по которым нужно понять реальную загрузку. Алгоритм простой.

1. Выписать все активности

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

2. Примерно оценить время на каждую активность

Точность до минуты не нужна, достаточно прикидок: «стендапы — 15 минут  в день», «ревью — 2–3 часа за неделю», «работа с багами  — полдня».

3. Сложить всё время, ушедшее не на задачи

Это сумма всех активностей — время, которое уходит не на продуктовые задачи..

4. Вычесть это из общего рабочего времени и посчитать долю

Например неделя — 40 часов, статичные активности — 8 часов, динамичные — 10 часов. Итого 18 часов ушло на сопутствующие активности. Осталось 22 часа на задачи. Затем 22 делим на 40.

22 / 40 = 0.55 — ваш фокус-фактор.

Дальше с этой цифрой уже можно работать: сравнивать периоды, смотреть, что влияет на просадку или рост, и настраивать планирование так, чтобы оно опиралось на реальность, а не на мифические «40 часов чистого времени».

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

• скопировать шаблон к себе в пространство;

• скорректировать состав активностей;

• скорректировать период под принятый в вашей команде;

• указать количество рабочих часов за период.

Этого достаточно, чтобы за пару минут получить честный фокус-фактор — без ручного пересчёта.

Как использовать фокус-фактор в работе

Сам по себе фокус-фактор — просто число. Он превращается в пользу тогда, когда начинает влиять на повседневные решения. И вот как это выглядит на практике.

На планировании

Фокус-фактор показывает, сколько времени, вероятнее всего, доступно на задачи. Если у вас около 20–25 часов на неделю, планироваться на все 40 — путь к переработке. Берите задач под наиболее вероятный доступный, рассчитанный через фокус-фактор, объём — и команда перестаёт оказываться в положении «пообещали, но не успели».

В переговорах с продактом

Цифры снимают лишние споры. «У меня остаётся около 22 часов на задачи. Если взять ещё две — мы не уложимся» — звучит куда конкретнее, чем «я не уверен». 

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

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

На ретро

Фокус-фактор помогает понять, почему планы сорвались:

• проанализировать состав работ по фокус-фактору;

• обсудить и принять решение насколько текущая картина соответствует целевой;

• принять решение по дальнейшим действиям.

Ретроспектива превращается из разговора «про ощущения» в анализ фактов.

Для контроля нагрузки

Фокус-фактор — хороший индикатор перегруза.

• стабильно низкий — значит, вас уводит поддержка, хаос или неясные задачи;

• стабильно высокий — процессы стали стабильнее.

Со временем появляются закономерности: недели с большим количеством встреч снижают фокус; спокойные недели — повышают. Стабильно низкий фокус-фактор на продолжительном участке — путь к выгоранию.

Для повышения качества задач

Когда становится понятно, сколько времени съедает не продуктовая активность, меняется отношение к требованиям:

• больше уточняющих вопросов;

• меньше размытых задач;

• меньше переключений контекста.

Это напрямую влияет на скорость выполнения задач и на ментальное состояние.

Как не превратить это в KPI

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

Фокус-фактор не измеряет продуктивность. Поэтому сравнивать людей между собой по фокус-фактору некорректно. Он показывает только одно: какая часть недели уходит на плановые задачи, а какая — на остальные активности. Если пытаться превратить эту величину в KPI, начинается предсказуемый сценарий:

• разработчики перестают учитывать всё, что «портит цифру»;

• поддержка, менторство и помощь коллегам начинают маскироваться под «настоящие» задачи либо перестает исполняться;

• фокус смещается с реальной работы на красивый отчёт.

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

Не сравнивайте людей по фокус-фактору

У разработчиков разные роли и нагрузки: кто-то больше сидит на поддержке, кто-то менторит, кто-то закрывает инциденты или проводит собеседования. Эти роли неизбежно дают разный фокус-фактор — и это норма. Сравнивать их между собой по этой цифре так же бессмысленно, как сравнивать backend и QA по количеству закрытых тасок.

Не пытайтесь «поднять фокус» любой ценой

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

Не используйте фокус-фактор в перформанс-ревью

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

Фокус-фактор — инструмент планирования и диалога, а не основание для оценки грейдов и определения размера бонусов.

Держите метрику прозрачной

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

Фокус-фактор — это фонарик. Им подсвечивают реальность, а не бьют по голове.

Что делать, если фокус-фактор низкий

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

Главная польза фокус-фактора — он помогает понять причину недовыполнения, а не ругать себя за неё. Вот что можно сделать, если фокус просел.

1. Понять, что именно съедает время

Низкий фокус-фактор — это симптом. Чтобы с ним работать, нужно выяснить источник нагрузки:

• всплеск багов или незапланированных тикетов;

• слишком плотный календарь встреч;

• дежурства;

• тяжёлые ревью или помощь коллегам;

• запросы от смежных команд.

Когда причина понятна, становится ясно, что именно нужно менять.

2. Обсудить нагрузку с тимлидом или продактом

Разработчик не обязан в одиночку тянуть весь хаос недели. Фокус-фактор помогает объяснить картину фактически: «За неделю было 10 часов багов и 6 часов поддержки. Поэтому фокус упал до 0.4».

Такой разговор упрощает перераспределение работы и корректировку планов.

3. Исправить то, что создаёт шум

Если уже понятно, что именно размывает фокус — можно перейти к корректировкам. Часто помогают простые шаги:

• сокращение митингов;

• перевод части коммуникаций в асинхрон;

• снижение частоты/времени статус-встреч;

• договорённость о фокусных окнах.

Иногда одного такого изменения достаточно, чтобы фокус заметно вырос.

4. Планировать в рамках реальной загрузки

Если фокус стабильно низкий, а задач на вас ставят как на человека с фокусом 0.8 — это прямой путь в выгорание. Цифра даёт объективный аргумент: «У меня остаётся 18–20 часов на задачи. Нужно планировать в этих рамках». Это не отказ от работы — это забота о стабильной скорости команды.

5. Не «подкручивать цифру»

Попытка поднять фокус-фактор искусственно — избегать ревью, не помогать коллегам, игнорировать баги — вредит процессам и команде. Задача фокуса — не выглядеть красиво, а отражать реальность.

6. Смотреть на тренд, а не на одну неделю

Одна неделя может быть хаотичной, другая — спокойной. Важно понимать динамику:

• фокус падает из спринта в спринт — растёт шум или сменились приоритеты, а может ломаются процессы;

• фокус растёт — загрузка становится стабильнее.

Как фокус-фактор помогает всей команде

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

Делает планы реалистичными

Когда каждый понимает свой реальный объём доступных часов, команда перестаёт планировать по принципу «втиснем как-нибудь». Суммарная вместимость перестаёт быть формулой «5 × 40 часов» и становится суммой реальных рабочих часов. Это снижает количество завышенных ожиданий и переписываний планов.

Снижает количество переработок

Реалистичное планирование автоматически уменьшает число переработок. Уходит ощущение вечного аврала: люди перестают работать «в долг», потому что план наконец-то отражает фактическую загрузку, а не абстрактные 40 часов.

Улучшает коммуникацию и распределение нагрузки

Фокус-фактор подсвечивает, где утекает время: слишком много митингов, неопределённые задачи, поток багов, тяжёлые ревью.

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

Укрепляет взаимодействие с продактом

Разговоры вида «мы не успеем» превращаются в предметный диалог: «У нас суммарный фокус — 0.58. Мы можем сделать вот столько».

Такой формат увеличивает доверие, снижает количество «передоговорённостей» и убирает лишние эмоциональные дискуссии.

Повышает предсказуемость команды

Фокус-фактор может плавать, но в среднем у любой команды есть свой диапазон — например, 0.55–0.65. Это позволяет:

• точнее прогнозировать спринты;

• строить дорожные карты без угадываний;

• понимать реальную пропускную способность команды.

Предсказуемость в итоге оказывается ценнее скорости — как для команды, так и для бизнеса.

Финал: осознанность и честность

Фокус-фактор — не про скорость и не про контроль. Он про честность: с собой, с командой и с людьми, которые зависят от вашей работы.

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

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

Фокус-фактор возвращает разработке устойчивость: он помогает строить реалистичные планы, снижает шум и делает работу предсказуемее.

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

Осознанность начинается с простого вопроса: куда на самом деле уходит ваше время? Фокус-фактор помогает на него ответить.