Николай рассказал про свой опыт на созвоне и получил инвайт на клабхаус!

А ведь это могли бы быть вы :)

Сегодня, в 8pm откроется ещё один созвон. Инвайтов там не будет, но будет возможность послать кого-нибудь нахер. В первые пять минут даже можно будет поругаться с админами!

> Обеспечены данными
Думаю, что к кейсу Артема это не очень применимо, ибо аутсорс.
+ Задачи написанные с браком, в принципе, никогда не надо брать в работу. И бить по рукам тех, кто берет даже после того, как ты объяснил, почему это плохо.

> по дизайну и аналитике, через неделю
Неделя — эмпирически или на основе каких-то конкретных причин?

Неделя, это у нас внутренний спринт. По поводу аутсорса, по большому счету не важно кто предоставит данные. Приоритет у тез задач котоыре обеспечены данными и у них скорый дедлайн.

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

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

В продуктовой разработке аналитики делают работу два раза

1. До начала работы дизайнеров/разрабов и тд — подтверждают возможность достижения цели, ради которой создаётся задача

2. После доставки ценности, через какое-то время: неделя/две/месяц и тд

Можно засунуть их в спринт, а можно оставить на стороне, как подключаемые по запросу ресурсы

В клиентской аналитиков часто нет.
Если я правильно понял, что имеется под аналитиком

Мой вопрос был к тому, что «1 неделя» в этом контексте выглядит как «магическое число»

> По Дизайну и Аналитикам те задачи которое связаны с задачами разработки у которых дедлайны будут через спинт

^

Сча, где-то была почти законченная картинка, она понятнее

Ритмичность задаем, поэтому такой срок, тут нет магии просто так сложилось)

Конечно проекты могут идти параллельно. В идеале не должен возникать конфликт за ресурсы.
Перед началом проекта/спринта данные ресурсы фиксируются и выделяются. Если ты грамотный руководитель проекта/продукт ты заранее об этом побеспокоишься.
Ситуация конфликта за ресурсы возникает наиболее часто в двух случаях:
1) поехало расписание по одному из проектов
2) набрали больше проектов, чем позволяют текущие ресурсы компании.

Ну если у вас дизайнер всегда успевает за неделю до разработки сделать свои задачи — тогда ок, имеет право на жизнь

Опять забыл реплай, сорри

Я вас понял, спасибо!
Артем решает другую проблему.

У него нет конфликта за ресурсы (есть, но он не согласен). Его проблема в том, что он пока не знает, сколько задач из каждого проекта брать в следующий спринт. Велосити команды он знает. Ресурсы, предположу, фиксирует до начала спринта.

Его проблема не в спринте, а до, короче :)

Надо целиком формально написать условия все таки. К вечеру сделаю. А пока поясню, что я еденственный пока что ПМ. Сейчас я на рандоме выбираю задачи, иногда попадаю, а иногда нет. Я хочу найти способ формализовать модель, по которой я преоретизирую задачи с date depended.

@revealed_dave  правильно написал, у нас есть  первоначальное ТЗ которое составляет аналитик что бы ограничить объёмы проекта и зафиксировать основные поинты.
Далее согласования и "утрясания" всех вопросов с заказчиком этот этап сложно прогнозировать.

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

У меня не предиктивная разработка. Аналитики и прочие работают весь проект.