Comments 35
+Саботаж с отключением интернета.
Ну оно же)
Разделяйте системы по произвольным границам: максимизируйте количество систем, задействованных в каждой фиче
Лиды и сеньоры такое махом спалят, и, если заметят в этом систематичность, быстренько эскалируют свои подозрения до начальства мимо CTO.
Вы не понимаете, это микросервисная архитектура! =)
Ну что вы, какие лиды! Люди, которые придерживаются этих советов уже давно на уровне высокого менеджмента сидят и на мнения простых лидов внимания не обращают.
Как правило, все эти сомнительные движения в сторону саботажа делает само начальство.
В одном огромном международном банке ждал больше двух месяцев замены картриджа в лазером принтере - нужно было два апрувала больших начальников, один из которых работал вообще в другой стране. С чувством глубокого удовлетворения узнал, что через сколько-то лет тот банк почти стал банкротом (не дало государство слишком большой). Зато все было "по каналам".
такое ощущение, что то что в 44ом расценивалось как саботаж сейчас местами норма
В кульминационный момент Второй мировой войны ЦРУ выпустило потрясающую книгу Simple Sabotage.
Эээ??? Чего-то я не понял - ЦРУ создано только в 1947, т.е. после Второй мировой ?
Вот так ящерики и палятся - это была первая хронооперация проведённая ЦРУ в рамках построения мирового рептиложидамасонского обкома. А может и не первая.
На самом деле это было "Управление стратегических служб" (Office of Strategic Services, OSS), предшественник ЦРУ.
Simple Sabotage была выпущена не ЦРУ, а Office of Strategic Services (Управление стратегических служб). Это по сути предшественник ЦРУ, на основе которого оно и было затем создано.
P.S. У меня эта книга по ссылке в посте не открылась, так что вот еще 1 источник.
Настолько круто, что достойно сохранения в закладки.
Не хватает пункта: Рекомендуйте менеджерам на вакантные места брать своих родственников, друзей, детей, жён и любовниц, а не людей с улицы. Ведь мы не просто компания, а одна большая семья и доверие для нас превыше профессиональных качеств.
В этом случае менеджеры будут за вас держаться и всячески защищать, а нанятые ими родственники значительно усилят саботаж в компании.
Современный руководитель постарается поставить вокруг себя своих людей, которые помогут ему достичь его целей. Чужие люди, оставшиеся от прежнего руководителя, ему не нужны — ведь они достигают каких-то своих целей.
Но ещё хуже, если у сотрудника есть план работы на несколько лет вперёд. Чтобы сломать такой план и насадить свой план, понадобится много усилий. Проще уволить и нанять нового.
Надо добавить пукты
1--Ставьте задачи только усно.
Вот примеры того как мне ставили задачи из разработки электроники.
"подружить платы", "оживить плату", "УУ вай вай."
2--если инженер делает заявку купить оборудование, то покупать не совсем то оборудование.
3-–все важные инструменты ( микроскопы, бокорезы, отвертки) убирать как можно дальше. Устанавливать формы допуска для получения этих инструментов инженерам и техникам
4–Назначать ответственные проекты в максимально безнадежные руки
5--командиром подводной лодки назначить человека с максимально плохой дикцией и произношением. Чтобы все по внутреннему телефону неправильно его понимали.
6--культивировать частые пустые разговоры в офисе. Разводить всяческие "дурка" чаты в компанейский мессенджерах.
7--запретить технические задания как пережиток СССР.
Очень подробный список. Трудно что-либо добавить. Но разве что добиваться разнообразия и инклюзивности несмотря ни на что, объясняя что только таким образом компания добьется успеха. И да ТЗ в печку.
Сразу видно, что новичок! Метод имени профессора Нордена: когда до окончания проекта осталось не так много, объявляем, что выбранный { процессор | язык | фреймворк | ваш вариант } плохой, и надо всё выкнуть и переписать с нуля: это единственный способ достигнуть абсолютного превосходства!
С 2014 на авторском курсе для слушателей 2х годичной MBA программы специально сделал несколько слайдов с этой методички OSS 1944 года для поговорить о саботаже, как в реальности он выглядит (банально редиректить на не тех людей - раньше секретарша на телефоне имела приличное влияние, переводить звонки или внезапно класть трубки и не отвечать на перезванивания) и как соотв можно руководителям выявлять (само собой и в другую сторону работает) эту деятельность, как раз от вот таких прошаренных СТО и/или их хитровыделанных подчиненных
Великолепно. Если вводить пункты аккуратно, будучи на влиятельной должности, подобное можно поворачивать годами без привлечения санитаров и леса! И ведь процессы естественные, смотря на отраслевых гигантов складывается ощущение (ведь формально всё в пределах нормы), что среднее руководящее звено училось по этому труду.
Так часто и происходит. И самое смешное или наоборот грустное (с какой уолокольни) тут то, что именно такие саботажники в глазах начальства выглядят надёжнее и перспективнее тех, кто реально двигает контору к результату!
Именно по этому важно уметь доказывать свою правоту, начальству в падлу (свои дела есть) разбираться, оно проверит тому, кто лучше докажет.
Не совсем. Если начальство - собственник, то да, можно доказать и часто с цифрами.
А вот если такое же наземное, то далеко не факт. Ибо принцип всех этих правил - един в своей сути:
Ни за что не отвечать самому, но генерировать видимость бурной деятельности с перекладыванием ответственности на коллег-конкурентов.
Начальство поверит тому, кому оно позволит что-то доказывать. А кому не позволит, тот может хоть сутки объяснять наедине с собой.
Это гайд, как стать ценным дорогим топ-менеджером с золотым парашютом ?
По моему все эти антисоветы являются best practices в мире разработки мобильных приложений. С релизным циклом в две недели реально важно делать всё осторожно и думать сразу далеко наперёд.
Большие проекты понять полностью невозможно, само собой разумеется подключение других разработчиков, которые могут подсказать. А встречи формата three amigo - дизайнеры, быкендщики, андроидщики, айосеры, аналитики и тестеры - бытовое явление в крупных проектах.
Из личного опыта:
Из личного опыта:
Начальник почему-то очень не любил бренчи и вообще любые мерджи в гите. Он хотел, чтоб история была строго линейная. И он решил с этим бороться - лично каждый день делал ребейс. Мы ему говорили, что так нельзя и чем это чревато, но он видимо считал себя единственным, кто знает как все должно работать и никого не слушал. Несколько раз таки получалось как в этой статье про 2*2=5. После этого он разочаровался в ребейсе, но от своей идеи строго линейной истории не отказался. Он придумал гениальный метод: мы все свои коммиты присылали ему в виде патчей (диффов) по почте, а он уже самолично их эпплаил, чтобы получилась линейная история.
А еще он не любил длинные коммиты и заставлял всех делать коммиты по 2-3 строчки, не более. Причем, если ему какой-то коммит не нравился, то он его мог спокойно выкинуть. Случалось, что после такой ампутации проект тупо не собирался, и он делал втык разработчику.
Еще требовал 100% покрытия кода тестами. Любой коммит должен был сопровождаться модульным и интеграционным тестом. Доходило до абсурда. Мне нужно было выкинуть кусок мертвого кода (метод с багами, который никогда не вызывался, потому что кто-то написал другой метод с аналогичной функциональностью). Начальник не верил, что этот метод прям вот совсем не нужен и требовал все вокруг обложить тестами. Как протестировать метод, который никогда не вызывается, а если вызвать то аппликуха просто крэшится - он не объяснил.
Было много и другой дичи, про которую надо отдельную статью писать. На минуточку, это крупный и известный проект (название не скажу ибо NDA), но в клиентах у которого Микрософт, Амазон, Тошиба и др.
Проработал я там полгода, поскольку не выдержал и сказал начальнику все, что я думаю о его методах (цензурно), после чего и был уволен.
Нокию так и развалили
Еще пример из жизни. Сажаете программистов по отдельности рядом с менеджерами, которые целый день громко разговаривают по телефону.
Однажды мне руководитель в качестве помощника для разработки микроконтроллерных прошивок (firmware) привёл Python программиста.
Это тоже элементы эффективного менеджмента?
Ещё несколько действенных вариантов саботажа со стороны руководства это ввести строгие правила оформления кода.
1 —Подолгу проверять код на инспекции программ.
2—Придираться к отcупам в исходниках функций. Строго заставлять программистов придерживаться именного этого конкретного стиля отступов и переносов фигурных скобок и расставления пробелов.
3—Заставить программистов писать подробные текстовые комментарии перед каждой функцией.
4 —Заставить группировать static функции внизу файла и дублировать прототипы static функций вверху (а-ля лишнее действие чтобы убить время).
5—Лишить программистов прав администратора на своих рабочих компьютерах. Запретить программистам прописывать пути в переменную PATH. Запретить установку утилит из CygWin MinGW и прочее.
6--Обязать программистов собирать код из IDE. Запретить использовать скрипты сборки. Сборка из IDE обычно сопровождается настройкой мышкой. А это как раз тормозит масштабирование проекта и развитие в целом.
7--Дать Junior разработчику право делать инспекцию программ Senior разработчиков, включая право вето на запрет Pull Request(ов).
Всё это примеры из реальной российской практики.
Простой саботаж в мире ПО