Pull to refresh
0
0
Send message

Выглядит, как будто вы просто переписали классическое ТЗ в формате User Story. Потеряли легкость US и полноту ТЗ

Вы серьезно не понимаете разницы между бизнес процессом и Use Case?

Вопрос и к Дмитрию и к комментатору: а зачем системные взаимодействия описывать в BPMN? Напомню, что BPMN - это Business Process Model and Notation. То есть сразу в названии, что это бизнес процессы, а не системные. Соответственно системный взаимодействия из С4 абсолютно правильно описывать в сиквенсе

За продуктом, очевидно, не в Agima

Все пытался понять, почему всю статью мы вроде про продукты, но нет - про проекты. А потом увидел подпись автора - Head of PMO и все встало на свои места, проджекты в подавляющем большинстве не умеют в продукт, они не умеют в ценность, они только про сроки и бабки.

Очень сильно выдает незнание терминологии, например, growth team - это не команда, которая создает продукт. Growth - это команда, которая растит уже существующий продукт, который доказал свою эффективность и потребительскую ценность, но уперся в некоторый потолок развития и ему нужен новый качественный скачок, они занимаются в первую очередь оптимизацией продукта: SEO, пользовательские пути, поиск узких мест в конверсии.

Второй момент, который выдает незнаение предмета с головой - это предложение поделить на две команды: дизайн и разработку. Узнаю проджекта! Но так делать нельзя, вы должны поделить задачи вертикально между командами, а не горизонтально, иначе не будет синергии кросс-функциональной команды, да и информация будет теряться.

И в целом, вопрос нужна ли вам продуктовая команда имеет очень короткий ответ - нужна, если вы пилите продукт. То есть сам вопрос и проблематика поставлены идеологически не верно. Хотя, возможно, цель статьи как раз и была навести потенциальных заказчиком на вывод, что не нужна, а надо брать проекты в Agima? Но как по мне, так все равно не получилось.

Information

Rating
Does not participate
Registered
Activity