На своей работе я начал помогать другой технической группе. Я был на нескольких стендапах, и мое первое впечатление, что отношения между бизнес-сферой и технической командой полностью разорваны.
Каждый стендап был очень напряженным и включал в себя деловой человек, тренирующий каждого члена технической команды и делающий много пассивно-агрессивных комментариев. Это может быть что-то вроде серой линии, но, судя по тому, что я видел, это как бы граничит с издевательствами. К слову, мне пришлось спросить одного участника после одного стендапа, действительно ли они в порядке, и они были очень расстроены.
Я разговаривал с каждым из членов технической команды, и похоже, что это происходило на протяжении всего проекта. Создается впечатление, что бизнес-сфера вообще не доверяет ИТ-команде и не понимает, что делает ИТ, и сколько времени и денег может потребоваться для внедрения.
Я не говорю, что все сказанное не имеет смысла. Определенно есть вещи, которые можно улучшить. Тем не менее, отношения, как они есть, контрпродуктивны, плохо влияют на моральный дух, и вы не можете действительно улучшить процессы команды в этой среде.
Как человек со стороны, я чувствую, что есть возможность попытаться восстановить эти отношения. Думаю поднять эти вопросы на ретроспективе. Тем не менее, я боюсь, что это может быть слишком конфронтационным. Кроме того, многие из этих проблем, вероятно, являются симптомами более серьезных проблем в проекте, контекст которых мне неизвестен, и для их решения, вероятно, потребуется больше времени, чем одна ретроспективная сессия.
Я знаю, что ретроспектива должна быть безопасным местом для высказывания любых опасений и предложений по улучшению, но не будет ли проблема токсичной рабочей среды слишком серьезной, чтобы ее поднимать?
Вы должны обязательно заняться этим, и я бы не стал обязательно называть это токсичной культурой (я согласен с @GregoryCurrie в том, что просто создание токсичной среды в ретро-стиле - это то, что нужно обсуждать с частным менеджером). Я бы порекомендовал вам обсудить несколько действий, которые являются токсичными, и назвать их негативным поведением, влияющим на взаимодействие в команде. Вы должны быть в состоянии определить это для команды и определить, почему это вызывает такую проблему для вас и для команды. Я бы порекомендовал иметь несколько идей о том, как его устранить.
Проблема с обращением к нему как к токсичности заключается в том, что это «обвиняющий» язык. Люди, которые ведут себя токсично, обижаются и закрываются. Обращаясь к поведению, он начинает менять привычки команды. Легче иметь конкретные примеры поведения и случаи, и сказать кому-то что-то, что он сделал что-то, что негативно повлияло на вас, гораздо легче переварить, чем утверждения, которые предполагают состояние «всегда».
Также полезно, если вы сами займетесь этим как частью проблемы. Люди чувствуют себя менее виноватыми, если вы способны вызвать такое поведение в себе. Они также с большей вероятностью присоединятся к вам в исправлении поведения, потому что теперь у них есть партнер в решении проблемы, а не кто-то, кто их осуждает.
Ретро должно оставаться безопасным местом, а это значит, что нельзя просто открыто обвинять людей. Это означает отстранение людей от проблемы и ее решение. Человек не плохой, поведение плохое.
Джоэл уже написал довольно хороший ответ, и я должен согласиться с ним в отношении общего направления и результата. Я хотел бы привести вам еще одну причину , почему это правильный образ действий.
Любые проблемы в команде должны подниматься в ретроспективе. Только если они не могут быть решены там, команда должна принять решение о привлечении кого-то еще, например, менеджера.
Но вы должны убедиться, что то, о чем вы говорите, действенно . Ваша проблема исчезнет только в том случае, если вы сможете выйти из собрания с набором действий , которые решат проблему.
«Командная культура токсична» — здесь нет ничего действенного. Это неконкретно и самоуверенно. Кто-то скажет да, кто-то скажет нет, и тогда вы снова в детском саду. Без каких-либо изменений в будущем или положительного исхода.
На самом деле вы не привели ни одного примера, поэтому мне придется его придумать: допустим, деловые люди несколько раз спрашивают вас о статусе вашего проекта, как будто они вам не верят. Может потому, что их на самом деле нет.
Когда мы находимся на наших статусных встречах, мне приходится повторяться несколько раз. Я чувствую, что вы либо игнорируете то, что я сказал, либо не верите тому, что я сказал. Я хотел бы, чтобы мы нашли способ сказать это только один раз.
Теперь это не мнение. Либо надо повторяться, либо нет. Любой может присутствовать и быть свидетелем этого. С другой стороны, у деловых людей могут быть веские причины задавать вам очень подробные вопросы, такие как «тестировали ли вы это», «развернули ли вы это в QA», «вы внесли свои изменения». Наверное, потому, что в прошлом они просто верили, когда люди говорили «сделано», а потом это было не так.
Итак, теперь у вас есть реальный пример поведения, которое вы хотели бы изменить, и вы задались вопросом, как изменить его конструктивным образом. Теперь вы можете перейти к обсуждению действий .
Для этого составленного примера действие может состоять в том, чтобы иметь список вопросов («определение выполненного» того, что вы выполняете Scrum), на которые необходимо ответить, чтобы любой элемент считался выполненным. Когда придет ваша очередь просмотреть статус элемента и все будет готово, просто просмотрите этот список и подтвердите каждый пункт списка. «Я написал код, Алиса провела проверку кода, мы развернули его в DEV, а Боб протестировал его. Чарли развернул его в QA всего час назад, вы можете проверить его там, если хотите. Это сделано». Или, может быть, вы найдете другое решение.
Но делайте это шаг за шагом. Выберите реальную вещь и улучшите ее действиями . Громкие размашистые заявления без реального содержания, типа «все это токсично», ни к чему не приведут.
Лучшие улучшения для обсуждения на ретроспективе — это те, которые являются действенными.
Самые приятные ретроспективы — это те, когда команда решает сделать что-то по-другому и сразу же начинает внедрять изменения.
Проблема с обсуждением «токсичных» вещей заключается в том, что «токсичное» — это слово, которое в основном означает «это то, что я считаю плохим и мне не нравится». Команде сложно изменить ваше эмоциональное состояние, потому что эмоциональное состояние по своей сути субъективно.
Гораздо проще внести изменения в процесс, который использует ваша команда. Также легче говорить об изменениях, когда вы формулируете изменения с точки зрения того, что должен делать ваш процесс; Преимущество этого заключается в том, что обсуждение значительно деперсонализируется.
В вашем конкретном случае я бы посоветовал вам обсудить тот факт, что деловые люди говорят на вашем ежедневном стендапе, и предложить изменить процесс, чтобы этого не произошло. Многие команды, использующие Scrum, вообще не позволяют не членам команды выступать на стендапе, потому что это мешает тому, чем должен быть стендап. Стендап предназначен для того, чтобы команда организовалась и решила свои проблемы, а не отчитывалась перед другими людьми в организации. Участие деловых людей делает встречу менее полезной для команды.
Обратите внимание, что, когда я излагаю вашу проблему выше в контексте изменения процесса, я вообще не комментирую , насколько плохо ведут себя гости на встрече. Об этом не нужно говорить, потому что сейчас мы говорим о действенных изменениях, которые принесут пользу команде, независимо от того, насколько грубы ваши деловые люди. Даже если их грубость всплывает в ходе обсуждения (что, вероятно, произойдет, если ваши ретроспективные встречи психологически безопасны), вы все равно можете поговорить об этом, потому что вы всегда можете просто направить всех обратно к предложенному вами изменению процесса и отклонить его. из того, как Бизнес Боб - большой придурок.
Да, это тема, которую следует поднять. И вы, как посторонний, находитесь в очень хорошем положении, чтобы быть здесь посредником. Но разрешение подобных конфликтов по-прежнему требует деликатного обращения, и ретроспективная встреча проекта может быть неподходящим местом для этого.
Если вы считаете, что проблема здесь в одном человеке, вам следует сначала поговорить с ним наедине . Обращение к их личным недостаткам на публике — это то же самое токсичное поведение, в котором вы их обвиняете: вы подрываете и унижаете их перед командой. Некоторые люди могут подумать, что дать им «попробовать их собственное лекарство» вполне заслуженно, но вряд ли это принесет много пользы. Большинство людей просто займут оборонительную или агрессивную позицию вместо того, чтобы задуматься и изменить свое поведение.
Лучшим подходом было бы поговорить с этим человеком наедине.
В принципе вы правы. Ретро — это место, где обсуждаются эндемичные вопросы, влияющие на процесс разработки.
На практике токсическое поведение нелегко исправить. Потому что если бы это было так, то, как правило, оно самоисправлялось бы, когда люди конфликтовали друг с другом на рабочем месте.
Не исключено, что во время большой групповой беседы все переворачиваются, чтобы увидеть точку зрения друг друга, но, по моему опыту, токсичные элементы, как правило, не так открыты.
Для справки: в качестве консультанта я работал со многими клиентами, которым требовалась дополнительная рабочая сила из-за нехватки рабочей силы из-за токсичного рабочего места (которое они не смогли определить и решить).
Токсичные люди, как правило, плохо играют с другими, по крайней мере, с людьми, для которых они токсичны. Возможно, поэтому они токсичны.
Вообще говоря, лучше обойти токсичные элементы и вместо этого обратиться к стороне, которая лично не является частью токсичной культуры, лично затронута любыми проблемами, с которыми сталкивается команда разработчиков (или, по крайней мере, заботится о проблеме) , и способны оказывать давление на токсичные элементы.
Это может быть HR, если проблема заключается в нехватке рабочей силы из-за ухода людей или в неприемлемом поведении, таком как запугивание. Это может быть управление продажами, если токсичность вызывает задержки и сбои в доставке. Это может быть генеральный директор, если токсичность вызывает всеобщие проблемы в компании.
Эскалация, эскалация, эскалация. Будьте готовы к тому, что ядовитые элементы будут откровенно лгать и утверждать, что проблема в другой стороне. Я не говорю, что они определенно будут лгать, я говорю, что нужно быть готовым, чтобы у вас были готовые контрдоказательства, чтобы опровергнуть их утверждения.
Никогда не упоминайте то, что у вас еще нет доказательств. Токсичные элементы, которым удалось избежать наказания за свое поведение, как правило, достаточно искусны в разборе всего, что их критикует, и полагаются на то, чтобы извлечь выгоду из сомнения; поэтому убедитесь, что ваш случай является железным и неопровержимо доказанным. Лучше подать небольшую, но верную жалобу сейчас, чем подавать огромную жалобу, в которой некоторые пункты списка являются необоснованными или неясными.
Если никто из тех, кто может оказать давление на ядовитые элементы, не верит вам, не хочет и не способен бороться с ядовитой культурой, то вряд ли вы найдете здесь решение. Мы говорим «токсичный», потому что он может непоправимо отравить окружающую среду, и если его никто не очистит, это может закончиться массовым выгоранием, низкой производительностью или массовым исходом разработчиков. Компании разорились из-за меньшего.
Предполагая, что ретроспектива, о которой вы говорите, проводится как с бизнес-сферой, так и с ИТ-командой, мой первый шаг — поговорить об этом со скрам-мастером или лицом, фасилитирующим эту ретроспективу. Видит ли этот человек те же проблемы, что и вы? Что они уже пробовали? Вы даже можете попытаться поговорить с другими членами команды один на один, но желательно, чтобы общекомандные проблемы обсуждались на ретроспективах со всей командой.
На позиции скрам-мастера я бы сосредоточился на двух вещах:
Только тогда вы должны попытаться исправить это. Пусть группа сама придумает надлежащие решения, которые они считают жизнеспособными и ценными, конечно, в идеале с помощью конкретных действий. Исправить это за один спринт/ретроспективу, вероятно, невозможно, так что не торопитесь и дайте команде не торопиться. Если ваши наблюдения верны, они, вероятно, уже давно сталкиваются с этой проблемой, поэтому не исправление ее в течение одного спринта не должно иметь большого значения.
Мне кажется, вы фокусируетесь не на той проблеме. Это проблема, что над людьми издеваются, в этом нет сомнений. Но настоящие вопросы заключаются в том, почему деловые люди сидят в ежедневных газетах. И почему ею руководят люди вне команды.
Вы не упомянули, каким agile вы занимаетесь, если это Scrum, Kanban или что-то еще. Я предполагаю либо Scrum, либо Kanban.
Ежедневно команда собирается вместе и внутренне синхронизирует усилия. И поднять вопросы, чтобы получить помощь. Стороны:
Никто другой не допускается. И PO даже не может задавать вопросы, он (она) там, чтобы поддержать команду, а не наоборот.
По какой-то причине это основное правило для ежедневных газет не соблюдается. Я думаю, что если сосредоточить внимание на том, как это влияет на команду, проблема исчезнет, если следовать надлежащим ежедневным заданиям.
Я думаю, что лучший способ получить полное решение или решения - это
сначала осознайте проблему
. Итак, я предпочитаю в качестве первого шага провести анализ первопричины проблемы. Потому что иногда мы сталкиваемся с некоторым поведением, которое является результатом других действий, мы даже не знаем их источника.
Поэтому постарайтесь узнать свою команду, связанные заинтересованные стороны и другие стороны, чтобы найти основную причину проблемы.
После обнаружения основной причины или причин рассмотрите Agile-манифест как основу для решения проблемы.
Я думаю, что некоторые из приведенных выше ответов имеют очень радужный взгляд на ретроспективу, которую трудно получить правильно в самых лучших обстоятельствах, но в среде, подобной описанной выше, она не может работать. Если так относятся к людям, ретроспектива не является безопасным пространством.
Проблемы, с которыми вы имеете дело, гораздо более фундаментальны и не будут решены путем их открытого обсуждения в групповой обстановке. Такой подход, скорее всего, провалится.
Я согласен с другими ответами, что, конечно, нормально поднять некоторые конкретные проблемы в ретроспективе и посмотреть, можно ли их решить или исправить. Ответ, который вы получите на них, уже во многом подскажет вам, стоит ли поднимать там более фундаментальные вопросы.
Что вы должны сделать? Скорее всего, вам придется поработать над своими отношениями с руководством обеих групп и общим руководством, которое у вас есть, и поднять этот вопрос перед ними.
Поскольку нам рассказывают только одну сторону истории, а вопросы травли часто субъективны (в равной степени возможно, что кто-то действительно издевается, поскольку у другого человека тонкая кожа, и ему нужно научиться воспринимать критику) , трудно дать беспристрастный ответ на этот вопрос. Итак, я собираюсь дать 2 ответа, и вы можете выбрать любой, какой вам нравится:
Одна из возможностей состоит в том, что это на самом деле издевательство. Это не нормально. Однако, как разработчик, «моральный дух команды» на самом деле не является вашей обязанностью, и все это знают. Если вы пойдете к другой команде, или к их боссу, или к кому-то еще и скажете: «Моей команде это не нравится», вас не воспримут всерьез. Вам нужно подняться по своей собственной цепочке команд к людям в вашей цепочке, которые несут ответственность за такого рода вещи. Скорее всего, это будет ваш непосредственный руководитель или, возможно, их непосредственный руководитель; Вам не нужно заходить слишком далеко. Если они не присутствуют на собраниях, на которых возникают эти проблемы, сообщите им, что есть опасения (и что это за опасения, вы можете повторить то, что вы написали здесь), и попросите их присутствовать на собрании, чтобы наблюдать в следующий раз. Если они уже присутствуют на собрании и знают о проблемах, подчеркните, что это вопросы, которые вы хотите решить; может случиться так, что ваш менеджер не знает, что эти комментарии вызывают проблемы, и думает, что все в порядке, поэтому дайте понять, что это не нормально и нужно что-то делать. В этот момент, если ваш менеджер отказывается что-то с этим делать, возможно, пришло время найти нового менеджера. Конечно, если вся команда разработчиков уволится из-за обращения с ними руководства проекта, то PM быстро окажутся в затруднительном положении, так как у них нет людей для выполнения задач; по крайней мере, теперь они могут сказать, что задачи выполняются, но не в соответствии с требованиями, но если все просто встанут и уйдут, у них не будет и этого. Так что в интересах всех решить эту проблему, не теряя при этом всей команды разработчиков. может случиться так, что ваш менеджер не знает, что эти комментарии вызывают проблемы, и думает, что все в порядке, поэтому дайте понять, что это не нормально и нужно что-то делать. В этот момент, если ваш менеджер отказывается что-то с этим делать, возможно, пришло время найти нового менеджера. Конечно, если вся команда разработчиков уволится из-за обращения с ними руководства проекта, то PM быстро окажутся в затруднительном положении, так как у них нет людей для выполнения задач; по крайней мере, теперь они могут сказать, что задачи выполняются, но не в соответствии с требованиями, но если все просто встанут и уйдут, у них не будет и этого. Так что в интересах всех решить эту проблему, не теряя при этом всей команды разработчиков. может случиться так, что ваш менеджер не знает, что эти комментарии вызывают проблемы, и думает, что все в порядке, поэтому дайте понять, что это не нормально и нужно что-то делать. В этот момент, если ваш менеджер отказывается что-то с этим делать, возможно, пришло время найти нового менеджера. Конечно, если вся команда разработчиков уволится из-за обращения с ними руководства проекта, то PM быстро окажутся в затруднительном положении, так как у них нет людей для выполнения задач; по крайней мере, теперь они могут сказать, что задачи выполняются, но не в соответствии со спецификациями, но если все просто встанут и уйдут, у них не будет и этого. Так что в интересах всех решить эту проблему, не теряя при этом всей команды разработчиков. все в порядке, и что-то нужно сделать. В этот момент, если ваш менеджер отказывается что-то с этим делать, возможно, пришло время найти нового менеджера. Конечно, если вся команда разработчиков уволится из-за обращения с ними руководства проекта, то PM быстро окажутся в затруднительном положении, так как у них нет людей для выполнения задач; по крайней мере, теперь они могут сказать, что задачи выполняются, но не в соответствии со спецификациями, но если все просто встанут и уйдут, у них не будет и этого. Так что в интересах всех решить эту проблему, не теряя при этом всей команды разработчиков. все в порядке, и что-то нужно сделать. В этот момент, если ваш менеджер отказывается что-то с этим делать, возможно, пришло время найти нового менеджера. Конечно, если вся команда разработчиков уволится из-за обращения с ними руководства проекта, то PM быстро окажутся в затруднительном положении, так как у них нет людей для выполнения задач; по крайней мере, теперь они могут сказать, что задачи выполняются, но не в соответствии со спецификациями, но если все просто встанут и уйдут, у них не будет и этого. Так что в интересах всех решить эту проблему, не теряя при этом всей команды разработчиков. тогда ПМ быстро окажутся в тупике, так как у них нет людей для выполнения задач; по крайней мере, теперь они могут сказать, что задачи выполняются, но не в соответствии со спецификациями, но если все просто встанут и уйдут, у них не будет и этого. Так что в интересах всех решить эту проблему, не теряя при этом всей команды разработчиков. тогда ПМ быстро окажутся в тупике, так как у них нет людей для выполнения задач; по крайней мере, теперь они могут сказать, что задачи выполняются, но не в соответствии со спецификациями, но если все просто встанут и уйдут, у них не будет и этого. Так что в интересах всех решить эту проблему, не теряя при этом всей команды разработчиков.
Теперь также возможно, что предпосылка вопроса преувеличена. Вы не привели прямых примеров того, что было сказано, а только сказали, что некоторые комментарии были «пассивно-агрессивными». Вы также сказали, что некоторые из сделанных замечаний действительно заслуживают внимания, что совершаются ошибки. Теперь, поскольку выше я защищал вашу позицию от команды премьер-министра, теперь я собираюсь защищать команду премьер-министра от ваших обвинений, просто чтобы быть справедливым. Если ваша работа не соответствует ожиданиям, вам нужно поработать над этим. Я предполагаю, что это не первая встреча, на которой команда PM подает жалобы; если они должны постоянно приходить к вам и постоянно жаловаться на одно и то же снова и снова, и это никогда не исправляется, что ж, это вызывает разочарование. Это не оправдание намеренно запугивать кого-то, но иногда просто говорят вещи, которые, возможно, не должны быть сказаны или не должны быть сказаны так, как они есть. Также возможно, что вещи считаются «пассивно-агрессивными», хотя на самом деле таковыми не являются, например, если ошибка указана как высокоприоритетная, а затем ее не исправляют, а затем она каскадом переходит в другую ошибку, а затем команда PM может сказать: «Ну, мы пометили это как высокий приоритет по какой-то причине»; для некоторых людей это может быть «пассивно-агрессивным», для других - нет. Тем не менее, это верное утверждение: если бы вы исправили первую ошибку как высокоприоритетную, то каскадной ошибки не произошло бы, и команда PM действительно сказала вам, что она имеет высокий приоритет, а вы пропустили мяч, так что у них как бы есть право расстраиваться. В этом случае вам нужно восстановить доверие между вашей командой и командой PM; PM считает вас некомпетентным, и они более или менее говорят это вам в лицо. Жалоба на это руководству, если вы последуете приведенному выше совету, не решит проблему. Если вы обратитесь с такой проблемой к руководству, они скажут: «Команда PM говорит вам, что вы некомпетентны, и, основываясь на показателях XYZ, мы согласны с ними, так что исправляйтесь, или мы вас уволим», и это если вам повезло и вас не уволят на месте.
Сделайте шаг назад и подумайте о ситуации логически: если вы отстранитесь от непосредственной ситуации, когда вы находитесь в одной команде и склоняете свое мнение к вашей «своей группе», считаете ли вы более вероятным, что команда менеджеров проектов ведет себя воинственно? нет причин, или вы считаете, что ваша команда постоянно проигрывает и дает команде PM повод злиться на вас? Уделите минутку, поразмышляйте над этим вопросом, и пусть он направит ваши следующие шаги.
Я собираюсь предположить, что предыстория этой ситуации примерно такая:
Это не поправимо.
Причина в том, что ваша компания, как и многие другие, не понимает, что это такое. Это больше не компания, которая продает физические продукты; это компания, которая производит программное обеспечение, позволяющее продавать физические продукты. Другими словами, ИТ — это не вспомогательное оборудование вашей компании, а ее ядро. Но руководство этого не понимает или не хочет признать. И пока это так, с ИТ по-прежнему будут обращаться как с рыжеволосым пасынком, и отношения между этим отделом и другими отделами никогда не смогут восстановиться.
Даже если бы у руководства действительно было прозрение, скорее всего, ничего не изменилось бы. Когда уровень доверия настолько низок, требуются огромные усилия, чтобы восстановить его; например, неправильных людей нужно перевести на другие должности или уволить, а правильных людей нужно нанять, дать им мандат на то, чтобы встряхнуть ситуацию, чтобы решить проблему, и на самом деле дать им полномочия для обеспечения выполнения этого мандата. Для большинства компаний это слишком длинный мост.
Итак, что касается вашего вопроса, нет : ничто из того, что вы можете сказать или сделать, не окажет существенного влияния на структуру компании и, следовательно, на отношение к ИТ. Вполне вероятно, что вы покажетесь менеджменту как высокий мак , которого нужно срубить, если вы не сможете соответствовать дисфункциональной динамике компании. Если вам это не нравится, ваш единственный выход — найти другую работу.
мотосубацу