Резюме : есть много статей в интернетах о том как это полезно и прекрасно логировать время и проделанную работу. Однако это для себя. Но зачем этого требует от вас руководство? Наверно из благих целей.

Есть одна менеджерская мечта - команда должна хорошо логировать свою работу и время, потраченное на нее. Ведь тогда будет понятно кто сачкует, а кто перегружен; кому медаль золотую вручить, а кому - позолоченную; какие задачи сложно даются, а какие - просто; сколько денег нужно потратить, а сколько - отобрать. Но на практике хренушки, к сожалению это не работает для большинства команд. Как правило по двум причинам:

Кто-то слишком ленивый, ведь логирование отвлекает от прямых обяазанностей ради “какой-то бюрократии”.

У кого-то просто нет для этого навыков. Есть люди, которые не умеют этого делать - когда забудут, а когда вовсе не придумают что написать… А чукча, оказывается, не писатель. Всему конечно можно обучиться при желании, но желания нет.

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

Полезность в логировании на самом деле огромная - человек упорядочивает свою работу; понимает насколько он завершил задачу, а сколько еще осталось; дает возможность другим понять и продолжить его труд если вдруг кирпич на голову. В общем-то это важная практика для time management’a.

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

Как Agile начистил рожу логированию

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

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

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

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

Залогированное время помогает находить проблемы . Т.е. если человек потратил слишком много времени на какую-то задачу, то либо он плохо разбирается в этой области (и ему нужно помочь), либо задача поставлена неверно, либо та часть приложения с которой он работает - проблематична. Да, это правда может помочь, но только если эти все проблемы не обсуждаются на ежедневных статус-митингах. Т.е. логирование времени тут заменяет общение с людьми. На самом деле общение с людьми не заменить, это всегда более эффективно, поэтому в данном случае (логирование времени как инструмент для выявления проблем) - это один из симптомов того что команда мало общается. На daily standups проблемы и так бы выявились при правильном подходе.

Если логировать, то как?

Во-первых, главное - это логировать не время, а сделанную работу. Лучшее место для этого - commit message если вы работаете с кодом и/или issue tracker. Так мы прогресс держим близко к тому где все крутится, не нужно далеко ходить чтоб узнать что конкретно сделал тот или иной член команды.

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

По логированию времени (или в общем по time management’у) есть много всего, повторять чужое не хочу, но посоветую все-таки очередной раз попробовать Pomodoro ;) У меня получилось где-то с третьего, и все равно периодически забрасываю.

Подытожим

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

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

Раньше я рассуждал просто. Моя работа заключается в том, чтобы писать код. Значит, когда я пишу код, я работаю. Получается, что мне нужно логировать время написания кода. После месяца таких логирований возникал вопрос: почему по цифрам получается, что вместо 40 часов в неделю я работал 25-30?

Первый же вывод, к которому легче всего прийти, - я весь месяц работал меньше положенного. Значит следующий месяц надо работать более активно! Но после месяца такой «активной» работы получалось, что работа-то сделана, а с самочувствием что-то явно не так. А ещё все лампочки горят красным , и работа как-то всё медленнее и медленнее работается.

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

За ответом можно сходить в храм под названием «Наука». Вот что рассказывает Барбара Окли в первом же видео курса Learning How to Learn (в недавней годноте была ссылка на конспект курса):

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

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

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

Используем аналогию с пинболом, чтобы разобраться.

Если вы помните, пинбол работает так: вы оттягиваете поршень, затем отпускаете его, он бьёт по шарику, и тот движется внутри автомата, сталкиваясь с резиновыми препятствиями и тем самым накапливая вам очки. Это похоже на то, как работает мозг. В сфокусированном режиме резиновые препятствия стоят очень близко друг к другу, и шарик может двигаться по одной и той же «тропинке», безрезультатно пытаясь вырваться за пределы. А за пределами этих препятствий (может даже совсем в другом углу «автомата») вполне может быть «правильная тропинка», которая приведёт вас к решению текущей задачи. И что же делать в таком случае?

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

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

Это был мой вольный перевод-пересказ первой лекции , которая доступна без подписки на курс. Лучше посмотрите оригинал, если понимаете английский.

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

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

Если вы не забываете о том, что работа - это не только активная часть, но и пассивная (отдых), то скорее всего вам не понадобится часто перезагружаться , и в следующий раз при оценке задач вы не будете думать, что если у вас есть 8 рабочих часов, то это время для непрерывной работы, в которой нет места отдыху.

Нужно логировать всё, что помогает решить задачу. В том числе и отдых.

Когда программа ведет запись действий в лог-файл (как правило, это файлы с расширением *.log), можно выяснить когда произошло то или иное событие, в какой момент времени произошел сбой приложения или возникла ошибка. Логирование позволяет отследить время старта сервера и его остановку, время подключения пользователя к базе данных, время попытки взлома веб-сервера и другие важные события, в зависимости от того, какая программа ведет запись истории в файл лога. Просмотр лога помогает отладить тот или другой программный процесс. LogViewer Pro - бесплатная для домашнего использования программа для просмотра логов. С её помощью Вы сможете читать лог-файлы в удобном виде, с выделением строчек лога цветом, в зависимости от того, какую информацию несет запись.

Просмотр логов

