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

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

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

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

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

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

(В качестве дополнения, весь код теперь подается на рецензию, и к нему должен прилагаться анализ кода. Здесь все определенно становится лучше)

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

Книга

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

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

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

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

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

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

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

Итак:

1. Сядьте со своей командой.
2. Раздайте им распечатки этой страницы и скажите, что вы разместили ее о них.
3. Пусть читают.
4. Попросите их помочь вам решить проблему.
5. Послушайте и запишите.
6. Сообщите об этом своему руководству.

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

Nerd Herding

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

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

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

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

Также убедитесь, что вы участвуете в собеседовании с новыми кандидатами.

Я использую jQuery throbber плагин: http://www.jquery-plugins.info/throbber-aka-loading-animation-00015440.htm

Это довольно просто и легко интегрировать. Может выполняться вручную и может быть присоединен для событий ajax автоматически.

На платформах Windows основным блоком программы является WinMain, если программа не настроена в качестве приложения консоли. «@ 16» означает, что ожидается 16 байт параметров. Так что компоновщик был бы вполне доволен вами, если бы вы дали ему функцию под названием WinMain с 16 байтами параметров.

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

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

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

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

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

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

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

Может быть, вам стоит пройти обучение.

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

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

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

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

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

На платформах Windows основным блоком программы является WinMain, если программа не настроена в качестве консольного приложения. «@ 16» означает, что ожидается 16 байт параметров. Так что компоновщик был бы вполне доволен вами, если бы вы дали ему функцию под названием WinMain с 16 байтами параметров.

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

Не удается переопределить свойства ForeColor и BackColor при блокировке?

Не удалось создать собственный класс текстового поля, который прослушивает событие KeyUp и перехватывает нажатие клавиши, если для свойства ReadOnly (или Locked) установлено значение true (не позволяя добавить его в текст). Тогда вы можете использовать любые стили, которые вам нравятся.

Звучит так, будто вы на правильном пути.

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

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

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

Интересно, как эти люди вообще попали в компанию:

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

Такие простые вещи, как написание циклов, являются сложны для них...

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

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

Мой совет:

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

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

Просто идея.

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

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