Общение в команде (особенно по электронной почте) – открыто или закрыто по умолчанию?[закрыто]

https://stackoverflow.com/questions/672213

21-08-2019
|

Вопрос

Я достаточно опытный разработчик C# (около 5 лет опыта), который недавно был назначен руководителем моей первой команды разработчиков в качестве технического руководителя (в нее входили 3-5 других разработчиков).За последние 4 месяца на этой должности постоянно возникала одна дилемма: попытаться найти правильную степень информированности о общении, которое происходит между менеджером проекта, менеджером по работе с клиентами, клиентами, дизайнерами, генеральным директором и мной (особенно по электронной почте). .

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

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

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

Уф...так много всего нужно учитывать.У кого-нибудь есть мудрое руководство в этой области?

Решение

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

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

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

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

РЕДАКТИРОВАТЬ:На Домашняя страница Джоэла есть два раздела: «Технический руководитель» и «Менеджер программы».Посмотрите статьи там, чтобы получить дополнительную информацию о менеджерах программ, особенно Переключение задач человеком считается вредным.

Другие советы

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

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

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

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

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

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

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

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

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

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

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

Есть еще несколько веских причин не использовать CC или BCC для всех, независимо от вашей должности:

TO означает «принять меры», CC — «принять к сведению для дальнейшего использования», BCC — «подслушать или рассылать по электронной почте».Следует быть осторожным при использовании той или иной электронной рассылки группе людей:
- Отправка электронного письма одному человеку — это прямое «ТО», а электронное письмо группе людей — только «ТО» тем, кому вам нужно предпринять действия (включая простое подтверждение).Это значение по умолчанию, в любом другом случае явно сообщите им, что ожидается (т. е.К вашему сведению, никаких действий не требуется и т. д.).
- Копируйте только тех, кого вы хотите принять к сведению для дальнейшего использования.Если вы ожидаете, что несколько электронных писем будут отправлены туда и обратно, прежде чем будет достигнуто соглашение или проблема решена, не ставьте «Копия», лучше всего позже отправить сводное подтверждение другим сторонам, которых необходимо уведомить.Помимо экономии времени каждого и предотвращения неправильного толкования из-за того, что кто-то примет к сведению неокончательное сообщение, это поможет сделать обмен более личным, более естественным и сократить формализм и бюрократическую волокиту.Зачастую к письмам CC-d относятся формально и это не всегда хорошо (но иногда именно то, что нужно).
- Использование BCC почти всегда недопустимо.Информация о том, что кто-то подслушивает ваши разговоры, если станет известна, легко разрушит вашу надежность.Это просто вопрос «когда».И стоит ли тогда вашей команде беспокоиться о том, что вы можете передать их разговоры BCC кому-то другому?Массовая рассылка через BCC в большинстве случаев также ошибочна, она создает впечатление, что электронное письмо адресовано конкретно получателю.
Пересылка, CC и BCC требуют небольших усилий, но увеличивают шум и ослабляют сигнал.Прежде чем составлять сообщение, стоит подумать о том, что именно вам нужно от человека и что он должен знать, чтобы действовать в соответствии с вашим сообщением.
Некоторые разговоры лучше вести полностью «оффлайн» (по телефону или, еще лучше, лицом к лицу), потому что это дает вам больше места для маневра.Передавать или оформлять письменно – это все равно, что загонять себя в угол.Последнее вы всегда можете подтвердить письменно.

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

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

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

Определенно не создавайте культуру BCCing.

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

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

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

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

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

Я вижу этот вопрос через год после его публикации, однако могу добавить свой опыт с некоторыми конкретными данными для моего случая.Для 2-3 разработчиков в проекте я в основном работаю один на один.Часто я делаю это через мгновенные сообщения или по телефону, поскольку большая часть моей команды проводит много времени в домашнем офисе.Время от времени встречи неизбежны, в основном, когда проект запускается (1-2 встреч с разработчиками обычно бывает достаточно, чтобы начать достаточно сложный проект), но, как правило, все общение с остальной частью компании происходит через меня, и разработчики получают дайджест.Единственное исключение — когда я связываю разработчика напрямую с пользователем (а не с руководством!) для проработки деталей проекта.

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

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

Я обнаружил, что для команд из 4–8 человек (8 человек обычно означают две команды) коротких 30-минутных встреч примерно раз в неделю более чем достаточно, чтобы держать всех в курсе событий.Это, конечно, в дополнение к личным встречам, которые я провожу ежедневно для младших разработчиков и примерно два раза в неделю для старших разработчиков.

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

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

Также проводятся встречи между разработчиками, когда им нужно что-то согласовать (например, когда разработчику Java и Javascript нужно проработать детали интерфейса).

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

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

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow