Как сбалансировать Teamwork и Babble?

Я почувствовал конфликт в организации, которая работает следующим образом:

  • Они хотят поощрять командную работу и хорошие личные отношения
  • Они хотят обсуждать личные дела, связанные с работой, и дизайнерские решения на работе.
  • Когда обсуждения затягиваются, спонсор раздражается, что «никто не работает».

Теперь пункт 2 необходим для пункта 1, но пункт 3 сводит на нет пункт 2, что потенциально может навредить основной цели — формированию хороших личных отношений.

Какое здесь хорошее решение? Я мог бы представить что-то вроде:

  • Принуждение к разговору на кухне
  • Ограничение времени для всех обсуждений
  • Скажите людям, чтобы они возвращались к работе, когда «уже слишком долго»

По какой-то причине, я не знаю, что, я не думаю, что это лучшее решение.

Ответы (6)

Дэвид был прав, когда я написал, что результат имеет значение ( доставленные ценности ), поэтому мне нечем поделиться, кроме истории.

У компании, в которой я работаю, есть несколько сайтов, и я хотел бы написать о двух конкретных сайтах: один, где обсуждения могут быть сколь угодно длинными, и другой, где спонсоры ведут себя так, как вы описали. Обе стороны продуктивны, но более умные вещи исходят от сайта, где мы можем обсуждать столько, сколько можем. Обмен знаниями происходит намного быстрее, когда вы можете обсуждать вещи. Там, где обсуждение контролируется, знания остаются там, где они есть, и некоторые люди «владеют» знаниями, а это медленно и вредно для здоровья.

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

Мой совет: научитесь вовремя заканчивать дискуссию.

Большое спасибо за ваше наблюдение роста инноваций! Я бы перефразировал ваше первое утверждение так: «Спонсор не может определить, какая дискуссия полезна, а какая нет (за короткое время), поэтому он должен посмотреть на результат и позволить команде решить, пока результат хорошо."
Я бы выразился иначе. В этой ситуации спонсор должен сделать две вещи: во-первых, доверять команде и обращаться с ней как со взрослыми, которые знают, какое преобразование продвинет проект вперед. Во-вторых, больше внимания уделяйте ценности и меньше микроуправлению. Лично мне было бы неприятно, если бы другой человек вместо меня решал, какой разговор ценен.

Это возможность обучить вашего спонсора. 100% FTE на самом деле где-то между 45% и, возможно, 75% действительно продуктивны, где баланс непродуктивен, чтобы включать общение среди прочего. 100% по-настоящему продуктивной работы недостижимы и, вероятно, отрицательно сказываются на производительности. В общении есть ценность, но вы должны убедиться, что оно не выходит из-под контроля.

Кроме того, обучайте свою команду. Внешность имеет значение.

Наконец, лучший показатель эффективности — это то, как вы оцениваете свои показатели. Если вы находитесь в зеленом против плана, то вам нужно работать со своим спонсором, чтобы облегчить микроуправление.

Я думаю, что есть несколько разных проблем

Они хотят обсудить личные дела, связанные с работой

Если у члена команды есть личная проблема, которая влияет на его работу, я не думаю, что есть смысл пытаться жестко контролировать обсуждение. Если вы это сделаете, вы рискуете обесценить и демотивировать члена команды. Что вы можете сделать, так это вести дискуссию к решениям, а не просто говорить о проблеме.

и дизайнерские решения в работе

Это совсем другое животное. Как только проектное решение принято, могут возникнуть проблемы, которые заставят пересмотреть решения. Важно убедиться, что все ключевые игроки участвуют в этих обсуждениях, когда это необходимо, и в равной степени, чтобы эти обсуждения были задокументированы и доведены до сведения остальной команды. Без второй части вы потеряете контроль над проектом из-за расползания масштаба, отсутствия общих предположений и т. д. Необходимость в этой документации должна подтолкнуть эти обсуждения к более формальному, а не к «культеру воды», что даст вам больше возможностей для ограничения времени дискуссии, чтобы вы могли избежать аналитического паралича.

