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

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

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

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

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

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

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

• Компания может не оценить их старания, но ничто не мешает вам это сделать. Говоря «спасибо» за хорошо выполненную работу, хваля хорошую работу и искренне выражая признательность, когда кто-то делает все возможное, вы покажете, что признаете их тяжелую работу. (Также время от времени приносите коробку пончиков, и это будет творить чудеса!)
• Быть гибким. Опять же, я не знаю, чем вы занимаетесь, но если возможно, постарайтесь облегчить людям жизнь. Позвольте им уйти пораньше, если у них назначена встреча или им нужно забрать своих детей. Я считаю, что если вы даете некоторую слабину в таких ситуациях, вы получите ее вдвойне, когда сроки сжаты или спина прижата к стене. Все дело в том, чтобы давать и брать.
• Помощь в карьере. Общайтесь с членами вашей команды. Узнайте, где они хотят быть через 5 лет. Попробуйте (это не всегда возможно) познакомить их с такой работой. Может быть, это изучение нового навыка или технологии, может быть, это другая работа (продажи, поддержка, управление проектами). Если люди учатся и чувствуют вызов своей работе, они, вероятно, будут работать усерднее.
• Будьте защитником. Все предыдущие пункты мало попадают в эту категорию. Вам нужно, чтобы они знали (или, по крайней мере, чувствовали), что, хотя компания хочет, чтобы вы управляли ими, вы также сражаетесь на их стороне. Скажите тогда, что вы цените положение, в котором они находятся, но также скажите им, что вы пытаетесь его изменить. Расскажите им, что вы пробовали и какие успехи у вас есть.
• Общаться. Продолжая вышеизложенное, сообщите о своем прогрессе. Если вы услышите что-то от руководства, решите, чем вы можете поделиться с командой. Если они чувствуют себя вовлеченными, они будут чувствовать себя вовлеченными и, следовательно, более преданными делу.
• Следите внимательнее. Вышеупомянутое не будет работать для всех. В этих случаях вам нужно следить за ними более внимательно. Знайте, над чем они работают. Попросите их зафиксировать время доставки (вам нужно знать, разумно ли это или это дополнено), а затем регулярно проверяйте, чтобы убедиться, что они уложились в этот срок. Если нет, узнайте почему. Вы не стремитесь к конфликту, это должно быть обсуждение типа "ну как я могу помочь вам уложиться в срок в следующий раз" - может быть, процесс нужно улучшить, может быть, они были прерваны или переназначены, может быть, что-то пошло не так. . Если сроки постоянно срываются, вам, вероятно, придется пойти по пути дисциплинарного взыскания.

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

Вы должны выяснить, ПОЧЕМУ им приходится работать сверхурочно. Являются ли они в целом непродуктивными или сроки нереалистичны? Если они нереалистичны, вам нужно предпринять шаги, чтобы сделать их реалистичными... Вовлеките команду в оценку временных масштабов; и если руководство настаивает на нереалистичных временных масштабах, вам нужно настаивать на дополнительных ресурсах.

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

Проблема культуры

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

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

• Недостаточно времени/ресурсов, потраченных на тестирование
• Недостаточно времени на документирование + рецензирование кода
• Слишком много внимания уделяется доставке
• Готовность накапливать неограниченный технический долг

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

Холодное чтение

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

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

Вылезти из ямы

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

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

