Представьте, что вы унаследовали большую команду разработчиков и обнаружили, что в прошлом собеседования имели определенные недостатки, а некоторым членам команды не хватало определенных навыков. Это, безусловно, неправильная идея повторно собеседовать всех, так как это вызовет много ненужного беспокойства, но вам нужно сразу знать, кто хорош в написании кода, а кто нуждается в некотором обучении или не должен был быть нанят. И вы не можете позволить себе тратить время на изучение этого, просто глядя на индивидуальную производительность, поскольку на нее будет влиять технический долг. Что бы ты сделал?
Это очень широкий вопрос, который находится на грани того, чтобы быть не по теме, поскольку он слишком широк и является опросом общественного мнения. Сказав это, я был в этом положении, и это обескураживает.
Единственный совет, который я мог бы дать вам, это - Делайте. Ничего такого.
Худшее, что вы можете сделать в качестве нового менеджера существующей команды, — это ввязаться в очевидную охоту на ведьм, принимая поспешные решения и поспешные суждения о навыках и компетенциях людей.
Потратьте некоторое время. Никто не умрет. Просто оставьте все на некоторое время. Слушай и смотри. Посмотрите, что происходит и как все делается. Поговорите с людьми о том, что, по их мнению, необходимо сделать и в чем, по их мнению, команда сильна и слаба.
Через некоторое время должна начать формироваться картина сильных и слабых сторон как у команды в целом, так и у отдельных сотрудников. Затем вы можете сформировать план по смягчению этих проблем.
Я придерживаюсь точки зрения, отличной от Марва, и тире здесь. Сначала я бы оспорил вашу оценку вашей команды. Во-первых, ваше заявление о том, что в процессе собеседования были проблемы, предполагает отсутствие понимания прогностической достоверности процесса отбора. Во-вторых, похоже, вы не понимаете концепцию распределения производительности. В этой статье — Forbes — есть хорошая дискуссия по этому поводу.
Вывод здесь таков: с обычными проблемами, с которыми мы сталкиваемся в процессе отбора и кривой распределения, маловероятно, что вы создадите лучшую команду, если будете проходить процесс увольнения и найма снова и снова. Глядя на отдельных исполнителей в надежде, что вы сможете заменить этого человека кем-то лучшим, статистически говоря, вы практически ничего не получите.
Это не означает, что вы не должны ставить перед собой индивидуальные цели, внедрять хорошую программу обучения/наставничества или даже отсеивать худших исполнителей и заменять их, но ваше внимание должно быть сосредоточено на эффективности команды в целом, а не только на отдельных сотрудниках. выполнение работы, но также четко определенные, эффективные процессы и процедуры; документирование политик и правил; и инструменты, с которыми они работают - все возможности. Сосредоточение внимания только на предполагаемых отдельных исполнителях и игнорирование вероятных других факторов, препятствующих возможностям, практически ни к чему не приведет.
Я согласен с Марв. Слушайте, диагностируйте и, в конце концов, тщательно лечите план лечения.
Я был в такой ситуации и создал матрицу навыков, которая была разделена на доступные навыки и необходимые навыки (на основе текущих и ожидаемых будущих проектов).
Затем мы постепенно разработали план обучения и взаимного наставничества. Что касается навыков, которых нам совершенно не хватало, мы сосредоточились на этих навыках для новых сотрудников.
Я бы очень не хотел разрабатывать план личного улучшения для кого-то, у кого я не брал интервью, но есть определенные тактики, которые вы можете использовать, чтобы побудить соответствующего человека уйти.
Единственное изменение, которое я хотел бы реализовать очень быстро, — это процесс контроля качества для новых сотрудников, например, заставить их писать код, обеспечить широту и глубину знаний, а также их способность наставлять и подталкивать других членов команды.
Я вижу, что за последние несколько дней вы опубликовали несколько вопросов, поэтому я собираюсь сделать некоторые предположения, что они связаны — надеюсь, это правда. Похоже, что у вас есть несколько Agile-команд (в частности, Scrum), которые вы унаследовали, и, возможно, существует общее впечатление, что они недостаточно эффективны. Я определенно могу сочувствовать вашей ситуации.
Это также звучит так, как будто вам нужно точно определить, насколько хорошо или плохо идут дела, а затем внести изменения в команды к лучшему.
Мой опыт подсказывает мне, что опора на простые метрики или вторжение в команды, повторное собеседование или другие разрушительные (и откровенно боевые) подходы доставят вам больше проблем, как вы упомянули в своем посте.
Я бы порекомендовал публично удвоить свои ценности Agile и Scrum. Открытость, самоорганизация, предоставление ценности и техническое превосходство — все это то, за что команда может сплотиться, и это ставит вас и команды в один угол. Возможно, в командах или в организации есть какие-то плохие привычки, которые можно бросить вызов, посмотрев, как они воплощают (или не воплощают) эти ценности.
Это также даст вам некоторое представление о команде. Когда вы встаете и говорите: «Кто будет заниматься этим со мной?» вы получите некоторых людей, которые являются и некоторых, кто не является. Из тех, кто нет, некоторых просто нужно убедить. Им нужно видеть, как вы придерживаетесь этих ценностей, когда им трудно, и это вдохновит их поступать так же. Кстати, некоторые из них могут быть не очень хорошими программистами, но лично я предпочитаю младшего программиста, стремящегося к совершенствованию, а не старшего разработчика, который самоуспокаивается каждый день. Наконец, у вас может быть несколько человек, которые просто не заинтересованы в том, чтобы быть частью постоянно совершенствующейся, высокоэффективной команды — вы можете решить эту проблему с ними, как считаете нужным.
Нет хорошего простого ответа, если только вы не планируете отказаться от всей команды и начать все сначала — и даже это легко, не так уж и хорошо. Однако создание хорошей культуры и отношений с командами, безусловно, является самым важным первым шагом. Пока это не произойдет, вы больше ничего не сможете сделать.
В дополнение к другим мнениям и опыту, представленным здесь, я бы сказал, что «интервьюирование» людей может быть хорошей идеей, но, на мой взгляд, не с целью сортировки плохих яблок от хороших.
Во-первых, предостережение: любой вид интервью может быть очень хорошо воспринят одними, но очень плохо другими. Без какого-либо отношения к вам, вашим целям или даже к тому, насколько профессионально вы их подняли. У некоторых это вызывает страхи или другие странные реакции, у людей возникают иррациональные эмоции (это нормально) и это нужно учитывать, прежде чем вступать на этот путь.
Тем не менее, и хотя у меня были смешанные результаты от этой техники, я считаю, что «собеседование» с целью познакомиться с вашей командой, узнать сильные стороны каждого, является похвальной целью и может привести к некоторым отличным результатам. Не используйте его как палку, это повредит вам и вашему авторитету в команде. На самом деле, даже используя его с самыми чистыми целями, он все равно может вернуться и сильно укусить вас.
Это все вопрос восприятия, поэтому убедитесь, если вы собираетесь это сделать, что у вас есть поддержка вашего менеджера в отношении принципа, целей и способа. Также убедитесь, что вы правильно управляете сообщением, прежде чем начать, чтобы процесс был прозрачным, а преимущества были четко изложены.
С опозданием на несколько лет, но я согласен с другими участниками. Скажем прямо: здесь нет быстрого решения. Нет переключателей для щелчка. На знакомство с вашей командой потребуется время — на самом деле этот процесс может никогда не завершиться, потому что люди меняются в своих способностях и стремлениях.
Один из способов познакомиться с ними поближе — это проводить семинары для 5-10 человек одновременно, охватывая методы, которым вы хотите, чтобы ваша команда следовала; TDD, непрерывная доставка, рефакторинг, безопасное кодирование, что угодно. Даже если они уже в какой-то степени следуют им, нет ничего плохого в повторении, чтобы убедиться, что все по-прежнему говорят на одном языке. Семинары помогут вам определить, кто уже способен в какой-либо области знаний, кто способен учиться, а кто борется с конкретными концепциями. Это также поможет вам определить, кто проявляет готовность помогать другим, кто обращается за помощью, когда она ему нужна, и кто предпочитает работать в одиночку. Как лучше найти своих наставников?
Марв Миллс