Мой коллега хороший парень, но его производительность ниже среднего. Должен ли я сказать своему боссу? [закрыто]

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

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

Теперь я не претендую на звание лучшего программиста в мире. Я работаю со многими очень умными людьми, которые лучше разработчиков, чем я. Однако я очень стараюсь написать настолько простой и надежный код, насколько это возможно. Я проверяю свои чекины. Если я вижу, что мой код становится запутанным и с ним сложно работать, я изменяю его. У меня было несколько бесед с моим коллегой, чтобы помочь ему написать лучший код. Это немного сложно, потому что а) у него более 20 лет опыта в этой области, а у меня всего 5, и б) он был нанят в качестве так называемого «эксперта по UX», и другие считают его опытным человеком.

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

1. Ничего не делай, разорись, чтобы убедиться, что этот продукт вышел вовремя и надежен, и подожди, пока он не выйдет из строя в будущем (я не буду работать с ним над этим проектом после первоначального выпуска).
2. Расскажи моему боссу о его исполнении. Мой начальник - разумный человек, но я чувствую себя неловко, принимая такой подход. Я не люблю «колотить» (из-за отсутствия лучшего термина) моих коллег, и я не знаю, как он это воспримет.

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

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

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

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

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

С точки зрения менеджмента, в этой ситуации есть 3 способа справиться с сотрудниками:

1. Взять под контроль свои слабости
2. Играть в свои сильные стороны
3. Избавиться от них (на самом деле не ваш выбор)

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

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

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

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

Играть в свои сильные стороны

Привет, Босс, я работаю с кодом для проекта x, и это великолепно. Код, с другой стороны, может использовать немало работы. Я думаю, что проект был бы лучше, если бы [ux парень] смог больше сосредоточиться на UX, в то время как я делаю некоторый рефакторинг, чтобы привести его в более стабильное состояние. Как только UX станет надежным, проект b, вероятно, сможет использовать его касание Midas.

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

Прекратите неоднократно исправлять свои ошибки. Он не будет учиться; Я знаю, что не буду.

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

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

Я был бы очень осторожен по нескольким причинам:

1. Как вы уверены, что не будете работать с ним после первого релиза? Ваше руководство может подумать: «Что за команда, посмотрите, как они вместе создали эту удивительность!» и хочу держать тебя вместе.

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

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

Каковы последствия, если вы не переделали всю его работу и просто допустили провал проекта? Последствия для тебя я имею ввиду.

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

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

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

Так много моих друзей работают ХОРОШО в течение типичного 40 / неделя в неуправляемом проекте, потому что они боятся неудачи, когда не понимают, насколько неудача ИЛИ успех напрямую влияет на всю вашу карьеру.

Более 80% проектов проваливаются, в этом нет ничего постыдного.

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

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

И надеюсь, что вы не были наняты в качестве няни. Удачи.

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

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

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

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

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

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

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

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

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

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