Я руковожу 20 инженерами-программистами, разделенными на 4 подгруппы. Каждая команда имеет хорошие стандарты работы и высокий уровень сопричастности, кроме одной. В этой команде есть один старший парень и три младших. Каждый раз, когда возникает критическая ошибка (влияющая на бизнес), этот старший парень всегда переносит работу на следующий день, говоря что-то вроде: «Я не могу закончить это сегодня», «Я посмотрю это завтра», «Мы действительно нужно это сегодня?» или «Как мы собираемся проверить это сегодня вечером?» Даже когда я сказал ему, что мне это нужно сейчас, он сказал, что у него есть другие дела, и улизнул, когда меня не было. Он также велел этим младшим отложить свою работу.
На прошлой неделе я сказал им на собрании команды, что ожидаю более высокого уровня ответственности. Если они что-то обещают, они должны это сделать. Если есть критическая ошибка, они должны исправить ее, даже если им придется остаться допоздна.
Сегодня был критический баг, и этот старший парень снова сказал то же самое - "Я не могу закончить сегодня. У меня встреча с друзьями, и я должен идти". затем он улизнул, пока я разговаривал со своим менеджером.
Это не тот менталитет, который я хочу, чтобы моя команда имела. Я планирую сказать ему, что он должен изменить свой стиль работы или найти новую работу, и жду ответа. Это слишком прямо, чтобы сделать это? Есть ли альтернативный способ решения подобных проблем?
Обновлять
В этом конкретном примере ошибка не позволяет 90+% пользователей войти в систему. В среднем в этом году это происходит раз в месяц, а в прошлом году — дважды. Критические ошибки — это четко определенные ошибки, которые: 1) не позволяют пользователям входить в систему и 2) не позволяют пользователям покупать продукты — только эти два типа ошибок.
Что мы сделали для подготовки каждого релиза:
Вы, кажется, путаете две вещи:
Они работают любое количество часов, чтобы решить неожиданные или незапланированные проблемы.
Они несут ответственность и обеспечивают качественную работу предсказуемым образом.
Собственность — это не команда, работающая всю ночь напролет, чтобы выполнить ваши обещания, данные клиентам. Владение — это знание того, что находится в коде, как он работает, наличие плана и возможность сказать вам, как и когда что-то будет сделано. Ответственность — это принятие разработчиками правильных решений, чтобы код работал правильно не только сегодня, но и в последующие годы.
Извините, если это немного грубо, но у меня было слишком много менеджеров, которые предлагали мне варианты вашего поста. Чаще всего дело доходит до:
Не могли бы вы уточнить в вопросе о том, что вы, как менеджер, сделали для подготовки этих релизов, расширения возможностей вашей команды и как вы прислушивались к их отзывам? Тогда можно говорить о собственности.
Даже когда я сказал ему, что мне это нужно сейчас, он сказал, что у него есть другие дела, и улизнул, когда меня не было.
Сегодня есть критический баг и этот старший парень снова сказал то же самое - "Я не могу сегодня закончить. У меня встреча с друзьями и мне нужно идти". затем он улизнул, пока я разговаривал со своим менеджером.
В обоих этих примерах вы называете его улизнувшим, но он своими словами сказал вам, что не собирается выполнять эту работу, и не сделал ее. Ускользание подразумевает, что он обманывает или нечестен, но звучит так, будто он откровенен, и вы должны это признать. Я работал с людьми, которые говорят, что разберутся, а потом исчезнут, и эти люди заслуживают увольнения. Кто-то, кто сообщает вам о своей пропускной способности, а затем следует, совершенно другой. Честность этого человека не проблема; он безработный только в том случае, если его результаты недостаточны.
На прошлой неделе я сказал им на собрании команды, что ожидаю более высокого уровня ответственности. Если они что-то обещают, они должны это сделать. Если есть критическая ошибка, они должны исправить ее, даже если им придется остаться допоздна.
Это разумное утверждение и уровень владения, который старшие инженеры обычно должны принимать с некоторыми оговорками:
Есть ли альтернативный способ решения подобных проблем?
Некоторые методологии разработки имеют встроенные способы решения этих проблем. Например, в Agile-разработке спринты — это способ пообещать, какая работа будет выполнена. Он также включает в себя встроенные способы измерения скорости (объем выполняемой работы) и обычно идет вместе с программным обеспечением (на мой взгляд, наиболее популярным является JIRA), которое определяет, достигают ли команда или отдельные лица эти цели. В гибкой разработке, если вам нужно изменить курс в середине спринта — например, потратить время на исправление критической ошибки — это отражает то, что вы по своей сути меняете масштаб. Обычно вы убираете что-то, чтобы добавить то, что должно быть добавлено. Этот процесс позволяет очень легко оценить, является ли это «я не могу сделать это сегодня» тем, что он усердно работает над другими важными целями, или тем, что он просто труден.
ИМО, это фантастический метод разработки программного обеспечения, который, к сожалению, почти никогда не выполняется правильно.
ОБНОВЛЕНИЕ : в ответ на редактирование вопроса эта ошибка носит абсолютно критический характер (в большинстве компаний ее называют демонстрационной, а не критической) и должна быть исправлена немедленно. Я бы следовал описанной выше технике — брал что-то с его тарелки в обмен на то, что он работает над этим сейчас.
Похоже, что этот проект был беспорядочным и очень напряженным для всех участников, но ошибка, из-за которой 90% пользователей не могут войти в систему, стоит того, чтобы задержаться. Вам нужно оценить, полностью ли этот сотрудник уволился (в этом случае вы должны помочь ему перейти на другую работу) или проект просто утомил его и ему нужен перерыв.
bug prevents 90+% of users from logging into the system. On average, this happens once a month this yearозначает, что время не тратится на тестирование критических функций. То, что время не выделено, является управленческой проблемой: «Делайте это вместо этого, это важнее». Если это произошло там, где я работаю/редактор более одного раза, и я предупредил их, я не буду задерживаться в следующий раз, когда у нас не было времени, чтобы убедиться, что это никогда не повторится (например, модульное и функциональное тестирование).В моем офисе мы обычно цитируем следующее:
«Плохое планирование с вашей стороны не требует чрезвычайной ситуации с моей стороны».
По моему опыту, разработчики часто мотивированы помочь с проблемой, возникшей из-за ошибки с их стороны или чего-то непредвиденного.
Но часто возникают проблемы, которые не только неудивительны, но и предсказуемы. Прежде чем вы решите поставить разработчику ультиматум и, вероятно, заставить его искать новую работу, вы должны задать себе следующие вопросы:
Достаточно ли вы сделали, чтобы избежать «критических» ошибок? Дали ли вы разработчикам достаточно времени для проведения тестирования, проверки кода, рефакторинга и мониторинга?
Следите ли вы за тем, чтобы новые функции активировались, когда есть достаточно времени для их исправления? (в отличие от позднего вечера или в пятницу).
Если критические ошибки являются обычным явлением, достаточно ли вы платите за сверхурочную работу или работу по вызову?
Разработчики, которых вы хотели заполучить, «владели» процессом выпуска? Смогут ли они остановить выпуск функции, если посчитают, что в ней есть ошибки?
Ваши сроки реалистичны и согласованы с командой разработчиков?
Если на все вопросы можно ответить однозначно «да», возможно, вам придется уволить старшего разработчика.
Если бы какой-то из ответов был "Нет" или "Я не уверен", то я бы начал искать проблему в управлении и устранял бы эти проблемы в первую очередь.
Вы заявляете об отсутствии сопричастности со стороны команды. Все, что создают ваши разработчики, принадлежит компании, а не им. Когда вы говорите, что ваши сотрудники должны «владеть» результатами своей работы, означает ли это также, что они будут получать прибыль, которую эти результаты приносят компании? Если это не означает, что они действительно не владеют работой, и вы не можете требовать от них права собственности.
Если есть критическая ошибка, они должны исправить ее, даже если им придется остаться допоздна.
Ваше решение по устранению критических проблем, заставляющее ваших сотрудников задерживаться допоздна, удобно для компании, и за это расплачиваются сотрудники. Опять же, это было бы нормально, если бы они также получали долю прибыли. Они?
В этом конкретном примере ошибка не позволяет 90+% пользователей войти в систему. В среднем в этом году это происходит раз в месяц, а в прошлом году — дважды.
Когда это происходит так часто, и вы не устанавливаете организационные процедуры, чтобы уменьшить влияние этих ошибок, виноваты вы как организация.
На самом деле, ваш нынешний подход к устранению «критических» проблем и ваше намерение уволить вашего сотрудника можно было бы считать признаком неблагополучной организации. Поведение вашего сотрудника может быть его способом отреагировать на это. Ваше обновление исходного вопроса со списком того, что, по вашему мнению, вы делаете правильно (в отличие от размышлений о том, что вы, возможно, делаете неправильно ), также показывает, что у вас может быть проблема с признанием того, что вы как менеджер являетесь частью проблемы.
Есть много вещей, которые руководство может сделать, чтобы улучшить качество и снизить срочность, прежде чем вы попросите сотрудников остаться допоздна:
Работа в программном обеспечении это очень распространено.
Вы относитесь к своим людям как к профессионалам. Вы говорите о собственности, но затем требуете, чтобы «критическая» ошибка была исправлена СЕЙЧАС.
Является ли ошибка действительно «критической»? Является ли это результатом неясных требований? Наш старый друг "прицел"?
В каждом из них вам (как менеджеру) необходимо управлять ожиданиями. Не каждая ошибка является «критической». Требования могут быть отстойными. Изменения масштаба проекта.
Вместо того, чтобы требовать, чтобы они бросили все ради чего-то «критического», поработайте со своими командами до тех пор, пока это не будет исправлено. Затем подведите их к этой оценке.
Я беру слово «критическое» в кавычки, потому что после 30 с лишним лет работы в этой области (да, я стар) этот термин используется очень неправильно. Все не может быть «критическим».
"yikes I'm old"- Это означает, что ваш вклад очень ценен.С обновленным вопросом теперь ясно, что вы пытаетесь решить не ту проблему. Поведение старшего инженера является признаком в корне нарушенного процесса разработки программного обеспечения и/или неблагополучной компании.
Если у вас каждый месяц появляются критические ошибки, то у вас есть как минимум одна из следующих проблем:
Учитывая, сколько у вас рабочей силы (20 инженеров — это МНОГО ресурсов), скорее всего, это комбинация всех трех.
Я предполагаю, что старшему инженеру надоело постоянное тушение пожаров, и это правильно.
Вам нужно копнуть глубже и устранить основные проблемы, из-за которых людям приходится постоянно работать допоздна. Убедить одного инженера чаще работать допоздна не поможет общей картине.
Что теперь с этим делать...
Шаг 1. Выясните, почему тестирование не выявляет эти критические ошибки
Первое, что вам абсолютно необходимо сделать, это не допустить, чтобы эти критические ошибки когда-либо попадали в рабочую среду. Каждая ошибка, попадающая в продакшн, — это ошибка в процессе тестирования.
Вернитесь к каждой критической ошибке, обнаруженной в рабочей среде, и точно определите, почему она не была выявлена при тестировании. При необходимости добавьте дополнительное автоматизированное тестовое покрытие, ручное тестовое покрытие или ресурсы для тестирования.
Шаг 2. Определите основную причину каждой критической ошибки
Для каждой критической ошибки узнайте:
Проведя этот анализ, вы обнаружите некоторые закономерности. Может быть, есть один или два разработчика, которые продолжают добавлять эти ошибки. Возможно, есть один модуль кода, который очень сложно модифицировать, не вызывая проблем. Или возможно, что с кодом в целом очень сложно работать.
Every bug that reaches production is a failure in the testing process- Почти правильно. "тестирование" является частью разработки. С 20 разработчиками вы должны использовать модульное / функциональное тестирование (предпочтительно оба). Таким образом, тестирование является неотъемлемой частью всего процесса разработки, а не отдельным процессом. Переформулировал бы как: Every bug that reaches production is a failure in the development process. Кроме того, я думаю, вам не хватает «руководства хочет функции XYZ от ABC». Всегда гигантский домпер на правильной работе. Затем вы получаете OP, требующий, чтобы вы остались допоздна ... затем вы ищете новую работу.Я хочу сделать еще одно замечание. Поспешное исправление ошибок часто приводит к техническому долгу. Если ваш старший разработчик спрашивает, как это будет тестироваться сегодня вечером, то это хороший вопрос, который старший разработчик должен задать! Я работал в местах, где срочность важнее качества, и это имело негативные долгосрочные последствия. В конечном счете, у вашей команды будет меньше возможностей, потому что она всегда тушит пожары.
Похоже, у вас огромная проблема с тестированием. Вы спрашиваете, почему все не отказываются от всех внешних обязательств по тушению пожара, но реальный вопрос в том, почему пожары начинаются каждый месяц?
Есть ли у вас QA/тестирование? Почему они не обнаружили, что первый и самый основной шаг (вход в систему) не работает. Как то, что вообще не работает, попало в производство.
Кроме того, почему ваш ответ на то, что пользователи не могут войти в систему, заставляет всех оставаться допоздна, спеша с «критическими» исправлениями, вместо того, чтобы системный администратор отменял обновление, и обновление можно было повторить позже после устранения проблем.
"Как мы собираемся проверить это сегодня вечером?" Это правильный ответ. Когда есть критическая проблема, и вас заставляют исправить ее прямо сейчас, как разработчики будут выделять время для надлежащей проверки правильности/высокого качества изменений и как QA предназначен для проверки того, что все остальное все еще работает после изменения. Похоже, вы также просите об этих изменениях в конце дня, когда все устали, а их мыслительные способности находятся на самом низком уровне, что делает еще более вероятным, что другие проблемы проникнут в это критическое исправление.
Когда люди наиболее продуктивны? Когда команда наиболее способна справляться с критическими ошибками? Были проведены исследования, которые отвечают на указанные вопросы о том, когда люди лучше всего справляются с определенными задачами.
У вас есть критическая ошибка, и вы хотите: а) Старший переключить умственные передачи, б) взять новую «критическую» задачу, в) работать «до тех пор, пока» над ее исправлением. И вы ожидаете, что этот критический патч будет работать? Честно говоря, что вы ожидаете от продукта, команды, членов команды, если ваши желания были удовлетворены?
Отпустите свое эго и иррациональные убеждения.
Термин, который вы ищете, — это дискреционные усилия , а не право собственности .
Я исхожу из того, что ваши сотрудники выполняют свои договорные обязательства (в противном случае ваш план действий ясен).
Вы не имеете права ожидать дискреционных усилий. Так оно и есть по определению. По сути, это не то, о чем вы можете говорить с ними и ожидать перемен. Скорее всего, вы получите противоположный ответ. Они не обязаны его давать. Угрозы их увольнением, скорее всего, вызовут крайне негативный отклик, к тому же они будут незаконными.
У меня нет хороших предложений о том, как вы можете улучшить ситуацию. Сам факт того, что вы можете положиться на Дискреционное Усилие некоторых из ваших людей, предполагает, что культура не обязательно нарушена.
Исправление этого потребует времени, поэтому вместо этого я могу предложить временные меры:
Зафиксируйте коэффициент шины 1
Почему только один сотрудник может решить эту проблему?
Иметь дежурный список
В соответствии с возмещением, согласованным с отдельными работниками, а не столько, сколько вы думаете.
Выпускайте обновления в лучшее время
Это может быть невозможно, но развертывание событий в лучшие времена может увеличить шансы на то, что кто-то поможет.
Ценность вашего программного обеспечения зависит от того, насколько хорошо оно поддерживается, поэтому вам не следует использовать дискреционные усилия в качестве опоры. Если вы хотите, чтобы ваше программное обеспечение поддерживалось на должном уровне, вам необходимо убедиться, что у вас есть все необходимое для этого.
Итак, вы ожидаете, что ваши сотрудники бросят свою социальную и / или семейную жизнь в мгновение ока, чтобы решить проблемы?
Неужели все так критично?
Кажется, что менеджеры всегда думают, что все имеет решающее значение, потому что сказать «нет» сложно. Это сильная потенциальная причина, по которой ваш ведущий разработчик сопротивляется. Они пытаются защитить свои границы, потому что вы этого не сделаете. И они пытаются защитить границы своей команды, потому что вы этого не сделаете.
Если они действительно настолько критичны, то что происходит не так, что позволяет этим проблемам происходить?
Если качество вашего продукта настолько плохое, вам нужно отойти и позволить разработчикам разработать план, чтобы вернуть продукт в нужное русло. Плохое качество связано не только с ошибками. Низкое качество снижает предсказуемость. Если вы постоянно отклоняетесь от плана из-за плохого качества, исправьте свое качество. И вы не исправите это, попросив разработчиков сделать это в их личное время. Если вы устанавливаете именно такие ожидания, то вы говорите своим разработчикам, что бизнес не заботится о качестве и, следовательно, не ценит предсказуемость. Если вы не цените предсказуемость, перестаньте жаловаться.
Если они действительно все критические, то почему бы вам не спланировать дежурную ротацию?
Это не только защищает личное время сотрудников и защищает потребности бизнеса, но также создает стимулы для разработчиков исправлять системные проблемы, из-за которых они так много борются. (возможно, вам нужно больше или лучше тестов, возможно, вы сломали устаревший код и т. д.)
Почему бы тебе не остаться допоздна и не исправить ситуацию?
Вы жалуетесь, что кто-то не работает всю ночь, чтобы решить проблему. Почему бы тебе не работать всю ночь, чтобы исправить это? Я думаю, вы найдете те же выводы, что и руководитель вашей группы.
Ваше поведение
Вы пригрозили уволить своих сотрудников за невыполнение того, что сами отказываетесь делать. Вы жалуетесь, что это происходит часто, но вы не запланировали это с ротацией по вызову или погашением технического долга.
Читая ваш список шагов по планированию релиза, я обращаю внимание на частое использование фразы «Я сказал им…» и детализированность планирования вплоть до имен функций. Вы планируете мелкие детали, которые легко изменить, но не планируете процесс поддержки вашего продукта.
Это 100% ваша проблема.
Твоя команда
Мне кажется, что у вас есть группа умных, честных профессионалов, которые знают, как делать хорошее программное обеспечение, но их менеджер любит диктовать им, как выполнять свою работу, и когда подход менеджера вызывает проблемы, заставлять их работать больше. часы.
Вы отступили и спросили свою команду, как получить менее критические ошибки? Спрашивали ли вы свою команду, как, по их мнению, они должны справляться с ответственностью за неожиданные критические проблемы?
Ваш тимлид прав, что опровергает ваши ожидания. И я рад слышать, что он поощряет свою команду говорить «нет». Он пытается защитить команду, потому что ты нет.
В то время, когда я руководил командой, я могу сказать вам, что один из самых сложных, но самых важных уроков — это научиться говорить «нет». Может быть, вы сможете чему-то научиться у этого вашего сотрудника.
Вы не можете заставить кого-то работать сверхурочно (зависит от страны и потенциально экстремальных обстоятельств в качестве исключения в законах)
Если человек не может или не хочет этого делать, вы обязаны найти соответствующего сотрудника или нанять постороннего помощника, если задача жизненно важна и требует немедленного внимания.
Попросите юриста по трудоустройству в вашей юрисдикции уточнить.
Что касается ответственности и выполнения поставленных или обещанных задач, у вас есть свой дисциплинарный арсенал вплоть до прекращения трудовых договоров.
Кроме того, что сказал Сефе...
Отвечая на обновленный вопрос:
Ваша большая проблема не в отсутствии собственности. Это скорее похоже на симптом более глубокой, лежащей в основе проблемы: тот факт, что ваш процесс разработки кажется существенно нарушенным.
Теоретически ваш процесс (т. е. автоматические тесты и покрытие тестами, планирование в спринтах, отсутствие внезапных изменений требований) должен предотвратить большинство проблем, с которыми вы сталкиваетесь.
По вашему собственному заявлению, вы столкнулись с несколькими проблемами «Showstopper» с программой даже при развертывании у клиента, а некоторые из них даже были регрессиями. Спринты не заканчиваются вовремя (тесты являются частью спринта). И даже когда тест написан, он не обеспечивает достаточного охвата, чтобы отловить эти ошибки. Вы также сказали, что у вас уже была ситуация «опоздания» (из-за которой вы впоследствии дали им выходные).
Вам нужно выяснить, что идет не так. Только найдя и решив основную проблему, вы можете надеяться исправить ситуацию.
Если 90% пользователей не могут войти в систему, и пользователи не могут совершать покупки (т.е. продажи теряются), вам необходимо немедленно вернуть обновление к предыдущей рабочей версии. Ожидание, пока ваши разработчики устранят неполадки и исправят ошибку, может занять гораздо больше времени и вызвать более негативное влияние на пользователей, чем просто возврат к предыдущей версии.
Что еще более важно, ваши разработчики с меньшей вероятностью захотят продолжать работать на вас, если они вынуждены выполнять сверхурочную работу, когда доступно лучшее решение. Если вы цените своих сотрудников, вы должны уважать их время вне работы.
Отвечая на обновленный вопрос,
Похоже, что была соблюдена хорошая рабочая практика:
Я частично согласен с положительной культурой исправления критических ошибок сверхурочно. Однако культура также должна отражать, что ни один код не идеален, если только вы не потратите на него много денег. Существует старая легенда о том, что НАСА потратило около 1000 долларов на строку кода! . Я не буду много комментировать культурную сторону, так как это уже было рассмотрено другими, вместо этого некоторые методологические предложения:
Структура команды в моде на данный момент — это специальные отряды, которые несут сквозную доставку и операционную ответственность за изолированную вертикаль, которую они пишут. Если что-то пойдет не так, их разбудят ночью, однако я бы с осторожностью вводил это в устаревшую среду, поскольку это вызовет отвращение, если у команды не было возможности внедрить качество, которого они хотят, с самого начала. -идти. И традиционные роли Ops с контрактами / оплатой, вероятно, более открыты для работы по вызову.
Лучшей идеей было бы внедрить идею чемпионов по контролю качества в команде и подход «3 amigos», т.е. продукт, разработчик и член отдела контроля качества вместе пишут спецификацию функций (дизайн, ориентированный на поведение). Это гарантирует, что «как член QA нарушит это» учитывается с самого начала, и это должно быть достаточно подробно, т.е. спецификация на примере. Член QA не обязательно должен быть человеком, пишущим автоматизацию, но он должен проверять код. Как упоминалось выше, автор кода не должен нести единоличную ответственность за аккредитацию его качества, и привлечение третьей стороны на как можно более раннем этапе процесса является положительным шагом.
Возможно, производственная среда и управление выпуском также нуждаются в улучшении. «Синие/зеленые развертывания» и «Тестирование в производственной среде» — это распространенная практика постепенного развертывания изменений для все более и более широкой аудитории только по мере того, как метрики доказывают свою эффективность. В идеале ваша промежуточная среда должна обнаруживать критические ошибки, но в рабочей среде всегда есть что-то другое, поэтому это никогда не должно быть выпуском большого взрыва.
Судя по временным рамкам, несмотря на то, что вы используете типичную частоту выпуска, вы можете рассмотреть возможность выпуска более частых выпусков. Более частые небольшие выпуски могут привести к меньшему риску, если они сочетаются с хорошей автоматизацией тестирования и выпуска. Это может быть связано с переключателями функций, чтобы функции можно было включить полностью, когда создание пользовательских историй завершено.
Я прочитал ваше обновление. Ваша проблема в том, что вы отправили бракованный товар. Вот и все. Вот над чем вам нужно работать — не отправляйте сломанные продукты.
Ваша жалоба нелепа. ВЫ решили отправить товар, когда он был сломан. Вот где доллар останавливается, с вами.
Затем вы допустили две ошибки: во-первых, кажется, что время вашего освобождения было таково, что вам об этом сказали в 16:00. Релиз за полчаса до прихода разработчиков на работу. Очень простое решение, это ваша работа знать это. Во-вторых, кажется, что у работника нет мотивации работать сверхурочно. Оплата сверхурочных обычно работает довольно хорошо. Среда, в которой вы допускаете регулярную поставку неисправного кода, этого не делает.
В свете обновленного вопроса я предполагаю, что, хотя у вас может быть проблема с отношением сотрудников , на самом деле у вас есть проблема с качеством программного обеспечения :
Не существует процесса обеспечения качества, независимого от разработчиков, которые пишут эти функции. Разработчики, как известно, плохо тестируют свой собственный код, в основном потому, что они, естественно, начинают с предположения, что все, что они написали, работает и должно работать так, как они задумали , а не так, как ожидает конечный пользователь .
Какая бы среда тестирования у вас ни была, она не подходит для воспроизведения проблем, выявленных вашими клиентами. Вы выявили ошибки, препятствовавшие входу в систему на нескольких этапах процесса, но окончательная проверка не выявила эту проблему.
Старший разработчик готов игнорировать критические проблемы, которые на самом деле являются критическими . «Чувак, мы с друзьями собирались сделать что-нибудь классное сегодня вечером» — это не та реакция на «никто не может войти в систему, поэтому наш бизнес теряет 100% возможного дохода от этих продуктов, который мы используем для выплаты вашей зарплаты», как вы хотите. чтобы увидеть. Если он так реагирует на чрезвычайную ситуацию, как вы думаете, как он справляется с мелкими вещами? С большим вниманием к деталям или с меньшим?
В вашей обновленной истории есть определенная часть, которая вызывает у меня еще много вопросов, и я думаю, вам нужно изучить ее подробно: в какой-то момент команда сказала, что они написали все тесты, и проблем не было. Затем вы говорите позже, что было обнаружено, что не все тесты были написаны в конце концов, что ошибка входа в систему не была идентифицирована, и что вы потратили дополнительное время на написание этих тестов и исправление проблемы входа в систему, что позже было продемонстрировано в производстве для не фиксироваться.
Когда вы сказали, что тесты все-таки не были написаны, почему они не были написаны? Был ли рассматриваемый случай недосмотром, или команда исказила завершение своей работы? Разумно ожидать, что первое будет происходить время от времени, второе — неприемлемое поведение, которое вы должны прояснить, что оно не будет допущено в будущем (если только это не было недоразумением с вашей стороны).
После того, как тесты были написаны, как вы узнаете, что эти тесты верны? Вы анализировали тесты? Ясно, что они не работают; все они прошли успешно, но проблема, которая была явно проверена и заявлена как исправленная, все же попала в производство. Нередки случаи, когда недобросовестные люди пишут тесты так, чтобы они всегда проходили успешно, особенно в условиях сжатых сроков. Если вы не в состоянии проверить тесты самостоятельно, вам следует найти кого-то из технических специалистов из другой команды, который проверит тесты за вас.
Там еще кое-что вы написали, что количество критических багов сейчас доходит до одного раза в месяц, а раньше было скорее раз-два в год. Почему это? Вы проводили какое-либо расследование, почему это происходит сейчас? Изменился ли продукт или команда за это время? Такое впечатление, что качество падает.
Вот что я думаю, что вы должны сделать:
Наймите хорошего, опытного QA-тестировщика и подвергните всю работу этой команды независимому QA-тестированию (вы должны сделать это во всей вашей компании, но эта команда особенно нуждается в этом, потому что качество падает).
Просмотрите тестовую среду и сравните ее с рабочей, чтобы убедиться, что тестовая среда по-прежнему соответствует рабочей среде.
Проверяйте качество и правильность тестов и кода, которые пишет ваша команда, на регулярной основе и более подробно, чем вы это делаете сейчас.
У вас может быть проблема с отношением в вашей команде к старшему парню, но у вас определенно есть проблема с качеством. Проблемы с отношением трудно исправить, но проблемы с качеством исправить легче, и у них есть дополнительный бонус в том, что отношение одного человека в команде становится неуместным, если вы делаете это правильно.
Будучи старшим членом команды и постоянно сталкиваясь с такими ситуациями, я могу только сказать, что парень, на которого всегда можно положиться, тоже нуждается в некоторой мотивации. Парень, безусловно, честный и имеет право на личную жизнь после работы, но он останется и будет исправлять ошибки, если у него будет лучшая мотивация или если вам удастся создать для него дружелюбную среду.
Подумайте об этом с другой стороны: что, если парень заболеет, или уволится с работы, или возникнет какая-то чрезвычайная ситуация, и ему придется на время покинуть офис. В настоящее время его время с друзьями кажется для вас проблемой, но у него могут быть все законные потребности покинуть офис даже в рабочее время (и проводить время с друзьями после работы также является законной потребностью).
Очень распространенная управленческая позиция заключается в том, чтобы всегда нападать на парня, который может это сделать . Это зависит от человека к человеку, но, будучи сотрудником, это может привести к разочарованию, и такая ситуация возникает, когда сотрудник начинает говорить вам «нет» .
Итак, на мой взгляд, вам нужно сделать две вещи:
1: ) Вы должны создать платформу обучения для младшего персонала и постепенно делегировать вещи, чтобы в момент острой необходимости вам не приходилось каждый раз смотреть на одного и того же парня.
2:) Пока в рабочее время парень делает то, что должен делать, и выполняет свои KPI, с ним все в порядке, и с ним нужно обращаться по-дружески.
Мне кажется, что он просто больше ценит пребывание вне офиса, чем в нем.
Тому есть много причин, и хороший менеджер не стал бы просто предполагать худшее. Возможно, у него дома личные проблемы, будь то отношения, болезнь или любые другие стрессы.
Возможно, он становится все более неудовлетворенным своей работой, и ему просто все равно.
Есть много причин, по которым он может вести себя именно так. Я бы посоветовал посмотреть, есть ли что-то, за что вы хотели бы дать дополнительную милость, прежде чем вы слишком сильно надираетесь или наказываете его.
Добро пожаловать в WorkPlace, где во всем виноват менеджер. Все .
Я смотрю на то, как они сказали, что продукт готов, а его нет, поэтому они должны держать свои слова. - Код проекта
Сформулируйте вопрос по-другому .
У вас есть старший инженер, на которого возложена ответственность за функцию, он отвечает за тестирование и сдал конечный продукт. Этот продукт, получивший зеленый свет, имеет серьезные проблемы с качеством. (И я согласен, что ваше определение довольно критично!)
Другими словами, у вас есть неэффективный старший инженер, который не хочет работать сверхурочно, чтобы исправить свои собственные ошибки (или, как вы выразились, выполнить свои обещания).
Но ключ здесь не в том, что инженер не будет работать сверхурочно — судя по комментариям, у вас есть мобильное приложение, так что вы все равно не сможете быстро выпустить исправление.
Ключевой вопрос заключается в том, что старший инженер в первую очередь дает зеленый свет этим неисправным продуктам.
Ожидания / законность здесь сильно зависят от того, где вы находитесь, но лично я никогда не работал в компании (США или Япония), где отсутствие собственности вашего старшего инженера было бы принято. Независимо от того, виновен он или нет, критическая ошибка должна быть исправлена как можно скорее. К счастью, я также не работал в компании, где мне хотя бы не заплатили (в разумных пределах) за мои усилия по исправлению собственных ошибок.
Следующим шагом здесь является рассмотрение и поиск причин возникновения этих ошибок. Большинство ответов здесь предполагают, что проблема носит системный характер - я бы сказал, что проблема есть только у одной из ваших нескольких команд, что говорит об обратном.
Тем не менее, вы должны проверить, найти причину и попытаться ее исправить. Если это просто неэффективный старший инженер, то необходимо предпринять шаги, чтобы поднять этого инженера на должном уровне или найти другого инженера, который может выполнять работу должным образом.
Кажется, пора поставить на заметку всю эту команду. Если они не начнут выполнять руководящие принципы, четкие руководящие принципы, они будут прекращены.
Вы можете добиться этого, установив рекомендации по ошибкам/проблемам, о которых сообщается относительно того, что они поддерживают. Например, ошибка с приоритетом 1 должна быть запущена в работу в течение 1 часа, после чего каждый час сообщается о прогрессе руководству (вам) до тех пор, пока ошибка не будет исправлена или не будет найдено обходное решение к вашему удовлетворению. Ваше удовлетворение является ключевым, и вы должны поддерживать их и другие команды в выполнении задач, когда работа выходит за рамки обычного рабочего времени, присутствуя или будучи в высокой степени доступным.
Когда они выходят из строя и уходят домой, значит, они не выполнили ваши требования по работе над проблемой и проверке каждый час. Теперь это измеримо. Эти рекомендации должны соблюдаться и другими командами.
Теперь, когда они не выполняют эти требования один раз, они направляют уведомление, официальное письменное уведомление, CC вашему менеджеру и отделу кадров о том, что они не выполнили свои обязательства. Во второй раз вы снова сообщаете, сообщаете команде, что третий инцидент является основанием для увольнения. В третий раз уволили.
Теперь я предполагаю, что у этого старшего разработчика есть некоторые критические знания, которые, по его мнению, делают их бесценными. Никто не настолько ценен, и это посылает такое сообщение. Они не поддерживают компанию, компания больше не будет их поддерживать.
Ожидайте некоторых последствий, если дело доходит до прекращения. Они действительно обладают знаниями, которые потребуют некоторых усилий, чтобы идти в ногу с другими. Удостоверьтесь, что младшие разработчики знают эти правила, если они могут начать тянуть вес, даже если их старший бросит их, тогда они смогут продолжать работу, когда вы устраните нарушителя спокойствия.
Every time there is a critical bug...ясно дает понять, что это происходит довольно часто. И это говорит мне о том, что ОП, вполне возможно, терпит неудачу в своей работе и оказывает давление там, где ему не место. Лично я думаю, что ОП необходимо пересмотреть, почему они развертывают код с такими ошибками в производстве, и, возможно, выяснить, как это исправить, прежде чем увольнять людей. Другими словами, я пытаюсь понять, почему в месте с 20 разработчиками нет надлежащего тестирования или даже реальной производственной команды для решения этих проблем.
Нео
DJClayworth
DJClayworth
Марсель
Код проекта
17 из 26
А. Дж. Фарадей
Код проекта
17 из 26
технофил
Джо Томкс
пользователь86742
джйятт
Аарон Ф
17 из 26
CL40
If there is a critical bug, they must fix it even if they have to stay late.Это шутка ОП? Будьте не столько погонщиком рабов, сколько лидером. RE: В прошлый раз, когда они остались допоздна, я дал им дополнительные 2 выходных. Это тоже просто глупо. Думали ли вы, что 2 дополнительных дня не имеют значения, если они пропустили что-то важное в тот день, когда они задержались? Знаете ли вы, как при этом накапливаются плохой сон и эмоциональное выгорание? Их обязательства перед вами ограничены, вы используете собственность как своего рода культовое оружие, чтобы контролировать их, и, похоже, старший видит это насквозь.франконд
ВеликобританияОбезьяна
ВЛАЗ
Марк Роттевил
БиттерманЭнди
Воо
семьдесят восьмой
Боб Джарвис - Слава Україні
арот
Гейб Сечан
смки
смки
смки
смки
Код проекта
Харпер - Восстановить Монику
Марс
Марс
семьдесят восьмой
смки
смки
Марс
Марс
Марс
смки
Марс
смки
смки
Марс
Марс
Марс
Марс
Наум
смки
смки
Марс
Марс
смки
Прасад Рагхавендра
If there is a critical bug, they must fix it even if they have to stay late.Как насчет тебя, приятеля-менеджера? Надеюсь , вы исправите хотя бы половину из них, прежде чем спрашивать других. Потому что вы руководитель и ничего вразумительного не объяснили, как вы держите буфер для критических багов и как оплачиваете сверхурочные.