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

Так что решилась написать максимально прикладную (приложу все усилия) статью про то что это такое, какие есть недостатки, ошибки в использовании, и как же это всё внедрить (если они реально вам подходят).

Всем привет) Я - Саша Зебелева, налаживаю процессы в IT командах.
Регулярно пишу в свой канал про жизнь и работу. Заходите на огонек 🔥

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

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

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

В конце этой статьи вы найдете ссылки на исходные материалы фрейма, инструкции на английском языке, а также на переведенный мной фрейм в Miro.

Хабр, привет! Я Саша, Product Manager в Ozon. Хочу сегодня поговорить с вами об исследовании зависимостей между подсистемами проекта, в частности, и повышении прозрачности процессов в разработке в общем.

Обычное дело: в команду приходит заказчик, приносит суперзадачу — киллер-фичу, которая по приблизительным оценкам будет приносить не меньше N денег в секунду. Очень важная и нужная штука. Потом проходит 3 месяца, а фича так и не появляется на проде. Более того, команда к ней так и не приступала. 

Почему? 

– вместо суперзадачи команда занимается какой-то ерундой — проблемы с приоритизацией;

– команда не поняла, что фича принесёт реальные деньги и насколько это важно — сложности с коммуникацией с заказчиком;

– недостаточно описаны требования, команда отфильтровала задачу как «не готовую к взятию в работу» — продакт не доработал;

– задача потерялась в недрах бэклога — продакт проглядел.

Все эти варианты говорят нам о наличии рассинхрона команд, ожиданий и реальности, рассинхрона подсистем относительно общего процесса, вследствие этого команда(ы) делает «не то» «не так» или не делает вовсе.

Давайте разбираться — расскажу вам об инструменте, который поможет выявлять приводящие к подобным ситуациям серые зоны, нестыковки, зависимости между подсистемами проекта; поможет всё это дело визуализировать и анализировать. Инструмент я назвала картой зависимостей.