Простой саботаж в мире ПО

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

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

  1. Настаивайте на том, чтобы всё выполнялось через «каналы». Не допускайте того, чтобы для ускорения реализации решений выбирались кратчайшие пути.

  2. Делайте «доклады». Говорите как можно чаще и пространнее. Иллюстрируйте свои «идеи» долгими историями из жизни и ссылайтесь на личный опыт. С готовностью делайте «патриотические» комментарии.

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

  4. Как можно чаще поднимайте вопросы о несущественных проблемах.

  5. Спорьте о чётких формулировках в общении, протоколах, резолюциях.

  6. Возвращайтесь к темам, по которым было принято решение на последнем совещании, и пытайтесь повторно открыть вопрос о целесообразности этого решения.

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

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

Меня всегда поражало, насколько хорошо эти советы прошли проверку временем. Я даже распечатал этот фрагмент и повесил его в рамочке в своём офисе:

simple sabotage
Простой саботаж

Ваша миссия

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

Технологии

  • При вступлении в должность потребуйте переписать основные системы, на что должно уйти 6-18 месяцев. Обвиняйте бывшего CTO.

  • Подталкивайте всех к использованию собственного языка и фреймворков.

  • Разделяйте системы по произвольным границам: максимизируйте количество систем, задействованных в каждой фиче.

  • Стимулируйте к сложной структуре среды разработки: пусть это будет сеть систем с как минимум десятком сервисов.

  • Сделайте так, чтобы среда продакшена максимально отличалась от среды разработки.

  • Выполняйте развёртывание как можно реже. Убеждайте, что относительно развёртываний нужно проявлять максимальные предосторожности. Используйте любую проблему в продакшене как причину для «нажатия на тормоз».

  • Введите очень сложные процессы для изменений в коде и стандартных рабочих процессов. Оправдывайте это «безопасностью» или «комплаенсом».

  • Сделайте так, чтобы каждая задача отслеживалась в трекере задач; её проверкой, установкой приоритета и утверждением должна заниматься группа не менее чем из пяти человек.

  • Не допускайте ничего, выходящего а рамки исходной задачи, например, очистку кода и другие вносимые по ходу дела улучшения.

  • Создавайте внутренние версии почти всего, что не является основной компетенцией. Оправдывайте это «нежеланием зависеть от стороннего поставщика».

  • Настаивайте на добавлении слоёв абстракции поверх всего. Выбирайте поставщиков, которые сами по себе являются абстракциями, а затем добавляйте новые слои абстракций.

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

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

  • Настаивайте на централизации почти всего в виде «платформы», которой владеет «команда платформы». Недоукомплектовывайте команду платформы и мешайте другим командам создавать то, чем может «владеть» платформа.

  • Заставьте команду платформы итеративно работать над API, часто его меняя, и обязуйте все остальные команды как можно чаще рефакторить код под последнюю версию API.

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

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

Продукт

  • Игнорируйте полезные метрики, обосновывая это научно (например, называя их «перекосом» или «запаздывающим показателем»).

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

  • Настаивайте на том, чтобы всё выполнялось как «серьёзнейшая задача», и на том, чтобы перед развёртыванием всё было совершенно готово.

  • Считайте каждую фичу «обязательной» и критически важной частью «нулевой версии» продукта. Не поддавайтесь на уговоры.

  • Разрабатывайте невероятно подробные «стратегические» планы.

  • Часто меняйте направление развития.

  • Отказывайтесь от очевидных улучшений как от «локальной оптимизации».

  • Для связывания ресурсов используйте популярные тренды. Начните развивать пространно сформулированную «ИИ-стратегию», которая на поверхности кажется правдоподобной. Активно тратьте средства на поставщиков и консультантов по этой стратегии.

  • Стимулируйте менеджеров по продуктам тратить основную часть времени на «стратегию» и «планирование».

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

  • Отказывайтесь слышать мнение пользователей, называя их «глупыми».

