„Прост саботаж“ в сферата на софтуера

В кулминационния момент на Втората световна война ЦРУ издава страхотна книга, наречена “ Прост саботаж“ (Simple Sabotage). В нея са описани различните начини, по които саботьорът или диверсантът могат да намалят производителността на компанията. Някои от тези съвети не остаряват, като например разделът „Обичайни нарушения на организациите и производството“:

1. Настоявайте всичко да се извършва по независими „канали“. Не позволявайте да се използват преки пътища за ускоряване изпълнението на решенията.
2. Изготвяйте „доклади“. Говорете колкото е възможно по-често и по-дълго. Илюстрирайте „идеите“ си с дълги житейски истории и се позовавайте на личния си опит. С готовност правете „патриотични“ коментари.
3. Ако е възможно, изпращайте всички въпроси на комисиите за „по-задълбочено проучване и разглеждане“. Стремете се да съставяте възможно най-големи комисии, с поне петима членове.
4. Колкото е възможно по-често повдигайте въпроси за несъществени проблеми.
5. Настоявайте за ясни формулировки в съобщенията, протоколите, резолюциите.
6. Връщайте се към теми, по които има взето решение на последното заседание, и се опитвайте отново да отворите въпроса за целесъобразността на това решение.
7. Съветвайте всички да бъдат „внимателни“. Бъдете „разумни“ и насърчавайте другите на заседанията да бъдат „разумни“, за да не прибързват с неща, които могат да причинят бъдещи неудобства или трудности.
8. Тревожете се за целесъобразността на всяко решение, повдигайте въпроса дали разглежданото действие ще попадне в юрисдикцията на групата или може да предизвика конфликт с политиките на някой по-висш ешелон.

Винаги ме е поразявало колко добре са издържали тези съвети проверката на времето. Дори разпечатах тази част и я окачих в рамка в кабинета си:

Вашата мисия

Да приемем, че сте наети на позиция главен технически директор и искате да намалите колкото се може повече производителността на предприятието, но без да ви хванат. Разбира се, можете да вземете поредица от очевидно лоши решения, но тогава съвсем скоро ще бъдете уволнени. Истинската цел тук е постепенно да изсмучете производителността на компанията, като същевременно поддържате фасадата на правдоподобност и нормалност. И така, какво може да се направи, за да се постигне това?

Технологиите

• Когато поемете управлението, изискайте пренаписване на основните правила, което би трябвало да отнеме 6-18 месеца. Задължително обвинете бившия главен технически директор.
• Накарайте всички да използват свой собствен програмен език и свой по-различен фреймуърк.
• Разделете системите по произволни граници: увеличете максимално броя на участващите във всяка функция системи.
• Насърчавайте изграждането на сложна структура на развойната среда: направете я мрежа от системи с поне десетина онлайн услуги.
• Направете производствената среда възможно по-различна от средата за разработка.
• Извършвайте внедряванията колкото е възможно по-рядко. Уверете се, че са взети максимални предпазни мерки по отношение на внедряването. Използвайте всеки проблем в производството като причина да „натиснете спирачките“.
• Въведете колкото се може по-сложни процеси за промени в сорс кода и в стандартните работни процеси. Оправдайте го с “ безопасността“ или „съвместимостта“.
• Направете така, че всяка задача и всеки алгоритъм да се проследяват в тракер за задачи; те трябва да се преглеждат, приоритизират и одобряват от екип от поне пет души.
• Не допускайте нищо извън обхвата на първоначалната задача, като например прочистване на кода и други подобрения, направени по време на работа.
• Създавайте вътрешни версии на почти всичко, което не е основна компетентност. Оправдайте го с това, че „не искате да зависите от външен доставчик“.
• Настоявайте да бъдат добавяни слоеве на абстракция върху буквално всяко нещо. Изберете доставчици, които сами по себе си са абстракции, и след това добавете нови слоеве абстракция.
• Налагайте технически решения, основани на прекалено оптимистични очаквания за мащабите. Планирайте поне три порядъка по-голямо работно натоварване, отколкото е сега.
• Стимулирайте колективната собственост върху системите. Направете така, че никой да не се чувства отговорен за тяхната поддръжка.
• Настоявайте за централизиране на почти всичко във вид на „платформа“, притежавана от „екип на платформата“. Намалете персонала на екипа на платформата и не позволявайте на другите екипи да създават неща, които платформата може да „притежава“.
• Накарайте екипа на платформата да работи итеративно върху API, като го променя често, и задължете всички останали екипи да преработват кода към най-новата версия на API възможно най-често.
• Наемете „архитекти“ и изисквайте дори малките промени да подлежат на „архитектурен контрол“.
• Изисквайте дори малките промени да бъдат обект на „контрол на сигурността“.

