DevPace
БлогСправкаНовостиСкачатьДемоТарифыПривязка устройстваВойтиНачать

Эксперименты в DevPace: как проверять свои идеи о работе

Почти у каждого есть свои теории о том, что помогает или мешает работать. “Если отключить уведомления на час, переключений будет меньше.” “Если начинать день с самой сложной задачи, фокус выше.” Проблема в том, что такие теории обычно живут и умирают в голове: человек попробовал, ему показалось, что стало лучше, и через неделю эта уверенность растворяется, потому что подтвердить её нечем. В DevPace для этого есть эксперименты — способ оформить личную гипотезу как настоящий проверяемый тест и получить оценку по реальным данным, а не по ощущению.

Как устроен эксперимент

Человек формулирует гипотезу в конкретных терминах: что меняется (например, на час отключаются уведомления мессенджеров в первой половине дня) и какой метрике это должно помочь (например, количество переключений контекста в час). DevPace фиксирует период до изменения как базовую линию, затем отслеживает период самого эксперимента и сравнивает метрику с той же базовой линией, с которой уже работают другие функции сервиса — тренды, дневные чек-ины, разбивка по часам. Никаких отдельных опросов или ручной разметки: эксперимент опирается на те же данные о категориях активности и переключениях, что и остальной DevPace.

Почему не просто “да” или “нет”

Самое простое решение — на выходе показать один из двух вердиктов: гипотеза подтвердилась или не подтвердилась. Так делает большинство трекеров, если вообще берётся оценивать эксперименты. Проблема в том, что реальные данные по работе почти никогда не выглядят чисто. Эффект может быть, но слабее ожидаемого. Данных может быть недостаточно, чтобы отличить эффект от случайного разброса между днями. Бинарный вердикт в такой ситуации не описывает реальность — он её упрощает до неправды.

Поэтому DevPace оценивает эксперимент по четырём исходам: гипотеза подтверждена, не подтверждена, недостаточно данных — и отдельно, подтверждена частично. Последний исход существует не для смягчения формулировок, а для конкретного технического случая: DevPace проверяет результат не только по направлению эффекта, но и против защитного порога — минимальной величины изменения, ниже которой эффект считается недостаточно надёжным, чтобы называть его чистым подтверждением. Если направление верное, эффект виден, но не дотягивает до этого порога — это не “не сработало” и не “сработало”, это отдельная, третья вещь, и называть её нужно отдельным словом.

Гипотетический пример

Представим гипотезу: “если отключать уведомления с 10 до 11 утра, переключений контекста в этот час станет меньше.” Базовая линия за предыдущие недели показывает в среднем 7 переключений в этот час. Защитный порог в этом случае — снижение минимум на 30%, то есть примерно до 5 или меньше, чтобы считать эффект однозначным. За две недели эксперимента среднее значение в час без уведомлений — 5.8: направление верное, эффект есть, но снижение составило около 17%, не дотягивая до заданного порога. DevPace в этом случае покажет “подтверждено частично” с честным пояснением: эффект в нужную сторону присутствует, но его размер меньше, чем нужно для уверенного вывода — возможно, стоит продлить эксперимент или расширить окно без уведомлений, чтобы проверить, растёт ли эффект.

Активный эксперимент в DevPace: день 1 из 5, базовая линия 6.9 переключений в час

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

Зачем это вообще нужно

Личная гипотеза о продуктивности — это не маркетинговое обещание, которое обязано “сработать”, чтобы оправдать своё существование. Это предположение, которое может оказаться верным, неверным или верным лишь отчасти, и все три варианта одинаково полезны, если сообщены честно. Инструмент, который умеет говорить “почти, но не совсем” вместо того, чтобы натягивать результат на удобный вердикт, обращается со своими данными и с человеком, который их читает, серьёзно. Именно поэтому в DevPace эксперименты оценивают, а не награждают чистыми галочками — так они действительно помогают понять, что работает именно для одного конкретного человека, а не подтверждают то, что он и так надеялся услышать.

Если хотите проверить собственную гипотезу на своих данных — начните с главной страницы DevPace.

Смотрите также