Как продемонстрировать руководству, что посредственные разработчики вредят команде

Ответ 1

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

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

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

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

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

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

Ответ 2

Забавный никто не сказал вам, что, может быть, вам не хватает управленческих навыков.

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

Возможно, вы должны пройти обучение.

Возможно, вы должны прочитать отчет о вам.

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

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

В этом случае перестаньте жаловаться и приступайте к работе. Не как кодер, а как менеджер.

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

Ответ 3

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

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

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

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

Ответ 4

Я был в этой ситуации раньше и могу, конечно, сопереживать. То, что я сделал, - это избавиться от небольшой самостоятельной задачи, которая должна взять меня или другого старшего разработчика не более чем на 2 дня или около того. Для этой задачи я создал несколько документов, определяющих, как должно быть реализовано решение, какие-либо изменения в базе данных и т.д. Затем я сажусь с разработчиком, даю им пошаговое руководство по проекту и назначаю его им с предельным сроком 1 неделя. В конце недели у вас есть что-то ощутимое, что вы можете сравнить их работу с тем, чтобы они соответствовали спецификации? Как они сделаны? Сколько ошибок обнаружил QA? Они каким-либо образом нарушили процесс сборки или разрыва?

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

Кроме того, убедитесь, что вы участвуете в опросе новых кандидатов.

Ответ 5

Мой совет таков:

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

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

Ответ 6

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

Кстати, мы использовали BugTracker.Net.

Ответ 7

Интересно, как эти люди попали в компанию в первую очередь:

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

Простые вещи, такие как пишущие петли, жесткие для них...

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

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

Ответ 8

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

Nerd Herding

Ответ 9

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

Итак:

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

Ответ 10

Peopleware - это еще одна книга, которая должна присоединиться к вашему списку.

Однако, когда я его читал, я не нашел его практичным, потому что никто в компании не хотел попробовать свои рекомендации.

Ответ 11

Похоже, вы на правильном пути.

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

Храните информацию о том, сколько времени занимает каждый из них, сколько дефектов производит код.

Покажите цифры верхнему управлению, теперь они должны быть уверены.

Ответ 12

Книга

Код завершен: практическое руководство по Разработка программного обеспечения Стивом Макконнелом

- хороший источник, который может помочь изучить лучшие практики.

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

Затем покажите, как команда лучших разработчиков может повысить рентабельность инвестиций.

Ответ 13

Держите отчет кратким. Не делайте это многословным. Положите это с точки зрения того, сколько денег они теряют на этом.

Ответ 14

Теперь у нас есть инструмент, который измеряет сложность наших модулей кода. Он работает на наших PL/SQL-модулях, но я считаю, что в других средах есть инструменты.

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

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

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

(Как и в стороне, весь код теперь отправляется на проверку, и должен сопровождаться сопроводительный анализ кода. Здесь все улучшается.)

Ответ 15

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

Ответ 16

Просто идея.

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

Ответ 17

Вот вам другая идея: Не исправить то, что они сломают. Отправьте его обратно для переделки в электронном письме, сообщив им, что не так и как исправить (только в общих чертах) и cc management. Обязательно обратите внимание, чтобы руководство понимало, как это повлияет на окончательный срок. Это создает документацию о проблемах с производительностью для вас, и некоторые из них могут перестать быть такими же плохими, когда им приходится исправлять свои собственные беспорядки.