спасибо за различие и явное упоминание о «обесценивании и демотивации», что я и заметил!

Лично меня совершенно не волнует, сколько болтовни и чуши будет продолжаться (при условии, что это вежливо и в целом уместно на рабочем месте), пока мы соблюдаем сроки и производим качественный продукт. Следите за своими показателями, активируйте своих сотрудников и управляйте своим проектом.

Обратной стороной этого является то, что я обычно также не рассматриваю возможность предупреждения. Если мы отказываемся от проекта, потому что команда не приложила усилий, мы поговорим об этом в нашей ретроспективе. Если один из членов моей команды недостаточно взрослый, чтобы понять, что нужно делать в будущем, он не останется в моей команде.

Мне очень не нравятся все три ваших решения. Каждый из них не относится к членам вашей команды как к взрослым. Относитесь к членам вашей команды с уважением и ожидайте, что они будут работать. PM — это не няня, а члены вашей команды — не дети (ну, по крайней мере, надеюсь).

В вашем описании проблемы есть что-то, что я считаю более важным, чем могло бы показаться. Эта комбинация «личных дел, связанных с работой» может иметь большое значение для спонсора. Он, вероятно, не реагирует таким же образом, когда команда работает над проблемами дизайна/реализации.

В общем, если эти разговоры имеют «личную» составляющую, то не на глазах у спонсора, лучше наедине с минимально необходимой аудиторией. Кроме того, вовлеченные члены команды должны быть очень напористыми в выражении своих аргументов, чтобы избежать перерастания проблемы в кисту. По той же причине такого рода обсуждения должны происходить только один раз, если это возможно, и вы, как руководитель проекта, должны быть в состоянии предоставить профессиональную точку зрения для решения проблемы. Возможно, вы не сможете решить разногласия, потому что, когда это личное, это может быть сложно, но, по крайней мере, вы сможете показать, чего вы ожидаете от каждого члена команды, чтобы проект продолжался в правильном направлении.

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

Я немного думал над этим вопросом, и что-то продолжало грызть меня с другими ответами, и я, наконец, понял это. Все это отличные ответы, ПРИ УСЛОВИИ, что все согласны как с целями, так и с процессом. И я думаю, отсюда и конфликт.

Во-первых - Обсуждения хороши и необходимы. Но в большинстве ответов предполагается, что все обсуждения а) либо связаны с работой, б) сосредоточены на отношениях с сотрудниками, либо в) сотрудники знают, когда уволиться и вернуться к работе. По моему опыту такое случается редко. Так что я вижу, как спонсор/менеджер расстраивается.

Во-вторых, как спонсор, если бы я увидел, что все тратят довольно много времени на разговоры о том, что может не иметь отношения к проекту, у меня были бы две первоначальные проблемы: а) я плачу за время по часам, и б) даже если Я нет, кажется, что оценка времени была завышена, чтобы включить время на разговоры и общение. Поэтому в первом случае я задаюсь вопросом: «Я плачу им за то, чтобы они стояли и говорили о личных проблемах?», а во втором случае: «Может ли мой проект быть завершен раньше, чем они сказали мне, если они работают, а не разговаривают?»

В-третьих, Жолт хорошо сказал об обмене знаниями. И этот момент относится к индивидуальному проекту — но является ли он частью проекта и необходимой частью процесса? Другими словами, для одних проектов необходимы исследования и сотрудничество, для других — нет. так ваш проект требует этого, или сотрудники делают это, потому что они «хотят»?

И вот тут-то и возникает вопрос согласования — знает ли ваш спонсор, что нужно для того, чтобы этот проект работал? Понимают ли они, что могут быть моменты, когда кажется, что что-то не делается, но на самом деле это могут быть самые важные обсуждения? И наоборот, понимает ли команда, какие конкретные требования предъявляются к этому проекту? График, объем и т.д.? Может быть, это просто не тот проект, о котором нужно много говорить, и им нужно подождать до следующего.