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

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

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

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

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

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

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

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

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

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

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

Ваша миссия

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

Технологии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Продукт

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

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

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

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

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

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

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

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

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

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

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

Руководство

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

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

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

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

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

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

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

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

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

Наём

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

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

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

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

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

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

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

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

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

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

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

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

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

Результат

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

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