August 25th, 2017

2019

Opportunity и Capability в ArchiEssence

Одно и то же русское слово "возможность" используется и для opportunity, и для capability.

В OMG Essence (системная схема проекта) слово opportunity, "возможность". Я когда-то перевёл даже множественным числом: "ищут разные возможности", а не "ищут конкретную возможность". Вот цитата из стандарта 1.1 (http://www.omg.org/spec/Essence/), и помним, что в стандарте намеренно приведены мутные формулировки, дабы поощрить их обсуждение командой проекта:

Opportunity: The set of circumstances that makes it appropriate to develop or change a software system. The opportunity articulates the reason for the creation of the new, or changed, software system. It represents the team’s
shared understanding of the stakeholders’ needs, and helps shape the requirements for the new software system by
providing justification for its development.

States
  • Identified (определена) -- A commercial, social, or business opportunity has been identified that could be addressed by a software-based solution.

  • Solution Needed (нужно решение) -- The need for a software-based solution has been confirmed.

  • Value Established (польза установлена) -- The value of a successful solution has been established.

  • Viable (жизнеспособна) -- It is agreed that a solution can be produced quickly and cheaply enough to successfully address the opportunity.

  • Addressed (использована) -- A solution has been produced that demonstrably addresses the opportunity.

  • Benefit Accrued (извлекается выгода) -- The operational use or sale of the solution is creating tangible benefits.

Это неважно, что software-based solution, у нас systems engineering essence (http://arxiv.org/abs/1502.00121). Но важно, что кроме "внешних возможностей" в состояниях "возможности" отдельно упоминается, что она должна быть в какой-то момент viable, "жизнеспособна": то есть произведена быстро и достаточно дёшево, чтобы быть использованной. An opportunity is viable when a solution can be envisaged that it is feasible to develop and deploy within acceptable time and cost constraints. Although addressing the opportunity may be a very valuable thing to do it is probably not a good idea if the resources expended will be greater than the benefits accrued.

Я "возможность" понимаю как двери в поезде метро: в какой-то момент поезд с вашей командой останавливается на станции, двери открываются -- и на станции стоит толпа стейкхолдеров, которые что-то хотят. А у вас есть, что им предложить по сходной цене. Это означает, что есть возможность сделать проект. Но бывает, что толпа стейкхолдеров стоит, а вам предложить нечего. Или вы предлагаете, а толпа стейкхолдеров ожидает чего-то другого. Тогда возможностей сделать проект нет, через пару минут дверь закрывается, "окно возможностей" захлопывается. То есть несмотря на то, что в OMG Essence подчёркивается внешняя сторона "возможности" (нужна ли наша система внешним стейкхолдерам), есть и внутренняя (нужно ли выполнять этот проект внутренним стейкхолдерам -- нашей команде). Стандарт это не акцентирует, но всё-таки поминает: It is important that the team understands the current state of the opportunity so that they can ensure that an appropriate software system is developed, one that will satisfy the stakeholders and result in a tangible benefit being accrued.

У "возможности" в Essence есть предписанная стандартом подальфа -- это need. A lack of something necessary, desirable or useful, requiring supply or relief. Need exists within the customer, and will be considered by product or portfolio managers who analyze whether there will be value generated by addressing the Need, and pursuing the identified opportunities.

Need -- это про использующую систему, в отличие от requirements, которые про целевую систему. В любом случае, не любые needs нужно удовлетворять, а только те, которые команде проекта удовлетворять выгодно. В убыток работать нельзя.

Поэтому я предлагаю подальфами возможности считать маржинальный бюджет (не "себестоимость"! читайте Голдратта для подробного разбора), а ещё новые технологии -- ибо со старыми технологиями обычно сделать проект не удаётся. Новые технологии это подальфа технологий. Подальфы легко могут быть подальфами двух альф сразу: новые технологии, если их осваивать, продвигают альфу возможностей и одновременно продвигают технологии. Можно также говорить и о skills команды как такой же "двойной" подальфе. С моделированием практик тяжело: "практика = дисциплина + технология", но дисциплина обычно в голове команды, поэтому альфу way of working я перевёл как "технологии", а вот "дисциплину" оставил для команды. Всё сложно, счастья нет.

И вот в этот момент появляется вопрос о capability -- переводить можно либо "функциональные возможности", либо "потенциал". Это как раз "возможность команды сделать быстро и задёшево, но чтобы получить прибыль". Это, конечно, внутренняя сторона возможностей. В OMG Essence не обсуждается capability. Если добавлять для группировки подальф skills, новых технологий, бюджета на марже -- сразу появляется лишний подуровень. Поэтому я выбрал не умножать число сущностей без надобности.

В ArchiMate 3.0, наоборот, нет возможностей/opportunity, но есть возможности/capability (http://pubs.opengroup.org/architecture/archimate3-doc/chap07.html#_Toc489946034) -- A capability represents an ability that an active structure element, such as an organization, person, or system, possesses.

In the field of business, strategic thinking and planning delivers strategies and high-level goals that are often not directly implementable in the architecture of an organization. These long-term or generic plans need to be specified and made actionable in a way that both business leaders and Enterprise Architects can relate to, and at a relatively high abstraction level.

Capabilities help to reduce this gap by focusing on business outcomes. On the one hand, they provide a high-level view of the current and desired abilities of an organization, in relation to its strategy and its environment. On the other hand, they are realized by various elements (people, processes, systems, and so on) that can be described, designed, and implemented using Enterprise Architecture approaches. Capabilities may also have serving relationships; for example, to denote that one capability contributes to another.

Capabilities are expressed in general and high-level terms and are typically realized by a combination of organization, people, processes, information, and technology. For example, marketing, customer contact, or outbound telemarketing.

Напомню, что ArchiMate тоже намеренно сделан невнятным, чтобы не потерять возможность моделировать самые разные ситуации. Так что тут тоже возможности трактовки довольно широки -- но это "внутренние возможности", "функциональные возможности", "потенциал", от которых мы только что отказались как от отдельной сущности в Essence. А любителям перевести что-то на русский можно посоветовать насладиться определением, где по сути заявлено "capability = ability".

А как мы себя будем вести в ArchiEssence? А по ситуации, я бы пока не предписывал какого-то поведения по моделированию capability -- особенно если учитывать, что Essence не работает с corporate governance, а сосредотачивается на уровне одного проекта/предпринятия, а ArchiMate как раз пытается акцентировать в стратегических и целеполаганческих своих расширениях именно понятия corporate governance. Но ежели приглядеться, то capabilities в Архимейте очень похожи на развёрнутые практики, practices -- которые полноценно поддержаны загруженными уже в чьи-то головы дисциплинами и развёрнутыми в предприятии технологиями. Capability -- это практика, которая освоена и ресурсно поддержана.

Так что я бы просто не считал пока, что в архимейт-моделировании обязательно использовать все-все имеющиеся там значки. Нет, я бы пытался не умножать число задействованных архимейт-сущностей без надобности. А там посмотрим: в каждом проекте будут свои любители Essence, свои любители ArchiMate, свои любители подходов неведомых нам сейчас школ бизнеса, свои стратеги и развиватели бизнеса со своими птичьими языками. И дальше уж как все эти стейкхолдеры договорятся.

Это я по следам дискуссии по поводу "возможности" в системной схеме мышления в https://www.facebook.com/alex.turkhanov/posts/10213618970925657.

Обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10211052463961572

По итогам всех дискуссий: capability -- это поставленная практика, возможность осуществления функции (т.е. готовность предоставления сервиса какими-то модулями, поддерживающими практику).
2019

Вопрос доверия подростков: решается только мимо школы

Пара текстов, которые ставят вопрос доверия подростков к старперам (то бишь взрослым):
-- Александр Молчанов: https://www.facebook.com/alex.molchanow/posts/1761839210542091
-- Никита Широбоков: https://www.facebook.com/photo.php?fbid=1523038507718997&set=a.596947040328153.1073741826.100000385866868&type=3&permPage=1

Тезис этих постов: подростки не верят взрослым, ибо через интернет на раз-два обнаруживают их некомпетентность. А взрослые не могут угнаться за подростками, ибо живут не в сети и модой, а своими старперскими навыками. И там даже гипотеза, что своих подростки отличают через мат: фальшивящие на каждом шагу взрослые не матюкаются.

В дискуссии по этому поводу у Анатолия Шперха (https://www.facebook.com/shperk/posts/10159193274405153) Александр Молчанов сказал: "У меня возникает ощущение, что спасать надо не отдельную школу - а всю иерархическую систему. Иногда думаю, что если отменить все регламенты и все министерства с отчетностью, то школа сама себя прекрасно спасет...", а Анатолий Шперх откликнулся "Но тогда это будет уже не школа, а нечто совсем другое".

Я об этом всё время и говорю -- мимо школы, только мимо школы. Школу уже ничего не спасёт: этот супертанкер, даже когда активно тонет, имеет радиус разворота 3 километра. Не вписывается эта детская тюрьма (не можешь не ходить, значит тюрьма) в современную жизнь. Поэтому в школе отбывают наказание, а вся положительная польза -- как в тюрьмах от прогулок.

Поэтому тьфу на них, и строить рядом что-то современное. А на месте школы когда-нибудь, как на месте Бастилии, поставят табличку "здесь танцуют" (или "здесь мастерят", ничем не хуже).

Что касается матерящейся молодёжи, то это факт, и он мне совсем не нравится. Но что они вот так уж всё гуглят, то это тоже не так -- их этому учить нужно. Они только свои мемы и прохождения игр гуглят в совершенстве. Увы, эти навыки потом не переносятся никуда. Умение играть в видеоигры остаётся только умением играть в видеоигры, умение виртуозно материться не переходит во владение всей полнотой русского языка, умение виртуозно пользоваться смартфоном не переходит в умение виртуозно пользоваться каким-нибудь спектрометром. Вот это нужно учитывать, и работать с этим. Мимо министерств и школ. Каждый как-то вокруг себя, уж как может. Немного народу, но спасём. При этом, увы, детки будут тратить значительное время на школу и инициации времён диких племён (сегодня это ЕГЭ -- бессмысленные и беспощадные подростковые испытания, к которым долго готовятся, но которые абсолютно не нужны в жизни -- зато дают право формально перейти в статус взрослых).

Это как интернет. Интернет в стране не министерством делался, а во многих городах просто появились провайдеры, которые что-то там такое делали вокруг себя, и связывались между собой. Потом бах -- и у нас интернет-инфраструктура. Государству осталось её не строить, а только регулировать насмерть. Вот так новое образование и появится: разные провайдеры нового образования в разных городах, повсеместно. Что эти провайдеры нового образования (которые не факт, что будут делать старперы) не будут внутри себя допускать много мата, я бы мечтал, но не могу на это надеяться.

Кстати, я год назад много писал про "мимо школы". Вот, например (и там много ссылок на другие тексты): http://ailev.livejournal.com/1280262.html

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10211052539163452
Комментарии ещё в http://vit-r.dreamwidth.org/890001.html и https://akoev.blogspot.ru/2017/08/blog-post_27.html