Time-to метрики

Все знают про метрику time-to-market, которая по-сути отражает скорость разработки. Чем медленнее мы будем выкатывать гипотезы – тем с большей вероятностью нас обгонят конкуренты или мы просто потратим все деньги на команду и не найдём product-market fit. Но почему-то редко анализируются другие time-to метрики, а чем меньше нужно времени (и мозговых ресурсов) на какое-то действие, тем больше времени остаётся для других дел.

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

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

На какое ещё время можно обращать внимание?

  • Time-to-data – время на доступ к информации. Как сложно найти нужную информацию? Например, почему сделали изменение в коде? Где взять логин и пароль в админку аналитического сервиса? Какие были договорённости на прошлом планировании? Где и как мы можем хранить эту информацию? Как сделать так, чтобы её можно было легко и быстро найти?
  • Time-to-action – время для действия. Сколько времени нужно, чтобы начать что-то делать? Например, к вам на проект пришел новый разработчик – сколько проходит времени до его первого коммита? Как можно это ускорить? Завернуть всё в докер? Предоставить компьютер с предустановленным и настроенным проектом? Потратить час на поверхностное объяснение проекта или скинуть ссылку на подробнейшую документацию на 500 страниц?
  • Time-to-decision – время для принятия решения. Сколько времени уходит на принятие решения в команде? Если вы каждый свой шаг согласовываете, то дела у вас наверняка идут очень медленно, а большой процент начатых активностей просто глохнет. Может можно что-то просто взять и сделать без апрува сверху или от всей команды? Или заранее всем вместе решить, кто какие решения принимает и в каких вопросах хочет принимать участие, например с помощью delegation poker?
  • Time-to-interaction – время на взаимодействие с другими людьми. Сколько времени ждать code-review? А сколько времени уйдёт у другого разработчика на этот code-review? На что из этого вы можете повлиять? Как это время уменьшить?
  • Time-to-small-things - время на разные мелочи. Наверняка, в день вы делаете сотни и тысячи мелких действий и небольшое ускорение в них может освободить вам голову и время. Как быстро вы печатаете? Как быстро навигируетесь в проекте/коде? Используете шорткаты? А time-to-coffee у вас какой?

В общем, иногда достаточно просто начать обращать внимание на то, куда уходит время – идеи о том, как ускориться придут сами. Так же полезно думать об этом, когда вы создаёте продукты и процессы для других – как вы можете ускорить и упростить для них использование вашего процесса/продукта?

Показать комментарии