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