Я возглавляю команду с 5+ разработчиками. У меня есть разработчик (назовем его A ), который является хорошим программистом, который пишет хороший чистый, понятный код. Однако им сложно управлять, и иногда я задаюсь вопросом, действительно ли он неэффективен или нет.

1. Наша компания требует, чтобы разработчики указывали прогресс работы в используемом нами трекере ошибок, не столько для мониторинга программистов, сколько для информирования заинтересованных сторон о прогрессе. Дело в том, что A обновляет ход выполнения задачи только тогда, когда она выполнена (возможно, через 3 недели после ее первой работы), и это заставляет всех задуматься о том, что происходит в середине недели разработки. Он не изменит свою привычку, несмотря на повторные исследования. (Все нормально, разработчики ненавидят бумажную работу, я тоже)
2. В последние 2-3 месяца он часто в отпуске из-за различных событий - либо он болен, либо вынужден присутствовать на многих личных мероприятиях и т. Д. (Все нормально, плохие вещи случаются в череде. Это просто совпадение)
3. Мы определяем спринты или дорожные карты для каждого месяца. И в начале спринта мы обсудим объем работы, которую каждый разработчик должен выполнить в спринте, и разработчики смогут установить количество времени, которое им нужно для каждой задачи . Обычно он не сможет выполнить все из них. (Это нормально, разработчики регулярно пропускают сроки не по своей вине).
4. Я базируюсь в Сингапуре. Не уверен, что это имеет значение. Да, азиаты известны своей сдержанностью, но имеет ли это значение?

Если произойдет только одно или два из вышеперечисленных событий, я не буду чувствовать, что А неэффективен, но все они происходят вместе. Так что у меня такое чувство, что А не работает и, может быть, не дай Бог, ослабевает.

Это просто чувство, основанное на моем многолетнем опыте программиста. Но я могу ошибаться.

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

Результат:

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

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

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

Дополнительные примечания:

1. Я ненавижу микроуправление. Таким образом, все, что у нас есть для нашего программного процесса - это Sprint (где задачи расставляются по приоритетам и назначаются, а в конце месяца - обзор объема проделанной работы). Разработчики должны будут обновлять задачи по мере их выполнения каждый день.
2. Там нет стоячей встречи, или что-то в этом роде. Главным образом потому, что у нас есть свобода работать из дома, и каждый дорожит этой свободой.
3. Хотя я тот, кто устанавливает крайний срок, но разработчики предоставят оценку для каждой задачи, и я буду решать - на основе оценки - задачи, которые входят в конкретный спринт. Если они не смогут выполнить задачи в конце спринта, я перейду к следующему. Таким образом, теоретически можно выполнить только 1 или 2 задачи в течение всего спринта, а затем перенести оставшиеся 99 задач на следующий спринт, и все же он будет в порядке, пока это оправдано, - в форме ежедневных обновлений о ходе работы.

Это должно быть удивительно легко решить проблему.

Проведите вторую встречу с ним. Скажите ему, что вы принимаете, что, вероятно, виновато ваше восприятие реальности. Затем уточните это как «однако, если это так, то нам нужно работать вместе, чтобы улучшить мое восприятие». Наконец бросьте ему вызов, чтобы решить эту проблему, чтобы он не чувствовал себя микроуправляемым.

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

Если нет, то вы получите эти проблемы.

Регулярные, запланированные, 1: 1 - отличная идея. И, как отмечали люди, приемы на работу не должны быть ортогональными для работы из дома. Но они должны включать три вопроса: что вы делали вчера? Что вы планируете делать сегодня? И тот, о котором большинство людей забывают ... Что (если вообще что-то) задерживает тебя?

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

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

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

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

Хороший улов!

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

Найти источник проблемы

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

Вы не совершенны ни

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

Все сказанное

Я написал пост в блоге об управлении программистами. Я думаю, что вы должны прочитать это.

http://deltreey.blogspot.com/2012/07/managing-programmers.html

Я не могу особо подчеркнуть последнюю часть этого поста.

Если ваши разработчики вообще хороши, они хотят писать код.

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

Когда вам кажется, что с кем-то «трудно справиться», как вы описали, чтобы лучше понять, как он работает, и есть ли проблемы (объективные или субъективные), влияющие на производительность членов команды разработчиков, подумайте о том, чтобы установить практику регулярных 1: 1 с вашим Члены команды, представленные в превосходной статье «Обновление», «Вентиляция» и «Бедствие» :

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

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

