Как мне управлять командой с разными уровнями квалификации?

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

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

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

Примечание: во время ежегодного обзора не должно быть никаких сюрпризов.

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

Я также рекомендую использовать автоматизацию как можно больше:

• Заставьте команду использовать такой инструмент, как NDepend или Resharper, если вы находитесь в сфере .Net. Настройте стандартные правила, если они вам не нравятся.
• Автоматизируйте тестирование настолько, насколько это практически возможно.

Трудно спорить с неудачным тестовым набором или автоматическим средством проверки, если они настроены правильно.

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

Предполагая, что все останутся в команде, я рекомендую разбивать задания на небольшие куски (более крупные - более опытным парням), и пусть самые опытные разработчики рефакторируют, когда вы закончите. Удостоверьтесь, что запускаете QA в узких, регулярных интервалах. Это очень близко к тому, что происходит в реальности в любом случае.

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

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

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

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

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

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

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

Проводите постоянное и регулярное тестирование и проверку качества. Сообщите человеку как можно скорее, когда вы увидите несоответствия.

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

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

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

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

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

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

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

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

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

Когда вы видите дурную привычку или что-то, о чем они должны (все) знать, остановите все и начертите на доске.

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

Есть несколько разных списков, которые я хотел бы рассмотреть с вашей позиции:

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

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

В некотором смысле это все сводится к общению. Удачи!

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

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