Как я могу заставить социально неуклюжую команду, которой не хватает хороших навыков межличностного общения, общаться более эффективно? [закрыто]

Я управляю социально неуклюжим коллективом, и это приводит к проблемам в общении.

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

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

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

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

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

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

Итак, главное, что мне нужно, — это более эффективное взаимодействие команды.

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

Я много раз говорил своей команде о повышении нашей заметности, о том, чтобы поговорить с другими членами команды и больше общаться в офисе, чтобы улучшить отношения.

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

Обновлять

Социальные мероприятия обычно происходят в рабочее время. Я могу думать только о событиях на Рождество, когда общественные мероприятия происходили в нерабочее время. Для каждого социального мероприятия люди в офисе решают, что в целом должно произойти: компания никому не навязывает случайные социальные мероприятия.

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

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

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

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

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

Комментарии не для расширенного обсуждения; этот разговор был перемещен в чат .
Я думаю, что недавнее обновление перенесло вопрос с территории «Пожалуйста, помогите мне» на «Пожалуйста, скажите мне, как заставить моих коллег действовать точно так же, как я, практически без каких-либо усилий с моей стороны для компромисса ... это не по теме».
@Lilienthal Почему вы перенесли уточняющие вопросы в чат? Люди просто будут задавать те же уточняющие вопросы, которые уже были заданы.
@user70848 user70848 Потому что в большинстве этих комментариев задавался вопрос, чтобы скрыть ответ. Обычно я восстанавливаю комментарии, в которых задаются полезные вопросы, но не всегда, и когда ОП не отвечает на какие-либо комментарии, это является дополнительным фактором.
Для записи решает команда, работающая над событиями. Возможные варианты: PTO или Посещение мероприятия. Проработать событие не вариант. Отсутствие запроса PTO и неявка на мероприятие приравниваются к отказу от вызова и неявке.
Может кто-нибудь пояснить, что именно не так с вопросом? Я вижу в этом несколько неправильных вещей, потому что я думаю, что предпосылка неверна: команда не бесполезна и, вероятно, не является социально неуклюжей. Но даже в этом случае ответы на подобные вопросы могут оказаться полезными. Чтобы лучше помочь другим понять образ мышления разработчика и то, что нам нужно для хорошей работы. Это полезно для всех. Так зачем закрывать такой вопрос? (не критикую, просто спрашиваю)

Ответы (13)

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

В качестве примера я приведу упражнение, которое я составил, управляя командой разработчиков. Я сделал несколько наборов танграмов из бумаги, и для каждого свой шаблон. Я разбила всех на небольшие команды (2-4 человека) и вручила им выкройку и блокнот. Их работа заключалась в написании инструкций (только текст, без графики) для того, чтобы кто-то построил шаблон, на который они смотрели. У них было около 15 минут, чтобы подготовить свои инструкции.

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

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

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

Это так унизительно, имхо, относиться к взрослому как к ребенку, кто-то может обидеться и уйти, есть причина, по которой требование может достигать 100 пенсов, требовать много итераций, и даже тогда оно все еще было плохим и несовершенным.
Возможно, это вопрос презентации. Цель состояла в том, чтобы подчеркнуть трудности написания и последующего следования таким инструкциям, а также обосновать открытое общение между всеми уровнями как во время сбора требований, так и во время реализации. Все, с кем я делал это, находили это в какой-то мере поучительным и уходили с немного большим уважением к тем, кто обычно находится на противоположных концах процесса. Что касается проблемы ОП, она также вытащила людей из их раковин и пообщалась с людьми, которые обычно просто имена в электронной почте с точки зрения их повседневной жизни.
Это случилось со мной. Я больше там не работаю.
Если вы пытаетесь интерпретировать документы с требованиями при прямом взаимодействии, документ с требованиями не соответствует цели и вместо этого должен быть составлен кем-то компетентным. Я имею в виду, что это буквально то, для чего этот документ.

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

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

