Данный гайд представляет собой перевод с небольшими художественными отклонениями опуса с The Daily WTF (How To Demoralize Employees: A DIY Guide for Terrible Companies).
- Убедитесь, что у сотрудников нет легко распознающихся посторонними логинов. Забудьте про iivanov или vpupkin и другие рекомендации новомодных веяний. Это может позволить сотрудникам чувствовать себя людьми, а не человеческими ресурсами вашей респектабельной компании! Учетные записи в Active Directory должны быть серийными номерами согласно «grid location». Убедитесь, что логины соответствуют расположению — номер здания, этаж, рабочее место. И вообще следуйте четким и удобным правилам именования, принятых в тюрьмах/концентрационных лагерях – ведь там это отлично работает!
- Создайте длинный, скрупулезный и сложный процесс QA, который занимает примерно 5 часов рабочего времени, чтобы пройти все тесты, даже если ошибки не обнаруживаются. Требуйте проверку кода как минимум в трех различных энвайрнментах, прежде чем он будет отправлен на мерж в продакшн ветку. На всякий случай, если работник вдруг начнет чувствовать, что этот процесс действительно полезен и необходим, покажите ему, что продакшен сервер настроен совершенно по-другому. И вообще ни один из тестовых серверов ему не соответствует.
- Кстати, о QA. Не утруждайте себя проверкой 3rd-party кода. Даже если этот код используется для обработки более важных бизнес-данных, чем основной код приложения. В то время как ваши сотрудники тратят время на проверку всех 30-ти пунктов касающихся стиля и качества основного кода, спокойно добавляйте сторонние библиотеки и плагины, которые выполняют критические манипуляции с данными без транзакций или корректного использования рекомендаций UPDLOCK.
Помните: смысл существования QA — это не качество ПО. Основной смысл их существования — чтобы было на кого свалить все шишки, если что-то пойдет не так.
- В качестве повышения концентрации исключительно на работе, обеспечьте группе ваших сотрудников бесцветный, безликий кубический опен-спейс. А второй группе, которая выполняет практически идентичные задачи, устройте современные стоячие столы, огромные пустые пространства и окна с прекрасным видом. Удостоверьтесь, что сотрудники первой кубофермы регулярно посещают сотрудников второй группы. Но не предоставляйте никакого комфорта для этих существ — даже бесплатный кофе! Если ваши работники принесут свой кофе, объясните, что это нарушает правила. Никакого кофе и пончиков на ранее утреннее собрание! И неважно, что вторая группа появляется в офисе только к обеду.
- Ни при каких обстоятельствах разработчики приложения не должны разговаривать с администраторами баз данных или иметь доступ к управлению базами, словно они настоящие люди. Все сообщения должны проходить через тикеты в багтрекере. Если тикет заполнен неправильно — ни администратор, ни менеджер не должен иметь возможность исправить его самостоятельно или связаться с тем, кто его создал — они должны просто удалить/закрыть тикет с пометкой «ошибка оформления », чтобы разработчик заполнил правильный тикет с нуля. И даже если это приведет к нарушению дедлайнов — это не имеет никакого значения. Нет ничего важнее, чем правильно оформленные тикеты!
- Раз уж мы заговорили об этом, используйте самый надежный (проверенный десятками лет работы), пусть и громоздкий Desk Manager, который вы найдете. Не важно, что система старая, загроможденная и вообще фундаментально негодится для agile разработки. Во всех полях следует использовать проверенный годами plain text, не допуская создания таблиц или кликабельных элементов. Если сотрудник думает, что можно просто взять и отправить другому сотруднику ссылку на тикет, это значит что он глуп должен быть за это наказан! Естественно, браузер на всех рабочих машинах должен быть залочен на Internet Explorer версии 8.
- И вообще, права на всех рабочих компьютерах должны быть зарезаны самыми надежными и бездушными способами. Групповая политика должна гарантировать, что бесполезные вещи, такие как история браузера или история чатов Office Communicator — всегда будут отключены. Фон рабочего стола должен быть заблокирован от изменения и установлен на логотип компании очень высокого разрешения (возможно это будет единственный яркий и привлекающий элемент всего рабочего места), без возможности его отключить даже для удаленного подключения. Групповая политика должна запрещать пользователю устанавливать любое ПО, и считать его небезопасным. И даже служба IT, не должна иметь возможности устанавливать разрешенное ПО из строго определенного списка, пока не выйдет как минимум три новых версии этого продукта, чтобы считать его достаточно проверенным в деле.
P.S. Практически каждый пункт в том или ином виде был замечен в реальных компаниях. Правда иначе не было бы так смешно грусто (на выбор).
Автор: Сергей Кулик
