Показаны записи 2581 - 2590 из 30962
</>
Re: ментальные процессы vs объекты и возможные изменения
metanymous в посте Metapractice (оригинал в ЖЖ)
Да, только, по одной форме за один раз:
--все исследуют "это" на материале нескольких исходных пар базовых прес. существования - отчитались
--все исследуют "даже" ...
...и т.д.
--все исследуют "это" на материале нескольких исходных пар базовых прес. существования - отчитались
--все исследуют "даже" ...
...и т.д.
Команда
Основные трудности в том, что практики работы с командой крайне неформализованы, имеют огромное количество вариаций в связи с личностным стилем руководителя. Они главным образом определяются дисциплиной “лидерство” (leadership), которая сама по себе крайне неформальна (хотя часть этих практик определяется более формализованными практиками human resources management и менее распространёнными talent management). В последнее время практики лидерства и командообразования для технических проектов изучаются в рамках развития методологий для agile видов жизненного цикла. Мы тут воздержимся от примеров практик, в которых определяются описания рабочих продуктов, используемых для работы с альфой команды — это совершенно особый предмет.
Подальфы команды — это “член команды” и “подрядчик”. Но могут быть и менее очевидные альфы, например, “сотрудничество” (которого вначале нет, а потом оно должно появиться) и “ресурсы” (которых вначале может не быть, но которые затем должны появиться): это всё разные аспекты “команды”, с которыми работают разные люди предприятия.
Основные трудности в том, что практики работы с командой крайне неформализованы, имеют огромное количество вариаций в связи с личностным стилем руководителя. Они главным образом определяются дисциплиной “лидерство” (leadership), которая сама по себе крайне неформальна (хотя часть этих практик определяется более формализованными практиками human resources management и менее распространёнными talent management). В последнее время практики лидерства и командообразования для технических проектов изучаются в рамках развития методологий для agile видов жизненного цикла. Мы тут воздержимся от примеров практик, в которых определяются описания рабочих продуктов, используемых для работы с альфой команды — это совершенно особый предмет.
Подальфы команды — это “член команды” и “подрядчик”. Но могут быть и менее очевидные альфы, например, “сотрудничество” (которого вначале нет, а потом оно должно появиться) и “ресурсы” (которых вначале может не быть, но которые затем должны появиться): это всё разные аспекты “команды”, с которыми работают разные люди предприятия.
Возможности
Основа работы с возможностями — это предпринимательство, которое принципиально неформализуемо, ибо связано как-то с оценками будущего. В современном мире предпринимательские решения слабо поддаются формализации. Это относится и к таким решениям, как принятие заказа к исполнению в зависимости от текущей загрузки ресурсов — принятие решения на основе теории предельной (marginal/маржевой/граничной) полезности (utility) и маржинальных цен, или инвестиционные решения в проработку возможностей по заключению контракта или выходу на рынок. Но в силу сложности предпринимательской деятельности и коллективного её характера появилось довольно много практик формализации и документирования промежуточных для принятия предпринимательских (инвестиционных, стратегических, маркетинговых) решений.
Пожалуй, альфа возможности — это самая сложная для работы альфа. По сложности работы с ней может сравниться только альфа команды. С другой стороны, инженер может стать великим предпринимателем и великим лидером. Но отнюдь не каждый великий предприниматель и великий лидер может стать инженером, так что к оценкам относительной сложности работы с разными альфами нужно относиться очень осторожно: что просто для одного человека, может быть запредельно трудно и даже невозможно для другого, и наборот.
Среди подальф возможностей нужно особо указать “бюджет”, с которым работают практики бюджетирования (включая такие, как beyond budgeting), а также “потребности” (stakeholder needs), с которыми работают практики анализа потребностей (user needs analysis, целеориентированная инженерия требований и т.д.).
Основа работы с возможностями — это предпринимательство, которое принципиально неформализуемо, ибо связано как-то с оценками будущего. В современном мире предпринимательские решения слабо поддаются формализации. Это относится и к таким решениям, как принятие заказа к исполнению в зависимости от текущей загрузки ресурсов — принятие решения на основе теории предельной (marginal/маржевой/граничной) полезности (utility) и маржинальных цен, или инвестиционные решения в проработку возможностей по заключению контракта или выходу на рынок. Но в силу сложности предпринимательской деятельности и коллективного её характера появилось довольно много практик формализации и документирования промежуточных для принятия предпринимательских (инвестиционных, стратегических, маркетинговых) решений.
Пожалуй, альфа возможности — это самая сложная для работы альфа. По сложности работы с ней может сравниться только альфа команды. С другой стороны, инженер может стать великим предпринимателем и великим лидером. Но отнюдь не каждый великий предприниматель и великий лидер может стать инженером, так что к оценкам относительной сложности работы с разными альфами нужно относиться очень осторожно: что просто для одного человека, может быть запредельно трудно и даже невозможно для другого, и наборот.
Среди подальф возможностей нужно особо указать “бюджет”, с которым работают практики бюджетирования (включая такие, как beyond budgeting), а также “потребности” (stakeholder needs), с которыми работают практики анализа потребностей (user needs analysis, целеориентированная инженерия требований и т.д.).
Стейкхолдеры
Основные практики работы со стейкхолдерами — это обеспечение того, чтобы представители групп стейкхолдеров/исполнители ролей стейкхолдеров активно участвовали в разработке, т.е. практики лидерства и коллаборации.
Стейкхолдеров обычно много (для удобного их группирования часто используют луковичную диаграмму — http://businessanalystlearnings.com/ba-techniques/2013/1/22/how-to-draw-a-stakeholder-onion-diagram), и все они обычно находятся в разном состоянии в какой-то момент времени. Поэтому хорошей практикой является определение подальфы “стейкхолдер”, и далее работа с отдельными экземплярами этой альфы (понимая, что продвижение по состояниям каждого из стейкхолдеров ведёт/drive к продвижению по состояниям всей альфы “стейкхолдеры”).
Помним также, что “подрядчик” и “член команды” — это тоже подальфы “стейкхолдеров”.
Основные практики работы со стейкхолдерами — это обеспечение того, чтобы представители групп стейкхолдеров/исполнители ролей стейкхолдеров активно участвовали в разработке, т.е. практики лидерства и коллаборации.
Стейкхолдеров обычно много (для удобного их группирования часто используют луковичную диаграмму — http://businessanalystlearnings.com/ba-techniques/2013/1/22/how-to-draw-a-stakeholder-onion-diagram), и все они обычно находятся в разном состоянии в какой-то момент времени. Поэтому хорошей практикой является определение подальфы “стейкхолдер”, и далее работа с отдельными экземплярами этой альфы (понимая, что продвижение по состояниям каждого из стейкхолдеров ведёт/drive к продвижению по состояниям всей альфы “стейкхолдеры”).
Помним также, что “подрядчик” и “член команды” — это тоже подальфы “стейкхолдеров”.
Архитектурные знания
Очень редко архитектурные (важные, требующие существенных переделок всего проекта при их изменении) решения изобретаются заново, чаще они повторноиспользуемы. Знания — это повторноиспользуемая в разных ситуациях информация, т.е. можно говорить об архитектурных знаниях.
Архитектурные решения – это чаще всего накопленные человечеством, отраслью, организацией, конструктором/проектировщиком знания. Чаще всего архитектура не “изобретается”, а просто дорабатывается уже готовая — якобы “новая система” использует огромное количество старых важных инженерных решений.
Тем не менее лидерство в инженерии обычно определяется предложением новых архитектур — новых инженерных решений, т.е. связано с развитием инженерного знания, обычно исходя из “первых принципов” (т.е. исходя из физических законов, теории алгоритмов и т.д.).
Очень редко архитектурные (важные, требующие существенных переделок всего проекта при их изменении) решения изобретаются заново, чаще они повторноиспользуемы. Знания — это повторноиспользуемая в разных ситуациях информация, т.е. можно говорить об архитектурных знаниях.
Архитектурные решения – это чаще всего накопленные человечеством, отраслью, организацией, конструктором/проектировщиком знания. Чаще всего архитектура не “изобретается”, а просто дорабатывается уже готовая — якобы “новая система” использует огромное количество старых важных инженерных решений.
Тем не менее лидерство в инженерии обычно определяется предложением новых архитектур — новых инженерных решений, т.е. связано с развитием инженерного знания, обычно исходя из “первых принципов” (т.е. исходя из физических законов, теории алгоритмов и т.д.).
Команда
Команда (team) инженерного проекта — это не просто какие-то люди или организации (группы людей с оборудованием и известным распределением полномочий). Это люди с совершенно определённым набором компетенций, нужных для реализации проекта, при этом речь идёт не только об инженерных, но и о менеджерских и других прикладных компетенциях.
Команда создаёт определение и воплощение системы, команда выполняет работы, команда применяет практики (дисциплины в головах и технологии в предпринятии).
Команда должна работать как слаженный коллектив, для этого её нужно организовать из отдельных составляющих её людей. Для того, чтобы каждый человек занял своё место на логистическом “конвейере” (ибо если какие-то места на этом “конвейере” не будут заполнены людьми, то целевая система просто не сможет выпуститься — необходимые на этом рабочем месте работы не будут произведены), нужно его “уговорить”.
Это функция “комиссара”, пропагандиста, специалиста по менеджерской дисциплине “лидерство” (leadership). Лидер выполняет работы, которые можно описать двояко (помним, что это два разных описания одной и той же деятельности):
● Убалтывает исполнителей ролей команды играть в этой команде необходимые роли (убалтывает путать “личное” и “общественное”).
● Осмысляет жизнь исполнителей ролей тем, что они приносят стейкхолдерам пользу, их жизнь и работа имеют значение для окружающих.
Команда (team) инженерного проекта — это не просто какие-то люди или организации (группы людей с оборудованием и известным распределением полномочий). Это люди с совершенно определённым набором компетенций, нужных для реализации проекта, при этом речь идёт не только об инженерных, но и о менеджерских и других прикладных компетенциях.
Команда создаёт определение и воплощение системы, команда выполняет работы, команда применяет практики (дисциплины в головах и технологии в предпринятии).
Команда должна работать как слаженный коллектив, для этого её нужно организовать из отдельных составляющих её людей. Для того, чтобы каждый человек занял своё место на логистическом “конвейере” (ибо если какие-то места на этом “конвейере” не будут заполнены людьми, то целевая система просто не сможет выпуститься — необходимые на этом рабочем месте работы не будут произведены), нужно его “уговорить”.
Это функция “комиссара”, пропагандиста, специалиста по менеджерской дисциплине “лидерство” (leadership). Лидер выполняет работы, которые можно описать двояко (помним, что это два разных описания одной и той же деятельности):
● Убалтывает исполнителей ролей команды играть в этой команде необходимые роли (убалтывает путать “личное” и “общественное”).
● Осмысляет жизнь исполнителей ролей тем, что они приносят стейкхолдерам пользу, их жизнь и работа имеют значение для окружающих.
</>
дисциплины, практики, методы Дисциплины/области интер
metanymous в посте Metapractice (оригинал в ЖЖ)
Методологическая действительность: дисциплины, практики, методы
Дисциплины/области интереса
Основная схема включает указание на три основные предметные области/области интереса/дисциплины (area of concern), они выделены на диаграмме зелёным, жёлтым и голубым цветами:
● Технологический менеджмент, упор на маркетинг/стратегирование: как сотрудничать со стейкхолдерами, которые дают возможности для самых разных проектов (“предпринятий” — от “предпринять что-то”) и соединять их с возможностями, которые даёт команда. Если возможности стейкхолдеров и команды совпали, то проекту быть! На диаграмме эта предметная область/дисциплина отмечено, как относящееся к “клиенту” (client). Системная инженерия всегда кого-то обслуживает! Инженеры не разрабатывают системы сами для себя!”
● инженерию: как придумать/определить и сделать/воплотить успешную систему. На диаграмме это область “инженерного решения” (solution, не путайте с decision!).
● Инженерный менеджмент, упор на операционный менеджмент и лидерство: как собрать и сплотить компетентную команду, оснастить её всеми необходимыми технологиями и организовать работы по проекту. На диаграмме это область “предпринятия” (от “предпринять” что-то, но слово “предприятие” не подходит, речь тут идёт не о юридическом лице — это может быть и большой холдинг, и какая-нибудь “рабочая группа проекта”. В OMG Essence это “Endeavor”, ибо стандарт писали в США главным образом. В Англии было бы “более по-французски” — Endeavour).
Дисциплины/области интереса
Основная схема включает указание на три основные предметные области/области интереса/дисциплины (area of concern), они выделены на диаграмме зелёным, жёлтым и голубым цветами:
● Технологический менеджмент, упор на маркетинг/стратегирование: как сотрудничать со стейкхолдерами, которые дают возможности для самых разных проектов (“предпринятий” — от “предпринять что-то”) и соединять их с возможностями, которые даёт команда. Если возможности стейкхолдеров и команды совпали, то проекту быть! На диаграмме эта предметная область/дисциплина отмечено, как относящееся к “клиенту” (client). Системная инженерия всегда кого-то обслуживает! Инженеры не разрабатывают системы сами для себя!”
● инженерию: как придумать/определить и сделать/воплотить успешную систему. На диаграмме это область “инженерного решения” (solution, не путайте с decision!).
● Инженерный менеджмент, упор на операционный менеджмент и лидерство: как собрать и сплотить компетентную команду, оснастить её всеми необходимыми технологиями и организовать работы по проекту. На диаграмме это область “предпринятия” (от “предпринять” что-то, но слово “предприятие” не подходит, речь тут идёт не о юридическом лице — это может быть и большой холдинг, и какая-нибудь “рабочая группа проекта”. В OMG Essence это “Endeavor”, ибо стандарт писали в США главным образом. В Англии было бы “более по-французски” — Endeavour).
Системная инженерия и менеджмент
Прежде всего нужно отметить, что менеджмент сам по себе неоднородная дисциплина. Менеджментов, тесно связанных с инженерией, выделяют три (но это только самое грубое деление):
● Инженерный менеджмент (engineering management), в основе которого лежит операционный менеджмент (исследования операций, логистика, проектное и процессное управление)
● Технологический менеджмент (technology management, можно перевести и как “технологичный менеджмент” и “менеджмент технологий” в зависимости от проставляемого акцента) — cтратегирование (предпринимательство, инновации) и маркетинг (продажи). Сюда же часто относят работу CTO и CIO.
● Системноинженерный менеджмент (systems engineering management) или в российской традиции “управление жизненным циклом”: часть системной инженерии, обеспечивающая целостность и преемственность в выполнении всех необходимых работ по мере того, как система проходит стадии замысла, проектирования, воплощения в жизнь, использования и вывода из эксплуатации.
Кроме этого “менеджер” ещё и работает с людьми (leadership) — выполняет роль лидера, катализируя сотрудничество.
Прежде всего нужно отметить, что менеджмент сам по себе неоднородная дисциплина. Менеджментов, тесно связанных с инженерией, выделяют три (но это только самое грубое деление):
● Инженерный менеджмент (engineering management), в основе которого лежит операционный менеджмент (исследования операций, логистика, проектное и процессное управление)
● Технологический менеджмент (technology management, можно перевести и как “технологичный менеджмент” и “менеджмент технологий” в зависимости от проставляемого акцента) — cтратегирование (предпринимательство, инновации) и маркетинг (продажи). Сюда же часто относят работу CTO и CIO.
● Системноинженерный менеджмент (systems engineering management) или в российской традиции “управление жизненным циклом”: часть системной инженерии, обеспечивающая целостность и преемственность в выполнении всех необходимых работ по мере того, как система проходит стадии замысла, проектирования, воплощения в жизнь, использования и вывода из эксплуатации.
Кроме этого “менеджер” ещё и работает с людьми (leadership) — выполняет роль лидера, катализируя сотрудничество.
Традиционный советский способ ведения сложных разработок
В) включал как административное, так и техническое руководство проектами со стороны генеральных конструкторов, совмещающих менеджерскую и инженерную роли — и по мере разворачивания работ акцент с технического руководства переводился во всё более и более административный пласт. Этот тренд советского времени был поддержан в постсоветское время: ГИП (главный инженер проекта) только номинально выполняет роль технического лидера, по факту же он менеджер и несёт ответственность за соблюдение сроков, выполнение бюджета, своевременность отгрузок результатов работ и проплат вознаграждений контракторам. По факту сейчас работы по удержанию инженерного целого выполняет “консилиум” начальников отделов специальной инженерии — в ходе проведения бесчисленных совещаний и согласований результатов работы подразделений. Это вполне нормально, но методы такой коллективной работы не опираются на системный подход явно, правила согласований изобретаются по ходу дела, нет ответственных за отсутствие “белых пятен” в целостной инженерной проработке, что ведёт к плохому качеству работ.
В) включал как административное, так и техническое руководство проектами со стороны генеральных конструкторов, совмещающих менеджерскую и инженерную роли — и по мере разворачивания работ акцент с технического руководства переводился во всё более и более административный пласт. Этот тренд советского времени был поддержан в постсоветское время: ГИП (главный инженер проекта) только номинально выполняет роль технического лидера, по факту же он менеджер и несёт ответственность за соблюдение сроков, выполнение бюджета, своевременность отгрузок результатов работ и проплат вознаграждений контракторам. По факту сейчас работы по удержанию инженерного целого выполняет “консилиум” начальников отделов специальной инженерии — в ходе проведения бесчисленных совещаний и согласований результатов работы подразделений. Это вполне нормально, но методы такой коллективной работы не опираются на системный подход явно, правила согласований изобретаются по ходу дела, нет ответственных за отсутствие “белых пятен” в целостной инженерной проработке, что ведёт к плохому качеству работ.
</>
Системноинженерое лидерство, заинтересовано объеди
metanymous в посте Metapractice (оригинал в ЖЖ)
Ещё одна классификация разных видов системных инженеров была предложена в 2013 году техническим директором INCOSE Bill Miller. Он предложил отнести всех системных инженеров к шести “племенам” (tribes) в соответствии с их основным интересом в системной инженерии:
1. Технические практики всего жизненного цикла (работа с требованиями, архитектурой, проверкой и приёмкой, и т.д.)
2. Системноинженерный менеджмент, который тоже озабочен практиками, только практики о другом (управление конфигурацией, управление информацией, и т.д.).
3. Моделеориентированная системная инженерия, которая пытается трансформировать практику использования неявных (и часто запертых в сером веществе инженеров) описательных и вторичных по отношению к спецификациям моделей в практику использования явных первичных и богатых выразительными возможностями моделей.
4. Нетрадиционные промышленные экосистемы (то есть за пределами аэрокосмической инженерии), часто включают и "местные" практики.
5. "Мягкие системы", системное мышление и системная наука, которые имеют дело со сложными, вероятностными или недетерминистскими системами.
6. Системноинженерое лидерство, заинтересовано объединить практики всех остальных племён и катализировать их дружную совместную работу.
1. Технические практики всего жизненного цикла (работа с требованиями, архитектурой, проверкой и приёмкой, и т.д.)
2. Системноинженерный менеджмент, который тоже озабочен практиками, только практики о другом (управление конфигурацией, управление информацией, и т.д.).
3. Моделеориентированная системная инженерия, которая пытается трансформировать практику использования неявных (и часто запертых в сером веществе инженеров) описательных и вторичных по отношению к спецификациям моделей в практику использования явных первичных и богатых выразительными возможностями моделей.
4. Нетрадиционные промышленные экосистемы (то есть за пределами аэрокосмической инженерии), часто включают и "местные" практики.
5. "Мягкие системы", системное мышление и системная наука, которые имеют дело со сложными, вероятностными или недетерминистскими системами.
6. Системноинженерое лидерство, заинтересовано объединить практики всех остальных племён и катализировать их дружную совместную работу.
Дочитали до конца.