Marat Khusainov
Бизнес

Я веду таблицу рабочего времени 2 года. Вот что в ней оказалось

6 мин чтения

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

Как родилась привычка

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

Решение нашлось простое: таблица. Открываю утром, фиксирую начало работы. Закрываю, пишу часы. В конце дня одна строка. Дата, часы, что делал, что планирую завтра.

Через полгода я понял, что использую её не только для счетов. По ней стало видно ритм: когда я продуктивен, когда выгораю, какие задачи реально съедают часы, а какие мне только кажутся долгими.

Что лежит в таблице

Четыре колонки, ничего лишнего.

  • Дата. Один день, одна строка.
  • Часы. Десятичные, не «с 10 до 18 с перерывами», а просто «5.5».
  • Что делал. Пара строк свободного текста, проекты и задачи.
  • План на завтра. Главное действие следующего дня.

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

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

Цифры за два года

За два года в таблице около 600 рабочих дней. Среднее 5.2 часа в день. Максимальный непрерывный спринт 9 дней по 8+ часов. Это была неделя релиза одного из клиентских приложений. Финальный полив фич, ревью App Store, исправление багов в день публикации. После этого спринта я три дня просто лежал.

Минимальные рабочие дни 1-2 часа. Обычно это понедельник или пятница, когда были встречи или административные дела. Иногда день после большого спринта.

Дни с нулём часов в таблицу не идут. Это не «прогулы», это нормальные выходные.

Где переломный момент

После полугода учёта я заметил странный паттерн. В дни, когда я работал 8+ часов, я был уставший, раздражительный и обычно недоволен результатом. В дни на 4-5 часов, наоборот, выходил с чувством «успел и сделал хорошо». Это не корреляция с типом задач. Спринты по 8 часов были и на простых задачах, и на сложных.

Я начал помечать в таблице эмоциональный фон в конце дня одной строкой: пустая, средне, плохо. Через ещё пару месяцев картина стала очевидной. После шестичасовой отметки уровень субъективного состояния начинает падать. Не лавинно, не сразу, но устойчиво.

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

Почему четыре часа это потолок

Четыре часа в день означает четыре часа полной концентрации. Без переключения, без чата, без проверки почты. Звучит мало. На практике почти никто не работает столько.

Когда я говорю «работаю восемь часов», на самом деле это:

  • 1 час реальной концентрации с утра
  • 30 минут чтения чата, ответов
  • 1 час фокусированной работы
  • 1.5 часа встреч и переключений
  • 2 часа работы в режиме «делаю руками, голова не очень»
  • 2 часа «доделать вечером, потому что не успел»

В сумме восемь. Реальной концентрации внутри два-три часа. Остальное иллюзия работы.

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

Что я перестал делать после этого открытия

Перестал работать вечером. Если днём не успел, перенёс на завтра. Никаких «доделаю после ужина». Вечером я плохо думаю, и весь код, написанный вечером, я в среднем переделываю утром.

Перестал заполнять время «не очень важным». Раньше любая дырка в расписании заполнялась мелкими задачами. Отвечу на письма, погуглю про библиотеку, посмотрю чужой код. Сейчас я знаю, что у меня есть конечный ресурс концентрации, и я не трачу его на то, что можно делегировать или вообще не делать.

Перестал «работать в субботу, потому что был ленивый в среду». Это всегда заканчивается одинаково. Пропадает воскресенье на восстановление, и в понедельник я никакой.

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

Что я начал делать вместо этого

Утро отдаю самой важной задаче. Первые два-три часа дня это самый ценный ресурс. Я не отвечаю в чатах, не открываю почту, не смотрю Telegram. Просто работаю над одной задачей.

Один день, одна большая задача. Если на день стоит фича плюс баг плюс документация плюс созвон, я заранее знаю, что не успею всё. Поэтому я выбираю одно главное действие, и день строится вокруг него.

После шести часов стоп. Даже если кажется, что «осталось чуть-чуть». Чуть-чуть займёт ещё два часа, и я сделаю это медленно и плохо.

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

Когда переработка оправдана

Иногда работать восемь-десять часов нужно. Финальный спринт перед релизом. Срочный баг в проде. Демо для клиента через два дня. Я не пуританин, переработки бывают, и в этом нет проблемы.

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

А ещё это инструмент честности с клиентом

Бонус, который я не закладывал. Когда клиент говорит «но мы же договаривались за неделю», я открываю таблицу и показываю. На эту фичу ушло 14 часов, на это API 6 часов, на правки 4 часа. Спорить не о чем, цифры зафиксированы по ходу.

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

Что взять отсюда

Если коротко:

  1. Заведите таблицу. Четыре колонки, ничего больше.
  2. Считайте только реальные часы концентрации, не «провёл на работе».
  3. Через два-три месяца появятся паттерны. Сначала вы их не увидите. Потом увидите сразу.
  4. Не верьте мифу про восьмичасовой рабочий день для соло-разработчика. Четыре часа полной концентрации сильнее.
  5. Гордиться длинными часами было нормой в XX веке. В разработке имеет значение не сколько ты сидишь, а что ты успел подумать.

Шаблон таблицы простой, я могу прислать в Telegram. Ну и если у вас есть свой опыт учёта времени, расскажите, мне интересны другие подходы.

Что дальше

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

Похожие статьи