Р5. Системное мышление. Моделирование: выбор рабочего проекта. В научении не стоит брать сразу сложные проекты. А что делать, если сложные проекты нужно уже как-то делать, а научение освоено еще не на уровне мастера?

Посты студентов Cистемное мышление
,
1

Спотыкаться, но делать … Другого способа в текущем нет.
Да, я предупрежден не однократно в руководстве, что не стоит ехать сразу на горном велосипеде и без шлема ))

Полтора месяца назад на примере управления своим проектов в команде в составе из 10 человек я создал модель и воплотил управление операционным потоком выпуска. С 01.06.2026 получил от руководства оргвозможность и политическую волю на проведение полезных изменений модели выпуска в департаменте 50 человек.
Я назвал этот проект П. 12. Инженерия платформы операционного потока выпуска предприятия с помощью трекера YouGile.

Собственно вот этим сейчас и занимаюсь.
Выполняя упражнение Aisystant немного застрял на моделировании…

Рабочий проект, взятый при задании моделирования в упражнении руководства Р5. Системное мышление:

Что сделано:

  • Проведено исследование возможных ограничений операционного выпуска цепочек производственных линий в департаменте. Создано описание гипотезы о том, какое ограничение ключевое. В моем случае все банально: Отсутствет мастерство и платформа коллективной собранности команд производственной линии.
  • Выдвинута гипотеза о том, что снимет
  • Выбрана сборка методов управления операционным потоком, включая инструмент моделирования управления выпуском рабочих продуктов работ по производственным методам
  • Описана модель операционного потока
  • Создана концепция (шаблон модели) операционного потока
  • Создана концепция использования (инструкция модели) операционного потока
  • Обкатана в течении 4 месяцев с командой моего проекта на предприятии (отрасль проектирования объектов транспортной инфраструктуры)
  • Проведена успешная работа с руководством по развитию модели на весь департамент на 50 человек. Создана “договорка” с руководством, и получена оргвозможность: выпущено официальное распоряжение на департамент.
  • С 01.06.2026 ведется работа по инженерии Операционного потока выпуска предприятия с помощью трекера

Целевая система проектной организации: Инженерные сооружения соединения (улицы, дороги, мосты, искусственные сооружения) транспортных потоков городской инфраструктуры по создаваемым моделям организации.

Ниже в таблице я выполнил домашнее задание с несколько расширенным вариантом. Но в ней у меня Целевая система это по-прежнему физический объект, предмет целевых моделей (наш выпуск, мы проектировщики).

Название проекта Целевая система (ЦС) Как называют того, кто будет её использовать? Что основное делает система в момент использования? Что основное делаете вы
[[П. 12. Инженерия платформы операционного потока выпуска предприятия с помощью трекера YouGile]] Инженерные сооружения соединения (улицы, дороги, мосты, искусственные сооружения) транспортных потоков городской инфраструктуры по создаваемым моделям организации Участники дорожного движения (автомобили, общественный транспорт, пешеходы) Соединяет транспортные потоки проездов и улиц участников дорожного движения “Инженер платформы операционного потока выпуская проектной документации”::создатель

Инженерия (моделирование, воплощение, развитие, поддержка и обучение пользователей) платформы и методов управления операционным потоком выпуска целевых моделей производственных линий департамента из 50 чел.

Вопрос: #вопрос Правильно ли я понимаю, что целевая система моего проекта остается той же, которая является целевой для организации выпуска в целом, а у моего проекта (Инженерия Операционного потока выпуска предприятия с помощью трекера) есть своя система (-ы)?

Буду очень благодарен единомышленником если кто-то подумает со мной или подскажет. Если нет, то что ж, пусть тут еще повисит пост, потом может и сам дойду умом …

Обновление на 2026-06-22
Моя гипотеза по итогу изучения и размышления над комментариями Максименко Н. и Левенчука А.:

  • Система, которой будет заниматься мой проект оргразвития: Платформа операционного потока выпуска рабочих продуктов информационных моделей целевых систем предприятия
  • Рабочий проект: П. 12. Инженерия платформы операционного потока выпуска информационных моделей производственных линий предприятия с помощью трекера YouGile
2

Можете ли Вы то же самое сформулировать иначе?