Давайте начнем с этого. Это обсуждалось на Рабочем месте раньше, но только потому, что ваши сотрудники не хотят жертвовать своим свободным временем бесплатно, чтобы тратить больше времени на дела, связанные с работой (например, на «общественные мероприятия», которые вы упомянули, которые я буду считать рабочими… связанные события) не означает, что им «не хватает хороших навыков межличностного общения». Похоже, вы лично осуждаете людей, которые могут быть не такими экстравертами, как вы, и я думаю, вам нужно срочно избавиться от этой привычки.

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

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

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

Вы не можете улучшить коммуникацию, набивая людей, как скот. Неудивительно, что ваша команда чувствует себя переполненной и ворчливой. Дайте им пространство для работы.

Раньше в офисе было очень тихо

Они работали. Это включает в себя размышления, а не только постоянные разговоры.

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

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

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

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

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

Я много раз говорил своей команде о повышении нашей заметности, о том, чтобы поговорить с другими членами команды и больше общаться в офисе, чтобы улучшить отношения.

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

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

Кажется, что избиение команды палкой и заявление о том, что это должно произойти, не решили проблему.

Да, смешно.

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

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

Я ценю ваши комментарии о плохих сообщениях об ошибках. Менеджер должен бороться за свою команду, поддерживая их усилия по поощрению других команд к документированию этапов воспроизводства, таких как функционирующие люди. Хорошо, я, возможно, преувеличил, но вы поняли идею. Это заставляет меня задаться вопросом, являются ли эти разработчики единственными здравомыслящими людьми в компании.
@msouth В настоящее время это тоже мое мнение. Я понимаю, что мой ответ выглядит крайне негативным в отношении ситуации, но я не буду лгать — кроме того, нам повезло, что мы можем что-то с этим сделать!
Да, да, ДА! Вопрос здесь — прекрасный пример того, как менеджер применяет фиксированное представление об идеальной сцене, которое не соответствует цели. Правильная цель этой команды — «осуществить высококачественную разработку программного обеспечения», а не «создать дружескую социальную атмосферу», как кажется, в центре внимания спрашивающего. (Примечание: термин «идеальная сцена» полностью определен в бесплатном саентологическом курсе по технологии правильных расследований .)
Это прекрасный пример старомодного менеджмента, который считает, что все должно решаться путем разговора. Технические специалисты так не работают. Технические специалисты ценят письменные надлежащие правовые процедуры, чтобы получить максимальную отдачу от рабочего дня, а также иметь письменный отчет о процедурах. В качестве бонуса, это в интересах всех. К сожалению, руководство динозавров этого не понимает и скорее просто небрежно проложит себе путь. В наши дни разработчики могут пойти практически куда угодно, поэтому руководству следует быть осторожным, пытаясь заставить технических специалистов работать как буйные продавцы.
Я почти хотел создать 20 аккаунтов, чтобы проголосовать за это. Для кого-то вроде меня, пытающегося управлять командой с позиции не-менеджера, это очень помогает.
Дополнительные преимущества использования системы для сообщения о проблемах включают точную информацию, повышенную эффективность и запись, которую может увидеть каждый. Получить точную техническую информацию при вербальном общении сложно. Разговор использует время двух людей без необходимости. Болтовня о чем-то также держит это только между этими двумя людьми. Написание чего-либо в системе дает вам более качественную информацию, которая достигает большего числа людей и сохраняется вечно, и все это с меньшими затратами труда.
На самом деле. В нашей организации остался практически только один несогласный, которого мы, похоже, не можем научить сообщать о проблемах по электронной почте с указанием доказательств и подробностей — он старомодный и предпочел бы просто вальсировать в офис и сказать «есть ошибка», ожидая, что все это сделают. бросьте все, что они делали, чтобы пройти по коридору и исследовать это на месте. Он не обладает властью, но, поскольку в наших интересах исследовать новые ошибки в нашей продукции, мы должны подчиниться. Меня раздражает прерывание и отказ принять процесс, но я рад, что это редкость здесь; все остальные научились.
@AnoE: Это не «оскорбительный тон», хотя мне очень жаль, что вы так себя чувствуете. Здесь также нет никакого «сарказма» и никаких предположений - я прямо процитировал утверждения из ОП, к которым я отношусь. Я никогда не говорил, что вопрос бесполезный (я даже не обсуждал качество вопроса) и никого не называл глупым. Есть много "конкретных советов". Ваш комментарий полон абсурда. Я приглашаю вас ознакомиться с правилами сайта о добросовестности. Вы также, конечно, можете написать свой собственный конкурирующий ответ. И, кстати, пишется «заслуга».
Нет, я действительно не знаю, что здесь взорвалось, но я посмотрю в другом месте, @LightnessRacesinOrbit.
Это великолепный совет. И откровенно, но конструктивно, а не оскорбительно. особенно «То, что ваш босс теперь высказал ту же критику, не означает, что критика обоснована… ваш босс (который еще более удален от мира разработчиков)».
@aquirdturtle: Допусти добросовестность и прочитай это так, как если бы это было сказано со смехом, а не с вилами в руках. Тогда прекратите подходить к ответам людей и называть их «ехидными и снисходительными», что является ехидным и снисходительным.
«Мне посчастливилось работать из дома половину недели, и я не могу представить себе, чтобы делать даже 20% того, что я сейчас делаю, если бы мне приходилось мириться с людьми, постоянно «подшучивающими» вокруг меня в течение дня». Теперь случай, к сожалению, и мой прогноз был точен. :(

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

Итак, по вашим пунктам -

[...] Я заметил, насколько тихой была команда и как неохотно они хотели общаться с другими в офисе.

Это означает , что у них есть общее базовое поведение как команды . В качестве естественного результата я предполагаю, что проблем с коммуникацией внутри команды нет : они появляются только тогда, когда этой команде необходимо сотрудничать с другими командами с другой динамикой. Сотрудничество внутри команды, если оно существует и является естественным, является преимуществом. Работайте с ним.

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

И так же работают другие ИТ-команды по всему миру — я бы даже осмелился сказать, что большинство из них, если принять во внимание мой личный опыт; такие инструменты, как Slack, Google Hangouts и им подобные, естественны для них .

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

[...] они мало интересуются общественными мероприятиями и часто избегают общения с другими командами из-за своего поведения.

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

Мое личное мнение, что, находясь близко друг к другу, я надеялся, что проблем с общением не будет.

Спросите их , как бы они предпочли настроить среду. Это может привести к ценной информации.

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

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

Итак, главное, что мне нужно, — это более эффективное взаимодействие команды.

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

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

С другой стороны, команда QA могла бы предоставить более качественную информацию: некоторые решения для тестирования позволяют, например, делать снимки экрана — но в 99% случаев требуется просто дополнительное усердие в описании сценария, чтобы помочь команде разработчиков выяснить возможные причины .

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

Я много раз говорил своей команде о повышении нашей заметности, о том, чтобы поговорить с другими членами команды и больше общаться в офисе, чтобы улучшить отношения.

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

Еще один момент, связанный с предпочтением текстовых методов общения, заключается в том, что они обеспечивают простой способ вернуться назад и посмотреть, что было сказано . По моему опыту, это может быть чрезвычайно ценным в любом количестве сценариев реальной жизни, особенно если графики плотные. Им также можно поделиться; даже если другой человек изначально не участвовал в обсуждении (по какой-либо причине), легко переслать электронное письмо всей команде или вставить его в систему отслеживания проблем, в результате чего вся команда будет иметь одну и ту же информацию. За исключением (письменных) заметок, это просто непрактично при общении с другими.
В целом отличный ответ и +1 от меня. Просто добавлю: «Я бы предложил выбрать кого-то, кто будет служить связующим звеном между технической командой и остальной частью компании» . Это менеджер. Это буквально их работа.
Бесконечно лучше попросить их выбрать рабочий процесс, процесс обработки ошибок, планировку офиса и т. д., который лучше соответствует их стилю общения и личностям, а не наказывать избиениями «и говорить, что это должно произойти». Гораздо больше шансов на успех, дайте им почувствовать, что они имеют влияние и что вы на их стороне, а не критикуете их регулярно, как в лицо, так и в адрес босса.

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

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

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

В каждой компании, в которой я работал последние 20 лет, разработчики обычно сводят общение с неразработчиками ( и вообще ) к минимуму. Но если мы не общаемся с пользователями и заинтересованными сторонами, как мы можем гарантировать, что оправдаем ожидания и предоставим удовлетворительный продукт? Как их менеджер, вы должны помочь вытащить их из их скорлупы.

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

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

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

Вы также можете добавить критерии приемки в свой процесс разработки. Убедитесь, что вовлеченный разработчик общается с пользователем, чтобы быть на 100% уверенным, что он понимает критерии.

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

И, наконец, взгляните на реализацию той или иной формы Agile-процесса. Опять же, это заставит ваших разработчиков общаться с вашими пользователями и заинтересованными сторонами.

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

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

Вы бы избили пострадавшего от инсульта, потому что он не ходил? Социальные навыки - это НАВЫКИ , как и любые другие, и им нужно учиться .

Вы подходите к этому на 100% неправильно.

Сфокусируйтесь на решении, а не на проблеме

Вам нужно, чтобы команда общалась. Решение состоит в том, чтобы НАУЧИТЬ ИХ

  1. Подавайте пример: учите их, делая и предоставляя им образец для подражания/наставника.
  2. Отправляйте их на занятия: индустрия самосовершенствования существует не просто так. Также существует множество книг, таких как «Как завоевывать друзей и влиять на людей» или «Семь привычек высокоэффективных людей», которые ОТЛИЧНО помогают развивать социальные навыки и добиваться успеха.
  3. Подержите руки. ИТ-специалисты в целом склонны быть неуверенными в себе в социальном плане, и их техническое мастерство — это то, в чем они проявляют себя. Люди избегают вещей, которые неприятны, и многим техническим специалистам неудобно общаться с другими людьми. Вам нужно будет взять их за руки и показать им некоторые ОЧЕНЬ БАЗОВЫЕ навыки, которым вы, вероятно, думаете, что никогда не должны никого учить. Угадай, что? Вы делаете
  4. Выявляйте препятствия и преодолевайте их: скорее всего, в вашей команде есть хотя бы один человек с аутизмом и, возможно, другие трудности, которые нужно преодолеть. Узнайте, с чем вы имеете дело, и адаптируйте свой подход к этому.
  5. Подойдите к этому как к НЕДОСТАТОКУ НАВЫКОВ , а не как к проблеме отношения.

Когда я перечитываю ваш вопрос, я вижу основную проблему, исходящую от вас, и, возможно, вам следует взять некоторые книги Дейла Карнаги для себя. Все в вашем вопросе касается того, чего ВЫ хотите и что ВЫ ДУМАЕТЕ , и никакого отношения к вашей команде. Вы настраиваете себя на неудачу!

Поймите свою команду: вы упомянули шум. Это одна из самых частых жалоб на этот стек, особенно от ИТ-специалистов. ВЫ можете видеть в этом больше связи, но ваша команда и большинство технических специалистов этого не видят. Когда вы пытаетесь сосредоточиться на продвинутых алгоритмах, болтовня в комнате отвлекает вас. Если вы хотите больше общения, выделите для этого время. Вы упомянули, что, по вашему мнению, сближение поможет команде сблизиться. Это не сработало, но вместо того, чтобы переосмыслить свой подход, вы думаете о том, что с вашей командой что-то не так.

ВАМ НУЖНО ДУМАТЬ С точки зрения того, ЧТО НУЖНО ВАШЕЙ КОМАНДЕ, А НЕ ТОГО, ЧТО ВЫ ЖЕЛАЕТЕ, ЧТОБЫ БЫЛО ИСТИННО

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

Начните с решения собственных проблем, перестаньте делать предположения и СЛУШАЙТЕ СВОЮ КОМАНДУ

Затем следуйте совету выше.

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

Вы работаете с умными людьми, чьими сильными сторонами являются решение проблем. Заставьте это работать.

  1. Для каждого запроса об ошибке, который не повторяется, как они собираются сообщить вам, что они связались с человеком и обсудили проблему дальше?
  2. Как это отслеживается? Если вы собираетесь ставить измеримые цели, вам нужен способ вести счет.
  3. Что такое разумное время отклика? Ни одна команда не может сделать все сразу, если вы не укомплектованы полностью. Установка некоторого ограничения по времени может помочь им справиться со своей нерешительностью.
  4. Что должно произойти, если они достигнут цели или не достигнут цели? Все любят награды, и ваша команда не исключение. Пусть они что-нибудь придумают, а потом посмотрим, сможет ли компания это реализовать.

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

@IDrinkandIKnowThings - Спасибо за отзыв. Я попытался смягчить это, сосредоточился и разработал план поведения.
Удалил мой голос против. Это читается гораздо менее суровым ИМО.
@MisterPositive — ценю вашу переоценку.
Я на самом деле проголосовал за него ;-) Вы хорошо поработали над редактированием IMO.

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

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

