Разработчики не видят, что они делают не так

Я хочу, чтобы они понимали, почему я хочу что-то делать. [...] Любой совет?

Не теоретизируйте, покажите им.

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

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

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

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

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

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

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

https://medium.com/gameful-design/does-gamification-work-in-the-software-development-process-76780e49e545

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

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

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

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

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

Посторонняя помощь

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

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

Не заставляйте это

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

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

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

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

Предостережение

Не пытайтесь сделать слишком много сразу. Я попросил менеджера дать моему отделу книгу на несколько сотен страниц о принципах SOLID и заставил всех нас прочитать ее. Это было настолько скучно, что я не мог продержаться и 5 страниц, не засыпая. Это было в то время, когда менеджер пытался заставить нас изменить очень значительную часть того, как мы писали код почти за одну ночь. Да, нам нужно было внести эти изменения, но их было так много, что мы не успевали за всеми. И все это была команда, без места для вопросов или даже объяснений того, что и почему были необходимы изменения. Наряду с другими существенными изменениями в отношении руководства это привело меня к тому, что после 4 лет работы я нашел другую работу.

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

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

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

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

1. Заставьте их исправить эти проблемы, а затем отследить результаты
2. Вы позаботитесь об этих исправлениях и продемонстрируете результаты

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

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

Начните и держите нас в курсе...

Вам нужно атаковать эту проблему на нескольких фронтах:

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

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

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

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

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

Предисловие

Поскольку этот вопрос был опубликован на Project Management Stack Exchange, а не на The Workplace или каком-либо другом соответствующем сайте, единственный правильный способ ответить на него с точки зрения управления проектами — сосредоточиться на организационных обязанностях и обязанностях по управлению проектами. Это означает отбрасывание многих несущественных частей вашего вопроса и сосредоточение внимания на основных аспектах управления проектами, которые имеют либо канонические ответы, либо, по крайней мере, общепринятые лучшие практики.

TL;DR

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

Ситуационный анализ

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

1. Возможно, вы имеете дело с некоторыми различиями между культурой работы в США и Европе. Даже если это не является прямой проблемой, она, безусловно, окрашивает некоторые перспективы и рамки вашей ситуации, и вам необходимо признать этот аспект проблемы.
2. Технический директор не берет на себя ответственность за проблему и не желает оказывать прямое влияние. Когда топ-менеджер говорит, что люди могут уволиться (а не что их могут уволить), этот человек отказывается оказывать прямое влияние и ставит вас в положение, когда вам приходится решать проблему посредством влияния, а не делегирования полномочий.
3. Ваша команда разработчиков сопротивляется рекомендуемому вами подходу, независимо от того, представлен ли он в форме предложений, указаний, принципов проектирования или чего-то еще, что может вызывать вопросы. Тот факт, что они делают это таким образом, который вы считаете грубым, свидетельствует о том, что вы не заслужили их уважения ни делегированными полномочиями, ни влиянием социальных навыков. Конечным результатом является то, что у вас нет возможности осуществить значимые изменения, даже если это является целью вашей организации.
4. С точки зрения управления проектами, ничто в вашем посте не касается метрик, ключевых показателей эффективности, элементов управления проектом или чего-либо еще, что можно измерить. Изменения сложны, и ими нужно руководить с точки зрения видения и применения просвещенного личного интереса. Управление проектами в качестве профессионала часто является трудной ролью именно потому, что это роль с большой ответственностью, но с очень небольшими прямыми или делегированными полномочиями. В результате руководители проектов обычно добиваются наибольшего успеха, когда они сосредотачиваются на контроле проекта в отношении бюджета, объема, графика и качества, а не на архитектурных или инженерных вопросах.
5. Ваша концепция вашей роли нуждается в уточнении. Вы собираетесь быть менеджером среднего звена, лидером-слугой, тренером, идейным лидером бизнес-процессов или кем-то еще? Тот факт, что у вас нет четкого представления о том, как вы должны руководить командой, и отсутствие указаний от старшего руководства о том, к чему вы должны привести команду, всегда является индикатором организационного процесса. проблема.

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

Рекомендации

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

1. Убедитесь, что вы получили от исполнительного руководства четкие указания относительно объема ваших полномочий (если таковые имеются), а также четкие ожидания и показатели того, как будет оцениваться ваша эффективность на этой должности.
2. О любой проблеме, которую невозможно решить в рамках ваших полномочий или влияния, следует четко сообщить высшему руководству вместе с любыми вспомогательными показателями и рекомендациями. То, что они решат делать с этой информацией (если вообще что-то) — это их ответственность, а не ваша.
3. Если это не является частью вашей работы, не думайте об управлении изменениями. Думайте с точки зрения измеримых результатов . Работайте с командой, чтобы определить желаемые результаты, ключевые показатели эффективности, которые измеряют прогресс в достижении этих результатов, и любые необходимые элементы управления процессом, необходимые для достижения этих результатов. Другими словами, создайте совместную ответственность за четко определенные результаты, а не пытайтесь генерировать изменения сверху вниз, которые вы не можете создать без активного сотрудничества команды.
4. Перестаньте брать на себя ответственность за проблемы, для решения которых вам не хватает инструментов, навыков, полномочий или других средств. Создайте совместную ответственность там, где это возможно, перенесите другие проблемы на организационный уровень, где они могут быть решены, и убедитесь, что все стороны (включая вас, разработчиков и технического директора) четко понимают, кто и за что отвечает в вашей существующей организации. культура.
5. Помните, что теперь вы «менеджер технических проектов» (что бы это ни значило в вашей компании), а не разработчик. Точно так же, как вы хотите завоевать их доверие к себе, выполняя свою роль, вам также необходимо создать и продемонстрировать доверие, необходимое им для выполнения своей роли. Если этого не происходит, это часть того, что вам всем вместе нужно исправить.

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

Из вашего сообщения видно, что вся команда не на борту. Следовательно, это не они; это вы и ваше руководство.

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

Включите их в планы повышения производительности.

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

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