Полное совпадение, включая падежи, без учёта регистра

Искать в:

Можно использовать скобки, & («и»), | («или») и ! («не»). Например, Моделирование & !Гриндер

Где искать
Журналы

Если галочки не стоят — только metapractice

Автор
Показаны записи 5291 - 5300 из 56300
</>
[pic]
Re: Моделируем на русском.

bavi в посте Metapractice (оригинал в ЖЖ)

)))
Спасибо. С Наступающим и здоровья с новыми годами!
Слава богу!
С наступающим тебя!
А есть настройка/тонкости для такого исследования при работе с оператором и самостоятельно?
Да, только, по одной форме за один раз:
--все исследуют "это" на материале нескольких исходных пар базовых прес. существования - отчитались
--все исследуют "даже" ...
...и т.д.
</>
[pic]
Re: Моделируем на русском.

bavi в посте Metapractice (оригинал в ЖЖ)

О себе могу сказать, что я стремлюсь к такому понимаю, хоть медленно, с отставанием, но стремлюсь)))
Т.е нечто похожее на следующее(если взять несколько пресуппозиций из списка):
- эта линия удлиняется
- даже эта линия удлиняется
- только эта линия удлиняется
- опять эта линия удлиняется
- эта линия уже удлиняется?
- эта линия еще не удлиняется?
- даже не только эта линия удлиняется
- ты знаешь, что эта линия удлиняется
- любопытно, эта линия удлиняется?
- насколько удлиняется эта линия?
- разве эта линия не удлиняется?
- неужели эта линия не удлиняется?
- насколько ты удивишься, что линия удлинилась?
....
и мы исследуем изменение именно этой связки на большом количестве субъектов?
Команда
Основные трудности в том, что практики работы с командой крайне неформализованы, имеют огромное количество вариаций в связи с личностным стилем руководителя. Они главным образом определяются дисциплиной “лидерство” (leadership), которая сама по себе крайне неформальна (хотя часть этих практик определяется более формализованными практиками human resources management и менее распространёнными talent management). В последнее время практики лидерства и командообразования для технических проектов изучаются в рамках развития методологий для agile видов жизненного цикла. Мы тут воздержимся от примеров практик, в которых определяются описания рабочих продуктов, используемых для работы с альфой команды — это совершенно особый предмет.
Подальфы команды — это “член команды” и “подрядчик”. Но могут быть и менее очевидные альфы, например, “сотрудничество” (которого вначале нет, а потом оно должно появиться) и “ресурсы” (которых вначале может не быть, но которые затем должны появиться): это всё разные аспекты “команды”, с которыми работают разные люди предприятия.
</>
[pic]
U @BWg1SWny:tDJl\HR7l"辚d

metanymous в посте Metapractice (оригинал в ЖЖ)

Возможности
Основа работы с возможностями — это предпринимательство, которое принципиально неформализуемо, ибо связано как-то с оценками будущего. В современном мире предпринимательские решения слабо поддаются формализации. Это относится и к таким решениям, как принятие заказа к исполнению в зависимости от текущей загрузки ресурсов — принятие решения на основе теории предельной (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 к продвижению по состояниям всей альфы “стейкхолдеры”).
Помним также, что “подрядчик” и “член команды” — это тоже подальфы “стейкхолдеров”.
Архитектурные знания
Очень редко архитектурные (важные, требующие существенных переделок всего проекта при их изменении) решения изобретаются заново, чаще они повторноиспользуемы. Знания — это повторноиспользуемая в разных ситуациях информация, т.е. можно говорить об архитектурных знаниях.
Архитектурные решения – это чаще всего накопленные человечеством, отраслью, организацией, конструктором/проектировщиком знания. Чаще всего архитектура не “изобретается”, а просто дорабатывается уже готовая — якобы “новая система” использует огромное количество старых важных инженерных решений.
Тем не менее лидерство в инженерии обычно определяется предложением новых архитектур — новых инженерных решений, т.е. связано с развитием инженерного знания, обычно исходя из “первых принципов” (т.е. исходя из физических законов, теории алгоритмов и т.д.).

Дочитали до конца.