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