Вопрос эффективного управления своим рабочим временем актуален для любого разработчика. Для технического директора — тем более. CTO одного из британских стартапов, рассказал о самописном решении, позволявшем ему анализировать собственную продуктивность на протяжении более чем 1 года. Далее предлагаем вашему вниманию непосредственно текст публикации, переведенной на русский язык и адаптированной силами редакторов блокчейн-стартапа Wirex.

Я — кофаундер и CTO успешного SaaS стартапа Overleaf. Наш офис расположен в Лондоне. С августа 2014 года по декабрь 2015 я вручную отслеживал свое рабочее время минута за минутой и анализировал данные в R.

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

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

Этот пост документирует простую систему, которую я создал, чтобы учитывать свое время, подходы к анализу данных и результаты. Главное, что я понял в процессе:

• Я отследил, что в среднем провожу за реальной работой чуть более 50 часов в неделю. Теперь я скептично отношусь к рассказам о 130-часовой неделе.
• Временные затраты на управление возросли на 230%, в то время как команда выросла на 200% (с 2 до 6 человек). Любопытно, что траты времени на встречи и совещания сократились на 70%.
• Время на саму разработку осталось в прежних рамках, но это прежде всего потому, что оно сместилось с будней на выходные.

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

Бэкграунд

Мне стоит рассказать о компании, чтобы вы понимали контекст.

Я и кофаундер основали Overleaf в конце 2012 года. К августу 2014, когда я начал свой эксперимент с учетом времени, мы проходили через акселератор Bethnal Green Ventures, наняли своего первого девелопера (тут нас стало трое) и прошли посевной раунд Digital Science — лондонского торгового инвестора. К декабрю 2015, когда я закончил эксперимент, нас было уже 9 человек. Пятеро из них — разработчики у меня в подчинении. Мы начинали в основном как B2C, но постепенно сместились в сторону B2B, стали продавать себя университетам и научным изданиям. Сейчас у нас около 400 000 пользователей.

Наш продукт — многопользовательский онлайн-редактор по образцу Google Docs, но ориентированный на научные работы. Он отлично подходит для набора уравнений, диаграмм, таблиц, справочных документов, так как в его основе лежит система набора LaTeX. Так что мы — компания для гиков, где поощряются такие вот странные эксперименты.

Методы

Вы можете узнать, как я собирал и обрабатывал данные в этом разделе, либо пропустить и сразу перейти к результатам.

Приложение «metime»

Апдейт от 30.08.2016: Я открыл исходный код «metime» на случай, если вам захочется узнать некоторые детали.

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



Ключевые особенности:

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

Я использовал формат «simple text» для упрощения ввода. Теги разделены пробелами, а их список отделен от комментария дефисом.

Например, вверху скриншота, на 2015-12-24 00:03:50, я закончил работу с тегом ops и добавил комментарий, что пытался отладить «загадочную ошибку IPN». Предыдущая запись имеет отметку 2015-12-23 23:30:02, то есть длительность работы с тегом ops составляла 34 минуты.

Если я заканчивал работать над чем-то, я нажимал на кнопку «Restart Clock» перед тем, как вернуться к работе. Нажатие создавало специальную запись «clock stopped». Например, я не работал с 17:55:00 до 23:13:24, то есть 5 часов. Скорее всего, я провел это время за ужином и общением с семьей.

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

Теги

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

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

• biz: администрирование, продажи, маркетинг, инвестиции, работа с поставщиками, работа с пользовательским фидбеком, метрики и аналитика
• dev: кодинг, прототипирование, создание структурных схем (wireframing), поиск багов и их исправление
• hiring: чтение резюме, проведение интервью, договоры, митапы, контакты с рекрутерами
• inbox: работа с почтой и уведомлениями
• manage: персональное планирование, планирование спринта, обучение разработчиков, встречи один на один, разбор кода, ретроспективы
• meeting: запланированные встречи, совещания и звонки
• metime: время, потраченное на учет времени в приложении (и немного на разработку самого приложения)
• qa: ручное тестирование
• support: поддержка конечных пользователей

Обработка данных

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

Приложение не фиксировало часовой пояс для каждой записи, хотя стоило бы это делать. Для вычислений по «времени суток» понадобилось учитывать часовые пояса, чтобы не упускать из виду перевод стрелок и поездки. У меня было довольно много командировок в США и на континент. Пришлось пересматривать весь материал и вручную добавлять данные о часовых поясах, сверяясь с календарем.

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

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

Результаты

В итоге я получил таблицу, содержащую 11978 записей за период с 2014-08-17 по 2015-12-23, то есть продолжительностью 493 дня. Для каждой записи указано время начала (UTC), часовой пояс и длительность (в секундах), плюс по одному столбцу с булевским значением на каждый тег. Также я добавил псевдо-тег «stopped», который означает, что часы были остановлены. Таблица для скриншота сверху выглядела примерно так:



Я пометил 41 день как выходные и праздники и исключил их из результатов, которые вы увидите дальше. В итоге осталось 452 дня, на каждый из которых приходилось в среднем по 26 записей. Переходим к графикам!

Время на часах

Возможно, самый популярный вопрос: сколько же выходило рабочих часов? За среднее значение я взял 52 часа в неделю (пунктирная линия на графике ниже). Провал в мае-июне 2015 вызван праздниками.



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