Я думаю, что, возможно, стоит пересмотреть все текущие процессы коммуникации с вашей командой. Как ваша команда общается друг с другом? Как они общаются с другими отделами и по каждому типу запросов, которые им адресованы? Что их раздражает в этих системах связи? И что раздражает другие отделы в попытках связаться с вашей командой? Как только вы узнаете текущие процессы коммуникации с вашей командой и от нее, вы сможете найти способы улучшить процессы, и это ключевой момент: способы, которые принесут пользу обеим сторонам, если это возможно, но в первую очередь принесут пользу вашей команде.

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

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

Я думаю, что команда разработчиков, которая предпочитает кодить, а не общаться с людьми, оценит любые улучшения коммуникации, которые вы сделаете, что позволит им тратить меньше времени на общение с другими отделами. После того, как вы сократите 95% ошибок, которые нужно было отправить обратно из-за того, что они недостаточно детализированы, они будут более охотно говорить с QA, что однажды это действительно странная ошибка, которая просто не будет сотрудничать. Важно сначала работать со своей командой; облегчите их жизнь, прежде чем просить их измениться, и просите их измениться только таким образом, который действительно необходим для эффективного делового общения.

Замечание по поводу 2-го типа общения, типа "мы тут все дружные" - вы не собираетесь превращать кого-то в офисного стеба, который не хочет им быть, и, возможно, вам будет обидно за попытку. Однако людям полезно иметь общий уровень комфорта при общении со своими коллегами. Основываясь на том факте, что ваша команда, похоже, не любит светские беседы, не связанные с работой, если вы хотите, чтобы они общались с другими, возможно, вы можете выяснить, будут ли они в порядке с некоторыми сеансами обмена знаниями с другими командами. . Вы можете спросить их, готовы ли они потратить час, чтобы поделиться некоторыми техническими знаниями с теми, кому это может быть полезно, или организовать какой-либо другой технический отдел, чтобы поделиться с ними некоторой информацией. Если это'

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

