Да, интуитивный ответ именно такой, согласен ))
Во-первых, такое распределение времени ожидание/в процессе не всегда.
Во-вторых, ожидание не пассивное. Там всегда есть много разной координационной и управленческой работы, ее тоже нужно отслеживать.
От отслеживания ничего не меняется. Пока это трекер, то это аналитика. Аналитиков всех уволить, они только всё понимают, ничего вокруг не меняют. Если меняют – они инженеры, а не аналитики, у них не трекеры, а каких-то другие системы. Скажем, issue tracker – это отслеживатель решения проблем, и он нужен для решения проблем, а не для аналитика, наблюдающего за чем-то и дающего своё мнение кому-то, кто принимает на себя ответственность и вкалывает.
Это всё, увы, в последующих руководствах подробненько, там и про issue trackers есть, case management.
Вам пока надо разобраться, как вы влияете в вашем проекте на ускорение ввода в эксплуатацию моста. Если не можете объяснить за пару минут, то хороший повод для закрытия проекта: “на ввод в эксплуатацию моста никак не влияет, можно уволить их там всех”. А у вас даже не ERP (планирование ресурсов), а вы это называете “трекером”, отслеживанием – и не ресурсов, а работ (хотя возможность их выполнения обычно в недостатке ресурсов и отслеживать надо бы их, но не отслеживать, а как-то влиять на их наличие вовремя к началу работы). Про работы много было на R1, это операционный менеджмент. И отслеживать: “вот эта работа опоздала на день, строительство моста задержалось на 180 дней – там вечная мерзлота, в сезон не успели, дальше полгода ждать”. Вот это надо как-то разруливать (а не отслеживать). И дальше показывать, где там ваше скромное место – только после предъявления того, что вы понимаете, что происходит и как вы влияете на ускорение ввода моста в эксплуатацию.
1 лайк
я не определял это внешним фактором.
такого не помню чтобы говорил, что так делаем или так нужно делать.
Вот не понимаю зачем такое писать?)))
Да, совершенно верно. Съехало в рассуждений от предмета вопроса в посте.
Вопрос которым я задался при выполнении упражнения выбрать рабочий проект, был такой:
таких не держим.
значит это ищью трекер и работают в нем инженеры.
То есть все таки целевой системой проекта issue tracker будет все та же целевая система::Мост (дорога, УДС и пр.).
Да, это главное во всём R5 – системном мышлении. Даже если кто-то убирает у вас помещение, если это не помогает ввести в эксплуатацию мост (физический объект), то это можно не делать. И причинно-следственные цепочки тут надо отслеживать. Все работают на одну цель.
А вот какие-там ещё системы и проекты в их цепочках стоят между вами и мостом – это второй вопрос. Их можно обсуждать только тогда, когда вы твёрдо знаете, что делаете мост (а не, например, описание моста). И все разговоры начинать с моста и его ввода в эксплуатацию, его характеристик в момент эксплуатации. И затем только переходить к сооружению и строительству, описаниям всего этого только после разбирательства с “как это будет в физическом мире”, а потом уже деталям работы с описаниями в длинной цепочке связанных проектов.
Это системная мантра, её надо блюсти. У всех в проекте одна и та же целевая система проекта, разные свои системы своих мелких проектов.
1 лайк
Огромное Вам спасибо!
Можно мне дальше работать.
А это взял в работу, сделаю:
2 лайка