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