Конечно, я бы мог пропустить Ваш пост через моих агентов… И сформулировать целый пул точечных вопросов… Но решил пойти более простым путём: если Вы сами сможете пересмотреть Вашу формулировку, сможете привести примеры того, как подобные задачи решали другие, то и “прошу помощи зала”, возможно, Вам и не потребуются.
Не?

1 лайк
3

Мой опыт взаимодействия с авторами руководств подсказывает мне: скорее всего, любое Ваше название будет подвергнуто жёсткой критике. Ибо цель не в том чтобы “назвать”, а в том, чтобы аргументировано обосновать.

Дело не в “названии” — каждый автор вправе именовать свою ЦС так, как ему заблагорассудится: "называть — давать название (а о названиях/именах заинтересованные стороны могут спорить годами…).

Подобрать название для ЦС, которое устроит авторов руководств — задачка та ещё. Так что от дискуссий Вам никак не отвертется…

И ещё. Авторы руководств сами иной раз меняют названия ЦС (уточняют, ссылаясь на эволюцию знания: “увольняют учебники”, “обновляют руководства” и т.п.). Поэтому, полагаю разумным:

  • либо истребовать у авторов руководств актуальный реестр названий ЦС и выбрать из такого реестра наиболее подходящие.

  • Либо самому составить такой реестр путём изучения не только материалов руководств, но и многих комментариев, которые авторы руководств в количестве оставили под постами стажёров…

  • И третий вариант: “если решение проблемы стоит денег, то это не проблема, а расходы” — банально купить у наставников платную стажировку. И там разобрать Ваши варианты “названий”.

Есть ещё один вариант. Но не для всех. Только для героев. Начать не с подбора названия, а с гипотез и обоснований. И рискнуть доказать, что предложенное название лучшее из всех-всех возможных. И обосновать каждую гипотезу, раскрыв методы верификации и фальсификации.

Других рекомендаций на текущий момент у меня нет.

1 лайк
4

Представим на миг, что я согласился. И мой ответ: “да, можно”.

Что изменилось в мире после моего ответа?

Возможно, и у Вас, и у читателей, появился вопрос: “почему можно?”
Наивно было бы полагать, что односложный ответ является тем решением, которое Вы ищете.

Скорее всего, читателю нужен не ответ “да, можно”. Скорее всего, и Вас, и читателя интересуют подробности: а как это проверить? А почему это лучшее решение из возможных? А почему другие решения были отвергнуты? …
…

Этим сообщением я пытаюсь донести простую мысль: как не изгаляйся, как не проси “помощи зала”, а бремя доказательств ложится исключительно на Вас.

  • В конце концов, именно с Вас спрос будет: единомышленники — они только до тех пор “единомышленники”, пока не приходится жертвовать своей шкурой. А не только декларировать готовность “ставить шкуру (чью именно шкуру?!) на кон”)))
5

Об этом уже писал кажется. Все заготовки и посты в клубе МИМ мною используются как одна из систем-создателей моей системы-создателя кусочков интересующей меня в текущем личности, то есть какого-то мастерства. Результат обсуждения темы заготовки - калибровка моего мастерства системного мышления как в конкретном предметном кейсе, так и в целом.

Да, конечно интересуют варианты объяснения. Просто да/нет вряд ли будут приняты мною всерьез, а пространство займет.

Мои отношения с ответственностью тут не предмет рассуждений.

Предмет рассуждений тут обоснование выбора Целевой системы.

Все что пишете тут Р5. Системное мышление. Моделирование: выбор рабочего проекта. В научении не стоит брать сразу сложные проекты. А что делать, если сложные проекты нужно уже как-то делать, а научение освоено еще не на уровне мастера? - #3 от пользователя advat больше похоже не на инженерное обоснования в соответствии с руководством, а на вероятностный подбор-в-слепую/уагадывание.

А ведь Целевая система подбирается не так и не для того, чтобы правильно внести в реестр проектов название проекта. А для того, чтобы создавать нужные и успешные (учитывающие важные ролевые интересы) системы, меняющие жизнь к лучшему. И в процессе создания и команд, и платформы, и саму систему договорить вокруг все эти заинтересованные роли как в контуре создателя, так и всех остальных категориях ролей контура внешнего. Чтобы работа была рациональна в конце концов.

