Как деморализовать сотрудников: Гайд для плохих компаний

в 23:38, , рубрики: демотивация, информационная безопасность, Офисы IT-компаний, юмор

Данный гайд представляет собой перевод с небольшими художественными отклонениями опуса с The Daily WTF (How To Demoralize Employees: A DIY Guide for Terrible Companies).

image

  1. Убедитесь, что у сотрудников нет легко распознающихся посторонними логинов. Забудьте про iivanov или vpupkin и другие рекомендации новомодных веяний. Это может позволить сотрудникам чувствовать себя людьми, а не человеческими ресурсами вашей респектабельной компании! Учетные записи в Active Directory должны быть серийными номерами согласно «grid location». Убедитесь, что логины соответствуют расположению — номер здания, этаж, рабочее место. И вообще следуйте четким и удобным правилам именования, принятых в тюрьмах/концентрационных лагерях – ведь там это отлично работает!
  2. Создайте длинный, скрупулезный и сложный процесс QA, который занимает примерно 5 часов рабочего времени, чтобы пройти все тесты, даже если ошибки не обнаруживаются. Требуйте проверку кода как минимум в трех различных энвайрнментах, прежде чем он будет отправлен на мерж в продакшн ветку. На всякий случай, если работник вдруг начнет чувствовать, что этот процесс действительно полезен и необходим, покажите ему, что продакшен сервер настроен совершенно по-другому. И вообще ни один из тестовых серверов ему не соответствует.
  3. Кстати, о QA. Не утруждайте себя проверкой 3rd-party кода. Даже если этот код используется для обработки более важных бизнес-данных, чем основной код приложения. В то время как ваши сотрудники тратят время на проверку всех 30-ти пунктов касающихся стиля и качества основного кода, спокойно добавляйте сторонние библиотеки и плагины, которые выполняют критические манипуляции с данными без транзакций или корректного использования рекомендаций UPDLOCK.

    Помните: смысл существования QA — это не качество ПО. Основной смысл их существования — чтобы было на кого свалить все шишки, если что-то пойдет не так.

  4. В качестве повышения концентрации исключительно на работе, обеспечьте группе ваших сотрудников бесцветный, безликий кубический опен-спейс. А второй группе, которая выполняет практически идентичные задачи, устройте современные стоячие столы, огромные пустые пространства и окна с прекрасным видом. Удостоверьтесь, что сотрудники первой кубофермы регулярно посещают сотрудников второй группы. Но не предоставляйте никакого комфорта для этих существ — даже бесплатный кофе! Если ваши работники принесут свой кофе, объясните, что это нарушает правила. Никакого кофе и пончиков на ранее утреннее собрание! И неважно, что вторая группа появляется в офисе только к обеду.
  5. Ни при каких обстоятельствах разработчики приложения не должны разговаривать с администраторами баз данных или иметь доступ к управлению базами, словно они настоящие люди. Все сообщения должны проходить через тикеты в багтрекере. Если тикет заполнен неправильно — ни администратор, ни менеджер не должен иметь возможность исправить его самостоятельно или связаться с тем, кто его создал — они должны просто удалить/закрыть тикет с пометкой «ошибка оформления », чтобы разработчик заполнил правильный тикет с нуля. И даже если это приведет к нарушению дедлайнов — это не имеет никакого значения. Нет ничего важнее, чем правильно оформленные тикеты!
  6. Раз уж мы заговорили об этом, используйте самый надежный (проверенный десятками лет работы), пусть и громоздкий Desk Manager, который вы найдете. Не важно, что система старая, загроможденная и вообще фундаментально негодится для agile разработки. Во всех полях следует использовать проверенный годами plain text, не допуская создания таблиц или кликабельных элементов. Если сотрудник думает, что можно просто взять и отправить другому сотруднику ссылку на тикет, это значит что он глуп должен быть за это наказан! Естественно, браузер на всех рабочих машинах должен быть залочен на Internet Explorer версии 8.
  7. И вообще, права на всех рабочих компьютерах должны быть зарезаны самыми надежными и бездушными способами. Групповая политика должна гарантировать, что бесполезные вещи, такие как история браузера или история чатов Office Communicator — всегда будут отключены. Фон рабочего стола должен быть заблокирован от изменения и установлен на логотип компании очень высокого разрешения (возможно это будет единственный яркий и привлекающий элемент всего рабочего места), без возможности его отключить даже для удаленного подключения. Групповая политика должна запрещать пользователю устанавливать любое ПО, и считать его небезопасным. И даже служба IT, не должна иметь возможности устанавливать разрешенное ПО из строго определенного списка, пока не выйдет как минимум три новых версии этого продукта, чтобы считать его достаточно проверенным в деле.

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

Автор: Сергей Кулик

Источник

Поделиться

* - обязательные к заполнению поля