Просмотрщик логов LogViewer Pro можно адаптировать под любую структуру записи файла лога. Для выделения цветом отдельных строчек лога достаточно задать выражение - слово или символы, встречающиеся в строке. Утилита распознает большое количество кодировок, выполняет поиск по файлу лога, умеет переносить строчки при недостаточной ширине окна, выводит содержимое лога на печать, поддерживает открытие сразу нескольких файлов в одном окне. К файлу лога можно применить фильтр, при просмотре лога можно устанавливать закладки, для удобства просмотра LogViewer Pro пронумерует строчки. Для оперативности и постоянного мониторинга программа может читать лог в режиме реального времени. Интерфейс программы изменяется - можно изменить цвет фона, выбрать шрифт, добавить или убрать отдельные элементы приложения. LogViewer Pro поддерживает работу из командной строки, является portable-приложением. Программа бесплатна для частного, домашнего использования. При бесплатном использовании утилиты LogViewer Pro будет при запуске открывать окно на 25 секунд с предложением о покупке лицензии - это единственное ограничение функционала программы.

Скриншоты программы LogViewer Pro

Состав сервисного лог-журнала

Сервисный лог включает в себя все этапы работы сервера логики. Данным параметром регулируется его состав: какие режимы и модули производят логирование, а какие нет. Параметр представляет собой строку, каждая из позиций которой содержит 0 или 1 и отвечает за включение логирования конкретного режима.

Сервисный лог нужен при обращении в тех.поддержку по проблемам, касающимся работы сервера. В обычном режиме его можно держать отключенным (или включенным неполностью), так как плотная работа сервера в непрерывном режиме может создавать файлы журнала в объеме до нескольких гигабайтов в сутки. Для отладки в реальном времени необходимо включить исследуемые режимы, произвести определенные действия, после чего вновь отключить. Сформированный файл в совокупности с другими журналами отправить в тех.поддержку. См. также модуль Сборка лог-журналов .

Значение позиций параметра в порядке следования

• 1. ProcedureShow
• 2.PBXSS
• 3.DB - логирование обращений в базу данных
• 4.HAL - логирование ядра
• 5.CallTaskManager - управление задачами

• 6.SmsTaskManager - логирование смс-сервиса.
• 7.SvcTaskManager - логирование служебных задач
• 8.AutoCallManager - логирование сервиса автодозвона
• 9.CallCenter - общее логирование Call-центра, имена операторов пропадут из задач.
• 10.CallPoolProgressive - логирование задач с прогрессивным обзвоном

• 11.CallPoolDistributed - логирование задач с ручным распределением
• 12.CallPoolReserved - логирование задач с закреплением абонента за оператором
• 13.CallPoolIncoming - логирование входящих задач
• 14.Searcher - логирование поиска оператора и абонента
• 15.CallHelper

• 16.TaskLogic
• 17.TALK - логирование диалоговых сценариев
• 18.SVC - логирование служебных сценариев
• 19.IVR - логирование IVR сценариев
• 20.IvrObjectReport - логирование объектов IVR

• 21.LineLogic
• 22.LineThreads
• 23.LLHWactions
• 24.Queue
• 25.QueueDebug пропадут подробности переключений

• 26.Timer - логирование таймеров
• 27.FlashTimer - логирование таймеров при переключении
• 28.ExtLines - логирование внешних линий
• 29.GetSetState
• 30.ShowHWActions

• 31.Threading
• 32.UserState - логирование состояний пользователя
• 33.DTMF - логирование полученных DTMF сигналов
• 34.Signals
• 35.MessageLoopReport

• 36.Conference - логирование конференц-связи
• 37.IMMessaging - логирование сообщений
• 38.UserRequest

Логирование счетчиков производительности

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

В зависимости от выбранного режима логируются значения базовых счетчиков, пользовательских счетчиков или и тех, и других вместе. Базовыми считаются счетчики: общая загрузка процессора (0-100, %), объем доступной физической памяти (МБ), текущая очередь диска (0-10), процент использования файла подкачки.

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

где {0} - числовой порядковый индекс счетчика производительности. В качестве значения для счетчика производительности, отслеживающего общую загрузку процессора, например, подставляется "Processor|% Processor Time|_Total ". Для других счетчиков соответственно.

Логирование использования ресурсов

С помощью параметра можно настроить вывод в лог журнал WATCHER информации по использованию процессом (процессами, в случае разделения) ресурсов системы. Объем используемой памяти, количество открытых дескрипторов, количество потоков, пользовательские системные ресурсы, ориентировочное среднее процессорное время по всему процессу и отдельно по всем его потокам.

Логирование сбоев тактирования таймера

С помощью параметра можно настроить вывод в лог журнал WATCHER информации по выделению процессорного времени потокам системы. Вместе с основной деятельностью сервер постоянно проводит проверочные замеры тестовым таймером и засекает задержки в выдаче управления. В случае если операционная система отказывает в выделении службе сервера процессорного времени, это происходит и с тестовым таймером. Существует возможность выставить границу для его логирования. Среди вариантов границы задержки в 20 мс, 100 мс, 500 мс, 1 с и 5 с. По умолчанию логируются все задержки более 100 мс. Увеличение и уменьшение значения может потребоваться проводить в случае запроса из технической поддержки в ходе работ над поиском причин заметного некорректного поведения сервера.

Параметры аппаратуры. Конфигурация

В данном модуле можно включить и отключить логирование событий аппаратуры (папка \oktell\Server\Log\Hardware). По умолчанию, некоторые трассировки выключены.

• Во время работы системы логируются события, которые включены в модуле "параметры аппаратуры ".
• В момент запуска системы логируются события, которые обозначены в серверном конфигурационном файле в ключе TRACE_HARDWARE