Где заканчивается РП и начинается программа.
Несколько продуктов. Одна команда. Жёсткий заказчик.
Каждый продукт — это отдельный дашборд с аналитикой расчётов и разрезов, присущих виду деятельности. Например, движение ГСМ: заправщик, объём (зима/лето), налив, датчики, ТС, заправка, расход, остаток — порядка десяти показателей на одном экране.
В команде: РП, тимлид, архитектор, аналитики, разработчики, тестировщики.
И перед РП встаёт вопрос: как приоритизировать продукты, чтобы хватило ресурсов?
Варианты известные:
— делать параллельно, переключаясь между проектами. Но тогда заказчику не видна работа;
— раздувать команду и бюджет. Но заказчик на это не согласен;
— согласовать приоритет с заказчиком. Рабочий вариант, но не в этом случае;
— принимать решение самому. Но на основе какого эффекта ранжировать?
Я пошёл от эффекта визуала.
Фича визуальна — разработали, показали. Не визуальна — связали с той, что визуальна, и выдаём вместе. Релизы к фиксированному темпу не привязываем: выпускаем, когда есть что потрогать.
Так заказчик видит дашборд и понимает, куда пошли деньги.
Но бывает иначе. Реальность масштабируется: несколько продуктов, одна команда, несколько заказчиков, несколько РП и программ.
На еженедельном планировании РП договариваются между собой и выстраивают приоритет. Это отлично работает в начале года, когда задач немного. И ломается в конце года, когда заказчик докидывает бюджет в проекты и требует успеть до декабря.
Здесь кто-то должен взять на себя роль цифрового комитета: выстраивать приоритеты, согласуя их с разными заказчиками. Это уже не уровень одного — это уровень программы. Но именно РПП, на мой взгляд, должен этот процесс инициировать и продвигать, а не ждать, пока его построят сверху. Пока процесса нет — его строишь ты, руками.
Расставили приоритеты — получили эффекты. Не договорились — страдает система.
У вас так же: одна команда на несколько продуктов? Кто расставляет приоритет — РП между собой, или уже дошло до кого-то сверху? Напишите, как у вас
Несколько продуктов. Одна команда. Жёсткий заказчик.
Каждый продукт — это отдельный дашборд с аналитикой расчётов и разрезов, присущих виду деятельности. Например, движение ГСМ: заправщик, объём (зима/лето), налив, датчики, ТС, заправка, расход, остаток — порядка десяти показателей на одном экране.
В команде: РП, тимлид, архитектор, аналитики, разработчики, тестировщики.
И перед РП встаёт вопрос: как приоритизировать продукты, чтобы хватило ресурсов?
Варианты известные:
— делать параллельно, переключаясь между проектами. Но тогда заказчику не видна работа;
— раздувать команду и бюджет. Но заказчик на это не согласен;
— согласовать приоритет с заказчиком. Рабочий вариант, но не в этом случае;
— принимать решение самому. Но на основе какого эффекта ранжировать?
Я пошёл от эффекта визуала.
Фича визуальна — разработали, показали. Не визуальна — связали с той, что визуальна, и выдаём вместе. Релизы к фиксированному темпу не привязываем: выпускаем, когда есть что потрогать.
Так заказчик видит дашборд и понимает, куда пошли деньги.
Но бывает иначе. Реальность масштабируется: несколько продуктов, одна команда, несколько заказчиков, несколько РП и программ.
На еженедельном планировании РП договариваются между собой и выстраивают приоритет. Это отлично работает в начале года, когда задач немного. И ломается в конце года, когда заказчик докидывает бюджет в проекты и требует успеть до декабря.
Здесь кто-то должен взять на себя роль цифрового комитета: выстраивать приоритеты, согласуя их с разными заказчиками. Это уже не уровень одного — это уровень программы. Но именно РПП, на мой взгляд, должен этот процесс инициировать и продвигать, а не ждать, пока его построят сверху. Пока процесса нет — его строишь ты, руками.
Расставили приоритеты — получили эффекты. Не договорились — страдает система.
У вас так же: одна команда на несколько продуктов? Кто расставляет приоритет — РП между собой, или уже дошло до кого-то сверху? Напишите, как у вас
Просмотры: 7