Продукцията

• Игнорирайте полезните показатели, като ги обосновавате научно (напр. като ги наричате „изкривяване“ или „изоставащи показатели“).
• Избирайте тщеславни метрики с малка или никаква връзка с бизнес стойността и високи нива на шумотевица.
• Настоявайте всичко да се изпълнява като „сериозна задача“ и всичко да е абсолютно готово преди внедряването.
• Третирайте всяка функция като „задължителна“ и критична част от „нулевата версия“ на продукта. Не се поддавайте на убеждаване.
• Разработвайте невероятно подробни „стратегически“ планове.
• Често сменяйте посоката на развитие.
• Отхвърляйте очевидните подобрения като „локални оптимизации“.
• Използвайте популярните тенденции за свързване на ресурсите. Започнете да разработвате пространно формулирана „стратегия за ИИ“, която на пръв поглед изглежда правдоподобна. Харчете агресивно за продавачи и консултанти за тази стратегия.
• Стимулирайте продуктовите мениджъри да отделят по-голямата част от времето си за „стратегия“ и „планиране“.
• Направете така, че за инженерите и продуктовите мениджъри да е трудно/невъзможно да използват продукта вътрешно.
• Отказвайте да чуете мнението на потребителите, като ги наричате „глупави“.

Ръководството

• Обвържете нивото на заплатата с длъжността, а длъжността – с размера на екипа, за да мотивирате раздуването на персонала.
• Съставяйте големи и обширни отчети за стратегиите, чиповете и техническата сложност.
• Извършвайте скъпи придобивания, за да навлезете в нови области на пазара. Оправдайте го със възможна „синергия“. По-късно прекратете производството на придобития продукт.
• Използвайте множество звена в структурата на отчетността.
• Накарайте служителите да докладват на мениджъри в други екипи, офиси или с други функционални отговорности, доколкото това е възможно. Направете така, че мениджърите да не са достатъчно подготвени, за да контролират тези доклади.
• Често пренасочвайте служителите с лоши резултати към други екипи.
• Възлагайте на най-добре представящите се служители изследователски теоретични проекти с неясно зададени критерии за резултатите.
• Винаги организирайте оперативки за всяко решение, независимо колко тривиално е то.
• Настоявайте, че всяка „заинтересована страна“ трябва да присъства на срещата.

Наемането на персонал

• Организирайте процес на наемане, който изглежда обективен, но всъщност е субективен.
• Отказвайте да наемете най-добрите с мотива, че „няма да се впишат в колектива“ или по някакъв друг неясен критерий.
• Наемете най-слабите въз основа на „потенциала“, „желанието“ и други неясни критерии.
• Наемайте скъпоплатени старши служители, които ще трябва да поемат голям брой подчинени.
• Използвайте високопоставени титли и измислени длъжности, за да привлечете опортюнисти.
• Наемайте „експерти“ с висока степен на специализация и след това създавайте измислени проекти, за да ги откажете да напуснат.
• Използвайте специализацията като оправдание за наемане на друг, помощен персонал.

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

• Изисквайте изключително подробни оценки на сроковете за всеки проект.
• Мотивирайте създаването на проекти, в които участват възможно най-много екипи, в идеалния случай работещи на различни места.
• Добавяйте нови изисквания, които зависят от работата, извършена от други екипи.
• Често използвайте скъпи агенции. Определяйте амбициозни обхвати на проектите и предавайте суровите прототипи на вътрешните екипи за доработка.
• Създавайте сложни системи за „самообслужване“ за заинтересованите страни в другите екипи.

Резултатът

Това не е лесна задача! Но ако успеете да се озовете зад вражеската линия и да получите позицията на главен технически директор, може да се справите много добре със саботажа на една софтуерна компания, а и не само.

Забележка за тези, които не са саботьори: очевидно това е история за това как да извлечете максимума със своя екип. Производителността като цяло е история за хиляди срезове и съкращения, и нито едно от тези неща поотделно няма да унищожи производителността само по себе си. Но производителността се натрупва в логаритмична скала, което означава, че всички горепосочени елементи са мултипликативни. Всъщност, ако извършите 100 действия, всяко от които намалява производителността с 5%, ще забавите работата 131 пъти! Единственият начин да не измъчвате инженерите е да кажете „не“ на тези стотина малки ограничения, всяко от които изглежда съвсем правдоподобно и благовидно.

Статията предизвика многобройни коментари, като един от тях е, че ЦРУ е създадено чак през 1947 година и как тогава в кулминационния момент на Втората световна война издава книгата Simple Sabotage? Отговорът е, че всъщност книгата е издадена от Управлението за стратегически услуги (Office of Strategic Services, OSS), предшественикът на ЦРУ и авторът е решил да представи нещата именно по този начин.