ailev.ru

Обсуждение

В архиве: 8 комментариев.

Читать и комментировать в ЖЖ ↗

Имя не сохранено · 15 марта 2013

Комментарий

ЦЕЛЬ, ею определяется остальное. Но в русском цель - просто цель. goal цель, задача, ворота, гол, финиш, мета end конец, окончание, цель, завершение, часть, край purpose цель, назначение, намерение, целеустремленность, воля, результат objective цель, задача, объект, стремление, объектный падеж, косвенный падеж aim цель, задача, стремление, прицел, прицеливание, намерение target цель, мишень, план, задание, норма, контрольная цифра object объект, предмет, цель, вещь, дополнение, конечная цель mission миссия, задача, задание, цель, представительство, предназначение destination назначение, пункт назначения, место назначения, цель, предназначение, адресат intent намерение, цель, умысел intention намерение, цель, стремление, замысел, умысел, идея point точка, пункт, момент, место, дело, цель

Имя не сохранено · 17 марта 2013

Комментарий

Как-то сразу в голову приходят из психологии: задатки, способности и навыки. Задатки закладываются генетически, то есть проектно. Они могли бы быть possibilities. Способности это задатки, которые проявляются в поведении, то есть доступные функции. Это похоже на capabilities. И есть еще навык, который развивается из способности посредством опыта. Его можно поставить в соответствие налаженному производственному процессу, но такой термин не очень смотрится в контексте. Opportunities могут остаться возможностями.

Анатолий Левенчук · 18 марта 2013

Комментарий

Capabilities -- это не функции. Это про те состояния, в которые система может привести окружающий мир. Хотя я понимаю, что граница между всеми этими определениями расплывчата ("способность иметь забитые гвозди" и "способность забивания гвоздей" практически неразличимы -- но всё-таки в первом варианте есть акцент на результат, а во втором варианте нет. Типа разницы между "учил" и "выучил").

Ответ на комментарий

Имя не сохранено · 18 марта 2013

Комментарий

Способность забивания гвоздей - это конкретный гвоздезабивающий агрегат, который стоит на сайте. У него есть паспорт, где написано, какие гвозди он способен забивать, и с какой скоростью. Возможность иметь забитые гвозди - это тот же самый агрегат, но должным образом установленный, подлюченный, заряженный гвоздями и обеспеченный материалом. Он подготовлен выполнять свои непосредственные функции, и мы можем уже оперировать числами другого порядка - сколько мы можем иметь забитых гвоздей, исходя из характеристик аппарата, запаса гвоздей, заготовок, стоимости электричества, и т. д. Как только в нем закончатся гвозди или материал, или будет отключен ток - возможность иметь забитые гвозди исчезнет, способность останется. Если я правильно понимаю разницу.

Ответ на комментарий

Анатолий Левенчук · 18 марта 2013

Комментарий

Я бы не играл тут в слова (я уже писал, что сами термины для меня мало что значат). Сначала мы абстрагируемся от конструкции, чтобы понять, какое поведение мы хотим получить от системы. Много разных конструкций могут поддержать одно поведение. А вторым шагом мы абстрагируемся от поведения, чтобы понять, какое состоянием мира мы хотим получить от поведения. Много разных поведений могут вести к одному целевому состоянию мира. Забитые гвозди -- это можно и людьми делать, и агрегатом, и поручить кому-нибудь. Забивать гвозди можно и агрегатом, и молотком. Capability -- function -- construction. А то, что вы пытаетесь обсуждать с гвоздями -- это availability (то есть доступность получения сервиса. Ибо аппарат может наличествовать, но быть поломанным, занятым, без запаса гвоздей и т.д.. Capability -- это содержательное рассмотрение, а availability -- операционное).

Ответ на комментарий

Имя не сохранено · 20 марта 2013

Комментарий

> ... "якобы архитектор" пристаёт ко всем с расспросами, и делает архитектурные описания -- архитектурой занимаются какие-то другие люди, а наш "якобы архитектор" при этом является только писарем, писцом, владеющим искусством записывать чужие мысли. ... В целом согласен, но резковато получилось. Несколько дней размышлял. ИМХО, "якобы архитектор", который "писарь", без него в сложной системе не обойтись, остальные видят только фрагменты процесса и их архитектурное творчество касается только своих фрагментов. А "писарю" доступно полное описание и он, гипотетически, чуть ли не единственный кто способен к постоянной трансформации системы от complexity к simplicity. Еще встречаются энтузиасты из числа обычных сотрудников, любопытство которых заставляет изучать всю систему по сделанному "писарем" описанию и предлагать варианты оптимизации системы. Но и в этом случае "писарь" для них как прожектор высвечивающий текущую архитектуру системы. А также "писарь" обязан консультировать "реальных архитекторов" из числа управленцев, чтобы минимизировать трансформацию архитектуры предприятия в сторону complexity.

Анатолий Левенчук · 20 марта 2013

Комментарий

Я не считаю, что получилось резковато: я ведь в жизни наблюдал некоторое количество таких примеров (и, увы, не наблюдал ничего "смягчающего"). Так что, увы, у меня тут написан мейнстрим, а вы приводите примерами как раз более редкие ситуации. Ну, и "администратор базы данных" финансовой системы никакого отношения к назначению KPI, должностных окладов, утверждению формул вычисления прибыли и т.д. не имеет. Так и "писарь на ArchiMate" не имеет отношения к формулированию того, как будет организовано предпринятие. А обсуждать -- так любые бабушки на лавочках у подъезда тоже могут обсуждать президента РФ, законы и т.д., но толку-то от этих обсуждений?

Ответ на комментарий