Как вы помогаете своим коллегам-программистам расти?

Как руководитель команды, как вы можете помочь вашим программистам расти?

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

Но я не совсем знаю, как это сделать, я должен

1. Часто взаимодействовать с ними, или дать им тихое время, оставить их в покое?
2. Попросите их следовать правилам кодирования, таким как принудительное выполнение модульных тестов, стилей кодирования, или позволить им делать то, что они считают нужным?
3. Будьте снисходительны с ними. Таких, как на самом деле не волнует, действительно ли они приходят в офис на 8 часов или 4 часа, или нужно навязать некоторые "дисциплины" на рабочем месте?

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

Как вы думаете?

Это очень тонкая грань, по которой ты должен идти.

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

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

Прочитайте « Три этапа зрелости команды разработчиков» Роя Ошерова и посмотрите, сможете ли вы выяснить, на каком этапе находится ваша команда. Это должно повлиять на то, как вы действуете. Чем более хаотично, тем больше вы должны поставить элементы управления на место. например. В чрезвычайно хаотичной команде вы должны начать с просмотра всего принятого кода. Но пока вы это делаете, найдите время, чтобы научить их просматривать код друг друга.

И если вам удастся вытащить команду из Хаоса в Midlife, измените свое поведение в этот момент, иначе они не будут двигаться дальше (это из личного опыта).

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

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

Например, в нашей команде мы можем свободно определять задачи обучения для себя, если они так или иначе (прямо или косвенно) связаны с проектом. Эти задачи обычно занимают от нескольких часов до одного дня в спринте (хотя не в каждом спринте). (Недавний пример: я получил задачу изучить и поэкспериментировать с Scala, исходя из того, что это - и функциональный подход в целом - может помочь упростить сложную часть нашего Java-кода.) Затем они расставляются по приоритетам и планируются в Спринт, как и обычные задачи. Также предлагается и ожидается проведение демонстраций / лекций о том, что мы узнали, для передачи знаний другим членам команды (и, возможно, даже разработчикам в других командах).

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

При работе в команде необходимо следовать одному и тому же процессу разработки. Конечно, этот процесс должен быть самым простым, что может сработать, а не то, что описано в 600-страничном руководстве. И процесс должен быть определен и постоянно адаптирован к ситуации самим коллективом . Так что, если команда согласилась на стандарт кодирования и TDD, они должны ему следовать.

Будьте снисходительны с ними. Таких, как на самом деле не волнует, действительно ли они приходят в офис на 8 часов или 4 часа, или нужно навязать некоторые "дисциплины" на рабочем месте?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Дайте вашей команде сложную работу и инструменты для их решения. Даже если вы считаете свою работу обыденной, потому что вы просто поддерживаете устаревшую систему, заставьте всех сделать ее лучше.
2. Ваша команда должна разработать стандарты кодирования. Ваша задача - помочь им обеспечить соблюдение и адаптацию стандартов.
3. Работайте со своей командой, чтобы разработать систему оценки. Ваша задача - помочь координировать эти усилия с командой и обеспечить соблюдение. Внешние силы ожидают качественного кода своевременно, и у них не всегда есть разумная логика для своих запросов. Вы не можете избежать этого, но вы должны управлять обеими сторонами. Как только ваша команда создаст себе репутацию для достижения цели, все будут больше принимать ваши оценки времени. Они должны знать, что вы поддержите их, если они приложат усилия.

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

Часто взаимодействовать с ними, или дать им тихое время, оставить их в покое?

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

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

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

Будьте снисходительны с ними. Таких, как на самом деле не волнует, действительно ли они приходят в офис на 8 часов или 4 часа, или нужно навязать некоторые "дисциплины" на рабочем месте?

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

Относится к вашим трем пунктам:

Часто взаимодействовать с ними, или дать им тихое время, оставить их в покое?

Я скажу, что это действительно зависит от типа человека, с которым вы работаете. Некоторые предпочитают обсуждать в определенное время кофе (около 10 часов утра), а в остальном работать без помех. С ними (хорошо, я признаю, я точно такой) я обычно отправляю электронные письма (даже когда они рядом со мной, например, в 2-3 метрах), чтобы вы могли оставить им выбор, когда они читают вашу информацию , И, между прочим, не спрашивайте их, «получили ли они вашу заметку» :-) И, конечно, некоторым «нужно» больше руководства, больше взаимодействия.

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

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

Будьте снисходительны с ними. Таких, как на самом деле не волнует, действительно ли они приходят в офис на 8 часов или 4 часа, или нужно навязать некоторые "дисциплины" на рабочем месте?

Если вы уже знаете, как работают люди и уверены в себе, чем они не подорвут вашу уверенность, вы можете ослабить дисциплину. Но я думаю, что на данный момент правило (или не правило), которое вы определяете, должно применяться ко всем. Важно то, что не должно быть никаких исключений. В настоящее время я очень рад работать на менеджера проекта, который просто говорит: «Пока вы выполняете свои 40 работ в неделю и работа выполнена, все в порядке». Таким образом, вы можете прийти поздно утром, работать только 6 часов, а следующие два дня работать 9 часов. Это не имеет значения, "пока работа сделана". Мне нравится это правило.

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

Но я не совсем знаю, как это сделать, я должен

1. Часто взаимодействовать с ними, или дать им тихое время, оставить их в покое?
2. Попросите их следовать правилам кодирования, таким как принудительное выполнение модульных тестов, стилей кодирования, или позволить им делать то, что они считают нужным?
3. Будьте снисходительны с ними. Таких, как на самом деле не волнует, действительно ли они приходят в офис на 8 часов или 4 часа, или нужно навязать некоторые "дисциплины" на рабочем месте?

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

Обратной стороной этого было бы изучение философии личностного развития, хотя это может быть сложным путем, если кто-то анализируется неправильно. Если вам нужно несколько примеров таких философий, вы можете взглянуть на Myers-Briggs, Enneagram и Strengths Finder 2.0 для нескольких примеров.

Вы спрашиваете их, как они предпочли бы работать.
Что бы они хотели изменить и так далее.

Не все сразу. Так же ... как вещи обнаруживаются.
Оставайся естественным. (или они почувствуют запах страха)

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

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

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

Как и у любого президента, вы держите последнее слово: вето .
Остальное зависит от группы.

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

Если вам повезет, у вас будет один или два программиста, чьи личные стандарты «тестирования» более строгие, чем стандарты всего отдела. В этом случае вы можете поместить их в «систему чести» по этим вопросам или даже принять их методы.

С «гибким временем» вы можете позволить себе более продуктивную работу. Пока они выполняют свою работу, я бы меньше беспокоился об их часах. Некоторые люди приходят, вкладывают в 5-6 «непрерывных» часов и достигают большего, чем другие, которые вкладывают в 10 медленных часов.

Но одна из ваших обязанностей менеджера - исправлять слабости. То есть вам придется БЫТЬ ВНИМАТЕЛЬНЫ на небрежных программистах, чьи стандарты тестирования неадекватны, или на людях, которые недостаточно продуктивны - потому что они не тратят время.