Qetzal ad libitum, ad infinitum

Вообще минусы публичных (внутри команды) апдейтов понятны — их написание отнимает время. А часть команда считает их мудой, которая не приносит пользы ("зачем писать, надо копать").

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

Представим уже более-менее подросшую компанию. Продуктовая команда будет получать много вопросов:
— А что вы делаете? А зачем?
— А когда будет сделана моя штука? А почему не скоро?
— А что интересного планируете выпускать? Нам надо для плана анонсов.
— А пишите нам, когда выпускаете новые штуки — мы будем партнёров оповещать.
— А расскажите про это вот изменение, нам надо маркетинговые материалы по ней готовить.
— А давайте каждое изменение в фичах, доступных на линейке планов, обсуждать с командой. Приходите к нам с каждым изменением для аппрува.

И так далее. У каждого отдела есть вопросы к продуктовой команде и это нормально. Если продукт в сердце компании, то любые изменения продукта влияют на всех. Отсюда вопросы. Проблема не в вопросах, проблема в том, что 1) это одинаковые вопросы от разных людей 2) у вас будут просить заранее ответы с детализацией, которая не нужна

Публичный ежемесячный апдейт снимает множество этих вопросов. Вместо подхода "приходите — я каждому расскажу" применяется подход "вся информация в известном месте — придите и возьмите".

— А что вы делаете? А зачем? → Вот документ со свежим списком и объяснением, не согласны — пишите в комментариях к документу.
— А когда будет сделана моя штука? А почему не скоро? → Вот тут список того, над чем мы собираемся работать, почему и какой прогноз по датам. Если вы считаете, что надо делать что-то другое — давайте обсуждать, почему ваша штука приоритетней текущего плана.
— А что интересного планируете выпускать? Нам надо для плана анонсов → А вот план.
— А пишите нам, когда выпускаете новые штуки — мы будем партнёров оповещать → Мы будем публиковать ссылку на документ в публичном канале, который все читают. Это наш публичный чейндждог, используйте его как хотите.
— А расскажите про это вот изменение, нам надо маркетинговые материалы по ней готовить → А вот тут в документе описано что, зачем и почему.
— А давайте каждое изменение в фичах, доступных на линейке планов, обсуждать с командой. Приходите к нам с каждым изменением для аппрува. → Вот документ с описанием изменений. Читайте, обсуждайте внутри, если с чем-то не согласны — приходите обсуждать конкретную штуку.

Паттерн один и тот же ("push/pull стратегии" или "тянитолкай" это всё примерно про то же). Такой подход не убирает вопросы на 100%(особенно если в деле завязаны игры статуса — "нет пусть ВЫ ко мне придёте"), но всё же облегчает жизнь. И самое интересное, что на практике мало кому нужно столько информации, сколько они запрашивают. Человек, который с радостью будет хотеть учавстовать в обсуждение каждого изменения ("хочу всё знать") на деле может не читать публичный документ и не обсуждать ничего (то есть не так уж это было ему/ей важно).

www.tgoop.com/qetzal_1up/1124

3.6K viewsFeb 6 at 11:22

Вообще минусы публичных (внутри команды) апдейтов понятны — их написание отнимает время. А часть команда считает их мудой, которая не приносит пользы ("зачем писать, надо копать").

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

Представим уже более-менее подросшую компанию. Продуктовая команда будет получать много вопросов:
— А что вы делаете? А зачем?
— А когда будет сделана моя штука? А почему не скоро?
— А что интересного планируете выпускать? Нам надо для плана анонсов.
— А пишите нам, когда выпускаете новые штуки — мы будем партнёров оповещать.
— А расскажите про это вот изменение, нам надо маркетинговые материалы по ней готовить.
— А давайте каждое изменение в фичах, доступных на линейке планов, обсуждать с командой. Приходите к нам с каждым изменением для аппрува.

И так далее. У каждого отдела есть вопросы к продуктовой команде и это нормально. Если продукт в сердце компании, то любые изменения продукта влияют на всех. Отсюда вопросы. Проблема не в вопросах, проблема в том, что 1) это одинаковые вопросы от разных людей 2) у вас будут просить заранее ответы с детализацией, которая не нужна

Публичный ежемесячный апдейт снимает множество этих вопросов. Вместо подхода "приходите — я каждому расскажу" применяется подход "вся информация в известном месте — придите и возьмите".

— А что вы делаете? А зачем? → Вот документ со свежим списком и объяснением, не согласны — пишите в комментариях к документу.
— А когда будет сделана моя штука? А почему не скоро? → Вот тут список того, над чем мы собираемся работать, почему и какой прогноз по датам. Если вы считаете, что надо делать что-то другое — давайте обсуждать, почему ваша штука приоритетней текущего плана.
— А что интересного планируете выпускать? Нам надо для плана анонсов → А вот план.
— А пишите нам, когда выпускаете новые штуки — мы будем партнёров оповещать → Мы будем публиковать ссылку на документ в публичном канале, который все читают. Это наш публичный чейндждог, используйте его как хотите.
— А расскажите про это вот изменение, нам надо маркетинговые материалы по ней готовить → А вот тут в документе описано что, зачем и почему.
— А давайте каждое изменение в фичах, доступных на линейке планов, обсуждать с командой. Приходите к нам с каждым изменением для аппрува. → Вот документ с описанием изменений. Читайте, обсуждайте внутри, если с чем-то не согласны — приходите обсуждать конкретную штуку.

Паттерн один и тот же ("push/pull стратегии" или "тянитолкай" это всё примерно про то же). Такой подход не убирает вопросы на 100%(особенно если в деле завязаны игры статуса — "нет пусть ВЫ ко мне придёте"), но всё же облегчает жизнь. И самое интересное, что на практике мало кому нужно столько информации, сколько они запрашивают. Человек, который с радостью будет хотеть учавстовать в обсуждение каждого изменения ("хочу всё знать") на деле может не читать публичный документ и не обсуждать ничего (то есть не так уж это было ему/ей важно).

BY Qetzal ad libitum, ad infinitum