Ivan Abashkin blog

У ребят из Formlab есть несколько крутых методичек по разработке корпусов. Одну из них я даже распечатал в качестве настольной книги и подсовываю команде при коммуникации по проекту. Очень даже помогает. Мало того, что чтиво интересное само по себе, так ещё и наглядно видны ключевые фазы разработки. Интересно, что этот опыт можно рассматривать не только применительно к корпусам устройств, но и к проектам по разработке нового устройства в целом. Формлабовские методички есть у них в боте @formlab_ru_bot . (Не реклама, ребята и вправду молодцы 😅)

Каждый раз, когда слышу "О, смотрите какая крутая идея! Давайте немедленно запустим её в работу" думаю о многозадачности, законе Литтла, пропускной способности и вспоминаю анекдот:

— Рабинович, партия и правительство приняли решение открыть в Одессе первый советский публичный дом. Вам поручено организовать его и стать его первым директором! — Ну, нет, не дождётесь. Что я, рыжий, что ли? — Почему вы отказываетесь? Это партийное задание!!! — Потому что я заранее знаю, как всё будет. Блядей разрешите нанимать только с партийностью с 1905 года, мебель дадите старую, подушки и бельё  я буду искать и покупать за свои. А потом пошлёте блядей на картошку, а Рабинович ложись и выполняй план!

Дмитрий Егоров сделал классный ролик про то, как даже грамотное управление операционкой и применение TOC не спасло компанию от банкротства. История про производителя бетона, который попал в ценовую войну и, несмотря на операционное превосходство, утонул из-за нехватки оборотного капитала. Рассказ про "компанию-зомби" – внешне успешную, но мёртвую внутри. Дмитрий рассказывает живо и с юмором. Рекомендую к просмотру всем, кто интересуется менеджментом и TOC. Полезный кейс.

Древний артефакт ушедшей сверхразвитой цивилизации

Вот все вокруг говорят про эффективность: "Мы должны быть эффективными", "это эффективная методика", "в компании эффективный менеджмент ", и т.д. Интересно, что слово "эффективность" это калька с английского. Вот только там есть два разных слова, которые переводят одинаково. Отсюда возникает некая путаница. Effectiveness (результативность) — это степень достижения поставленных целей или желаемых результатов. Это отвечает на вопрос: делаем ли мы правильные вещи? То есть, насколько успешно организация или человек достигают своих стратегических целей. Efficiency (эффективность использования ресурсов) — это способность выполнять задачи с наименьшими затратами ресурсов, времени или усилий. Это отвечает на вопрос: делаем ли мы вещи правильно? То есть, насколько оптимально используются ресурсы для достижения целей. Пример:

- Компания может быть эффективной (effective), если она успешно выводит на рынок новый продукт и завоевывает долю рынка. Однако, если при этом она расходует слишком много средств или времени, она может быть неэффективной (inefficient) с точки зрения использования ресурсов. - Напротив, компания может быть эффективной (efficient) в операционной деятельности, минимизируя затраты и оптимизируя процессы, но если она не достигает своих основных бизнес-целей, она считается неэффективной (ineffective) в целом.

Какую из этих ситуаций подразумеваете вы, когда произносите "эффективный"?

Тот момент, когда изменение маленькое, а эффект большой. Резонит добавил на свои конверты с платами отрывную чеку, и это просто взорвало офис. Наконец-то! Ура! Больше не нужно искать ножницы, чтобы открыть этот долбанный конверт. Рраз — и сразу видишь, что тебе приехало.

Когда навел порядок в процессах у себя отделе. Только у себя в отделе ...

Один из лучших софтскиллов, которым я располагаю - шоколадка или банка энергетика (в зависимости от предпочтений).