Они вообще не хотят быть офисными стебами или просто не хотят быть офисными стебами все время в рабочее время? Это другое.

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

У вас ошибочное представление о результатах такого расклада. Microsoft изучила это :

Исследователь Microsoft Эрик Хорвиц обнаружил, что работникам требуется в среднем 15 минут, чтобы вернуться к задаче, над которой они работали после того, как их отвлекли.

Джоэл Спольски уточняет :

Вот простая алгебра. Скажем (как, кажется, свидетельствуют данные), что если мы прервем программиста, даже на минуту, мы действительно потеряем 15 минут продуктивности. [..] Он может найти его, что занимает 30 секунд, или он может спросить Джеффа, что занимает 15 секунд. Поскольку он сидит прямо рядом с Джеффом, он спрашивает Джеффа. Джефф отвлекается и теряет 15 минут продуктивности (чтобы сэкономить Матту 15 секунд) .

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

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

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

Это видео Джоэла, оспаривающего преимущества открытых пространств, может быть ценным. youtube.com/watch?v=R1V8OUOb-Hw

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

Что касается неправильного обращения с ошибками, это серьезная проблема. Работа с ошибками — наименее забавная и, по большей части, неблагодарная задача в программировании. И неправильное обращение с ошибками стоит денег вовремя для тестировщиков, клиентов и других заинтересованных сторон, которые ожидают, что это будет исправлено. Это можно обвинить в неловкости, но на самом деле это просто лень и попытка уклониться от своих обязанностей.

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

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