В индустрии, где мы часто говорим о рабочей неделе в 130 часов, 52 часа — вообще не повод для хвастовства. Меня сложно назвать лентяем. Я не подсчитывал свои нерабочие часы, но я совершенно точно никогда не подходил к ним настолько сознательно. Несколько часов каждый день уходило на еду, дорогу до работы, гигиенические процедуры и прочие повседневные вещи. В те недели, когда удавалось работать по 70 часов, я, как правило, просто пренебрегал некоторыми вещами из этого списка. И, конечно же, всем нам надо спать, а когда приходится особенно тяжело, мы рады любой возможности пожить вне работы. Но стартап — это марафон, а не спринтерская дистанция.

Распределение времени по тегам

Идем дальше. На что я тратил свое время? За весь период самыми объемными стали теги «biz» и «dev». На каждый в среднем приходилось по 18 часов в неделю. На третьем и четвертом месте менеджмент и совещания. За ними идут найм и поддержка пользователей.



Стоит заметить, что часто теги объединялись (например, «biz meeting»), в этих случаях часы не добавлялись к разным тегам. При этом проводить сравнение между тегами вполне допустимо.

Нужно также иметь в виду, что я подсчитывал время на подсчет времени. Этот вид активности обозначен тегом «metime». Под этим тегом я учитывал время только если на подсчеты уходило больше одной минуты. Чаще всего это случалось, когда я вводил сразу несколько записей задним числом. Очевидно, что количество часов тут занижено, но сравнительно несильно. Не более, чем на час в неделю.

Изменение тенденций во времени

Как же с течением времени менялось распределение часов по разным видам деятельности? Общий график разбивки по неделям и тегам был бы слишком объемным и загруженным. Чтобы ответить на вопрос я попробовал несколько вариантов регрессии, в итоге остановившись на логарифмической регрессии. Значимые тенденции и исключения отображены в таблице ниже.

Тег	Исходное кол-во ч/нед	Конечное кол-во ч/нед	Изменение в %	p < 0.05
biz	20	13	–36%	?
dev	17	16	–3.1%
inbox	1.3	2.9	120%	?
manage	3.1	10	230%	?
meeting	8	2.3	–72%	?
qa	1.2	2.8	120%	?
support	3.3	1.6	–51%	?
(total time on the clock)	49	53	8.6%

Например, среднее время, которое я отмечал тегом «biz» уменьшилось на 36% с 20 часов до 13 часов в неделю по ходу эксперимента. Галочка в последнем столбце отмечает, что тенденция была статистически значимой с отклонением не менее p = 0.05. Таким образом, несмотря на еженедельные изменения, мы можем быть в достаточной степени уверены, что для этого тега характерен постоянный нисходящий тренд.

Если мы посмотрим внимательно на другие значимые тенденции, общая картина будет следующей. С ростом команды менялась и моя роль. Я стал больше времени тратить на управление (тег «manage»), контроль качества («qa») и почту («inbox»). Довольно неожиданным оказался нисходящий тренд по совещаниям («meeting»), несмотря на увеличение количества часов на управление. Скорее всего, так вышло, потому что многие виды управленческой деятельности, такие как анализ кода, я реализовывал не на совещаниях, а через GitHub и с помощью чатов. Наконец, многие совещания проходили по задачам, которые могли получить тег «biz», такие как встречи с клиентами. В сумме, активность по тегу «biz» снизилась, поскольку ее заменила управленческая деятельность.

Я включил в таблицу две строки, по которым не отмечено значимых изменений. Это «dev» и суммарное время работы (total time on the clock). По общему времени работы не было значимых изменений, потому что не было существенного роста за время эксперимента. В основном перемены коснулись содержания задач, над которыми я работал. А почему не изменилось количество часов на разработку («dev»), мы узнаем в следующем разделе.

Подведем итоги. Вот графическое отображение для изменения количества часов по каждому из 5 основных тегов и их логарифмическая регрессия, которая показывает изменения. Сюда же добавлен псевдо-тег «onClock», который показывает общее количество рабочих часов.

Будние дни vs выходные

В какие дни я занимался той или иной работой? Поменялось ли тут что-нибудь? Чтобы ответить на этот вопрос, я поделил все записи на три категории — по времени:

• выходные: с 19.00 пятницы до 7.00 понедельника
• будни: 7.00-19.00, понедельник-пятница
• рабочие ночи: оставшееся время (вечера с понедельника по четверг)

Отрезки времени с семи утра до семи вечера — по местному времени, с учетом часового пояса.

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

Тег	Категория	Исходное кол-во ч/нед	Конечное кол-во ч/нед	<Изменение в %
dev	выходные	3.6	8.5	140%
dev	будни	11	6.5	–40%
support	выходные	0.29	0.68	130%
support	будни	2.4	0.83	–65%

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

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

И вот как все это выглядит в графической форме. График похож на предыдущий, но данные разбиты по времени дня. Позитивные и негативные тренды по тегу «dev» хорошо видны, так же как и другие значимые изменения из предыдущего раздела — для будней.

Заключение

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

Этот проект был для меня самым близким к реальной исследовательской работе за долгий период. И поскольку Overleaf — инструмент для исследователей и ученых, мой проект стал хорошей иллюстрацией, что из себя представляет настоящая исследовательская работа. Забыть, насколько хаотичен процесс, очень легко. В основе этого поста около 3000 строк в файлах R-markdown, на бумаге, скорее всего, все это заняло бы гораздо больше места.

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

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

Узнать подробности построения регрессионной модели, на основании которой автором материала были получены описанные выше результаты, можно в разделе Appendix: Regressions оригинальной статьи.

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