imageВопрос эффективного управления своим рабочим временем актуален для любого разработчика. Для технического директора — тем более. 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». Оно не выиграет наград, но дело свое делает. Выглядит вот так:

image

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

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

Я использовал формат «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», который означает, что часы были остановлены. Таблица для скриншота сверху выглядела примерно так:

image

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

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


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

image

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

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

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


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

image

Стоит заметить, что часто теги объединялись (например, «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», который показывает общее количество рабочих часов.

image

Будние дни 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» хорошо видны, так же как и другие значимые изменения из предыдущего раздела — для будней.

image

Заключение


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

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

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

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

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

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

Комментарии (13)


  1. l0rda
    08.09.2016 16:25
    +1

    Думал речь о станции технического обслуживания.


    1. Dendroid
      08.09.2016 16:32
      +1

      А я зашёл почитать про деформацию времени в специальной теории относительности…


  1. IronHead
    08.09.2016 16:46
    +2

    Я — кофаундер и CTO успешного SaaS стартапа Overleaf.

    Моя бабуля сочла бы эту фразу за ругательство…


    1. AVKinc
      08.09.2016 19:52
      +1

      Прям с языка сняли.
      Успешный стартап.
      Типа «серьезная фирма возьмет в аренду дырокол».


  1. Stiver
    08.09.2016 17:36
    +2

    Тот же самый учет в докомпьютерные времена: Эта странная жизнь (поскольку перевод, вряд ли автор напрямую вдохновлялся)


  1. springimport
    08.09.2016 19:48
    +1

    Тут есть все: бесполезный учет времени, и банальщина, и реклама, и молодой-успешный-перспективный-стартап но нет одного — смысла.


  1. jeremiah
    08.09.2016 20:44
    +1

    У вас на сайте WirexApp, в меню выбора языка пункты указаны на уже выбранном языке, что есть зло (если пользователь не читающий по-Английски зашел на Английскую версию сайта, то чтобы переключиться на Русский он должен уметь читать по-Английски, чтобы понять, что Russian это Русский). Чтобы этого избежать в меню обычно пишут на том языке который этот пункт меню и представляет.


  1. zenkz
    08.09.2016 20:44

    Статья — детальное пособие «как сгореть на работе».
    Конечно, если это свой бизнес, то отношение к использованию времени совсем другое, т.к. это инвестиция в будущее, но всё равно 50 часов эффективного рабочего времени — это часов 80 с учётом перерывов и это довольно много для нормальной жизни.
    Получается либо вы работаете без выходных, либо по 16 часов в день.
    Мне всегда было интересно насколько это продуктивно.
    Разработчик — это не технический директор, но судя по себе заметил, что общая эффективность работы снижается, если работать более 8 часов в день долгое время. Часто то, на что вечером уходит час, утром решается за 15 минут.

    Пробовали ли вы оптимизировать ваше рабочее время?
    — делегировать часть работы на других
    — уменьшить время на рутинные задачи путём автоматизации (к примеру система хитрых фильтров для почты)
    — уменьшить время на совещания (за счёт планирования и подготовки вопросов для обсуждения)
    и т.д.

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


    1. kraidiky
      08.09.2016 21:40
      -1

      А то есть то, что среди его окружения 130-часовая рабочая неделя считается нормальной вас вообще не смутило? :)))))
      Как я понял со слов автора, со своими 50 часами он смирился, но вообще говоря это повод для стыда. :)

      Сам когда-то проводил такой эксперимент, тупо ставя пометки в Эксельник. С тех пор сильно поменял своё представление о реальных трудо и времязатратах.


      1. Enwony
        08.09.2016 22:43
        +1

        130 часов — это ~18,5 часов при 7 дневной неделе. Это 5.5 часов на сон (все остальное я вообще не считаю).
        Это что-то из разряда фантастики. 52 часа работы (не перерывов) — это уже очень хороший показатель (7.5 часов каждый день) — думаю, дальнейшее увеличение времени работы уже идет во вред.

        Я проводил похожий эксперимент в течении года для измерения эффективности работы — и, надо сказать, интереснее всего оказалась не полученная статистика, а воспитанное в течении эксперимента более внимательное отношение к своему времени и к тому, на что оно тратится.


        1. cigulev
          10.09.2016 01:00
          -1

          Почитайте мой коммент ниже, да, это фантастика, как полёт человека в космос, великое открытие или спортивное достижение. Но всё это реальность нашего времени.


      1. cigulev
        10.09.2016 00:58
        -1

        В статье написано не про окружение, а про то к чему все стремятся в IT индустрии в силиконовой долине, почитайте хотя бы это — https://vc.ru/p/how-great-ppl-work.

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


  1. pomme
    09.09.2016 04:19

    > Я — CTO.
    > команда выросла с 2 до 6 человек

    Полагаю, первые двое — CIO и VP-IT.
    Позже к ним присоединились VP of Engineering, IT Director, Chief Data Scientist и Chief Security Officer.

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

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

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