1. Общение

Да, если в рабочее время проводятся мероприятия, спонсируемые работой, и ваша команда приглашена, и, что важно, на мероприятия собирается начальство, команда должна быть там. Неявка часто считается тем, что они:

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

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

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

2. Установите четкие ожидания.

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

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

Когда у вас будет встреча, вы должны дать понять, что, хотя их поведение было хорошим в прошлом, компания вносит изменения. Устное/лучшее общение теперь является частью их должностных инструкций. Их прежнее поведение больше не будет терпимо, потому что… причины. Если у вас нет этих причин, вам нужно получить их от вашего босса — и лучше, чтобы они были хорошими. Неразумно ожидать, что кто-то изменит свое поведение из-за чьих-то субъективных мнений или любимых проектов. Если это так, они увидят это насквозь, и ничего не изменится.

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

Я подозреваю, почему ваша команда молчит, из-за боязни возмездия за ошибку или глупый звук. То есть у вас нет психологической безопасности на рабочем месте. На самом деле вы говорите о том, чтобы «бить их палкой». Я предполагаю, что ваша команда явно или неявно боится высказываться из-за негативного подкрепления в прошлом, либо из-за ошибки или непонимания с их стороны, либо из-за плохо определенных целей и ожиданий со стороны вас или других менеджеров. Я также подозреваю, что команда обеспечения качества также может давать отрицательное подкрепление; это потребует обсуждения того, как ваше рабочее место может улучшить психологическую безопасность в целом, а не только в вашей команде. Изучите «психологическую безопасность» для команд/рабочих мест.