По совету Александры прочел «Проект Феникс». Удивительно, но за 4 года изучения Теории Ограничений я умудрился пройти мимо этой книги. Книга как будто списана с нашей компании. Если автозаменой по тексту поменять некоторые фамилии, можно было бы обвинить автора в промышленном шпионаже. Как и герою книги, мне пришлось пройти очень похожий путь. Применяя практики TOC и Канбан-метода вместе, мы перешли от состояния полного хаоса к ситуации, когда моя роль стала минимальной — система работает практически автономно. В книге полно понятных и наглядных примеров и метафор из разных сфер: TOC, Agile, Бережливое производство, CI/CD, командообразование и лидерство, взаимодействие человеков. Многие сложные концепции становятся понятнее. Очень понравилась иллюстрация концепции Planned Load из TOC применительно к интеллектуальному труду и идея борьбы с UN_planned Load (незапланированной загрузкой), потому что она разрушительно влияет на рабочую систему. Ещё понравилось, как подсвечено, что постоянное давление по срокам может на ровном месте создать кучу проблем с результативностью. Классно показаны коммуникации и корпоративная грызня. Полезно увидеть, как бывает. Ну и, конечно, иллюстрация «Люди — хорошие» (но не все!). С некоторыми вещами я не совсем согласен, например, с непрерывными улучшениями в местах, где не болит, но описано это всё очень «вкусно». У авторов есть также более подробное руководство по идеям, описанным в романе. Нужно будет обязательно почитать.

Хаос как демотиватор: почему инженеры уходят из компаний На прошлой неделе мы собеседовали очень крутого инженера, настоящего профессионала своего дела. Глубокие знания, серьезный уровень подготовки – парень явно выделялся. Ближе к концу собеседования, когда дело уже шло к финальным вопросам, мы поинтересовались, что же побудило его искать новое место работы. «Достал бардак», – ответил он. Постоянный поток срочных задач, авральный режим, сверхурочные – всё это стало неотъемлемой частью его рабочего процесса. «От меня команда зависит», – добавил он, ведь помимо всего прочего, он ещё и тимлид. Ему поручают проект, а дальше – полная импровизация. Никто не удосуживается снять с него бремя операционки: нарезать задачи, отслеживать выполнение, разруливать бесконечные изменения. Всё валится из рук, а сил не остаётся. Но это было ещё не всё. «Полтора года мы работали над проектом, выложились по полной, а в итоге оказалось, что он никому не нужен», – поделился инженер. Все усилия, бессонные ночи, нервы – всё впустую. Ноль результата. Эта ситуация в очередной раз подчеркнула одну важную мысль: хаос в компании, отсутствие грамотного управления и четких целей – всё это вынуждает ценных сотрудников уходить. Никто не хочет заниматься бесполезной работой. Да, наши люди готовы терпеть сложности, брать на себя дополнительную нагрузку и ответственность, но при одном условии: их труд должен приносить реальную пользу, воплощаться в востребованном продукте. Когда же результаты работы выбрасываются на свалку, это демотивирует сильнее всего. Компания в этот момент теряет самых компетентных, самых заинтересованных и мотивированных людей. Чтобы инженерная компания процветала, инженеры должны чувствовать себя востребованными, должны гордиться результатами своего труда. А для этого необходимо всего лишь чётко обозначить цели и задачи деятельности, сделать так, чтобы люди понимали, ради чего они работают. И это начинается с грамотной постановки целей и задач для всей компании.

Преодоление сопротивления к изменениям. Недавно, Дмитрий Егоров выпустил очень содержательный и подробный ролик про сопротивление изменениям. Из него (и из TOC Handbook стр. 574-584) мы можем узнать о 9 слоях сопротивления изменениям: -== Проблема ==- 0. Проблемы не существует ... 1. Отсутствие согласия с тем, в чем именно состоит проблема 2. Проблема находится за пределами моего контроля -== Решение ==- 3. Не согласие по поводу направления решения 4. Несогласие по поводу деталей решения 5. "Да, но ... решение имеет негативные последствия" -== Внедрение ==- 6. "Да, но ... Мы не можем внедрить это решение" 7. Несогласие по поводу деталей внедрения 8. ""Вы знаете, это решение содержит риски ..."" 9. "Я так не думаю" - Социальные или психологические барьеры ---- Давайте подробнее посмотрим на нулевой слой "0. Проблемы не существует ...". Александра Брызгалова подсветила мне важность этого слоя, и я полез разбираться. Если вы пошли обсуждать с кем-то проблему, то нужно убедиться, что она не только ваша, но и "его". Иначе вы вместо напарника по решению получите в лучшем случае лицо безразличное к вашим словам. Вот что нам советует Handbook на этот случай:

Как нам продвинуться дальше этого Уровня? Лучший способ - потратить время на то, чтобы полностью понять позицию другой стороны. Мы должны позволить другой стороне высказаться и помочь им раскрыть свои предположения, пока мы не определим их ложное предположение относительно ситуации. Следующий шаг - доказать им, что их предположения на самом деле неверны, и проблема действительно существует.

Попробовал выдумать иллюстрацию диалога, по прохождению этого слоя: Отец: Андрюш, ты сделал домашку? Андрей: Нет, пап, я не успел из-за кружков и сильно устал. (Андрей не видит проблемы в невыполненной домашней работе. Для него проблема – усталость после кружков) Отец: А тебя завтра по этой домашке будут спрашивать? (Отец пытается перевести Андрея на Уровень 1 – показать ему наличие проблемы. Он не спорит с тем, что Андрей устал, но мягко подводит его к мысли, что несделанная домашка может привести к неприятностям.) Андрей: Да, скорее всего. Ну и ладно, спросят – скажу, что не успел. (Андрей все еще не видит проблемы в несделанной домашке.) Отец: А ты помнишь, как в прошлый раз ты не сделал домашку по математике, и тебе поставили двойку? (Отец приводит пример, демонстрирующий негативное последствие игнорирования проблемы – двойку. Он апеллирует к опыту Андрея, чтобы тот сам осознал наличие проблемы.) Андрей: Да, ты прав! Что же делать? Не хочу опять двойку получать.

Вот ещё классный вариант: https://t.me/abahkin_blog_chat/462

Хочешь в фирме все улучшить, Изменения внедрить? Не спросив, ломай и строй, Всем мозги промыть настрой! Пусть начальство не поймет, Ты же – гений, патриот! Если бизнес вдруг умрет, Скажешь: "Сам виновен тот!"

Из комментариев к этому посту: https://t.me/boriskotovich/484

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

Ламинарное и турбулентное. Чем больше завихрений, тем меньше пропускная способность.

https://t.me/Pminstitute/1424 Это приемлемый вариант для консультанта. Но работая в найме, далеко не всегда получается выстроить разговор с собственниками. Чаще приходится лавировать меж сыплющихся как из рога изобилия хотелок и требований и нет возможности возразить или выстроить диалог. Иногда чувствуешь себя будто, жонглируешь горящими шарами, стоя на одноногой стремянке, а тебе с одной стороны ещё подкидывают шаров, а с другой выкручивают из этой стремянки винтики, чтобы использовать в других местах. В такой атмосфере, чтобы справится с управлением, нужно наглядно показать что система перегружена и в неё уже больше не впихивается горящих шаров. И вот думается, что "лечить управлением проектами" такую ситуацию можно именно с точки зрения выстраивания четких правил и договоренностей о запуске новых инициатив в работу и для просчета доступной мощности на текущие и желаемые хотелки. Здесь получается что "управление проектами" нужно "людям снизу", чтобы выстроить доказательную базу для разговора с "людьми сверху". Иначе не поймут.

Аналоги Miro: Китай: - https://pixso.net - https://boardmix.com/ Россия: - https://sboard.online - МТС Линк Доски - https://pruffme.com/ - https://flip-chart.ru/ Победитель: - Холст: https://holst.so/ Аналог Zoom: - Контур.Толк.