Поток информации/знания в [закрытой] команде

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

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

1. Внутренняя утилита Твиттера-esque. Возможно, Wiki, если можно заставить это работать, я лично, находит его немного слишком много. Но Твиттер отличается. "просто добавленный метод расширения для выхода из подобного пункта в rowfilter" и материале как этот.

2. Некоторые люди могут найти его немного властным, но общее местоположение для утилит, таким образом, Вы знаете, где посмотреть и представить в виде строки. CountOccurrences не рассеивается всюду по кодовой базе.

Еще несколько вещей по моему мнению:

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

• Фактор культуры - Делает место работы, обеспечивают достаточно социализации, чтобы помочь команде образовать гель, или могли некоторые упражнения тимбилдинга, например, курс препятствия или готовящий вместе, быть полезными в получении некоторой установленной динамики. Есть ли смирение среди разработчиков так, чтобы не было больших эго, которые могут быть проблемой. Другой фактор здесь состоит в том, чтобы думать о том, как Вы ответили бы на это: Вы перешли бы к локальному пабу и выпили бы со своими поддерживающими товарищами по команде? Если да, то у Вас есть некоторые положительные стороны здесь, в то время как в противном случае затем может быть некоторое расследование, чтобы сделать здесь.

• Ретроспективное продолжение - Как идеи представлены во время ретроспектив, которые рассматривают и реализованный? Как встречи обрабатываются в целом?

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

Я добавлю еще много

• Наймите правильных людей - Это важно, если Вы хотите создать динамичное великое (необщительные люди требуют намного большего усилия),
• Pre-mortem и вскрытие. Мы используем Wiki для этого, создаем страницу для каждого из Ваших проектов, разделяем его на раздел повторяющихся вещей (оба товара и плохо). В конце каждого этапа сделайте, чтобы команда встретилась, чтобы сделать вскрытие. В конце проекта (или после продолжительности фиксации времени), сделайте, чтобы координатор проекта скомпилировал это во что-то легкое, чтобы читать для потомства (и поместить его на Вашу Wiki)
• Ежедневно стоячий необходимость! Вы уже сказали это, но я нахожу его настолько полезным!
• Если Вы имеете несколько команд в компании, организуете конференцию об одном из их самых больших успехов. Если бы возможно регулярно, даже accros отдел, Вы были бы удивлены, как художникам может быть интересно в работу программистов.
• Ланч является хорошим временем для совместного использования, в нашей компании у нас есть завтрак президента, ланч руководителей проекта, конец ужина проектов. Я люблю их всех, смешивание и подгонку для больших результатов.
• Удаленная встреча с целой компанией является большой, мы делаем это по крайней мере один раз в год (утро, мы представляем то, что подходит в futur, день, операции для приобретения знаний о проектах),
• Wikis являются большими, но остерегаются информации, которая может становиться ложью со временем (это - повторяющаяся проблема с любой записанной информацией),

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

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

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

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

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

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

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

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

Время.

Чиновник

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

Это также легко в бюджет: N разработчики переходят к встрече в течение часов T.

Неофициальный

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

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

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

Путь тяжелее к бюджету: разработчик Mary спросила разработчика Sophie о динамической связи в течение полутора часов. На следующий день она возвратилась с некоторыми вопросами. Опытные разработчики проведут больше времени, распределяя, в то время как моложе будет требоваться большее количество времени, учась.

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

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

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

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

• никакие стены - Не Имеют всех Ваших разработчиков в одной большой, неокруженной стеной комнате - где все видят и говорят друг с другом.
• общие цели - обеспечение Вашей команды имеет хорошее понимание целей ВКЛЮЧАЯ цель самосовершенствования
• вознаграждение - вознаграждающий - даже если ничто больше затем коммуникация - не укрепляет то, что Вы надеетесь выполнять

Национализация и общая цель всегда поощряют exchanege информации.