4. Шум/офисный стеб.

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

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

5. «Мы хотим, чтобы команды сами определяли интерфейсы».

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


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

Это определение необходимости организационной психологии . То, что вы можете сделать для ее решения, минимально, а проблемы, которые вы можете вызвать, могут быть огромными. Как упоминает Снарк Найт , вполне возможно, что у вас есть хотя бы один человек в спектре аутизма, скорее всего, Арпергер (АС). И я держу пари, что у вас их больше одной, все, что вы упоминаете, похоже на книгу о СА.

С АС дело в том, что даже те, кто не относится ни к какому спектру аутизма, но может считаться пограничным, будут находиться под влиянием людей с СА, так что у вас есть что-то вроде снежного кома. Тот факт, что новые члены команды раздражают или что ваша команда не может воспроизвести ошибку и уж тем более не спрашивает тестировщика о шагах по ее воспроизведению, подтверждает это: AS может следовать инструкциям, но они действительно плохи, чтобы «выйти наружу» . коробка» . А их ресурс - замкнуться в скорлупе, типа "это можно сделать", отказ говорить или объяснять, мутизм, а иногда и неловкое поведение, особенно когда на него надавливают.

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

Наконец, это НЕ ВАША ВИНА. Даже не ваша ответственность. Попробуйте сначала поговорить со своим начальником, попробуйте связаться с отделом кадров, чтобы узнать, знают ли они о каком-либо известном сотруднике с синдромом Аспергера (у них может быть ASSQ или аналогичный тест).