В общем, вывод делаю такой, что слишком размытый получился мой пост и там много лишних объектов внимания, отвлекающих от содержательной части. Перепишу.

Но сейчачс коротко так. Занимаюсь проектом организационного развития в департаменте с 01.06.2026. Мой объект внимания тут Операционный поток выпуска.

Что сделано:

  • Проведено исследование возможных ограничений операционного выпуска цепочек производственных линий в департаменте. Создано описание гипотезы о том, какое ограничение ключевое. В моем случае все банально: Отсутствет мастерство и платформа коллективной собранности команд производственной линии.
  • Выдвинута гипотеза о том, что снимет
  • Выбрана сборка методов управления операционным потоком, включая инструмент моделирования управления выпуском рабочих продуктов работ по производственным методам
  • Описана модель операционного потока
  • Создана концепция (шаблон модели) операционного потока
  • Создана концепция использования (инструкция модели) операционного потока
  • Обкатана в течении 4 месяцев с командой моего проекта на предприятии (отрасль проектирования объектов транспортной инфраструктуры)
  • Проведена успешная работа с руководством по развитию модели на весь департамент на 50 человек. Создана “договорка” с руководством, и получена оргвозможность: выпущено официальное распоряжение на департамент.
  • С 01.06.2026 ведется работа по инженерии Операционного потока выпуска предприятия с помощью трекера

Целевая система проектной организации: Инженерные сооружения соединения (улицы, дороги, мосты, искусственные сооружения) транспортных потоков городской инфраструктуры по создаваемым моделям организации

Вопрос: вопрос Правильно ли я понимаю, что целевая система моего проекта остается той же, которая является целевой для организации выпуска в целом, а у моего проекта (Инженерия Операционного потока выпуска предприятия с помощью трекера) есть своя система (-ы)?

6

Привет) Ты в графах создателей запутался. У тебя разные проекты, проект, который создаёт сооружения в реальном (и ваша фирма как кусок цепочки, которая ведёт к созданию сооружений в реальном мире) это одно, а ваша фирма как орг звено и создатели этого орг звена (менеджеры и ты в их числе) это другое. И создание фирм это системный менеджмент, а создание сооружений это инженерия. И создают они разное. Т.к. до менеджмента ехать ещё пару лет на собаках, я бы тебе посоветовала идти дальше по Системному мышлению, когда до графов создателей доберёшься (там даже картинки есть) должно стать понятнее.

А так ты вроде и сам себе ответил “поток работ” на вашей фирме и конструкции в физическом мире это разное. С конструкциями надо разбираться, чтобы не фуфло делала ваша фирма. А чтобы это не фуфло делалось быстро, ну важно конечно, но как бы во вторую очередь. Я тут умничать не могу, есть приценденты где занимались будущие мастера “всем вместе сразу”, посмотри доклад Дениса с конференции МИМ последней (которому как раз мастера присвоили и у которого платформа по выпуску инноваций для нефтянки).

2 лайка
7

Привет, Натали!)

Да, верно, проекты разные и создают разное.
Проект “инженерия организационного потока выпуска целевых моделей предприятия” создает не целевую систему предприятия, а много каких систем (описание/модель потока, мастерство в оргзвеньях производственных линий, выпуск рабочих продуктов) и я понимаю, что ближайшая цель создаваемой системы проекта не Мост или Участок УДС.

И не относится к “целевым моделям”::“описаниям целевых систем” по типу часть-целое.
И модель операционного потока выпуска, и инфраструктурная платформа (трекер с шаблонами), и мастерство пользователей инструмента и выполняющих работы по заданной инструкции, - все это не имеет отношение по типу часть-целое к информационной модели Моста.
А скорее сам выпуск операционного потока.

Но сам выпуск операционного потока не имеет смысла без привязки к успешности создаваемых Целевых систем выпуска предприятия (Мост, Дорога, Участок УДС, …).
В таком случае целевой системой может быть выпуск, моей системой платформа операционного выпуска по методу. А Целевая система предприятия это надсистема для целевой системы моего проекта оргразвития.

Так что ли?)

8

