Согласен, вот прямо сейчас не готов предоставить ссылки на исследования, но по моим ощущениям Org-Mode like структуры и MM очень сильно различаются. Кстати, приходит на ум, что движение глаз по наблюдаемому объекту проходит по спирали (ну или кругу), а не линейно как многие привыкли думать. За счет этого объем внимания распределяется по частям объекта равномернее в случае MM, а не Org-Mode.
Думаю, что не так это просто. MindMap изобрели потому что он не наследует последовательность (сверху-вниз), свойственную текстам, и позволяет произвольно смещать фокус внимания отдельно от этой последовательности. Показательным тестом был бы трекинг взгляда Mapper-a.
Вообще несколько непонятен общий подход. Я попробую обрисовать применительно к Enterprise in-house development (на нашем примере).
Допустим, есть стандартный цикл Dev — Test — Acc — Prod. Поскольку приложения ноне многокомпонентные (БД + APP), то есть конфигурация, которая связывает их вместе. Теперь в случае с Docker, разработчик готовит среду (image) и приложение (app), скрипт установки APP в среду (deploy), скрипт конфигурирования (configure). Помимо этих объектов существует объект конфигурации на каждом этапе.
Соответственно, по этапам цикла редко ездят изменения всех этих объектов.
image — реже всех, но именно в этом и ценность — в одном месте собрано, во всех работает. По сути это материалиазация выбранного стека технологий.
deploy — чуть чаще, но неразличимо чаще. Зависит от выбранного стека технологий. Зависит от собственно требуемых настроек приложения.
configure — примерно одинаково с deploy, потому что так же зависит от стека технологий, но в тоже время больше зависит от приложения
app — чаще всех. по сути фиксирует изменения бизнес-процесса компании.
Для изменений configure необходимо также предусматривать изменение объекта конфигурации каждого этапа.
А вот было бы интересно провести один день в контексте tracker ассистента. Ну или просто ассистента, чтобы понять механику акселератора. Заодно и рубрика один мой день пополнится )
Сдается мне, что модель комфортности несколько сложнее, чем «лучше открыто, чем закрыто» и «вместе чем раздельно». Например, был офис Philips — за счет отказа от постоянного места жительства, они дали возможность (а может и вынудили) гибко выбирать контекст работы — тихие закутки, общие спейсы, командные пространства. Не уверен, что многие компании на это же и решились, но тенденция идет в этом же направлении. Все эти игровые/душевые/бары/ad-hoc переговорные и пуфики позволяют подбирать окружение под текущий настрой, что улучшает общее состояние и повышает продуктивность. Примеров уже сильно больше чем Philips WPI.
Однако, и то и другое упирается в ограничитель сознания сотрудников. Во-первых, это сложная (сначала) работа — рефлексировать свое состояние. Осознать, что надо двигаться куда-то существенно сложнее, чем просто двигаться. Второе — преодолевать устоявшийся стереотип о важности последовательности выбора. Боязнь осуждения при смене вида деятельности/нахождения — довольно серъезно влияет на решимость такого шага. Для этого собственно и делают офисы веселыми — мнимое общественное «порицание» нивелируется несеръезностью обстановки. Третье — быть готовым к таким перемещениям. То есть не упираться в наличие вороха бумаг, уметь оставлять поводки для тех, кто будет искать контакта по принципу пространственного поиска, быть мобильным в части использования различных технических средств в различных пространствах. Ну и другое по мелочи.
Механизмы работы с такими ограничениями есть как со стороны компании — веселые офисы, лидеры, BYOD, виртуализация, интегрированная коммуникация — так и со стороны сотрудников. Но формализация таких механизмов у сотрудников еще требует размышлений.
Но ценность в деталях — зимние варианты и мобильные варианты. Кроме того, инфраструктура — не самый последний вопрос, хотя с ним существенно все понятней чем с материалами дома. Например, интернет, электричество, вода.
Ну тут «правильная» цель описания процессов — начало анализа и выявления плохих этапов. Но в нашей действительности до этого никто особенно не доходит. Считается, что описание процесса — самая что ни на есть цель аналитической деятельности (тут, конечно, я про свой опыт говорю, уверен, у всех пони резвятся на облаках).
Просто ACM — это такой Agile для процессов, поэтому он раньше дает выгоду. Но есть у меня сомнение — будут ли процессы таким образом подкрученные хоть как-то измеримы и сопоставимы?
Вот, кстати, интересный аспект. Инструментов обжалования действий начальника я навскидку не приведу из «реальной» офисный жизни. Все что мне приходилось видеть — это возможность уволиться )))
Допустим, есть стандартный цикл Dev — Test — Acc — Prod. Поскольку приложения ноне многокомпонентные (БД + APP), то есть конфигурация, которая связывает их вместе. Теперь в случае с Docker, разработчик готовит среду (image) и приложение (app), скрипт установки APP в среду (deploy), скрипт конфигурирования (configure). Помимо этих объектов существует объект конфигурации на каждом этапе.
Соответственно, по этапам цикла редко ездят изменения всех этих объектов.
image — реже всех, но именно в этом и ценность — в одном месте собрано, во всех работает. По сути это материалиазация выбранного стека технологий.
deploy — чуть чаще, но неразличимо чаще. Зависит от выбранного стека технологий. Зависит от собственно требуемых настроек приложения.
configure — примерно одинаково с deploy, потому что так же зависит от стека технологий, но в тоже время больше зависит от приложения
app — чаще всех. по сути фиксирует изменения бизнес-процесса компании.
Для изменений configure необходимо также предусматривать изменение объекта конфигурации каждого этапа.
Ну и там написано всякого
www.w3.org/community/webpayments/wiki/Main_Page
www.w3.org/wiki/Payments_Task_Force
и собственно описываемая встреча
www.w3.org/2013/10/payments/minutes/
Однако, и то и другое упирается в ограничитель сознания сотрудников. Во-первых, это сложная (сначала) работа — рефлексировать свое состояние. Осознать, что надо двигаться куда-то существенно сложнее, чем просто двигаться. Второе — преодолевать устоявшийся стереотип о важности последовательности выбора. Боязнь осуждения при смене вида деятельности/нахождения — довольно серъезно влияет на решимость такого шага. Для этого собственно и делают офисы веселыми — мнимое общественное «порицание» нивелируется несеръезностью обстановки. Третье — быть готовым к таким перемещениям. То есть не упираться в наличие вороха бумаг, уметь оставлять поводки для тех, кто будет искать контакта по принципу пространственного поиска, быть мобильным в части использования различных технических средств в различных пространствах. Ну и другое по мелочи.
Механизмы работы с такими ограничениями есть как со стороны компании — веселые офисы, лидеры, BYOD, виртуализация, интегрированная коммуникация — так и со стороны сотрудников. Но формализация таких механизмов у сотрудников еще требует размышлений.
А альфы — молодцы, да!
Но ценность в деталях — зимние варианты и мобильные варианты. Кроме того, инфраструктура — не самый последний вопрос, хотя с ним существенно все понятней чем с материалами дома. Например, интернет, электричество, вода.
Просто ACM — это такой Agile для процессов, поэтому он раньше дает выгоду. Но есть у меня сомнение — будут ли процессы таким образом подкрученные хоть как-то измеримы и сопоставимы?