Хорошая новость: как только вы узнаете, КАК работать с людьми с синдромом Аспергера, вознаграждение может быть огромным.

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

Я управляю социально неуклюжим коллективом, и это приводит к проблемам в общении.

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

  • Уничтожить команду. (Пусть они действуют как личности.)
  • Устранить неловкость
  • Исключите тот факт, что вы управляете ими.

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

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

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

и часто откладывают общение с ними других команд из-за их поведения.

Это вопрос разных ожиданий? Если это так, то руководство должно исправить это. Либо команда должна реагировать определенным образом, либо другие люди должны знать, чего они реально могут ожидать от команды.

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

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

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

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

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

Не делайте из этого то, чего вы хотите . Сделайте так, чтобы это было необходимо сотруднику.

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

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

Я много раз говорил своей команде... больше общаться в офисе, чтобы улучшить отношения.

Забудь это. Это не похоже на работу вашей команды. Не действуйте так неуместно, требуя чего-то, чего требовать не следует.

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

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

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

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

Я нашел этот ответ очень полезным, я думаю, что можно внедрить новые процессы, например, заставить разработчиков предоставить видео, показывающее работающую функциональность, если они собираются пометить ошибку как неспособную воспроизвести, это, по крайней мере, покажет их процесс в отношении тестирования, и в конечном итоге может помочь в предоставлении им отзывов, если это необходимо.
Что касается нежелания руководства вмешиваться, я думаю, что это, вероятно, тот случай, когда руководство не хочет принимать решения и хочет, чтобы команды сами решали, что должно произойти, и чувствуют, что в настоящее время это не так. Я не согласен с ними в том смысле, что считаю, что решения должны принимать мы, как менеджеры.
Меня учили, что самые эффективные лидеры почти ничего не делают каждый день. Они могли вызвать гольф <э-э, заболел>, и все равно все работало без сбоев. «Если вы хотите, чтобы у вас были последователи, дайте им задания. Если вы хотите, чтобы у вас были лидеры, дайте им обязанности». (Они сами изобретут способы добиться успеха.) Я восхищаюсь вашей реакцией на расширение идеи, обдумывая, как использовать ее в вашей среде. Видео, демонстрирующие работу функций, также могут помочь в обучении других команд, и такие видео также могут быть полезны для обучения других (например, клиентов)... Отличная идея!

Кажется, есть проблемы в техническом рабочем процессе ваших ошибок.

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

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

То, что команда обеспечения качества должна привлекать своего менеджера, неверно. На самом деле, в идеале репортер должен закрывать ошибку после того, как подтвердит, что она была исправлена.

Есть несколько способов исправить это: один — просто позволить команде QA повторно открывать закрытые ошибки. Или повторно открыть недавно закрытые ошибки. Вы также можете определить промежуточный статус, например «ожидание закрытия» или «требуется дополнительная работа по контролю качества». Другой способ — работать с полем владельца ошибки, чтобы разработчики прокомментировали там, что описания недостаточно, и назначили его обратно репортеру (баги, отнесенные к команде QA, будут как бы закрыты для статистики команды разработчиков).

Идти и говорить с тестировщиком - не правильное решение.

Конечно, иногда это будет очень полезно. Но в других случаях это будет пустой тратой времени обоими разработчиками на тестировщиках, например, тестер должен был заявить, что произошел сбой в 2:35, где X должен был быть Y, вместо того, чтобы ожидать, что разработчик сам заметит, что не так. просмотрев полное видео.

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

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