Как стать автором
Обновить

Комментарии 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), но в клиентах у которого Микрософт, Амазон, Тошиба и др.

Проработал я там полгода, поскольку не выдержал и сказал начальнику все, что я думаю о его методах (цензурно), после чего и был уволен.

Нокию так и развалили

И подразделение мобильных телефонов в Siemens.

Еще пример из жизни. Сажаете программистов по отдельности рядом с менеджерами, которые целый день громко разговаривают по телефону.

Однажды мне руководитель в качестве помощника для разработки микроконтроллерных прошивок (firmware) привёл Python программиста.
Это тоже элементы эффективного менеджмента?

Ещё несколько действенных вариантов саботажа со стороны руководства это ввести строгие правила оформления кода.

1 —Подолгу проверять код на инспекции программ.

2—Придираться к отcупам в исходниках функций. Строго заставлять программистов придерживаться именного этого конкретного стиля отступов и переносов фигурных скобок и расставления пробелов.

3—Заставить программистов писать подробные текстовые комментарии перед каждой функцией.

4 —Заставить группировать static функции внизу файла и дублировать прототипы static функций вверху (а-ля лишнее действие чтобы убить время).

5—Лишить программистов прав администратора на своих рабочих компьютерах. Запретить программистам прописывать пути в переменную PATH. Запретить установку утилит из CygWin MinGW и прочее.

6--Обязать программистов собирать код из IDE. Запретить использовать скрипты сборки. Сборка из IDE обычно сопровождается настройкой мышкой. А это как раз тормозит масштабирование проекта и развитие в целом.

7--Дать Junior разработчику право делать инспекцию программ Senior разработчиков, включая право вето на запрет Pull Request(ов).

Всё это примеры из реальной российской практики.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории