lytdybr

Подход TameFlow говорит следующее (а вся книжка подробно это объясняет и даёт отсылки к другим книжкам на ещё более подробные объяснения): надо использовать теорию ограничений, но в разработке и архитектуре в отличие от машиностроения ограничение сразу не видно. И давайте добавим замечания Элона Маска для инженерной части, https://incrussia.ru/switch/five-steps-by-elon-musk/. И помним, что это всё работает только для ситуации, когда всё произведённое вы немедленно продаёте, и нужно быстро-быстро удовлетворить спрос. Так что: -- менеджеры сначала убирают время ожидания ресурсов за счёт устранения мультизадачности (побочный эффект: время на согласования/координацию, время на переключение), а также отвлечений ресурсов. Какой-то из этих ресурсов -- ограничение, но мы этого не знаем. Принимаем решения только на тему когда начинать работы. Это контринтуитивно, требует изменения в головах менеджеров, но не требует изменения в собственно работе. DevOps (инженер-технолог завода-автомата) ничего не делает, никаких рацпредложений, они бесперспективны, если не касаются реального ограничения -- но мы ж не знаем, где оно!), а операционный менеджер ломает свои модели работы. Это первая треть книжки TameFlow. -- технари убирают ненужное в технологии, пункты 3 шагов Маска. Это же связано с разницей output (мы суетимся и много работаем) и outcome (работы мало, но результаты есть). -- останавливайтесь, когда достигните полной загрузки (полной эксплуатации) ограничения и даже раньше (ибо требуется ещё и буфер оставить свободных ресурсов, чтобы не образовалось "пробки" -- метод барабан-буфер-верёвка вам в помощь). В технической части -- когда приходится много возвращать в "как было" уже убранного. -- снимайте ограничение (время работы ресурса, прежде всего ресурса-ограничения). Если уменьшать время работы других ресурсов, то это может уменьшить стоимость сдельной оплаты за ресурс, но не даст ускорения. Но перед этим убедитесь, что вы будете ускорять ровно то, что надо: «Если вы роете себе могилу, не нужно рыть ее быстрее, просто перестаньте это делать». Видео 23-й встречи лаборатории собранности: https://www.youtube.com/watch?v=bd_NJOVIROM, мы там договариваемся, что онлайн-курс будет опубликован в середине октября, а ещё я рассказываю краткое содержание идей по описанию динамики (обсуждение не столько скоростей, сколько ускорений и усилий, требуемых для их достижения, а также переход на квантовопободные вычисления динамики). Уже после этого рассказа я изложил это более обстоятельно и со ссылками на первоисточники вот тут: https://ailev.livejournal.com/1648977.html, а потом добавил ещё и про третью производную (рывок/jerk) в первом и седьмом абзаце тут: https://ailev.livejournal.com/1649277.html. Над этой темой терминологии нужно думать-думать. Скажем, "прирост скорости" это вроде как ссылка на "ускорение", но без включения времени. Давайте попробуем в механике: "прирост скорости с 20км/час до 30км/час" -- нормально звучит? А теперь через ускорение: это как с 0 км/час разогнаться до 10 км/час, то есть с 0 м/сек до 2.8 м/сек. Если за пару секунд, то ОК. Если за десятую секунды, вам мало не покажется. Это ж то же самое, что затормозить на бегу об стенку! А тут наоборот: стенка вас разгонит до беговой скорости. Если вы двигались равномерно, а потом вдруг "скорость приросла на 10 км/час за десятую секунды", это будет один рывок/удар. Если у вас было две секунды, то совсем другой рывок/удар/jerk, производная третьего порядка. Конечно, когда мы говорим о скорости работы (которая не имеет массы) или скорости финансового потока (там тоже массы нет), то рассуждения будут другими, но выкидывать длительности приложения усилий нельзя. Дальше вопрос: а что будет, если вместо "прироста скорости" перейти на обсуждение "ускорения", а "прироста ускорения" говорить о рывке? Это сразу даст нам ещё и вариант обозначения действия: ускорение и рывок отглагольные существительные. Если говорить дальше о менеджменте, то там тоже нужно быть внимательным: все эти Flow Time и Touch Time весьма абстрактны, можно пытаться назвать их поточнее (что на английском регулярно пытаются делать. Скажем, Flow Time is also known as Time in Process, Process Time or System Lead Time. Flow Time is often and ambiguously referred to as Cycle Time, especially by practitioners of the Kanban Method. Все стараются, как могут, при этом речь идёт о продолжительности, а не о собственно моменте времени. Очень не хочется сочинять русскоязычную онтику операционного менеджмента, но на кону облегчение понимания (все авторы подчёркивают, что предмет у них абсолютно контринтуитивен и понимание даётся очень трудно, справляются только сугубые технари, и даже люди с финансовым образованием не прорываются, хотя им вроде как математика не чужда. Я считаю, что проблемы в том числе и из-за весьма специфической терминологии, затрудняющей граундинг математики -- слова не помогают найти нужные объекты в жизни, это всё оказывается "яблоками из задачи", без намёков на "яблоки из жизни"). Описание практик у меня оказалось разорванным по нескольким местам, и это надо как-то собрать в кучку в одном месте: -- "Методология" рассказывает всё про формат типа BoK (описание практик, меняющих состояние альф), но отдельно пишу про объяснительные теории (дисциплины практик), причём дальше это никуда не идёт, кроме как "дисциплины дают объекты внимания и объяснения" и ещё говорится об эволюции практик. -- в "Системной инженерии" добавляю про языки паттернов, ибо в языках паттернов есть место для объяснений, а в архитектуре "почему" важнее "как": формат BoK не подходит. -- в TameFlow приводятся рассуждения, прямо указывающие на задействование Mental Models, полностью эквивалентных "порождающим объяснительным моделям" (формат -- онтики с метриками и формулы для описания связей между метриками, "как в физике") и используются эти Mental Model для принятия решений. И эта работа с Mental Models противопоставляется "методологиям" типа BoK. Этот формат "изложение с формулами" эквивалентен формату с паттернами, только рассуждения про "силы" даются не качественные, а количественные -- связь характеристик описывается не словесно, а формулами. В курсе Павла Усанова буду читать "Подходы к современной праксиологии на базе системного мышления третьего поколения". Системное мышление первого поколения базировалось на понятии системы в её окружении, второго поколения добавило в рассмотрение агентов (люди, предприятия), создающих системы, а третьего поколения пришло к идее развития систем в ходе техноэволюции. В рассказе будет представлено как системная инженерия, базирующаяся в конечном итоге на теории принятия решений (основа праксиологии) предлагает "умные мутации" в ходе техноэволюции, сочетая разумность целенаправленных действий людей и их инструментов (включая компьютеры, включая организованных в предприятия людей) и непредсказуемость окружающего мира, невозможность планового действия. Восторг-видео, иллюстрирующее работу последних новинок в генерации изображений (берём чьё-то фото и говорим художественной нежити изобразить этого человека в нужном виде -- и отлично ведь получается!): https://www.youtube.com/watch?v=W4Mcuh38wyM. С лицом уже разобрались, а следующая версия софта будет рисовывать ещё и правильные руки, на недостатки в прорисовке рук уже обратили внимание. Я уже послал эту ссылку одному знакомому владельцу студии игровой графики. Это всё только самое начало цветочков, ягодки пойдут лет через пять, ещё через пару поколений хардвера. С хардвером ведь тоже много интересного происходит, и что было доступно только для самых богатеньких, станет доступным для всех. Так, пошли слухи о разработке карты с 120GB памяти HBM2e для NVIDIA H100 -- https://wccftech.com/nvidia-hopper-h100-pcie-graphics-card-120-gb-hbm2e-memory-capacity-rumor/. На такую одну карту влезут и будут быстро просчитаны дома под столом художества, которые раньше надо было месяцами считать на запредельно дорогих суперкомпьютерах. Но если что-то можно посчитать под столом, то в облаках можно будет посчитать по факту бесплатно. Вот очередной сервис, там тоже пока бесплатно: https://www.wombo.art/create, промпт "Systems thinker in the nearest future enjoying systems that he created yesterday". Похоже?