Неверно. Цель выделить правильный объект, вокруг которого потом скоординировать мышление всего коллектива. И дальше назвать, удерживая тип. Если всё OK, то можно даже не обосновывать.

Ваши агенты не помогут тут, они не понимают, зачем это всё делается. Вот они точно, только про обоснование – неважно зачем, лишь бы “обоснованно” ))) [да, это наезд]

9

модель – понятно (но это не система), дальше “выпуск” (это что в мире? как ткнуть пальцем?), выпуск “объекта операционный поток” или “результат операционного потока – это выпуск”? Поток – это что, как ткнуть пальцем? Река – поток, но можно ткнуть пальцем! “Операционный поток” – это что? Как ткнуть пальцем на производстве, чтобы не попасть случаем в другие потоки (какие? ими тоже управлять?)? “Управлять” – это что делать с потоком, какие его характеристики менять?

Вот это надо продумать.

И да, основная путаница – слишком много звеньев в графе создателей в рассуждении, они там путаются (design-run путаница).

10

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

image
image2473×382 273 KB

Мое текущее понимание, операционного потока - это последовательное выполнения работ производственными линиями::агент с созданием рабочих продуктов за отрезок времени, то есть скорость.
Но ткнуть пальцем наверное не получится ))

Ткнуть пальцем получится в конкретного Бориса::агента, который разработчик::роль::создатель “информационной модели”::описание участка автомобильной дороги::система, работающий на своем компьютере::система (в него тоже можно ткнуть) с наученным мастерством (мастерство в мозгу, тыкать пальцем в туда можно осторожно, иначе может сбоить))) в голове по описанному методу.
Не знаю, в общем по этому вопросу сложно пока ложится у меня …

Как сейчас мне представляется управление заключается в следующем:

  1. Сначала задаем путь смены состояний работ над рабочими продуктами
  2. Потом работаем над увеличением скорости:
  • уменьшать перегрузы и простои рабочих станций в ожидании касания работы (сбор ИД для работы)
  • брать работу в колонку В работе при достаточной подготовке Исходных данных в колонке “:clipboard:ИД для работ”
  • уменьшение отвлечений и переключений в выполнении работ (лимитирование work-in-process, попадающих в колонку В работе)
  • сокращение переделок и доработок
  • сокращение ожидания внешнего контура, который в нашем span of control
  • коллективно удерживать внимание на внешнем ожидании в sphrer of influence, колонка “:five_o_clock:Контроль агентов”
  • параллельно с этим активно работать над поиском текущих ограничений и заниматься системно-инженерным творчеством в поиске “подходяшек”/интервенций снятия ограничений и/или снижению вероятности и влияния риска (как события-следствия в графе причинности)

image
image2198×360 186 KB

  • а также еще заниматься поиском и снятием ограничений уже не в самом проекте какого-то объекта, а в целом по цепочкам производства отделов департамента

image
image2486×387 288 KB

Этакий :chart_increasing:Контур непрерывных улучшений, на котором также ищется одно самое блокирующее ограничение из всего списка возможных.

Хотя сейчас перечитываю, что написал, и думается, что дал ответ не на тот вопрос ))

11

Типовой случай: разработчики ERP очень плохо представляют, что у них там целевая система ))) Перечитайте Aisystant – и попробуйте переформулировать для ваших реалий (в R1-R4 было достаточно для того, чтобы можно было переформулировать).

12

Изучил главу.
Выделил для себя интересное по похожим цифровым объектам внимания, это по своей сути цифровые двойники физических систем, так:

  • CRM - цифровой двойник создания клиентуры, описывает клиентуру::система
  • ERP - цифровой двойник потока ресурсов (сырья в разной степени готовности), описывает “ресурсы (сырья)”::система

С учетом выше обсужденного и изученного, получается, что применительно к моей ситуации (наше предприятия занимается разработкой описаний информационных моделей “транспортной инфраструктуры”::“целевая система” предприятия::создатель), что я делаю
- Трекер работ - цифровой двойник потоков работ производственных линий, описывает “рабочие станции производственных линий”::система.

Ближе?)

13

Вы как-то интересно сравниваете. Например, похожа ли рабочая станция на сырьё? Вы вроде бы это отождествляете. Какая-нибудь деталь для обработки в потоке ресурсов похожа на работу? Вы вроде бы это отождествляете. Просто по типам. Мысленно представьте себе эту рабочую станцию как сырьё, деталь как работу.

