Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Category:

Чеклисты в blended learning service: не прощёлкать важное, но и не забюрократизироваться

Почему мы в Школе хотим избежать традиционного айтишного зоопарка? Взять две дюжины самых лучших и дешёвых онлайн сервисов для разных применений -- и voila, Айсистент (AIsystant ещё начали называть AllSystant, олсистентом-всесистентом) наш! Нет, так не пойдёт. Даже если мы закупим 10 сервисов для 10 функций по 10 копеек на установку каждый, результатирующие blended learning services будут стоить отнюдь не рубль: разница накопится в ходе всего жизненного цикла -- обслуживание 10 разных контрактов, коммуникация на 10 разных языках, интеграция 10 разными способами дадут в ходе жизни сервиса затраты много больше исходного рубля. Любое изменение станет дорогим кошмаром. Если мы закупим 2 сервиса за 50 копеек, которые закроют все те же 10 функций (разницу между функциями и сервисами смотри в учебнике "Системное мышление 2019"), то обслуживание будет в разы проще -- меньше контрактов, меньше способов интеграции, меньше знаний в головах персонала. Для того, чтобы использовать поменьше заказных компонент и тем самым обращаться к "всеохватному" и "всепрограммируемому" кровавому энтерпрайзу (для нас, похоже, это MS Office 365 Education), существуют чисто экономические соображения.

Кстати, SpaceX сделал ровно то же самое: изготавливает огромное количество детальков космического корабля сам, что резко уменьшило расходы на коммуникацию с контракторами. Те же принципы за программой повышения культуры "вы можете себе это позволить" (affordability) на флоте США, где идёт программа по enterprise commonality, то есть унификации модулей для всего флота-как-предприятия, (https://www.navsea.navy.mil/Media/News/Article/1391473/navsea-commonality-teams-findings-could-save-millions-in-fleet-maintenance-costs/ -- почему-то смог открыть только через VPN, там тоже свой Штаткомпозор работает. Начиналась enterprise commonality с программы замены самых разномастных дешёвых насосов на небольшую номенклатуру более дорогих насосов -- уменьшение номенклатуры и закупка типового насоса оказывается в ходе полного жизненного цикла дешевле покупки уникального самого дешёвого насоса для каждого отдельного применения).

Что мы сейчас будем делать в плане описания Школы, документирования архитектуры предприятия? Мы все наши кейсы "обоснуем" (essentialize, азаза -- essence это "основа", вот её и выделим), то есть установим проектные альфы для каждого кейса (черновой список кейсов -- https://ailev.livejournal.com/1492409.html, по каждому кейсу типовая альфа, а дальше для каждого экземпляра кейса -- экземпляр альфы), сделаем чеклисты для состояний альф, меняемых практиками (список практик для курса и потока нарезаны тут: https://ailev.livejournal.com/1496250.html). Для каждого чеклиста сделаем предложения по evidence/рабочим продуктам в виде форм, и привяжем к этому issue tracker. Потихоньку всю школу переведём на чеклисты: проверку наступления предписанных практиками событий для альф-кейсов и порождение работ, если события почему-то не наступили. Вводим учёт событий, управляем вниманием -- поднимаем осознанность в том, что происходит в Школе.

Поэтому формальный язык (SysMoLan) сначала заточим для этой чеклистизации. У нас была идея ArchiEssence, мы к ней возвращаемся на новом уровне (только альфы уже не просто основные альфы Essence, и SysMoLan вместо Архимейта). А потом да -- конфигурация описания Школы как скрипты на SysMoLan, а они конвертируются в скрипты конфигурации Айсистента (про пересечение с тематикой "скриптов как конфигурации" и RPA я писал в https://ailev.livejournal.com/1496250.html). Поэтому SysMoLan как DSL заточим поначалу на это. А пока нет DSL, будем писать просто псевдокод произвольного синтаксиса. По сути, это всё DDD -- только event storm мы делаем по идеям OMG Essence.

Отдельное дело будет -- как не забюрократизироваться. Ибо нет ничего более бюрократизирующего, чем все эти многочисленные обязательные чеклисты, от заполнения которых не даёт уклониться компьютер. Но при этом помним, что в клинике чеклист перед опирацией снижает смертность на 30% (книжка https://www.ozon.ru/context/detail/id/26845885/). Чеклисты у нас, кстати, в ходу на тех курсах, где зашкаливает количество разных мелких разномастных практик -- тот же системный фитнес. Не факт, что этими чеклистами пользуются, но при разработке курса они оказываются очень удобной формой документирования. Чеклисты не заменяют учебник, не учитывают подробности, но управляют вниманием: не дают забыть о важном. Вот это важное и пишем. Это шанс не прощёлкать важное, но и не забюрократизироваться.

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

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216791384510999
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 0 comments