• Модульные тесты — я думаю, что 80% — это абсолютный минимум для долгосрочной поддерживаемой кодовой базы. Я стремлюсь к 98%+, и это почти всегда достижимо. Речь идет не о том, чтобы поставить галочку в контрольном списке мазохистского SDLC. Во-первых, не весь код легко тестировать. Написание тестов для такого кода заставляет разработчика переосмыслить дизайн и организацию кода. Возможность модульного тестирования кода делает его лучше. Я говорю это как абсолютную истину, потому что верю в это и никогда не видел контрпримера. Кроме того, модульное тестирование выявляет множество ошибок, которые в конечном итоге проявляются в производственной среде, причем часто коварным и трудновоспроизводимым образом. Наконец, модульные тесты служат своего рода документацией намерений разработчика, когда первоначальный кодировщик перешел к другому проекту, а сопровождающий пытается сделать вывод, чего он пытался достичь. Я утверждаю, что модульные тесты всегда экономят больше времени, чем стоят, поэтому опытные разработчики будут тратить время на их написание. К сожалению, я бы поставил на то, что менее 20% разработчиков во всем мире считаются «зрелыми» по этому показателю. :/ Вы не можете сказать, насколько хорошо вы справляетесь с модульным тестированием, пока не внедрите анализатор покрытия кода в процесс сборки и не поместите результаты на "
• Приемочные тесты — вашей команде нужно исправить множество ошибок, потому что вы передали надлежащее тестирование своим пользователям, и это вполне понятно злит вашего босса. Ваши разработчики ленивы, считают, что тестированием должен заниматься кто-то другой (например, выделенные тестировщики), и явно не поддерживают набор автоматизированных тестов. Вам нужны тесты, которые запускаются при каждом слиянии, при каждой производственной сборке, при каждом развертывании в каждой тестовой среде и при каждом производственном развертывании. Вам нужен широкий охват за счет рандомизированной генерации тестов и обширной проверки данных в вашем коде. Это целая тема сама по себе, но также является основой вашей проблемы. Вам не нужно писать тысячи тестовых случаев, чтобы иметь полезный набор приемочных тестов. Но вам нужно найти хорошую среду тестирования, освоиться с ней и сделать ее своим новым лучшим другом.
• Обзор кода — многие разработчики не получают пользы от обзора кода, который легко доступен. Во-первых, проверка кода должна помочь поддерживать единый стиль и подход в команде. Я не думаю, что разработчикам нужно писать код, как если бы все они были клонами, в стиле XP. Но это помогает обеспечить соблюдение некоторых общих стандартов, не превращаясь в войны форматирования. Это распространяется на шаблоны проектирования и идиомы кодирования, которые часто встречаются в вашей проблемной области. Во-вторых, проверка кода — это возможность учиться как для автора, так и для рецензентов. Это особенно хороший способ для младших разработчиков перенять передовой опыт у старших (при условии, что старшие на самом деле хорошие программисты). Рецензенты должны задавать много вопросов всякий раз, когда код не ясен, и процесс должен быть совместным, а не конфронтационным. Третий, хорошие рецензенты часто могут обнаружить ошибки, просто прочитав код. Это не будет происходить постоянно и не заменит тестирование. Но этоприятный бонус , и тот, который вы получаете «бесплатно» только потому, что потрудились попросить двух других людей прочитать ваш код. Каждое слияние должно иметь код-ревью .
• Написание хорошей документации игнорируется примерно 95% всех разработчиков, учитывая мое крайне ненаучное суждение. Вам не нужна документация уровня НАСА для улучшения вашей кодовой базы, и не весь код требует такого же уровня документации. В общем, чем больше кода повторно используется, тем больше документации он должен иметь. Таким образом, любые разделяемые библиотеки/классы/модули должны иметь дополнительную документацию, особенно для таких вещей, как безопасность потоков, безопасность исключений, предполагаемое использование, подробные API-интерфейсы функций, обработка нулей и т. д. Индивидуальный код приложения должен быть более понятным и самостоятельным. документирование. Опять же, вы не можете сказать, насколько хороша ваша документация, пока вы не сгенерируете ее как часть процесса сборки и не опубликуете на локальном веб-сервере. Множество ошибок возникает из-за несоответствия предположений и ожиданий между инженерами (о допустимых значениях для полей, где происходит проверка и т. д.). Документация помогает смягчить этот режим отказа.
• Рефакторинг — это одна из самых ценных вещей, которую вы можете сделать для грубой кодовой базы, которая приобрела много технических долгов. Это, пожалуй, второето, что вы должны сделать (конечно, после написания модульных тестов!). Для небольшой компании или стартапа бывают случаи, когда быстро двигаться и ломать вещи — правильный курс действий. Но это не может поддерживаться бесконечно. Если вы не будете сильно настаивать на паузах в рефакторинге, то ваша команда в конце концов упадет с обрыва технического долга (звучит так, как будто она держится за крошечную ветку, пока мы говорим). Хорошие инженеры в любом случае должны настаивать на рефакторинге. Тот факт, что вы не упомянули какие-либо средства защиты, поддерживаемые разработчиками, говорит мне о том, что вам не хватает таких инженеров. Код не обязательно должен быть идеальным в первый раз, когда вы его пишете (и почти никогда не будет). Но вы должны иметь возможность улучшать его каждый раз, когда прикасаетесь к нему. Рефакторинг должен быть второй натурой для всей вашей команды, и каждый должен чувствовать себя способным сделать это. когда изменения явно выгодны для всей команды. Очевидно, вы хотите избежать бесполезного рефакторинга. Но я сомневаюсь, что это даже риск для вашей команды.
• Эксплуатация/метрики. Вам нужны не только тесты на уровне кода и внешние по отношению к вашему продукту, вам также нужны операционные метрики, чтобы увидеть, как работает ваш продукт. И эти метрики должны включать в себя параметры качества (количество транзакций, скорость, количество/коэффициент ошибок и т. д.). Ваш начальник не должен требовать, чтобы вы исправляли ошибки. У вас должны быть свои собственные цели качества, определенные командой, которые заставят вас переходить в режим очистки, когда вы отклоняетесь от них.