14

Добрый день.
Насколько я понимаю, проект оргразвития предполагает перевод управления командой инженеров из какой-то программы/software (в том числе из её отсутствия) в Yougile. В моем представлении это - смена метода (управления ресурсами, планирования работ - насколько я себе представляю функционал Yougile). Таким образом здесь вы будете сначала в роли методолога (разработаете метод планирования работ и назначения ресурсов на них с помощью Yougile), а затем в роли методиста займётесь уже его имплементацией (и метода, и Yougile одновременно с ним так как они взаимосвязаны).

Если это похоже на правду, то данное вами выше описание не вполне корректно. Вообще то что там написано мне сложно воспринять, так как очень много существительных идут подряд. “Платформа операционного потока” - это непонятно. Вообще “операционный поток” - для меня непонятная категория. (М.б. я конечно ещё не дошёл в руководствах до неё, но мне кажется “поток работ” это более правильно). Далее “…потока выпуска рабочих продуктов” - ок, считаем что рабочие продукты оргзвеньев, которым вы даруете новые методы контроля их работы - это информационные модели целевых систем предприятия (хотя мне кажется тут нужно заземление, и правильнее бы сказать “информационные модели мостов” к примеру). Но тогда в вашей фразе после “рабочих продуктов” надо ставить тире: “… рабочих продуктов — информационных моделей мостов”.
И тогда цель проекта - ускорение выпуска оргзвеном информационных моделей (за счёт смены метода планирования и операционного управления этим оргзвеном на Yougile), а целевая система проекта - это самое оргзвено (или несколько их).

Здесь кстати в названии проекта явно видно то о чём вам написали выше - как будто в проекте по инженерии системы создания смешаны и целевая система проекта, и целевая система предприятия: “… информационных моделей производственных линий предприятия…” - это речь про информационные модели ваших производственных линий, то есть модели оргзвеньев? А что тогда за их “операционный поток выпуска”, это похоже на серийное предпринимательство, а серийно полагаю в вашем случае всё же производятся информационные модели мостов, а не производственных линий.

Также есть вопрос к “инженерия платформы… с помощью трекера Yougile”. Если Yougile это действительно именно трекер, то с его помощью инженерия вряд ли возможна, зато возможно управление потоком работ - их планирование и назначение на эти работы ресурсов.
То есть в названии тоже следует отразить что мы планируем делать в проекте (изменять метод планирования и назначения ресурсов - на Yougile), с чем мы это будем делать (с оргзвеньями, которые вы знаете как называются - предположим группы информационного моделирования). Можно ещё наверное задаться тем каким методом будет реализован проект, и на какой результат расчитываем (сокращение срока моделирования на 20%? Сокращение числа моделлеров на 20% при сохранении сроков?)

Тогда название могло бы выглядеть как “Изменение метода операционного управления отделами информационного моделирования на управление с помощью Yougile с целью сокращения сроков моделирования на 20%”…
Я конечно чувствую что в моём варианте названия тоже что-то не так, но мне он кажется более корректным чем исходный.

15

Да, представить такое сложно.

Такс…
Откачусь назад, и попробую еще раз взглянуть со стороны на все эти объекты внимания по порядку, по ступенькам, и подробно объяснить себе, что собственно я делаю.

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

Что делаем

“Наше предприятие”::создатель занимается разработкой проектной документации/информационных моделей “капитальных объектов линейной транспортной инфраструктуры”::целевые-системы-предприятия в период эксплуатации и создания.

Для кого/чего делаем

Делаем для для того, чтобы транспортный поток проходил с заданной (описанной в схемах транспортного обслуживания территории и генеральных планах города) пропускной способностью (интенсивностью) всех участников дорожного движения “участка улично-дорожной сети”::целевая-система:

  • автомобили
  • общественный транспорт
  • грузовые авто
  • пешеходы

То есть потребность надсистемы задается описаниями в документах: Проект планировки территории, Схема транспортного обслуживания территории, Техническое задание застройщика, Технические условия и требования систем окружения.
Эти все описания на документах: рабочие продукты входа в производственный конвейер.

