В настоящее время я работаю менеджером проекта и техническим руководителем в очень небольшой команде, поскольку мы только начинаем. На данный момент я управляю примерно 6 людьми, и интеграция и общение между членами команды идут отлично. За исключением конкретного члена команды.
У этого человека есть некоторые привычки, которые иногда могут сильно раздражать остальных членов команды, включая меня. Одна из моих обязанностей — привести команду к новому рабочему процессу и техническому стеку, и мне это очень нравится, но я не могу тратить на это все свое время, так как мне еще нужно много чего спланировать.
Со всеми другими членами команды я могу научить их, откуда собирать информацию, или научить их основам чего-либо, и они могут с легкостью найти недостающие ссылки в Google/Stack Overflow, если я не могу помочь. .
Однако этот другой член команды (который должен быть разработчиком среднего уровня), кажется, никогда не сможет провести какие-то фундаментальные исследования. В первый раз, когда он сталкивается с проблемой, он жалуется, что никогда не делал этого раньше или что это технически невозможно (даже если иногда это просто вопрос следования документации).
Он не может изучить то, о чем я его прошу, а когда я прошу его изучить А, он возвращается, рассказывая о том, какие классные Б и В. Этот человек сильно переоценивает свои знания и способности к обучению. Около 60% времени он проводит за рабочим столом, а остальные 40% посвящены перекурам, переходам от стола к столу или случайным прогулкам по компании.
Каждый раз, когда я прошу его выполнить более сложную задачу, он говорит о том, что сдается и расстраивается, перебивает других членов команды, даже не углубляясь в изучение темы. Другие члены команды или я прихожу к нему на помощь и решаю проблему, иногда за считанные минуты. Имейте в виду, что другие члены команды также плохо знакомы с этим рабочим процессом, набором инструментов и техническим стеком (и имеют меньший общий опыт разработки программного обеспечения).
Если бы единственная проблема заключалась в том, что этому человеку действительно трудно выполнять то, о чем я его прошу, я, вероятно, все равно не стал бы писать это. Однако я заметил, что другие члены команды устали от этого. Он очень громко говорит в нашем очень маленьком офисе и часто ведет случайные разговоры на такие темы, как игры и музыка, когда мы пытаемся выполнить работу. Так что мы просто качаем головой и пытаемся игнорировать его большую часть времени.
Я обратился с этим вопросом к генеральному директору нашей небольшой компании. Он попросил меня попробовать еще немного, чтобы привлечь его к работе, и поговорил с ним о том, чтобы быть менее навязчивым с командой (что, похоже, сработало примерно на день). Это небольшая и действительно новая (пару недель) команда в небольшой компании, поэтому я ношу много шляп, от менеджера проекта до архитектора программного обеспечения, скрам-мастера и технического руководителя, поэтому я чувствую/знаю, что это мое. ответственность поговорить с ним и разобраться с этим.
Тем не менее, я не знаю, как подойти к нему по этому вопросу, так как половина проблем связана с его навыками межличностного общения, и этому человеку очень трудно принять даже незначительную обратную связь, поскольку у него более 10 лет опыта работы с программным обеспечением. разработка.
Я осознаю, что, если я буду продолжать работать в областях, связанных с управлением, мне придется часто сталкиваться с подобными проблемами. Я мог бы пойти к генеральному директору и сказать ему, что я не могу иметь этого человека в своей команде, но я не хочу быть несправедливым и отказываться от него, не давая ему шанса стать лучше. Каков наилучший способ решить эту проблему для кого-то на моем месте?
Каков наилучший способ решить эту проблему для кого-то на моем месте?
Я бы порекомендовал обзоры производительности. Это хороший способ похвалить и покритиковать подчиненных. Я бы просто составил список того, что вас беспокоит в его работе, и прямо сказал бы этому человеку, что вам не нравится, и предложил бы, как, по вашему мнению, он должен улучшиться.
Если это по-прежнему не приведет к каким-либо улучшениям, я подниму вопрос с моим менеджером и порекомендую предупредить его. Промойте и повторите, и если это не сработает, есть только один результат.
Я знаю, что это может быть непопулярно, но ваше описание слишком близко к тому, с кем я имел несчастье работать.
Когда люди говорят о плохом яблоке , портящем хорошую команду, они имеют в виду именно таких людей. Представленные вами черты:
Это вещи, в которых начинающая команда разработчиков программного обеспечения не нуждается. Удалите его как можно скорее или разберитесь с последствиями. По моему опыту, ваша команда начнет изолировать его, и это вызовет все более раздражающее поведение с его стороны.
В моей личной сказке человека не удалили после нескольких жалоб от всех членов команды. Окружающая среда постепенно ухудшалась, становясь все хуже и хуже. Более половины этой новой команды сменили работу в течение года, включая меня, и проект провалился.
Помогая им реже.
Другие члены команды или я им приходят на помощь и иногда решают вопрос за считанные минуты.
Я бы предложил поощрять его продолжать попытки найти решение самостоятельно и помогать только тогда, когда он начал блокировать вашу работу. Я обнаружил, что когда люди слишком охотно помогают, может развиться зависимость от этой помощи.
Реже помогая этому сотруднику и продолжая привлекать его к ответственности за работу, которую ему поручили, вы окажете на него большее давление, чтобы:
Ваш генеральный директор проинструктировал вас дать ему больше времени, чтобы войти в курс дела; План личного совершенствования представляет собой формализованную версию этого процесса. Это план, который вы составляете вместе с сотрудником, чтобы привести его производительность к определенному стандарту к определенной дате. Хотя они часто используются в качестве предлога для увольнения человека, который не смог улучшить себя, они также могут использоваться как настоящий метод повышения производительности сотрудника.
Если в вашей компании есть отдел кадров, они должны знать, как его создать; если вы этого не сделаете, есть ряд шаблонов, которые вы можете использовать в Интернете.
Я хотел бы расширить ответ dan-klasson. Выделите время для проведения регулярных контрольных встреч с каждым членом вашей команды. Это могут быть 10-минутные доклады, в которых обратная связь идет в обе стороны.
Важно не выделять его, чтобы он не сразу почувствовал угрозу. Если вы хотите помочь ему стать лучше, вам нужно, чтобы он чувствовал себя комфортно с вами, он должен доверять вам как менеджеру.
Для коротких 121 встреч вы можете проводить их раз в неделю или раз в две недели. Забронируйте их все заранее, с небольшим запасом времени между ними, чтобы подготовить каждое из них. 10 минут и 5 минут должны работать, или дольше, если вы считаете, что вам это нужно. Может быть, пойти дольше для первого. В приглашениях на встречи напишите, о чем вы хотели бы поговорить. Я расскажу об этом ниже. Сделайте встречи закрытыми, чтобы люди не могли видеть, о чем они, в календарях или системе бронирования помещений. Используйте конференц-зал для ощущения уединения или, если у вас его нет, отправляйтесь на кофе со своими отчетами.
Преподносите эти встречи как возможность дать и получить обратную связь в безопасном месте, где есть закрытая дверь, и они могут высказать свое мнение. Заранее попросите их подумать об этих встречах и постарайтесь дать им возможность с нетерпением ждать их. Они являются частью вашего укрепления доверия с каждым из ваших отчетов.
Сообщите команде во время стендапа или любого другого общего собрания, что вы будете проводить эти встречи с этого момента, потому что вы хотели бы установить более открытую культуру обратной связи, и вы хотели бы, чтобы они были более активными и чувствовали себя комфортно. сказать вам, если вы сделали то, что им не понравилось. Сделайте это до того, как отправите первые приглашения.
В своих приглашениях попросите их подготовить что-то вроде этого:
Затем подумайте об одних и тех же вещах по отношению к каждому из них. Делайте заметки в течение недели и приносите их на собрания.
Превратите каждую встречу в беседу. Речь идет не о том, чтобы отчитать их, а о том, чтобы узнать о них. Дайте им возможность быть открытыми и поговорить с вами. Не допрашивайте их, а задавайте открытые, наводящие вопросы или просто дайте им высказаться. Скажите им, что вы будете делать заметки, и действительно делайте заметки.
Архивируйте свои заметки, чтобы создать историю того, что вы обсуждали с каждым из них. Это дает вам возможность отслеживать их индивидуальный прогресс на протяжении всего их профессионального роста (правда, в очень незначительной степени, но все же). Это также дает вам бумажный след того, как они могут не добиться успеха.
С некоторыми из них эти встречи могут быть типа "Привет, как дела?" - "Отлично, спасибо. Мне очень нравится моя работа" - "Приятно слышать. У вас есть что-нибудь, о чем вы хотели бы со мной поговорить? - "Нет, я действительно счастлив" - "Хорошо". , то я тоже доволен. Продолжайте в том же духе». Это легко. Тем не менее, запишите это.
Теперь, что касается ваших проблемных отчетов, постарайтесь заставить его увидеть свои собственные недостатки. У него могут быть не самые лучшие социальные навыки, и он может не знать, как он выглядит в глазах других членов команды, в частности о том, что он громкий или отвлекается на другие темы.
Цели, которые вы можете поставить вместе с ним (и это пока не PIP), — это быть более сосредоточенным, делать что-то одно, но делать это хорошо, или работать в паре с вами или кем-то еще. Запишите эти цели и проверяйте их на каждой последующей встрече. Конечно, вы должны делать это для каждого из ваших отчетов.
Поговорите с генеральным директором о вашем плане сделать это, чтобы он был в курсе. Вы можете написать электронное письмо, информирующее его о вашем плане. Ключевой момент, который вы хотите донести до него, заключается в том, что вы пытаетесь поддержать, дать проблемному разработчику шанс исправиться, но в то же время вы создаете документацию на случай, если не получится защитить компанию. от последствий, если его нужно будет отпустить. HR будет любить вас за всю эту документацию, если в конечном итоге его уволят.
Также учтите, что он может быть на испытательном сроке. Вы сказали, что команда новая, а компания маленькая. В таком случае я бы дал ему время до окончания испытательного срока, а незадолго до его окончания дал бы оценку для принятия решения.
Это шанс для вас получить большой практический опыт управления. Чем сложнее, тем большему вы учитесь.
Алекс М