Хорошо, как лидерство, ваша работа - вывести проекты за дверь. Таким образом, вы должны быть тем, кто применяет стандарты, проверяет код, запрашивает отчеты о проделанной работе и все такое, когда разработчики предпочитают, чтобы вы оставили их в покое. Это всего лишь требования менеджмента, и, за исключением проверок кода, на самом деле навыки сотрудников не растут.
Однако вы хотите помочь им расти, что является отличным атрибутом лидера.
Обзоры кода, безусловно, являются первым шагом, они помогут вам увидеть, кто обладает не звездными способностями и нуждается в улучшении, чтобы иметь даже удовлетворительную производительность. Они помогут разработчикам увидеть другие способы сделать что-то и понять другие части кода, чем те, над которыми они лично работали. По моему мнению, рецензирование кода лучше всего проводить лично в конференц-зале с разработчиком и рецензентом (который должен быть другим разработчиком, когда это возможно, не всегда ведущим, рецензирование кода другого также является навыком, который необходимо развивать), и вы как модератор. Вы должны вести записи о том, что необходимо изменить, чтобы определить тенденции. То, что вы действительно ищете, это не ошибки или изменения (код каждого может быть улучшен), а постоянный отказ учиться на ошибках. Не говорите высшему руководству о том, что вы храните эти записи, иначе вы будете вынуждены использовать их в качестве показателей в процессе оценки эффективности, что откровенно противоречит цели. Если несколько разработчиков делают одни и те же ошибки, возможно, стоит заняться обучающей сессией или записью вики о том, как делать X.
Теперь о растущих недостатках, доходящих до минимального уровня. Во-первых, вы должны знать, какие наборы навыков имеют разработчики и какие наборы навыков было бы полезно, чтобы они имели, и что они могут быть заинтересованы в получении знаний. Вам нужно поговорить с ними, просмотреть их резюме и понять, что они любят и не люблю делать
Не давайте все интересные задания только самым опытным. Это не помогает другим быстро освоить новые проблемы и технологии. Вы не можете перейти от того, чтобы быть самым младшим парнем, получающим только самые маленькие и наименее важные задания, старшему парню, если кто-то не рискнет и не назначит вам более сложную работу. Тем не менее, для получения более продвинутых навыков, возможно, потребуется сначала назначить парного специалиста на менее опытного. Включение юниоров в обзоры кода также предоставит им более продвинутые методы.
Сначала дайте им шанс самим разобраться в проблеме. Но иногда люди застревают и не знают, с чего начать (навык, который вам также необходимо развить, особенно у начинающих программистов) или что делать, чтобы решить проблему.
Если вы дадите им пару дней на изучение чего-либо, а у них все еще нет направления, как они собираются что-то делать, то вам, возможно, придется вмешаться с некоторыми предложениями. Если вы технический специалист, вы можете дать им несколько идей о том, как решить проблему. Если нет, то встреча с несколькими людьми, на которой вы обсуждаете идеи, может помочь, если человек застрял. Или попросить более опытного человека дать несколько советов. Чего вы не хотите, так это отнять у них проблему и решить ее самостоятельно. Но вы должны сбалансировать выполнение проекта с эго программиста, и иногда вам нужно отправлять их в определенном направлении. Если у него плохое решение, и его нужно исправить, худшее, что вы можете сделать, - это дать его кому-то другому, если вы не собираетесь уволить программиста.
Я видел плохих программистов, где кто-то другой должен исправить почти все, что они делают. Другие программисты возмущены этим и просто хотят, чтобы человек покинул их жизнь. Содружество плохого программиста приводит к уходу хороших программистов. Вы должны найти грань между умением играть и развлекаться. Если вы даете кому-то несколько шансов, и он или она никогда не поправляются, то ослабьте его или ее.
Для пожилых людей, которые уже компетентны в своих текущих навыках, все проще. Обычно вам просто нужно дать им возможность сделать что-то новое, и они запрыгивают и учатся этому. Просто убедитесь, что интересные возможности распространяются, и не все идут к Джо, чудотворцу, который может все исправить. Вы хотите закончить десятью Джо, а не одним.
Еще один способ развития навыков - еженедельная 1-часовая тренировка. Сделайте так, чтобы каждый разработчик отвечал за определенную тему. Это поможет им лучше общаться, заставит их глубже исследовать что-то и принесет пользу всем их исследователям. Некоторые темы должны быть назначены людям, которые не знакомы с этой темой, чтобы вынудить их приобрести некоторые знания в этой области, а некоторые должны быть назначены тем, кого вы знаете, как местные эксперты по этой теме. Темы должны представлять собой комбинацию вещей, в которых вы нуждаетесь, чтобы люди хорошо разбирались в ближайшее время или прямо сейчас, и некоторый охват новых технологий, которые вы не используете прямо сейчас, но люди интересуются, чтобы узнать, могут ли они быть полезными. Но каждому, включая самого младшего, должна быть назначена тема.
В зависимости от того, как выставляется счет вашим разработчикам (это сложнее в условиях выставления счетов клиентам), разработчикам обычно стоит иметь 4-8 часов в неделю для работы над личными проектами. Они будут рады сделать это. Лучшие люди захотят там работать и многому научатся, что пригодится в будущем. Для счетчиков компонентов трудно понять необходимость этого, но это время будет многократно окупаться удовлетворенностью сотрудников, новыми функциями или программным обеспечением, которые никому не нужны (или которые помогут автоматизировать некоторые трудоемкие задачи), и более быстрой разработкой из-за новые методы изучены. Некоторые разработчики будут использовать это время строго для личных проектов, не связанных с тем, что вы делаете (и это хорошо, они все равно будут приобретать навыки и радоваться этой возможности), но многие другие будут использовать его для решения постоянных проблем, которые из-за характера управления проектами кто-то успел решить заранее. Таким образом, вы можете получить рефакторинги, которые принесут пользу всем; некоторые люди могут написать тесты, чтобы улучшить охват тестами, чтобы упростить рефакторинг; другие могут исследовать некоторые новые функции, которые могут сделать ваше программное обеспечение более полезным для его клиентов. В общем, если вы можете убедить счетчиков бобов, нет никакого способа проиграть, предоставив им эту свободу.
Вы должны научиться балансировать, позволяя людям немного потренироваться в своих навыках и поддерживать проект в нужном русле. Чем менее опытен разработчик, тем больше кому-то нужно проверять прогресс, особенно на ранних стадиях, когда изменение направления легче. Неопытный может бороться и бояться говорить. Эти люди, как правило, уходят незадолго до запуска, и вы обнаружите, что их часть проекта еще далеко не завершена. Будьте особенно внимательны, чтобы проверять прогресс у всех, кто у вас часто менял работу (если только они не были подрядчиками, так как это характер контракта).
Как правило, более опытным людям можно доверять, чтобы они сообщали вам, когда у них возникают проблемы с поиском решения, и им нужна помощь от кого-то, кто обладает большими знаниями в этой области, или они пойдут искать этого человека и получат передачу знаний. Таким образом, их не нужно тщательно контролировать на начальных этапах изучения новых навыков для проекта. Они найдут способ доставить проект. Тех, у кого есть опыт доставки, обычно можно оставить в покое, за исключением отчетов о минимальном прогрессе (обычно вам также приходится отчитываться перед своим руководством и, следовательно, нужна некоторая информация).