Этот сайт называется «Управление проектами». Я не уверен, подходит ли мой текущий контекст.
Я скрам-мастер. Это означает, что я не «выше» и не «ниже» кого-либо в моей команде.
Мы работаем на уровне «равный-равному» (надеюсь, это совпадающая формулировка). И я новичок в компании.
В текущей ситуации есть отчет, который я бы назвал «показателями тщеславия» (см. « Показатели тщеславия против действенных показателей »).
Если бы я был лидером, я бы просто сказал. «Прекрати. Не трать время на этот отчет».
Но я не лидер.
Я знаю, что если вы спросите «Зачем вам нужен этот отчет?», то другие найдут массу причин, по которым они считают, что отчет нужен. Чем больше я прошу в направлении типа «прекрати это», тем больше другие будут думать, что им нужно защищать то, что они сделали в прошлом.
Я думаю, что легче убедить людей начать что-то новое, чем убедить кого-то перестать делать то, что делалось несколько месяцев. Связанный с этим: предвзятость продолжения плана
Как стимулировать изменения на уровне «равный-равному»?
Рекомендации к книгам или статьям очень приветствуются.
Вы можете тактично изучить, какие изменения были внесены для улучшения продукта или команды на основе этих показателей за последние несколько месяцев. Если эти измерения привели к улучшениям или более эффективным решениям, они не являются показателями тщеславия. Ваша новизна может быть преимуществом здесь. Вы можете сказать: «Извините, я новичок. Можете ли вы помочь мне понять, как команда или руководство используют эти показатели для принятия решений?»
Если это метрики тщеславия, вы всегда можете использовать подход «какая информация поможет вам принимать решения более эффективно?» и заставить людей перейти на эти меры.
Сложный вопрос; На мой взгляд есть два варианта:
Во-первых: спасибо за ссылку на блог метрик тщеславия. Это было интересное чтиво.
Резюме по второму пункту: монетизируйте затраты
Во-вторых: я имел дело с той же проблемой в моей предыдущей компании. Я создал отчет, потому что меня попросили сделать это. После первого раза я спросил, зачем я его создаю, потому что на создание ушло какое-то время (на сбор всей необходимой информации я мог потратить 3-4 часа). Ответ был таков: мы используем его для принятия решений о том, как управлять (очевидно, у нас был долгий разговор об этом, потому что само по себе это не то, что скрам-команде нужно услышать от высшего руководства).
Так как значения отчета я не увидел, то создал его за месяц. Всего было получено 5 докладов. Я спросил их: «Что вы узнали из этих 5 докладов?» , "Какие действия вы предпримете?" Их ответ: «Мы их еще не читали». Я прекратил делать их с аргументом, что если они успеют это прочитать, я создам его снова. Я добавил аргумент, что это отнимает много времени, которое я мог бы потратить на свою реальную работу и, таким образом, создавать больше ценности. Это сработало как шарм. Я сказал им, сколько стоит создание отчета (включая время, необходимое от других людей), они были шокированы, увидев его в долларах. После этого мои усилия по монтажу никогда не подводили. Если компания считает, что рентабельность инвестиций того стоит, я проверяю ее через некоторое время. И иногда я ошибался, иногда я был прав (насчет того, что оно того не стоило),
Если бы я был лидером, я бы просто сказал. «Прекрати. Не трать время на этот отчет».
Да, вы могли бы, и на этот раз вы можете быть правы. Но всегда ли ты прав?
Сила Scrum-команды в том, что она объединяет знания и понимание нескольких людей. Решения принимаются на основе консенсуса в результате выдвижения веских аргументов или применения хорошего подхода к решению проблем.
Я знаю, что если вы спросите «Зачем вам нужен этот отчет?», то другие найдут массу причин, по которым они считают, что отчет нужен. Чем больше я прошу в направлении типа «прекрати это», тем больше другие будут думать, что им нужно защищать то, что они сделали в прошлом.
Вот почему важно, чтобы Скрам-мастер понимал мотивацию и предубеждения, существующие в его команде.
С некоторыми членами команды вы можете просто представить им сильный аргумент.
Другим членам команды, возможно, придется самим принимать решение. В этой ситуации может быть хорошей идеей сосредоточиться на последствиях проблемы, а не на самой проблеме. Часто команда сама принимает решение.
Например, я мог бы собирать статистику о времени, которое команда тратит на создание отчетов. Когда команда увидит эту статистику, она может решить, что это слишком много. Как скрам-мастер, вы можете предложить им просмотреть все отчеты, которые они составляют, и решить, не нужны ли некоторые из них.
Принятие таких решений сложно и может занять много времени. Это того стоит, потому что совместная работа команды сверстников — очень эффективный способ работы.
Я думаю, у вас есть две проблемы, и первая проблема. Я делаю вывод только на основе того, что вы написали, поэтому я могу ошибаться, но я рискну.
В идеале высокоэффективная команда должна иметь представление о командных целях, задачах, способах достижения консенсуса и взаимной заинтересованности своих членов среди других качеств. Я думаю, что ваша первая проблема заключается в том, что ваша команда может быть не такой эффективной, как могла бы быть.
Второй вашей проблемой является отсутствие процесса. Анализ решений — важный управленческий процесс, и требуется немного усилий, чтобы внедрить и поддерживать его на должном уровне. Требуется некоторое время для выработки критериев принятия решений, методов анализа, времени для оценки проблемы, обсуждения и, наконец, достижения консенсуса или голосования или любого другого метода, который следует выбрать. Это не требует лидера, чтобы сделать это успешно, и на самом деле, вероятно, лучше всего работает на равных.
Если ваша команда была высокоэффективной, и член поднял проблему, например, с метриками, команда использовала бы этот процесс для принятия необходимого решения. Вам может не понравиться ответ, но он был командным, и это важно.
добро пожаловать!
Вы задаете общий вопрос на конкретном примере. Я постараюсь ответить обоим.
Я вижу здесь несколько важных моментов:
Общий:
Специфический:
Тот факт, что вы являетесь SM, а не членом команды разработчиков, является наиболее важным обстоятельством в отношении «внедрения изменений на уровне одноранговой сети». У члена команды есть множество способов внести изменения в команду: например, старший разработчик может в значительной степени полагаться на свой опыт; очень самоуверенный и напористый разработчик может доминировать в разговоре; разработчик, ориентированный на данные, может поразить статистикой; и есть еще. Но у скрам-мастера другая роль, а значит и другой подход.
Роль скрам-мастера состоит в том, чтобы тренировать команду к совершенствованию. Как говорится: «Я здесь не для того, чтобы отвечать на ваши вопросы, я здесь для того, чтобы подвергать сомнению ваши ответы».
На самом деле, я бы отошел от парадигмы «движения изменений»: это звучит так, как будто разработчики — это лошади, тянущие повозку, а вы держите вожжи и едете в другом направлении. Вместо этого я предлагаю «поощрять изменения», «мотивировать изменения», «задаваться вопросом об изменениях».
Теперь позвольте мне сделать паузу и перейти к пункту два: вы новичок в организации.
Какова динамика вашей команды? Я бы настоятельно рекомендовал тимбилдинг и формирование команды в качестве вашего первого приоритета: потому что до тех пор, пока ваша команда не примет вас и не начнет доверять вам как одному из них, они не будут открыты для каких-либо предложений об изменениях с вашей стороны. Взгляните на ценности Scrum и посмотрите, как вы все справляетесь с ними.
Поощрение изменений в качестве SM требует терпения, уважения, коллегиальности и больше слушания, чем разговора.
Хорошо, а теперь вернемся к тому, как вы, как скрам-мастер, хорошо интегрированный в вашу команду, можете поощрять изменения в области, в которой, по вашему мнению, есть место для повышения гибкости.
Во-первых, постарайтесь избавиться от убеждения, что вы правы в этом вопросе, и если ваша команда просто выслушает вас, они поймут и будут убеждены. Это не продуктивное отношение к разговору, который носит исследовательский, любопытный или ободряющий характер. (Поверьте мне, я знаю, как это трудно сделать! ;))
Ретроспектива — это каноническое место для проверки процессов и процедур команды и определения областей, требующих улучшения. Как SM, вы можете разработать ретро-стиль, чтобы стимулировать размышления о широких областях, к которым, по вашему мнению, относится этот отчет. Например:
сделайте диаграмму с Усилием на одной оси и Ценностью на другой. Пусть команда потратит некоторое время на молчаливое написание всех общих действий, которые они могут придумать, а затем примерно разместите их на схеме. Поговорите, если есть разногласия по поводу того, куда должен идти предмет. Затем посмотрите на область (большие усилия, низкая ценность) на доске и посмотрите, сможете ли вы определить некоторые вещи, которые можно переместить в направлении (малые усилия, высокая ценность) или даже полностью исключить.
обсудите метрики и отчетность и определите, что входит в каждую из них и что ими движет. Попросите команду совместно нарисовать диаграммы, чтобы показать это: некоторые из них, вероятно, будут стандартными схваточными диаграммами циклов проверки-адаптации, а некоторые будут более специфичными для местных условий.
поговорите о прошлом, настоящем и будущем общения с заинтересованными сторонами — активно привлекайте к этому вашего PO. Для каждого широко используемого коммуникационного шаблона или артефакта расскажите о том, как мы пришли к этому, и представьте, куда мы могли бы пойти в будущем, чтобы быть более гибкими и приносить больше пользы.
Будьте открыты для любых идей, вопросов и изменений, которые могут возникнуть в результате этого. Не пытайтесь подвести разговор конкретно к результату или даже к конкретной теме, которую вы хотите. Если команда особенно занята одним из них, повторяйте его несколько раз либо в каждом спринте, либо чередуя с другими подходами. Я бы позволил команде получить несколько из них, прежде чем я представлю конкретный отчет, который меня беспокоит, если бы они все еще не сделали этого.
И последнее соображение: один подход, который может быть полезен для преодоления такого сопротивления:
Я знаю, что если вы спросите «Зачем вам нужен этот отчет?», то другие найдут массу причин, по которым они считают, что отчет нужен. Чем больше я прошу в направлении типа «прекрати это», тем больше другие будут думать, что им нужно защищать то, что они сделали в прошлом.
это попробовать «Пять почему» ( https://en.wikipedia.org/wiki/5_Whys ). Я всегда начинаю это с чего-то вроде: «Я не намеренно неприятна, это настоящая техника». И вместо того, чтобы спрашивать «зачем вам нужен этот отчет», я бы начал с «зачем мы делаем этот отчет». (Всегда используйте язык «мы»!)
Надеюсь, это поможет. Удачи!
Этот вопрос лучше всего подходит в контексте навыка лидерства.
Поскольку вы новичок в команде, а команда следует предвзятому мнению, вам нужно применить свои лидерские качества, чтобы убедить, что более выгодно?
Я согласен с тем, что инструмент альтернативных издержек может помочь, но то, как вы применяете этот инструмент, будет более важным.
Я бы предположил, что на самом деле не вам решать, найдет ли отчет полезным кто-то другой. Как мастер схватки вы являетесь неформальным лидером команды, у которой нет лидера, которому поручено вести за счет убеждения, а не авторитета. Но это не обязательно означает, что вы должны определять , что должна делать команда, а также является ли конкретная задача, выполнение которой поручено команде [извне...], полезной или нет. Вы должны начать с того, что поручено команде, а затем работать с командой и внутри нее, чтобы помочь ей выполнить свои задачи.
Тем более, что вы новичок, "много слушайте".
Дэвид Эспина
Тьяго Мартинс Перес