Следующие шаги

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

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

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

Удачи!

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

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

Сосредоточьтесь на сотрудниках. Убедитесь, что вы проводите (лучшая практика) еженедельные встречи один на один, чтобы обсудить более крупные цели, большие идеи, профессиональное развитие. Вот отличный ресурс со смесью платных и бесплатных предложений — в бесплатных материалах есть реальная ценность: https://www.manager-tools.com/

В частности, ищите информацию о встречах «один на один».

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

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

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

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

Вы используете формальный процесс? Я предполагаю, исходя из контекстных подсказок и вашего другого вопроса, что вы а) создаете программное обеспечение и б) в Китае. «a» имеет значение, «b» может не иметь значения, но имейте в виду, что я исхожу из перспективы Соединенных Штатов/Канады, и могут быть культурные/обученные модели поведения, которые влияют на жизнеспособность моих предложений или требуют их адаптации. Эти предложения основаны на более чем 20-летнем опыте профессиональной разработки программного обеспечения и опыте работы в компаниях, начиная от крошечных стартапов и заканчивая крупными глобальными предприятиями, и имеющих все, от чрезвычайно поддерживающего руководства до деспотов, управляющих делами.

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

Последний пункт, вероятно, самый важный, но первые 4 — это то, что поможет вашей команде. Вы не можете заставить людей «сосредоточиться», по крайней мере, неэффективно.

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

Отвечая конкретно на этот бит:

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

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

Исправьте это, установив цель на день, над которой команда может работать: «Еще 3 ошибки, и мы все сможем вернуться домой. X, если вы закончили свою ошибку, можете ли вы объединиться с Y, чтобы мы все могли вернуться домой быстрее». ?"

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

Плохие условия труда сказываются на ваших сотрудниках — неважно, кто в них виноват.

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

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

Отвечая на ваше первое обновление:

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

В воскресенье? Я бы сказал, что по крайней мере восемь часов приемлемо. Хотя я бы надеялся, что им надоест раньше!

Для начала, почему бы вам не сделать работу на выходных более увлекательной?

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

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

Так что смиритесь с тем, что никто все равно ничего не сделает, вы ведь можете придумать что-нибудь получше, чем просмотр социальных сетей?

Вы можете начать с игр по программированию, таких как TIS-100 и Shenzhen I/O , и соревноваться друг с другом за высокие баллы.

Как только все немного расслабятся и повеселятся, может быть, вы могли бы подумать о проекте по программированию, над которым вы могли бы поработать вдесятером вместе? Может быть, у кого-то из вас уже есть идеи?

Это выходные! Вам не платят. Так что делай, что хочешь.

Затем, может быть , если вам так хочется , в последний час каждой субботы и воскресенья вы можете сказать: "Хорошо, ребята! Давайте каждый из нас возьмем ошибку и потратим последний час сегодняшнего дня на ее исправление!"

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

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

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

Если вы можете исправить список ошибок, вам больше не нужно будет приходить на выходные (как бы вам этого ни хотелось после реализации последнего бита ;-))

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

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

Я думаю, что до сих пор никто не обратился к следующему: люди сосредотачиваются на «нельзя» (что я полностью поддерживаю) или сосредотачиваются на некоторых методах кодирования.

Если вы не можете полностью отменить неоплачиваемую сверхурочную работу (как она исходит сверху), что вы можете сделать?

• Можете ли вы предоставить гибкий график работы? «Ребята и девушки, я знаю, что нам нужно работать 80 часов в неделю, но в моей команде вы можете приходить и уходить, когда хотите, вам просто нужно отсчитывать эти часы, потому что я пока не могу это изменить».
• У вас есть средства для компенсации? Некоторое финансовое вуду может быть в ваших руках. «Я знаю, что сверхурочные на самом деле не оплачиваются компанией, но каждый сотрудник в моей команде получает бонус в размере 1000 долларов, если мы исправим 100 ошибок к концу года».
• Получите неденежную компенсацию, а-ля Google сделал это, чтобы люди дольше оставались в офисе. «Люди, работающие сверхурочно, получают трехразовое питание бесплатно, получают пропуск в тренажерный зал и могут бесплатно посещать терапевта в редкие нерабочие часы». Я преувеличиваю, конечно.
• Вещи, которые я не придумал, но поддерживаю вашу команду всеми возможными способами. Купите им компьютеры получше. Переместите их в лучший офис. Перережь горло высшему менеджеру и отмени неоплачиваемую сверхурочную работу. Такие вещи.
• Если ничего не получается: уволиться всей командой и найти новую работу/запустить стартап.

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

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

Угадай, кто хуже всех, и накажи их первыми, назови их поощрительными les autres.

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