Конечно, никто не отменяет форс-мажор и влияние третьих сил. И конечно в наших расчетах ситуация, приближенная пусть не к идеальной, но точно не учитывающая рисков влияния третьих сил (как упомянутые скачки валюты или локдауны). Но тем не менее, для того, чтобы понять, что именно даст нам внедрение того или иного сервиса с целью автоматизации - расчеты нужны.
а) принимается решение о продолжении или прекращении использования текущего решения;
б) для заказчиков, не обеспечивших выполнение заявленных метрик, будут применяться более жесткие фильтры в рамках согласования бюджета с отделом финансового контроля и планирования. Не удивлюсь, если при аналогичном запросе бюджета на автоматизацию запрос такого заказчика будет профинансирован в последнем приоритете.
Да, буквально недавно делали отчетную презентацию на команду.
Приведу верхнеуровневую статистику:
в выборке из 10 внедренных сервисов 7 из них показали целевые значения по достижению заявленных метрик;
в трех случаях метрики не были достигнуты, из них по двум сервисам с Бизнес-владельцами создали чек-листы по принятию решения о замене сервиса в случае, если в горизонте полугода целевые показатели метрик не будут достигнуты; по одному из трех сервисов уже принято решение о замене текущей системы, работы начаты.
Привет и спасибо за вопрос, он действительно интересный!
В нашем случае мы, как указано в статье, используем скорее не продуктовый, а проектный подход, когда мы хотим за довольно короткие сроки закрыть конкретную боль бизнеса, привнеся автоматизацию через готовые "коробочные" решения. Как метод оценки и скоринга проекта WSJF использовать не совсем корректно, поскольку методика полезна для оценки конкретных фич и оптимизации беклога задач в рамках разработки продукта.
Привет! Продолжаем рассказывать про наши процессы и приоритизацию, подробнее можно почитать в нашей новой статье :) https://habr.com/ru/companies/lamoda/articles/836582/
На самом деле, ответы на эти вопросы тянут на новую статью - которую мы уже начинаем готовить, в ней мы обязательно раскроем наши подходы и практики к выстраиванию процесса.
Overall, у нас безусловно есть и RACI-матрица разграничения зон ответственности между всеми участниками проекта, и схема с подробным описанием реализации инициатив нашего беклога, и продукты, в которых создаем "карточки проектов" и ведём эпики.
Обязательно поделимся в новой статье подробностями - спасибо за вопросы!
Да, непосредственно реализация происходит в рамках кросс-функционального взаимодействия внутри компании, если мы говорим о подготовке к внедрению сервиса на нашей стороне.
Здесь задача проектного менеджера - своевременно прийти в "чужой" беклог, описать и запланировать аналитику/разработку/настройку с владельцем или проектным менеджером этого беклога. Как правило, такие задачи анализируются не более 2 недель, на реализацию также уходит не более 2-3 недель. То есть мы знаем и понимаем наш горизонт планирования фактически во всех беклогах кросс-функциональных команд, которые планируем задействовать с учетом тех функциональных требований, которые мы создаем совместно с бизнес-заказчиками.
Задачей специалиста саппорта фактически является обеспечение второй линии техподдержки, у такого специалиста точно есть full access админские права внутри сервиса/системы, с помощью которых он может подключиться к решению инцидента пользователя и внести, к примеру, необходимые корректировки в выстроенной бизнес-логике или например выяснить, каких прав не хватает у пользователя.
Привет! Если говорить о ролевом разделении, то это: проектные менеджеры, бизнес-аналитики, специалисты саппорта, а также с октября к нам присоединился менеджер продукта.
Привет!
Комментарий валидный, принимается :)
Конечно, никто не отменяет форс-мажор и влияние третьих сил. И конечно в наших расчетах ситуация, приближенная пусть не к идеальной, но точно не учитывающая рисков влияния третьих сил (как упомянутые скачки валюты или локдауны). Но тем не менее, для того, чтобы понять, что именно даст нам внедрение того или иного сервиса с целью автоматизации - расчеты нужны.
Да, если можно так выразиться :)
В случае недостижения метрик:
а) принимается решение о продолжении или прекращении использования текущего решения;
б) для заказчиков, не обеспечивших выполнение заявленных метрик, будут применяться более жесткие фильтры в рамках согласования бюджета с отделом финансового контроля и планирования. Не удивлюсь, если при аналогичном запросе бюджета на автоматизацию запрос такого заказчика будет профинансирован в последнем приоритете.
Да, буквально недавно делали отчетную презентацию на команду.
Приведу верхнеуровневую статистику:
в выборке из 10 внедренных сервисов 7 из них показали целевые значения по достижению заявленных метрик;
в трех случаях метрики не были достигнуты, из них по двум сервисам с Бизнес-владельцами создали чек-листы по принятию решения о замене сервиса в случае, если в горизонте полугода целевые показатели метрик не будут достигнуты; по одному из трех сервисов уже принято решение о замене текущей системы, работы начаты.
Привет и спасибо за вопрос, он действительно интересный!
В нашем случае мы, как указано в статье, используем скорее не продуктовый, а проектный подход, когда мы хотим за довольно короткие сроки закрыть конкретную боль бизнеса, привнеся автоматизацию через готовые "коробочные" решения. Как метод оценки и скоринга проекта WSJF использовать не совсем корректно, поскольку методика полезна для оценки конкретных фич и оптимизации беклога задач в рамках разработки продукта.
Привет!
Продолжаем рассказывать про наши процессы и приоритизацию, подробнее можно почитать в нашей новой статье :) https://habr.com/ru/companies/lamoda/articles/836582/
Привет!
На самом деле, ответы на эти вопросы тянут на новую статью - которую мы уже начинаем готовить, в ней мы обязательно раскроем наши подходы и практики к выстраиванию процесса.
Overall, у нас безусловно есть и RACI-матрица разграничения зон ответственности между всеми участниками проекта, и схема с подробным описанием реализации инициатив нашего беклога, и продукты, в которых создаем "карточки проектов" и ведём эпики.
Обязательно поделимся в новой статье подробностями - спасибо за вопросы!
Да, непосредственно реализация происходит в рамках кросс-функционального взаимодействия внутри компании, если мы говорим о подготовке к внедрению сервиса на нашей стороне.
Здесь задача проектного менеджера - своевременно прийти в "чужой" беклог, описать и запланировать аналитику/разработку/настройку с владельцем или проектным менеджером этого беклога. Как правило, такие задачи анализируются не более 2 недель, на реализацию также уходит не более 2-3 недель. То есть мы знаем и понимаем наш горизонт планирования фактически во всех беклогах кросс-функциональных команд, которые планируем задействовать с учетом тех функциональных требований, которые мы создаем совместно с бизнес-заказчиками.
Задачей специалиста саппорта фактически является обеспечение второй линии техподдержки, у такого специалиста точно есть full access админские права внутри сервиса/системы, с помощью которых он может подключиться к решению инцидента пользователя и внести, к примеру, необходимые корректировки в выстроенной бизнес-логике или например выяснить, каких прав не хватает у пользователя.
Привет!
Если говорить о ролевом разделении, то это: проектные менеджеры, бизнес-аналитики, специалисты саппорта, а также с октября к нам присоединился менеджер продукта.