На основания всего сбора потребностей проекта формирую дорожную карту контрольных событий проекта (альфы) в онлайн таблице с командами.

image
image1803×512 50.7 KB

Эти контрольные события обсуждаются на планерке.

Далее они погружаются в трекер на доску управления проектом:

image
image2153×259 132 KB

Каждое контрольное событие представляет собой описание желаемого состояния объекта/альфы.

Как делаем

Далее каждое контрольное событие из доски Управление декомпозируется на задачи как часть-целое и переносится уже непосредственно на доску Операционный поток проекта
в колонку Задачи

image
image2267×197 113 KB

Задача в текущем моем понимании это желаемый результат ко времени. Результат - чаще всего рабочий продукт справильным (с заданным описанием в задаче) состоянием, полученного за счет выполненных цепочек работ по методу. Выполнение этих работ - производство.

Что понимаем под понятием Работы. Мне понравилось как @annlub902gmail-com в видео https://youtu.be/U70KqmJ0FGY?si=APX9aZ1nywKFIf4I на 16:35 описала понятия работы в операционном менеджменте. Работа = акт траты ресурсов во времени. (про методы работы и мастерство агента в роли пока не говорим).

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

Производство “проектной документации”/“целевых моделей”::описаний-как-физических-объектов происходит за счет проделанной работы (производственного акта траты ресурсов во времени) агентами в ролях.

Трекер задач и работ - цифровой двойник потоков (последовательности, очередности) нужных работ

Трекер предприятия::агент это экзокортекс для коллективного/командного удержания внимания на описаниях плана и факта выполнения работы.

Для того, чтобы работы и временная мощность выполнения на них текущее и плановое (в будущем) было не предметом описаний::ментальных-объектов в голове агентов, а описанием документированным, отчужденным, возможным к коллективной критике/коррекции, и чтобы с этим можно дальше было как-то планировать загрузку команды, а также находить ограничения (там где затор) и устранять его причины.

А также для того, чтобы работа (трата ресурсов) выполнялась нужная по трассировке от потребности - контрольного события - задачи с чеклистами::описания возможности приемки - работа. А не нудная отсекалась сразу или обсуждалась и отсекалась.

Тогда получается так:
Трекер работ - цифровой двойник потоков планирования и контроля работ (траты ресурсов) команд, описывает ресурсы.

16

тут речь про то, что есть готовая информационная модель - эпистема, а далее агенты ее переносят на носитель (carrier) чем бы это ни было (запись на диск, флешку, печать на бумаге (лазерный принтер, плоттер)) ?

17

Нет, тут речь о том, что наша организация создает описание целевой системы, а не создает физически разворачивание создание целевой системы на площадке.
То есть мы не строим Мост, а мы создаем описание моста в период эксплуатации, и описание разворачивание его создания на площадке строительства, и саму площадку строительства, это раздел по 87-ПП называется Проект организации строительства.

Создаем мы модели либо на локальном сервере предприятия, либо в облаке, это тут не предмет рассмотрения.

А то что вы описали это разность объектов хранения документирования: 1. Файлы с описание в формате PDF/IFC на диске/облаке или 2. Текст на бумажном носителе, книги с переплетами, - вторично.

18

Добрый день!

Да, теперь тоже так склоняюсь думать. Управление потоком работ это по сути управление ресурсами. Так как работа это акт траты этих самых ресурсов.
Ресурс сейчас понимаю как временную мощность агента с ролевым мастерством достаточного уровня для успешного выполнения работы в профессиональном (прикладном) предмете.

Про методолога, методиста согласен. Все это необходимые роли. Но по факту выполняю гораздо больше ролей в этом проекте: Методолог, Инженер платформы, Методист, Лидер, Просветитель (провожу обучение, создаю и поддерживаю мастерство использования системы).

Тоже так думаю. Операционный поток я читаю как поток операций. Операция - это выполнение работы. Итог, да, поток работ или рабочий поток.

Мое представление тут чуть другое. “Целевые модели”::описания мостов::целевых-систем происходит же не за один присест одного агента в роли. Это именно цепочка каких-то артефактов/рабочих продуктов, которые как кирпичики лего также имеют свое время разработки/развития и время использования в последующей цепочке производства (насколько я понял ключевой принцип метода JTBD).

