Как заставить команду BI работать в вертикальных срезах, например, пользовательских историях

Я Agile-коуч для группы инженеров по бизнес-аналитике и специалистов по данным.

Вообще говоря, существует 2 разных типа рабочих элементов, которые они выполняют:

  1. Пользовательские отчеты и информационные панели, например Business Objects, Looker
  2. Активация, связанная с платформой, например конвейеры данных Airflow, конфигурация AWS, работа Snowflake и S3.

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

Один разработчик будет постоянно работать над новыми конвейерами данных и поддерживать существующие конвейеры данных.

Один разработчик будет делать только Looker или BO.

Один разработчик будет заниматься исключительно деятельностью, связанной со Snowflake и т. д.

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

Есть еще несколько переменных, которые усложняют мою проблему. У нас нет навыков управления продуктами в команде — у нас есть PO, но он деловой человек без реального опыта работы в ИТ.

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

Мой вопрос прост: как мне заставить мою команду работать гибко и вертикально.

Ответы (1)

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

Несколько предложений в этом направлении

  • Проведите ретроспективу со всеми членами команды о том, как они могут коллективно изменить представление бизнеса о том, что они ничего не приносят. Пусть они сами придумывают идеи и какое-то время пробуют самые многообещающие (или те, которые получают наибольшую поддержку).

  • Не позволяйте команде горизонтально нарезать рабочий элемент. Если ни один вертикальный срез не может быть согласован, тогда предположим, что это наименьший рабочий элемент, которым может стать.
    В то же время установите ограничение WIP на рабочие элементы. Если член команды хочет приступить к новому рабочему элементу, который превысит лимит незавершенного производства, попросите его помочь в завершении рабочего элемента, который уже находится в процессе выполнения, даже если для этого рабочего элемента не осталось работы в его области знаний. . Это поможет быстрее выполнять рабочие задачи, а также перекрестно обучает команду.
    Вы можете разрешить команде создавать (разрезанные по горизонтали) подзадачи в рамках рабочего элемента, чтобы знать, в каких технических областях необходимо выполнить работу, но выполнение подзадачи не будет иметь никакого значения для любых показателей, которые вы отслеживаете. . Однако они могут помочь команде увидеть, где и как несколько человек могут сотрудничать над одним и тем же рабочим элементом.

Извините, я изо всех сил пытаюсь понять ваш второй пункт. Не могли бы вы перефразировать. Вы говорите, что я должен отслеживать рабочие элементы или горизонтальный срез, который включает рабочие элементы?
@ user32613: перефразировал. Вы должны отслеживать рабочие элементы (и выполнять их как можно быстрее), но разрешить технические задачи, чтобы было видно, как члены команды могут работать вместе над рабочим элементом.
Спасибо за ответ. Обязательно сделаю первый пункт. Второй момент - проблема. У меня нет полномочий как у Agile-коуча заставлять их делать вертикальные срезы. Тем не менее, рабочие элементы представляют собой горизонтальные технические задачи (настолько маленькие, насколько они могут их получить). Они утверждают, что это истории, но на самом деле это просто технические задачи. Однако я налагаю на них ограничения WIP.
@ user32613: Если у вас нет полномочий, попробуйте привлечь на свою сторону кого-то, у кого есть полномочия предотвращать «неправильную» нарезку. PO может быть хорошим кандидатом, поскольку он может настаивать на том, что истории имеют (для них) узнаваемую ценность для бизнеса. Тот факт, что он не технарь, может помочь в этом.