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

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

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

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

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

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

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

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

Какие еще ресурсы есть? Книги, статьи, общие советы были бы полезны.

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

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

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

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

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

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

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

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

Может тебе стоит пройти обучение.

Может, тебе стоит прочитать отчет о тебе .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Им тяжело такие простые вещи, как петли для письма ...

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

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

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

Ботаник стадо

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

Так:

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

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

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

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

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

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

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

Книга

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

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

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

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

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

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

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

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

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

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

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

Просто идея.

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

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