Руководство

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

  • Делайте большие доклады о стратегиях, фичах и технической сложности.

  • Совершайте дорогостоящие приобретения, чтобы входить в новые сферы рынка. Обосновывайте это «синергией». Прекращайте эксплуатацию приобретённого продукта.

  • В структуре отчётности используйте множество связующих звеньев.

  • Максимально заставляйте сотрудников отчитываться менеджерам в других командах, офисах или с другими функциональными обязанностями. Сделайте так, чтобы менеджеры были плохо подготовлены к контролю этих отчётов.

  • Часто переводите плохо справляющихся с обязанностями в другие команды.

  • Назначайте лучших работников на исследовательские теоретические проекты с нечётко заданными критериями результатов.

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

  • Настаивайте, что на совещании должен присутствовать каждый «стейкхолдер».

Найм

  • Организуйте процесс найма, который кажется объективным, но на самом деле субъективен.

  • Отказывайте в найме лучшим, мотивируя это тем, что они «не впишутся в команду» или каким-то иным нечётким критерием.

  • Нанимайте слабейших, обосновывая это «потенциалом», «рвением» и другими нечёткими критериями.

  • Нанимайте дорогостоящих сеньор-руководителей, которые должны будут брать на себя большое количество подчинённых.

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

  • Нанимайте «экспертов» с высокой степенью специализации, а затем надуманные проекты, чтобы не дать им уволиться.

  • Используйте специализацию как оправдание для найма другого, вспомогательного персонала.

Управление проектами

  • Требуйте крайне детализированных оценок сроков по любому проекту.

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

  • Добавляйте новые требования, которые зависят от работы, выполняемой другими командами.

  • Часто пользуйтесь услугами дорогостоящих агентств. Устанавливайте амбициозные масштабы проектов и передавайте сырые прототипы на доделку внутренним командам.

  • Создавайте сложные «самообслуживающиеся» системы для стейкхолдеров в других командах.

my alt text
Кадр из видеоклипа 1994 года Sabotage группы Beastie Boys. Текст песни в основном посвящён технологическому руководству и продуктивности разработчиков.

Результат

Это непростая задача! Но если вы сможете высадиться в тылу врага и получить должность CTO, то у вас может всё получиться.

Примечание для тех, кто не диверсант: очевидно, это история о том, как достичь максимума со своей командой. Продуктивность в целом — это история о тысяче порезов, и ничто из этого по отдельности само по себе не уничтожит продуктивность. Но продуктивность накапливается по логарифмической шкале, то есть все перечисленные пункты мультипликативны. По сути, если совершить 100 действий, каждое из которых снижает продуктивность на 5%, то работа замедлится в 131 раз! Единственный способ не мучать инженеров — это сказать «нет» этой сотне мелких порезов, каждый из которых кажется вполне правдоподобным и благовидным.

Источник: https://habr.com/ru/articles/782278/


Интересные статьи

Интересные статьи

Больше четверти населения Земли — свыше 2 млрд человек — лишены полноценного доступа к питьевой воде, по оценкам ООН. И недостаток в пресной воде только возрастает. Однако новые технологии могут его в...
В конце года мы рассказывали о необычных муз. инструментах, стримах и стартапах. Решили продолжить обсуждение, но при этом разбавить различные материалы о стриминге заметками о продуктивной работе и л...
Впервые о намерении создать полноценный плавучий дата-центр компания Nautilus Data Technologies (NDT) заявила несколько лет назад. В 2015 году она разработала и протестировала прототип,...
Привет, Хабр! Пару лет назад я начала публиковать обзорные статьи игровых облачных сервисов — как российских, так и зарубежных. Облачный гейминг набирает обороты, так что названия гла...
Наследники Коносуке Мацуситы удивили посетителей CES 2020 первыми в мире VR-очками c поддержкой HDR. Представленное устройство оказалось прототипом, при этом вызвало живой интерес посетителей и э...