Учет трудозатрат, на мой взгляд, тема такая же многогранная, как и деликатная. В зависимости от вашей позиции или, как это сейчас принято говорить, роли, к ней можно относиться по-разному. Если кратко, то я – за учет трудозатрат. И, тем более, за автоматизированный учет. Далее попробую объяснить, почему я так считаю и каким инструментом для этого пользуюсь уже более 7 лет.
Если вы считаете, что учет трудозатрат угнетает в вас свободную личность и не позволяет раскрыть ваш творческий потенциал на все сто, то эта статья не для вас. Я не буду вас переубеждать, мы с вами живем в разных мирах. Если вас устраивают «восьмерки», несмотря на вашу роль угнетаемого или угнетателя, то эта статья и не для вас тоже. Может быть, вы придете к этой необходимости позже. Может быть, она вас никогда не коснется – жизнь дает нам много вариантов. Моя статья для тех, кто любит это дело и регулярно практикует. Я не претендую здесь на новизну, но надеюсь быть полезным в каких-то нюансах.
Об авторе
За последние 7 лет я прошел путь от ведущего программиста до руководителя департамента и обратно, и все это время я использовал ManicTime для учета своих личных и производственных трудозатрат.
В этой заметке будут три небольших раздела и итоги (читать можно любой из них):
Зачем нужен учет трудозатрат?
В этом разделе я попытаюсь изложить свой взгляд на то, кому это надо и зачем. Думаю, что те, кто регулярно практикует, могут пропустить этот раздел и сразу перейти к следующему. Здесь и далее любые сильные утверждения следует воспринимать как мой скромный взгляд на вопрос, если не оговорено иначе.
Мне повезло работать в компаниях и командах, где учет трудозатрат рассматривался не как репрессивный механизм, а как источник ценных данных. Ценность этих данных не только в их наличии (табельная «восьмерка» тоже в наличии, но от этого не сильно легче), но и в детализации. На мой взгляд, важным является не только наличие трудозатрат, но и то, какие действия были выполнены в этот временной интервал. Эта простая информация (задача, временной интервал, действие) позволит получить интересную и полезную статистику, необходимую для выполнения различных задач по анализу и планированию.
Развивать онтологию действий можно бесконечно долго, но стоит придерживаться какой-то практичной целесообразности. Онтология действий нужна в первую очередь для решения практичных вопросов планирования, и здесь важно найти «золотую середину». Сформировать начальный список действий можно с тех действий, которые выполняются у вас всегда (или вы считаете, что выполняются у вас всегда), и за несколько итераций скорректировать этот список. Итерации могут быть как месячной, так и квартальной длины, здесь надо ориентироваться на объем информации для анализа и количество сотрудников, которых эти нововведения затронут.
Кому же это надо? На мой взгляд, на этот вопрос есть три ответа:
Организации
Руководителю
Сотруднику
Каждый из субъектов решает различные задачи с помощью данного инструмента. У всех есть нечто общее – это стремление к повышению своей эффективности. Но все они под «эффективностью» понимают свое и по-своему эти задачи решают.
В том или ином виде любая организация стремится осуществлять контроль использования доступных ей ресурсов (как бы бездушно это не звучало). Это базовая потребность организации, если она хочет иметь возможность выполнять задачи анализа и планирования своей деятельности. В данном случае отличие от конкретного руководителя подразделения в том, что задачи анализа и планирования учитывают данные трудозатрат по всей организации и выполняются различными «не-инженерными» подразделениями. Это может быть стратегическое планирование с целью определения неэффективных направлений и развития перспективных, это может быть финансовый учет и планирование бюджета и т.п. Повторюсь, что основное отличие в том, что деятельность выполняется на уровне всей организации.
С точки зрения линейного руководителя его задача (кроме других прочих) в том, чтобы его сотрудники в срок выполняли поставленные задачи. И здесь также необходим контроль. И лучше, если он будет поименный. Не смотря на то, что многие из нас переходят на гибкие методологии, где ответственность за достижение целей возлагается на команду целиком, важно отслеживать вклад каждого участника команды. И основной целью является повышение равномерности нагрузки в команде и устранение ситуаций, когда несколько участников команды «тащат» и со временем выгорают. А это, в свою очередь, приводит к неприятным последствиям, как для руководителя, так и для команды. Но прежде чем «затащить» и выгореть, работу надо спланировать. И в этом процессе непосредственное участие принимает руководитель, который становится проводником между непреклонной волей организации с ее стратегическими планами и конкретными командами исполнителей. Чтобы хорошо спланировать будущее, нужно хорошо знать прошлое, и в этом деле статистика и учет являются ключевыми и подчиняют себе не только учет трудозатрат, но и в целом организацию производственных процессов. Я сталкивался с таким мнением, что подобный контроль и учет трудозатрат полезен только при выполнении типовых работ (как любят говорить в интернетах: «клепать формочки»). Но я считаю, что это мнение не совсем верно и этот подход может применяться при выполнении исследовательских и опытных работ. В своей практике мы его использовали при выполнении НИОКР в области разработки программного обеспечения. В целом, эта деятельность повторяет цикл Деминга, который, на мой взгляд, является базой, если его участники хотят двигаться в направлении повышения эффективности своей деятельности.
На уровне исполнителя вопросы «личной эффективности» не являются последними, и подтверждением тому является бесконечный поток статей, книг, Youtube-передач. Статьи, книги и передачи во многом про то, как организовать свое бытие и сознание, чтобы выкроить еще пару часов на работу, самообучение или хобби. В итоге для многих эта «гонка» заканчивается, в лучшем случае, выгоранием (о чем тоже говорит не малое количество статей). Но если вы уже встали на эту скользкую дорожку, то тут необходимо, в первую очередь, обеспечить себе контроль использованного времени и только потом планирование. Любые изменения в личной или профессиональной жизни возможны только тогда, когда а) поставлена цель и б) изучены доступные ресурсы. И время является главным среди этих ресурсов. Четкий учет и контроль смогут ответить на вопрос, куда же уходит время. Анализ поможет ответить на вопрос, где временной ресурс используется неэффективно, а планирование позволит высвободившееся время использовать с пользой. И эта польза может выражаться по-разному, зависит уже от ваших желаний и воображения.
Вся это долгая прелюдия, на мой взгляд, подводит к одному: в профессиональной и личной жизни учет используемого времени является важным элементом. И хорошо если мы сможем им заниматься без излишнего ментального и физического сопротивления.
Программы для отслеживания времени
Сейчас рынок программного обеспечения для отслеживания времени насыщен большим количеством программ. Во многом, появление этих программ связано с развитием культуры удаленной работы в последние 10-15 лет. Дополнительное развитие они получили в последние два года в результате перевода многих сотрудников на удаленную работу из-за пандемии.
Если поискать в интернете, то можно найти большой список такого рода программ. Например, к ним можно отнести следующие: TogglTrack, TMetric, RescueTime, Timely, Clockify, WakaTime, ManicTime, TimeDoctor и другие.
Из этого списка я пользовался TMetric, RescueTime и ManicTime.
RescueTime был моей первой попыткой в использовании программного обеспечения для автоматизированного учета трудозатрат. Эта программа автоматически записывает время, проведенное в тех или иных программах или на сайтах, автоматически категоризирует их в зависимости от своих настроек (т.е. относит к категории рабочего времени, развлечений и т.п.). Все данные отправляются на сайт RescueTime, любая статистика и аналитика тоже доступна только на сайте. В бесплатной версии данные доступны только за последние три месяца, что несколько ограничивает возможности по использованию. В итоге RescueTime я забросил. Примерно год назад я снова пробовал его использовать – у него появилась возможность интегрироваться с Visual Studio Code, но работала она не стабильно.
Следующей попыткой было использование ManicTime. Этому научили меня мои коллеги, за что им отдельное спасибо. В ManicTime я получил тот наоборот функциональности и гибкости, который помог преодолеть мне ментальный барьер по использованию. Эту программу я использую последние годы и более подробно о своем опыте опишу ниже.
В один момент времени, когда только появился TMetric, я попробовал его использовать и надеялся получить от него более информативную статистику по работе в средах разработки. Но на ранних этапах его развития каких-то дополнительных преимуществ я не получил и вернулся к проверенному временем решению.
Еще интересным решением выглядит WakaTime, которая нацелена на интеграцию с различными инструментами (на сайте большой список, как офисных продуктов, так и IDE), но опыта работы с ней у меня нет. Будет интересно обсудить, если у кого-то такой опыт имеется.
Выбор системы отслеживания времени во многом зависит от личных предпочтений и накопленных паттернов работы с ними. Вот о своих паттернах я и расскажу чуть ниже.
ManicTime
Основной механизм работы ManicTime – это запись временных интервалов. Временной интервал является тем самым кубиком, из которого построено все остальное в ManicTime: запись, редактирование и пометка интервалов, автоматическое определение типов и категорий интервалов, базовая статистика по различным срезам.
Различные временные интервалы отображаются на временных шкалах (timeline). ManicTime содержит четыре основных шкалы, а также имеет возможность добавить дополнительные. Если совсем на пальцах, то ManicTime позволяет автоматически отслеживать время своей жизни на работе в разрезе того, был активен компьютер или нет, какие приложения были активны, какие документы были открыты, и позволяет помечать все эти интервалы времени пометками-тегами.
Основные шкалы:
Документы
Приложения
Использование компьютера
Теги
Первая шкала – «Документы». На ней отображается список файлов и веб-сайтов, которые были «активны», т.е. в определенный момент времени то или иное приложение работало с тем или иным файлом. Чтобы определить документ или веб-сайт, ManicTime должен уметь интегрироваться с приложением и получать от него необходимую информацию. Такая интеграция реализована через систему плагинов. Базовый набор плагинов поддерживает основные офисные приложения и браузеры. В платной версии доступны интеграции с GitHub, Jira и некоторыми другими системами управления проектами. Используя данную шкалу можно посмотреть статистику работы с теми или иными документами и сайтами. В первое время я испытывал к этому определенный интерес, но со временем он сошел на нет, так как основными инструментами для меня стали другие шкалы.
Аналогично устроена следующая шкала – «Приложения». На ней отображается список приложений, которые были активны.
Шкала «Использование компьютера» показывает активность пользователя за компьютером, например, когда компьютер был активен, когда заблокирован или выключен, когда была активна сессия RDP. На этой шкале можно увидеть статистику своей активности, своих чаепитий, перекуров или того хуже – совещаний. ManicTime имеет мобильный клиент, но, к сожалению, он работает только в связке с ManicTime Server. ManicTime Server я никогда не использовал по разным причинам, и поэтому вряд ли смогу про него рассказать что-нибудь полезное (если у кого-то есть опыт работы с ним, то я буду рад услышать и обсудить). Но если бы мобильный клиент умел интегрироваться с клиентским ManicTime, например, посредством выгрузки в него данных из мобильного приложения, то и отсутствия, и посещения совещаний можно было бы логировать в основном приложении. Особенно это актуально, если у вас было несколько совещаний подряд, в этом случае приходится использовать подручные средства для временной пометки таких интервалов.
В платной версии есть небольшое улучшение – после разблокировки экрана автоматически всплывает диалоговое окно, которое предлагает пометить интервал отсутствия. Этой функцией я тоже активно пользовался, она позволяет сделать сразу пометки и выгрузить эту информацию из головы.
И наконец, самая важная и наиболее используемая мной шкала – «Теги». На этой шкале отображаются пользовательские теги – пометки для временных интервалов. Они могут быть сделаны в любом виде, но с двумя ограничениями: во-первых, запятая рассматривается, как разделитель тегов, во-вторых, длина тега не может превышать 200 символов. Эти два простых правила позволяют очень гибко описывать метки для временных интервалов. Можно придумать свою онтологию, добавить свои категории и порядок их следования, для меток можно задать цвета для лучшего цветового разделения интервалов. Полученные теги могут быть использованы для просмотра и анализа статистики по различным срезам.
Помимо гибкой системы тегов ManicTime имеет очень удобный и мощный инструмент редактирования и управления ими. В нем сделано все, чтобы пользователь потратил минимум усилий для выбора существующей или создания новой метки и назначения ее интервалу. Диалоговое окно редактирования метки можно вызвать с помощью комбинации клавиш, из контекстного меню или пользовательского интерфейса. В этом окне отображается поле для ввода тегов, а также список ранее использованных тегов. Список тегов сортируется таким образом, что последние использованные теги попадают в верхнюю часть списка и это позволяет сократить время работы с ними. По моему опыту у меня были сотни, если не тысячи тегов, и постоянное пролистывание списка довело бы меня до ручки. Кроме этого, при вводе части тега или выборе тега в списке существующие теги фильтруются – и это бывает удобно, когда возникает необходимость в использовании меток, которые были использованы некоторое время назад. В целом, разработчики серьезно подошли к повышению эргономичности данного диалога, и чувствуется, что они понимают, для кого они делают свою работу.
Помимо диалогового окна, теги можно проставить из контекстного меню (если не требуется создания нового тега или редактирования существующего). Это делается в «два клика», но простановка тегов из диалогового окна удобнее и для меня это основной механизм.
В платной версии программы существует еще одна очень важная функция, которой я пользовался на работе постоянно – запись скриншотов. Запись скриншотов позволяет получить дополнительную информацию из тех приложений или документов, с которыми интеграции нет, или информацию вытащить сложно. Например, по скриншотам Visual Studio Code я определял, с какой веткой работал (а там всегда есть номер задачи), по скриншотам видеоконференций определял, какой вопрос обсуждали и тому подобное. Особенно это бывало полезно в те дни, когда в течение дня не успеваешь сделать пометки и вечером надо это все разобрать. Но если соблюдать дисциплину, то можно обойтись и без этой возможности.
И самое главное (ради этого все и писалось!): система плагинов позволяет разработать собственный модуль, с помощью которого можно расширить функциональность ManicTime. Имеется возможность разрабатывать три типа плагинов. Первый тип – это «Tracker», он предназначен для интеграции с внешними приложениями или веб-сайтами. Он позволяет получать из них дополнительную информацию (тот же пример с названиями веток из Visual Studio Code). Второй тип - это «Timeline», он позволяет добавить специфичную шкалу, на которой будут отображаться специально подготовленные метки. Третий тип плагинов - это «Tag», с его помощью можно импортировать теги из внешних источников и экспортировать теги и временные интервалы во внешнюю систему (например, систему управления проектами). Таким образом, расширяя возможности ManicTime, можно автоматизировать рутинные операции, которые вы выполняете каждый день.
ManicTime имеет большой набор функциональности, которой я не пользовался (но пользовались мои коллеги, например) – это работа с таймерами (таймер, обратный отчет, Pomodoro), горячими клавишами для большего набора действий, строкой фильтрации тегов и пометкой оплачиваемых интервалов, в платной версии есть возможность выгрузить табель рабочего времени (Timesheet).
Интеграция с ManicTime
И третья, небольшая, часть про то, как мы с коллегами пользовались возможностями программы для сокращения наших трудозатрат на ведение трудозатрат (простите).
Мой типичный workflow (в русском языке я думаю правильное слово процесс или последовательность действий, но workflow короче и понятнее в ИТ среде) выглядит следующим образом:
Ежедневно в течение рабочего дня, я проставляю метки для интервалов (подробнее ниже). Делаю это либо раз в несколько часов, либо по окончанию какой-либо задачи или активности. Раньше перерывы на обед, чаепития и прогулки с собакой тоже отмечал, сейчас перестал, т.к. особой смысловой нагрузки они не несут, а продолжительность имеют почти одинаковую изо дня в день. К концу рабочего дня я имею помеченные временные интервалы, пригодные для занесения в систему управления проектами. К тому же, у меня есть понимание, сколько я отработал за день.
В конце недели, как правило, в пятницу, я выгружаю трудозатраты в YouTrack. Перед выгрузкой я пробегаюсь по дням, чтобы проверить, что действительно ничего не забыл. Выгрузку я делаю с помощью плагина (о нем тоже ниже), этот процесс занимает 3-4 минуты в неделю.
Как выглядят метки для интервалов? Все метки должны содержать два обязательных тега, любое количество дополнительных тегов и комментарии (к метке можно добавить комментарий). Это наше «внутреннее» соглашение, и вы можете сделать это своим, более удобным, для вас способом.
Два обязательных тега – это номер задачи и действие. Номер задачи должен начинаться со специального символа или нескольких символов (например, для Redmine мы использовали решетку, а для YouTrack префикс проекта). Действие у нас всегда начинается с собачки (@) и должно соответствовать справочнику в системе управления проектами.
Два дополнительных тега – это тип трудозатрат (у меня это Work) и название задачи. Временной интервал привязывается по номеру задачи из обязательно тега, поэтому название задачи может быть произвольным. Я использую краткое, менее формальное название.
Наличие помеченных интервалов уже позволяет сократить время на перенос трудозатрат в систему управления проектами. Но если использовать возможности ManicTime по созданию плагинов, то можно разработать плагин, который будет эти трудозатраты выгружать автоматически. Так мы и сделали! Мы разработали модуль, который обладает двумя возможностями:
Отправка временных интервалов в систему управления проектами с привязкой к номерам задач, простановкой действий и добавлением комментариев. Это позволяет одним нажатием выгрузить трудозатраты и не заниматься этим вручную (см. выше пример экрана).
Загрузка из системы управления проектами открытых персональных и групповых задач и формирования из них тегов. Это позволяет в диалоговом окне добавления тегов выбирать их из уже существующих.
Полученный плагин имеет небольшое количество настроек – необходимо задать адрес сервера и токен для авторизации, указать список префиксов, которые будут использоваться для вычисления номера задачи. Остальные настройки опциональные.
И как итог хотелось бы резюмировать
Не пытайтесь насильно внедрить программы для учета рабочего времени, их всегда можно обойти и саботировать.
Если вам интересно попробовать или вы уже ведете трудозатраты, то попробуйте, например, ManicTime, возможно он окажется полезным для вас и будет удобнее других систем.
Если вы начали вести или ведете трудозатраты, то попробуйте выработать систему меток. Это позволит, как автоматизировать работу с ними, так и анализировать статистику.
Если у вас есть система меток, то автоматизируйте работу с ней – зачем делать руками то, что может сделать машина.
Будьте эффективны и находите время на хобби и личностное развитие!