Мы стали бежать быстрее. Но туда ли? Как Time to Value возвращает разработке понимание ценности

[Dhwtj]

Все эти time to уже не важны на российском рынке: встрясок типа ковид или импортозамещение больше нет, рынок монополизирован или близок к тому, выхода на глобальный рынок для быстрого масштабирования и захвата огромного рынка сбыта тоже нет.

Забудьте. И успокойте бесноватых маркетологов, они "готовятся к прошлой войне"

[Ivan_Rogovoy]

Получается Time to Value — это не столько ещё одна метрика, сколько изменение точки ответственности?

Как будто есть риск просто добавить в дашборд ещё один показатель: «релиз → эффект = 120 дней» — и на этом успокоиться. Но кто и что реально может повлиять на эти 120 дней?

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

Может еще тогда разделить Time to Value и Time to Evidence — время до появления достаточных данных, чтобы уверенно сказать, что ценность действительно возникла? Особенно для продуктовых гипотез: когда эффект нельзя честно измерить сразу после релиза.

и еще, а не должна ли зрелая команда измерять не только скорость получения value, но и стоимость ошибки — сколько мы потратили, прежде чем поняли, что гипотеза была неверной?

Бэклог как портфель экспериментов с разной стоимостью неопределённости.

Кто-то вообще считает стоимость/время до опровержения гипотезы наряду с Time to Value?

[tasha_belyanskaya]

Полезная статья. В текущих реалиях уже мало «быстро работать работу», нужно «быстро работать нужную работу», чтобы продолжать зарабатывать и не разориться.

[AntonBorisov]

Ну, во-первых, я обеими руками за идею про time to value instead of time to market. Как минимум, потому что действительно не все измеряют time to value, и прежде всего потому, что не понимают из чего состоит value. Давайте будем честными.
Во-вторых, я сторонник того, чтобы value было сформулировано не техническим языком. Если value сформулировано технически, "повышение доступности систем", как ты пишешь, к примеру, то я хочу, чтобы это было выражено как-то еще. Мы это повышаем, чтобы что? В чем глобальная цель вообще всей этой инициативы? В чем ее ценность для благополучателей, если можно так сказать? Это у меня ещё со времен работы в моей первой международной компании выработалось - иметь валидируемую зависимость усилий и ценности для целевой аудитории.
В-третьих, в моем понимании, для конкретного разработчика может быть не настолько важно знать, в чем ценность его работы для конечного пользователя системы, потому что он в первую очередь фокусируется на задаче и на том, как она сформулирована. Но здесь нужно иметь какой-то взгляд на точку разделения между зонами ответственности, где ценность для конечного пользователя, еще не понятна или не настолько важна для исполнителя, и областью, где она уже становится критична. И вот для product/project manager это критично, он должен понимать, зачем мы это вообще делаем. Для конечного разработчика - не обязательно, на мой взгляд опять же.
В-четвертых, мне твое предложение учитывать adoption и организационные изменения очень напоминает модель ADKAR от PROSCI. Это модель, которая как раз описывает управление изменениями в организации. Тут, я лично, согласен по каждому пункту - без учёта того, как новый продукт или фича "приземлится" в реальные процессы, это всё не имеет смысла. Можно посмотреть на чуваков, которые сейчас вайбкодят по одному красивому приложению для iOS в неделю, но категорически не понимают кому это нужно, как они будут этим пользоваться, а главное - какое value это принесёт конечному пользователю, за которое он будет готов заплатить.
В-пятых, напишу в личку) и так не факт, что на моей пустой учётке без кармы комментарий дадут опубликовать)

[Virchenko]

Отличная статья, отдельный лайк за разбор – почему скорость не равна ценности.

Отдельный лайк 2 за понятный фреймворк для работы 👍