_{Очень сильная сторона упомянутой статьи заключается в том, что она самодостаточна , в том смысле, что помимо объяснения преимуществ, она также предоставляет набор практических рекомендаций, в основном позволяющих начать практиковать обычные 1: 1, не углубляясь в другие источники (хотя и ищут дополнительная информация не помешает, вы знаете).}

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

Вы всегда можете предложить, чтобы он регистрировал / предоставлял обновления более регулярно, чтобы минимизировать подобные конфликты. Это может позволить вам сформулировать ваш запрос с точки зрения помощи команде, а не «я не знаю, что вы делаете».

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

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

бессмысленный

Ежедневные обновления статуса бессмысленны. Когда люди сообщают, что «сегодня я заполнен на 2,5%», «сегодня я закончил на 3,74%» - это смешно.

Это не представляет никакой ценности для заинтересованных сторон и раздражает людей, выполняющих работу.

Оставьте их на работе, не потревоженные.

необоснованный

На каком основании вы полагаете, что разработчик А «неэффективен»? Если его / ее работа выполняется вовремя, этого должно быть достаточно.

Вы говорите, что ненавидите микроуправление, но именно это вы и описали.

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

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

опасно

Пересмотрите основание для вашего «ощущения», что разработчик А «отстает». Вы думаете, он / она мог бы сделать лучше, но на основании каких доказательств?

Несчастная!

Продолжайте, как описано, и в какой-то момент разработчик А, скорее всего, решит, что он / она недооценен, дал достаточно компании и найдет другую компанию. Выдавливать последние 0,01% усилий у сотрудников гораздо менее важно, чем удерживать их на долгий срок.

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

Что касается оценки - это классическая проблема. Я рекомендую прочитать «Оценка программного обеспечения - демистификация черного искусства» Стива Макконнелла. В этом случае у вас создается впечатление, что большинство ваших разработчиков недооценивают. Это, как ни странно, нормально и редко решается. Я бы предположил, что у вас есть проблемы с самим процессом оценки, а не с этим отдельным человеком.

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

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

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

А как насчет регистрации кода? Проверяет ли он свой код все время? Лично я считаю, что программисты на самом деле не менеджеры, и чем больше вы пытаетесь управлять, тем больше они разочаровываются. На самом деле, я ненавижу делать эти задачи по обновлению, и, вероятно, именно поэтому PM и Leads для. Но в то же время я предоставляю информацию о статусе во время скрам-встреч или когда мы встречаемся. Теперь, когда вы назначаете задачу, они фиксируют временную шкалу или это вы назначаете временную шкалу?

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

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

Одна вещь, которую вы можете сделать, это интегрировать что-то вроде XPlanner с инструментом управления версиями.

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

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

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

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

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

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

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

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

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

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

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

Быстрые отступления, которые больше связаны с коммуникацией, чем с подотчетностью, и просто устанавливают цели, больше всего на свете, на мой взгляд, делают гибкую работу. Остальные, которые я мог взять или оставить, особенно Scrum, который я рассматривал как змеиную нефть руководителя / заинтересованного лица.

Неэффективные?

Интенсивность приливов и отливов во время карьеры человека. Если он стоит больше, чем стоит, поговорите с ним и постарайтесь облегчить его работу. Или же начать искать замену.

связь

Не полагайтесь на еженедельные встречи. Большинство людей не собираются делать полный мозговой дамп. График больше 1: 1с. Спросите их, как идут дела, что вы можете сделать лучше, и что, по вашему мнению, они могут сделать лучше. Иногда говорить не о чем, но это нормально. Имея больше 1: 1, вы увеличиваете вероятность того, что они не забудут упомянуть что-то.

Иметь более стойкие средства общения

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

Управления источником

Пусть каждый проверяет свой код ежедневно. Если вы используете git, попросите их открыть свой филиал в репо компании. Глядя на коммиты, вы можете сказать, как они работают.

Отделите средства от концов

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

Вот мои предложения:

1. Инновации: воображение и креативность используются для снижения затрат и улучшения текущей ситуации.

2. Корпорация: готовность помогать другим в достижении их целей

3. Инициатива: Попытка нестандартных работ и задач.

4. Посещаемость: отсутствие или опоздание, ниже стандартов.

5. Бдительность: способность быстро понимать новую информацию и ситуации

6. Точность и качество: проверка кода, своевременная доставка, скорость выдачи).