По этой причине я настроил автоматизм при выполнении задачи ответственный создатель этого “кирпичика” должен всегда давать описание созданного кирпича и его путь размещения. и (!) давать свое представление следующего шага: того как и кем будет этот рабочий продукт дальше использоваться.

image
image502×429 15.9 KB

Ну да предметом моих рассуждений и этих мумучения это ответ на вопрос корректно ли называть одну и ту же целевую систему и для предприятия в целом и для создаваемой мною платформы. Теперь прихожу к выводу, что нет. Но удерживать внимание на них (ЦС выпуска) нужно в каждом проекте разработки целевой модели.

Выпуск использую как описание Вещи покидающей границу предприятия, то за что предприятие получает обратный Финансовый поток (оплату и актирование за результат).

В моем понимании термина Инженерия, это все что связано с замысливанием, созданием, развитием, поддержкой, ремонтом и пр. Выбранный трекер это один из инструментов, любой инструмент как часть-целое выбранного метода задает некие границы работы по методу, то есть формирует framework цепочек workflow. То есть в обратку как-то и сам оказывает влияние на метод работы. Трекер тут может быть любым, если соответствуют ключевым, выбранным мною архитектурным характеристикам трекер-системы (не знаю можно ли все таки называть ее системой?).

Не совсем так. Я вижу так: Метод планирования это отдельная история, я создал инструкцию по методам планирования для руководителей проектов и начальников отделов (и они разные). Но трекер тут больше уже про воплощение запланированного по методам планирования.

Этим вопросом задаваться нужно, но в другой роли, в роли инженера подсистем целевой модели. Моя точка рассмотрения тут из роли создателя и пользователя платформы потока рациональных работ. Не делать лишнюю, вносить все задачи с чеклистами, создавать очередь работ, выявлять и подсвечивать недостающие исходные для работы. И постепенно ставить культуру рациональной работы.

Вот пока что в не туда в моем мире )) В моем мире физическое время ожидания как внутреннего так и внешнего может достигать и 90 - 95%. Поэтому мое представление, что ключевые ограничения в основном в таких объектах внимания как: Потребности и интересы, Координационные акты вокруг целевой системы контуров проектных ролей (внешнего и внутреннего), Радар ограничений с выходом на события-риски через моделирование граф причинности и поиск через радар ограничений и постоянных непрерывных интервенциях в этом направлении по улучшению как четкости в коллективном понимании создаваемой системы, так и в поиске и снятию ключевого текущего ограничения.
А вот сделать быстрее модель.. Если ты сделаешь модель не за 1 месяц а за 2, при том, что общее время ожидания из-за плохого исследования, стратегирования и планирования будет 9 - 12 месяцев насколько это критично?
В моем понимании срок там не критичен, а критична точность и снижение переделок.

19

А зачем тебе трекер тогда? Прости пожалуйста. Кроме того, что работы получат описание в цифровом формате. И того что это бюрократически можно продать начальникам как “улучшение”.

20

Хуже: если они делают описание моста, но не строят мост, то вообще ничего не надо – “строители идиоты, не могут построить по нашим чудесным описаниям. Это неважно, что описание плохие, они соответствуют требованиям, и отвалите”. И, конечно, тогда ускорение строительства моста – внешний фактор, с ним не работаем )))

Поскольку тут про “Системное мышление” и всё сразу съехало с целевой системы на цепочку описаний, то бить надо сразу в главное: непонятно, как это всё связано с мостом. Понятно, что есть цепочка проектов работы с бумажками, если на выходе будут бумажки, а моста не будет – то вроде как можно требовать зарплату по потраченному времени. Но не по итогу: построенному мосту.

Вот этот ход первый. Если трекер не ускоряет пуск в эксплуатацию моста, то он не нужен. Аргумент даже не про “трекер для работ”, а вопрос о том, как эти работы вообще связаны с целевой системой. Если непонятно как – можно не делать, всех уволить. Деньги сэкономят, дело не дойдёт до работ, а уж до трекера и подавно.

Всё начинается с целевой системы, и если она далеко – то это главная проблема, надо уметь удерживать её во внимании.

1 лайк