Спасибо большое!

Коллеги, доброго дня!
Продублирую здесь на всякий случай- по причине самочувствия я отменила игру простомощно, письма об этом участникам отправляла
Если письмо не пришло, прошу посмотреть в спаме или сориентироваться по этому сообщению)

😢 поправляйтесь!

Спасибо, на пути к этому)

Салют

👋Привет!

Привет
Я Никита из команды Product Mindset Nsk, и мы готовим новый митап ^^ Проанализировав вашу обратную связь и наши пожелания родилась тема митапа - "Продуктовая культура".
Почему я это пишу?
Мы ищем спикеров готовых рассказать про построение продуктовой культуры, внедрении разных подходов, роль продактов и другие темы которыми вы хотели бы поделиться.  

Писать @Akirman или @holysin, если вы готовы поучаствовать в вероятно самом большом продуктовом митапе Сибири 😄

Ух ты как круто

Всем привет! Кто-нибудь проводит у себя в продуктовых командах что-то вроде ретроспектив за год? Если такие есть, поделитесь опытом: как у вас это происходит?

Привет. Провожу. Можно взять формат годовой ретро https://blog.unusual-concepts.ru/2016/03/09/year-retrospective/

всем привет! зачиталась теориями по канбану и нашла причину понегодовать) кто практикует, объясните, может я не по тому поводу негодую)
Ситуация: философия канбана говорит о том, что увеличение количества сотрудников не решают проблему факапов сроков. WIP/Troughtput вроде все понятно и логично, окей.
Но в другой статье, беря за пример очередь на стойке в аэропорту с переодическими "срочными" пассажирами, которых проталкивают без очереди вперед, один из вариантов решения проблемы: увеличение стоек регистрации. Но это увеличение количества сотрудников... либо примеры плохие, либо я не до конца поняла)

Мне кажется тут плохой пример. Увеличение скорости прохода стоек регистрации может создать очередь у входа на посадку в самолёт. Если не прав поправьте, пожалуйста.

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

Добавление новых сотрудников ведет к попаданию в шторминг J кривой. Поэтому и не стоит этим заниматься

Стойки регистрации не равно количество участников команды в случае Канбана.
Часто бывает так, что при перегрузке, например, QA, когда задачи застревают, другие члены команды тоже могут подключаться к тестированию, чтобы избежать пробок. Т.е. члены команды условно универсальны и их задача проводить таски по этапам  совместно.

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

👍

о, круто, спасибо!

КМК пример про стойки - это вообще не про сотрудников, а про классы обслуживания 🤔
типа что обеспечиваем одним и тем же набором людей различные характеристики прохождения через систему в зависимости от класса обслуживания