Позвольте мне начать с объяснения большой, неразрешимой проблемы:
В моей команде появился новый директор по технологиям, и он настаивает на том, чтобы решить, как настроить Jira, влияя на людей, которые ему не подчиняются. Несмотря на то, что он настаивает на обратном, он, кажется, не имеет ни малейшего представления о том, как работает agile или Scrum, но остальная часть команды очень довольна этими вещами. Он не понимает, что входит в стендап, и когда мы недавно устроили ретроспективу, он 90 процентов времени смотрел на свой ноутбук. Это (и его явное смешение водопада и гибкости) вызывает очень настоящие проблемы.
Он талантливый программист, но также немного придурок и непроницаемый коммуникатор. Он ведет указом, а не примером. Плохо, что я уже решил, что ухожу (ожидаю предложения в ближайшие два дня), а наш старший фронтенд-разработчик уволился сразу после того, как мы наняли очень младшего фронтендера, которому очень нужна была его работа. наставничество.
Теперь к моему более узкому вопросу
Должен ли кто-то в этой роли иметь решающее слово в подобных вещах? То, как он хочет настроить Jira, не имеет смысла ни для кого другого. Как я могу сопротивляться и выступать за Agile и Scrum?
Я пытаюсь исправить как можно больше, прежде чем уйти, потому что мне нравится компания, и я действительно забочусь о команде, и я хочу, чтобы они добились успеха.
Любые советы о том, как помочь мне помочь моей команде, прежде чем я уйду, будут оценены.
Нацельтесь на цель(и), а не на путь.
Jira — это такой же инструмент, как и любой другой. Слишком часто я вижу, как люди заботятся о том, чтобы Jira была организована, забывая, что, как и любой другой инструмент, Jira должна быть средством достижения правильной цели или результата.
Сделайте шаг назад: подумайте , почему вы вообще используете Jira ? Назовите 3 основные причины. Как он (или, что еще лучше, все , кто использует Jira, если вы хотите иметь более последовательное представление). Совпадают ли ответы? Совпадают ли цели использования Jira? Возможно, ваш менеджер запрашивает конкретное использование, потому что он предполагает определенные отчеты, которые нельзя получить с помощью Jira как есть. Может быть, у него вид, ориентированный на водопад, и он ожидает от Jira сроков выполнения. Суть в том, что если есть конфликт с использованием Jira, то это потому, что у людей разные ожидания от Jira. Обсуждая это, старайтесь вообще не упоминать Jira.
Примеры:
Теперь настройте план достижения целей: пока все согласны с тем, что Jira может (и, самое главное, не может !), предложите несколько планов по достижению целей. Если возникают разногласия по поводу целей, необходимо установить приоритеты (и обсудить альтернативы). Скажем, если менеджеру нужно знать план доставки на 1 год, фраза «Джира не получит его, смирись с этим» не поможет. Следует обсудить альтернативы. Точно так же, если согласованный подход не помогает команде, команда должна договориться о том, как достичь целей (например, чтобы иметь «слои» использования Jira... например, менеджеры, использующие Epics, как они хотят, и команда используя Задание/Историю).
На ваш первый вопрос: JIRA — это замена доски задач, которая является инструментом для команды, позволяющей визуализировать и организовывать свою работу, а заинтересованным сторонам — быстро видеть, как идут дела. По большей части это означает, что именно команда решает, как его использовать. Большим исключением, которое я бы увидел, было бы то, что для заинтересованной стороны вполне разумно сделать запрос о конфигурации, чтобы они могли лучше видеть статус спринта и работы, если это также не влияет на команду много.
Что касается вашего второго вопроса, это сложный вопрос. Это действительно сводится к тому, почему они это делают. У многих людей намерение хорошее — они думают, что помогают. Может быть, то, что они делают, сработало где-то еще, и они предполагают, что это сработает и там. Или, может быть, у него на самом деле есть лучший способ делать что-то, но, поскольку он просто принуждает к этому, вы получаете все неудобства от изменения, но не видите никакой выгоды. Для этих людей вы обычно можете показать им влияние, которое они оказывают, и попросить их замедлиться и провести некоторые экспериментальные изменения с командой, попросив их предложить предложения по проблемам, с которыми борется команда, и вы можете попробовать эти предложения, прежде чем вносить изменения. они постоянные. Изменения, которые на самом деле лучше, будут иметь смысл, а изменения, которые не подходят, отойдут на второй план.
В редких случаях я сталкиваюсь с людьми, которые делают это без добрых намерений. Каким-то образом за свою карьеру они усвоили, что должны контролировать действия других людей, и именно поэтому они узнают, что они важные лидеры. Эти люди могут измениться, но это долгий путь. Обычно проще просто выйти из зоны их поражения.
Простой вывод: если вы уходите, то лучшее, что вы можете сделать для своей команды, это почти наверняка ничего не делать . Пытаясь «исправить» все, чего вы можете добиться, — это расстроить своих коллег, которым не нравится неявный конфликт, который возникнет.
Я пытаюсь исправить как можно больше, прежде чем уйти, потому что мне нравится компания, и я действительно забочусь о команде, и я хочу, чтобы они добились успеха.
Новые люди редко делают что-то из какого-то голливудского злодейского наслаждения злом. Возможно, нового технического директора выдвинули из его зоны комфорта, возможно, он шокирован преувеличением своего опыта. Неважно, ты идешь дальше.
Сосредоточьтесь на том, чтобы убедиться, что ваши задачи выполнены и что ваши проекты работают гладко, когда вы уходите . Так вы сможете наилучшим образом служить своей команде.
Тьяго Кардосо
Алексей Р.