Как стать автором
Обновить

Комментарии 20

Может показаться, что ведение базы своих действий занимает очень много времени, но это не так

Это так. Я пытался вести подобную отчетность для себя и если писать её так, чтобы она не выглядела мусором через полгода, в среднем я тратил по 45 минут в день. И это были полные 45 минут в день активного времени. Т.к. я слежу за здоровьем, то стараюсь делать перерывы раз в час на 10-15 минут, то я получаю примерно 6,5 часов реального рабочего времени. С учетом того, что концентрация у меня не вечная, а в хорошие дни я реально работаю 5 часов, а в плохие 3,5 часа.


И самое важное. За 4 месяца ведения отчетности, я посмотрел в неё после того, как создал ровно один раз — когда в компании проходила самооценка своей работы (и оценка других), было просто супер легко написать, чего я добился за полгода. Но с другой стороны, я сожрал за 4 месяца почти 70 часов, которые я мог бы потратить на разработку.

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

В книге «Эта странная жизнь» Даниил Гранин описывает систему учёта времени советского энтомолога Александра Любищева. Немного заезженый пример, да и там более макроскопический учёт, но всё же.


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

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

Я веду свои задачи и отчеты в https://hackmd.io/ — это такой веб-блокнот с поддержкой markdown. Там еще куча разных функций (работа в команде, экспорт в кучу форматов и т.п.), но самое удобное для меня — онлайн (например на совещаниях можно зайти с телефона — добавить задачу или найти инфу).

Делаю нечто похожее.
Поскольку живу всегда внутри емакса (exwm в том числе), то настроил окружение так, чтобы возможность написать заметку была от меня не дальше, чем «C-c c», заметки ловятся в отдельный capture.org, который разгребаю раз в пару дней, полезное структурирую и раскладываю по соответствующим org-файлам, нужное для отчетности перетаскиваю в org-jira буфер для выгрузки в трекер, если из чего-то складывается атомарная полезная заметка, форматирую и выгружаю в вики.
Получается довольно удобно, особенно из-за полного отсутствия времени на переключение контекста. С тех пор, как перешёл на org-mode, вообще не понимаю, как жил раньше — простое древовидное представление чтобы показать кому-то, система тегов для поиска и невероятная, ограниченная только фантазией пользователя, гибкость, получаемая за счёт скриптования прямо на ходу, можно прямо в этом же файле.
Плюс экспорт в rst для технической документации и экспорт в латех для всех остальных документов.
Хотелось бы увидеть init.el с этой функциональностью

Когда-то Toggl использовал, когда надо было отчетность по задачам выдавать работодателю.

Я веду подобный учёт около 30 лет.
Главная для меня цель — контролировать количество отработанных часов в неделю и месяц, «подпинывая» самого себя таким образом. По моему опыту, большинство программистов в офисах реально не отрабатывают и 100 часов в месяц, и поэтому они вряд ли хотят своё время измерять и рассказывать правду о своём напряженном труде :)
Сейчас учёт веду в таблице гугл, записываю каждый день, сколько над каким проектом работал.
Разбиение достаточно «крупно-блочное» — проекты (обычно приходится работать над двумя-тремя параллельно), обучение. До уровня отдельных задач в этой таблице не опускаюсь, для этого есть Redmine у заказчика.
В конце недели и месяца смотрю на суммарные цифры.
Я пытался ещё какую-то пользу из этих данных извлечь, анализ проводить. Максимум что могу посчитать — распределение времени по проектам. Это, кстати, очень помогает при оценке новых проектов.
В общем, моё резюме такое: пару минут в день не вредно на это потратить.
а как насчет распределения времени между работой и не-работой? Какое выходит соотношение в лучшие и худшие недели?
Когда-то пытался вести статистику и по нерабочим активностям, но бросил, не увидел смысла.
Бывает, 25 рабочих часов в неделю получается.
42 часа — это максимум. В последние годы получается обходиться без штурмовщины.
В общем, на не-работу времени достаточно остается.
мы про одно и то же говорим? Я имею в виду соотношение между работой и не-работой в рабочее время.
А, извините, не понял.
В среднем моя статистика примерно такая: В офисе с 12 до 20:30. Из них обед 20 мин, полдник 20 мин, пинг-понг 20 мин, новости (не программистские) 20 мин. Отлучения в туалет и налить чая — мелочи, не учитываем.
Особого разброса от недели к неделе не было.
Я для этих целей rescuetime использую — она конечно не покажет чем конкретно ты занимался, но некую картину понять можно
А когда вы были на фрилансе — вы не включали общение с клиентом в биллинг? Я обычно включал, и все воспринимали это нормально.
они же потенциальные клиенты… если уже договорились что будем работать, то да, конечно, всё закладывается в ценник. Но если мы поговорили и в итоге он больше не пришёл, то время потрачено зря.

Я включал, но не описывал это именно как общение — записывал в составе обсуждаемых задач.

наверно какой-то тулзой можно следить что сейчас активно и группировать по активным приложениям, чатик, мейлы, гугл, IDE, но как оно поможет не понятно, всё это нужно для работы, разве что в фб/хабре и тому подобном можно меньше сидеть, но пока бегут тесты/компилиться почему бы и нет
Программирование это удовольствие, искусство. Низводить себя до анализируемого на эффективность станка, изготавливающего детали, значит упустить весь сок.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории