Что делать, если младший не принял ваше предложение? [закрыто]

Я возглавляю команду из 3-4 младших разработчиков. Моя работа - помимо написания кода - обеспечивать надзор и руководство для юниоров.

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

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

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

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

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

Этот подход важен по следующим причинам:

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

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

• Ваш код предполагает доступ к производственной базе данных. Как мы можем изменить это так, чтобы он все еще работал и мог быть правильно протестирован JUnit в автономной среде разработки? (потенциальный ответ: ах! мы должны использовать внедрение зависимости ....)
• Что произойдет, если злоумышленник преднамеренно отправил какой-то умно сконструированный SQL в вашу онлайн-форму ввода данных? (потенциальный ответ: ах! возможно, нам не следует создавать операторы SQL путем объединения непроверенного текста из интернета)

РЕДАКТИРОВАТЬ : Если вам удастся убедить своего младшего в том, что правильно сделать, это следовать вашему предложению, но они все еще неохотно, чем вот некоторые дополнительные советы:

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

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

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

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

• Есть ли у вас полномочия добиваться конкретных решений?
• Какова степень этого авторитета?
• Есть решение плохое или просто другое?

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

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

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

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

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

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

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

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

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

мое решение намного превосходит их

а также

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

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

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

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

Прежде всего, знаете ли вы настоящую причину, по которой ваш младший не принял ваше предложение?

Иногда вы знаете, что младший может написать что-то лучше своего старшего из-за новых перспектив и более современного образования в области КС. Хотя в старшем возрасте вы могли видеть больше примеров из реальной жизни. Но плохая ловушка, в которую я часто вижу своих пожилых людей, - это забывание о том, что лучшие практики со временем могут измениться. Я уверен, что это не относится к вам, поскольку вы обновляете себя на таких сайтах, как эти. ;)

Я бы посоветовал подойти к вашим юниорам без какой-либо (или небольшой) «ауры» старшего, постараться поговорить с ними ровно, проявить любопытство в написанном ими коде. Задайте вопросы, услышите их ответы. Не спрашивайте обвиняющим образом, таким как:

«Ваш код довольно негибкий, вам нужно изменить его на это ...»

вместо этого спросите

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

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

Контролируете ли вы push-доступ к хранилищу?

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

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

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

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

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

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

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

Что ж, это кажется интересным и очень естественным для молодых программистов, сильно привязанных к написанному ими коду, возможно, они потратили довольно много времени на то, чтобы прийти к тому же самому, или они выбрали его с какого-то хорошего сайта (ТАК действительно, Эй, Джон Скит написал это мужчина ! !).

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

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

У каждого свой стиль. Если вы найдете 10 разных людей и представите им нетривиальную проблему, они предложат вам 10 разных подходов, использующих 10 разных стилей «стандартов кодирования».

Дело в том, чтобы выбрать то, что имеет значение. Если что-то представлено вам младшим, которое не дает правильного решения, делает это крайне неэффективно (+1 порядок, а не инструкция здесь или там) или создает дыру в безопасности, то объясните свою проблему и почему. Если это комментарий «Я бы сделал это», то это здорово, вы бы сделали «это», а она сделала «что-то другое», но проблема все еще достаточно решена (см. Выше). Перейдите к следующей функции или исправить.

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

РЕДАКТИРОВАТЬ: убедитесь, что ваши предложения являются подлинными и не завуалированные требования. Предложение - это просто предложение, которому можно следовать или нет. Если это требование, укажите это как таковое.

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

Что касается попыток заставить младших разработчиков делать то, что вы предпочитаете делать:

• Контролируйте свою терминологию, делая предложение не то же самое, что делать рекомендацию, которая определенно не совпадает с указанием направления . Используйте терминологию соответственно, чтобы донести свою точку зрения, и если вы считаете, что ваш способ сделать что-то - лучший способ сделать это, скажите им, что это ваша рекомендация. Точно так же, если абсолютно необходимо, чтобы все было сделано определенным образом (т.е. не выдерживало задержки), тогда просто будьте тупыми и указывайте им, как это должно быть сделано.
• Младшие разработчики все еще проходят учебный процесс независимо от того, как вы формулируете вещи, всегда приводите своего рода аргументацию того, что вы им говорите, если только у вас нет особой причины, по которой вы не можете. Даже в этом случае большинство людей поймут, если вы скажете что-то вроде: «Это должно быть сделано так, мне все равно, но решение уже принято». они имеют тенденцию быть довольно разумными.
• Если это действительно просто предложение, то убедитесь, что ваша идея на самом деле лучше, чем, как это было. Если вы не думаете, что это так, то сядьте с разработчиком и сделайте обзор кода и концепции, чтобы они могли обосновать свое решение. Может случиться так, что как только они начнут объяснять это кому-то еще - и вы зададите правильные вопросы - они увидят лучший способ и захотят перекодировать вещи самостоятельно.
• Не спорьте по поводу деталей, если их решение похоже на то, что вы изначально предложили, может быть, они приняли то, что вы им сказали, и сделали вещи немного по-другому или изменили свою первоначальную концепцию, основываясь на вашем предложении.

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

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

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

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

Дайте заказы. Жить с последствиями. Учитесь на опыте. Уважение это улица с двусторонним движением. Вы демонстрируете это, а они нет.