Category: авиация

2011

Модели требований/целеполагания пока проигрывают в популярности архитектурным моделям

Вчера прошло совместное заседание методсовета ШСМ и русского отделения INCOSE, где обсуждали SysArсhi (https://ailev.livejournal.com/1444887.html). Большинство вопросов было к мета-модели SysArchi в части требований/целеполагания (в ней части хорошо видны -- сиреневенькая часть относится к модели требований/целеполагания, жёлтенькая к архитектуре предприятия, зелёненькая -- архитектуре целевой системы):
SysArchi_nov18

Видео всего заседания -- https://youtu.be/yTa9UrjQgd4. Утверждённое соглашение о моделировании SysArchi версии 1.0 -- https://yadi.sk/i/zhht0RshtJzyMQ

Мои выводы:
-- разговор про архитектуру и архитектурные описания (спасибо ISO 42010, IEC 81346 и т.д.) уже более-менее все поддерживают. И более-менее понимают про 4D экстенсионализм. И что целевая система и обеспечивающая система неразрывны и должны бы моделироваться вместе.
-- модели требований не понимает никто. В головах только понятия "требования" и где-то далеко от них понятие "стейкхолдер". Далее идёт неясная цепочка понятий, где выделяются "потребности". Что трассировка потребностей к требованиям впрямую не может быть осуществлена (там же граница системы по пути! Изменение стейкхолдеров и их viewpoints/языка, разные свойства разных систем) признаётся, но про механизмы моделирования этого никто не знает. Поэтому уйма вопросов,

Итого:
-- соглашение о моделировании утвердили в текущей версии (обозвали её версией 1.0 и призвали духов природы продолжать работать над следующими версиями -- вдруг откликнутся?), равно как и отметили, что SysArchi в его текущем виде мало поможет в больших проектах, и что мало кто может внести в эту метамодель что дельное (а что там лишее -- так запросто можно не использовать. Например, не использовать моделирование требований вообще). Дальше внимание нужно уделять SysMoLan (https://ailev.livejournal.com/1443879.html).
-- мне нужно что-то делать, чтобы в головах появилось не только представление об архитектуре и основных архитектурных решениях, но и представление о целеполагании.

GORE -- goal-oriented requirements engineering, это как раз то, что требует моделей требований. Я когда-то много об этом писал: https://ailev.livejournal.com/811715.html (2010 год), и это был фронтир (https://ailev.livejournal.com/900086.html), но за прошедшее время моделирование требований прошло по факту в мейнстрим, и даже в определении системной инженерии начали говорить не только о раннем по жизненному циклу определении/описании потребностей (stablishing stakeholders’ purpose and success criteria, and defining actual or anticipated customer needs and required functionality, early in the development cycle), но и документировании и моделировании требований: https://ailev.livejournal.com/1453390.html. Тем самым GORE и MBCD начинают смешиваться до неразличения -- и это поставлено как проблема в инженерии требований, см. соответствующий раздел в https://ailev.livejournal.com/1425741.html

Модели требований понимаются сейчас как модели, в которых отмоделированы взаимовлияния стейкхолдеров по поводу системы: что кто почему хочет. Эти модели нужны, чтобы снимать противоречия в требованиях, в том числе за счёт снятия стейкхолдерских конфликтов -- почему и нужно моделировать стейкхолдеров и их взаимоотношения.

Работа с целями обеспечивающих систем (в инженерии предприятий, по факту это практики стратегирования) -- это модели целеполагания, motivation models (например, стандарты OMG BMM, business motivation model, или OpenGroup ArchiMate 3.0 motivation extention).

Системность SysArсhi была в том, чтобы
-- моделировать целевую систему в её операционном окружении и обеспечивающие системы в рамках одной модели. И рамках одной же модели и с одинакомым подходом делать моделирование требований/целеполагания для целевой системы и для обеспечивающей (например, использовать эти модели для проведения business/mission analysis -- понимать, насколько участие в проекте какой-то целевой системы связано со стратегией предприятия обеспечивающей системы).
-- убрать дребезг, возникающий при моделировании сразу нескольких системных уровней (когда в зависимости от уровня кого-то называют то "член команды", то "(внешний) стейкхолдер" или одно и то же описание то "потребностью/требованием стейкхолдера", то "системным требованием". В Архимейте всё это одноуровнево, поэтому полно этих разделений на "внутренний-внешний". Поэтому значок используем один: "требование", а уж как его разные команды назовут (требование, потребность, ограничение/архитектурное решение) -- это уже зависит от того уровня, которым занимается команда, как целевой системой.
-- моделировать на одной диаграмме все важные описания: не только архитектурные описания, но и архитектурные потребносити/требования/стратегию (архитектурные, то есть ведущие к архитектурным решениям, потому как для детальной инженерии требований все эти визуальные языки -- слону дробина, см. подробней книжку "Визуальное мышление. Доклад о том, почему им нельзя обольщаться", там я об этом подробно написал: https://ailev.livejournal.com/1437344.html). Вот модель целеполагания и попала в мета-модель.

Архимейт этого всего не позволяет сделать как-то приемлемо, конечно, но цели были именно такими. Так что тамошний обрывок модели требований/целеполагания -- это как раз попытка отразить последний пункт, добавить язык моделирования требований в архитектурный язык. Конечно, возникает большое количество вопросов к самой модели целеполагания именно АрхиМейта (она не была существенно поправлена в SysArchi), но предназначена она именно для того, чтобы требования брались как-то обоснованно, с учётом какой-то цепочки моделирования ситуации в системном окружении, ведущей к системным требованиям.

Основные различения для этого моделирования заключаются в понятиях стейкхолдер, интерес, оценка интереса, цель, принцип/дисциплина, требования. Увы, большинство обсуждающих пытаются вообразить, что бы там могло скрываться за этими обыденными словами (их не волнует обычно, что в английском для "цели" могли бы быть target, goal, object, objective, aim и даже mark, purpose и end, и это ещё не конец списка -- да и по-русски тоже есть много чего, включая канцеляритную "целеустановку". Но очень редко "мишень", хотя в английском target тут вполне немилитаристски слышится). Со словом "интерес" (concern) вообще беда. Но в данном случае непонимания моделей требований упирается не в эту игру содержанием слов (см. "слова-термины важны, и слова-термины неважны" -- https://ailev.livejournal.com/1442764.html), а именно с непониманием самой идеи моделирования требований, обсуждаемых там сущностей-концептов.

Вот онтика системных описаний, где подробно прописаны понятия интереса и оценки интереса -- https://ailev.livejournal.com/1429330.html. В том числе там прописано отличие интереса (concern) и метода описания (viewpoint). Это самая частая ошибка моих студентов. Понятие дисциплины (из которой берутся принципы, как закономерности дисциплины, и для выражения понятий которой существует метод описаний) -- вот тут: https://ailev.livejournal.com/1427265.html. Дисциплина нам важна, как что-то, позволяющее адекватно моделировать интерес. Интерес -- это просто функциональное обозначение какой-то предметной области, необходимой стейкхолдеру для его деятельности. Он для удовлетворения своего интереса он выбирает (или ему предлагают!) какую-то дисциплину и связанный с ней метод описания объектов этой дисциплины. И далее уже описывается, что там с оценкой интереса в данном проекте. То есть "хотелка" это не интерес, а как раз оценка интереса! А цель -- это переход в действие, что нужно сделать (глагол), чтобы сдвинуть оценку интереса. Результирующие требования описываются в терминах выбранной дисциплины (и если вы не читали учебники по дисциплинам, отвечающим на те или иные интересы проекта, то вам этих требований обычно не понять. Ну, или вы просто не учтёте этих требований, потому как не знали о них! Помним, что требования открывают/discover или выявляют/elicit, а не "разрабатывают" -- сидя на диване, их не "сочинишь").

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

В общем, с моделированием требований/целеполагания беда. Вывод: мне нужно об этом говорить более подробно. У меня сейчас в поддержку архитектурных описаний (кишок системы) самая толстая и сложная глава в учебнике -- пятая. А в поддержку внешних (чёрного ящика) описаний системы много меньше. А зря. Так что буду потихоньку вносить поправки в свои курсы и тексты, исправлять ситуацию.

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

Будущее automotive: в самом низу платформенного стека!

Интересно, проверял ли кто-либо цифры из презентаций OCSiAl? Доклад очень интересный, обратите на него внимание: водится критерий для отделения экзотического транспорта от эксклюзивного, и эксклюзивного от массового. Никаких "автопилотов" (они будут везде и выносятся за скобки), в расчёт идёт только удельный вес энергии и самого транспортного средства в расчёте на одного пассаржира. Вот (ставьте там сразу воспроизведение на скорости 1.5, иначе невозможно слушать -- https://youtu.be/fAxz1u9GFV0):

Сразу дам ссылку на "юджет" (Ujet, упоминающийся в докладе складной электроскутер за 10тыс. евро с запасом хода до 150км -- https://www.ujet.com) и саму компанию OC Si Al -- https://ocsial.com/ (carbon nanomaterials for the global industry).

Очень правильный ведь подход, с самого низа технологического/платформенного стека: от материалов -- что в части удельной энергоёмкости на килограмм веса, что в части прочностных характеристик, нужных для снижения веса.

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

Всё-таки фронтир инженерии сейчас где-то в районе автопрома, авиация тут будет догонять. Это я продолжаю гнуть линию рассуждений про automotive из "Онлайн курсы системной инженерии: насколько современной?" (https://ailev.livejournal.com/1403010.html), "Что на свете всех сложнее? Автомобили вырываются вперёд" (https://ailev.livejournal.com/1398456.html), "NVIDIA как поставщик инфраструктуры для роботакси-стека" (https://ailev.livejournal.com/1384766.html).

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

Конечно, сразу бросается в глаза, что для гиперлупа трубу включили (или не включили? Что там включили в движущийся состав? Активную магнитную подушку?), а рельсы для поездов вместе с насыпью, мостами и тоннелями исключили. Более того, и автодорожную сеть при этом подходе нужно бы включить. А для авиации вообще дорог не нужно, только посадочные площадки (не такие дорогие, как дороги). Но всё одно подход интересный.
2019

Управление жизненным циклом и управление работами

Управление работами и управление жизненным циклом
Стадии жизненного цикла в водопадном виде жизненного цикла заканчивались предварительно запланированными гейтами, в которых независимыми экспертами оценивались собранные в единое целое результаты предыдущей стадии и принималось решение о продолжении проекта на следующей стадии (go/no-go). Если до момента назначенного рассмотрения проекта независимыми экспертами в рамках прохождения гейта кто-то из разработчиков частей системы не успевал закончить разработку своей части и проверку того, насколько она не нарушает работу всей системы в целом, то весь проект ждал окончания работ этого разработчика. Гейты как раз и были задуманы, чтобы выявить системные риски появления конфигурационных коллизий, неочевидных системных эффектов, непредвиденных трудностей в разработке отдельных частей системы. И если не включить в рассмотрение результаты чьей-то частной работы, то появляется риск неучёта каких-то системных эффектов в целой работе.

В ранних версиях жизненного цикла крупных (прежде всего аэрокосмических, традиционных для системной инженерии) проектов гейтов было порядка пятнадцати, и проект надолго останавливался во всех пятнадцати точках для сведения всех отдельных разработок в непротиворечивое и лишённое конфигурационных коллизий целое и последующего просмотра результатов работ стадии независимыми экспертами. По мере осознания того, что водопадная модель с гейтами является утопией, появления компьютерных систем управления конфигурацией и изменениями и уменьшения числа конфигурационных коллизий, перехода к параллельной инженерии, число гейтов сокращалось. В авиации гейтов сначала стало порядка семи, а нынче их всего три, при этом даже не все из них связаны с инженерией: например, решение о сворачивании проекта принимается, когда проектирование зашло уже довольно далеко, но не собран достаточный для уверенности в финансовом успехе проекта пакет предзаказов на новую модель самолёта (Altfeld, Hans-Henrich. Commercial aircraft projects: managing the development of highly complex products, 2010).

Отсутствие заранее запланированных гейтов не означает, что не ведётся управление работами. Оно ведётся, только проходит по контрольным точкам (milestones, вехам), представляющим из себя сочетание какого-то (возможно, очень сложного составного) требования и момента времени, к которому это требование должно быть удовлетворено. Если контрольная точка не пройдена к её запланированному моменту времени, просто принимаются меры для её скорейшего прохождения, но из-за этого не останавливаются все остальные работы по достижению других контрольных точек, как это было бы в случае гейтов.

Управление выполнением практик (назначением практик на работы), чтобы получился результат без конфигурационных коллизий – это управление жизненным циклом (lifecycle management). Управление работами (operation management, управление операциями) заключается не столько в том, какие практики в какой момент выполнения работ выполняется, сколько в управлении выделением ресурсов для прохождения всех контрольных точек в срок и в соответствии с бюджетом. Управление жизненным циклом рассматривается как преимущественно инженерная дисциплина (нужно хорошо знать практики инженерной работы), управление работами как менеджерская дисциплина (нужно хорошо знать практики операционного менеджмента).

Виды практик управления работами
В управлении жизненным циклом в том числе принимается решение о том, какие практики управления работами выбрать, ибо существует большое разнообразие этих практик.
Классическое управление проектами (project management, проектное управление) подразумевает одномоментное планирование перед началом всех работ для всех контрольных точек как сроков их достижения, так и работ по их достижению (то есть назначение ресурсов на работы происходит в момент планирования всех работ сразу, а не каждой отдельной работы). По факту это означает составление плана-графика выполнения работ с назначением ресурсов на эти работы ещё до начала выполнения работ. Это часто называют предварительным (up-front) планированием работ, а весь проект просто считают уникальной работой, имеющей чётко определённые время начала и конца, а также выделенные для неё ресурсы.

Но отнюдь не все работы с системой удаётся запланировать до начала выполнения этих работ, когда мало что известно про определение системы, мало что известно про воплощение системы, и даже мало что известно про обеспечивающую систему (т.е. ресурсы). Предварительное планирование легко делать для проектов изготовления и сборки, когда определение системы готово. Но вот детально планировать работы по определению системы обычно не удаётся. И тогда используют другие методы управления работами.

Если непонятно, какие могут быть контрольные точки больших кусков работы, то речь идёт об управлении программами (program management). По мере понимания этих контрольных точек программой запускаются проекты ведения работ по их достижению, используя предварительное планирование достижения каждой из них. Но нет плана запуска отдельных проектов программы, ибо деятельность программы как раз и состоит в определении этих проектов и планировании их, дальше работы проектов управляются стандартными методами проектного управления. Управление программами отличается от остальных методов управления работами тем, что отношение часть-целое в них меняет тип управления работами, а в остальных методах нет: в программах обычно нет «подпрограмм», но есть «проекты». В проектах же обычно подпроекты, процессах подпроцессы, в кейсах подкейсы и т.д..

Если контрольные точки и ресурсы для их выполнения известны, но неизвестно, в какой момент происходит запуск большого числа однотипных работ, речь идёт о процессном управлении (process management). Процессом тут называют не уникальную работу, а типовую последовательность шагов, обычно определяемую не столько планом (и уж тем более не графиком), а регламентом.

Если контрольные точки неизвестны, и ресурсы для их выполнения тоже неизвестны, и появляются по мере выполнения работ, то от самой идеи проектирования как предварительного детального планирования пришлось отказаться, и появилось новое поколение вариантов назначения работ на практики жизненного цикла (т.е. новое поколение видов жизненного цикла), получившее название гибких (agile, аджайл, эджайл) методологий. Эти гибкие методологии считают относящимися к разновидностям спиральной модели.

Особенно это проявилось в проектах программной инженерии, где программные системы были очень непохожи, и нельзя было даже сделать предположений, какие работы нужно включать в план их разработки – в отличие от зданий, где заранее было известно, что нужно будет делать фундамент и возводить стены, а потом делать монтаж оборудования и внутреннюю отделку, в отличие от самолётов, где сразу понятно, что в составе самолёта будет фюзеляж, крылья, салон, в программных продуктах нельзя сразу было сказать его состав, и поэтому работы по разработке нельзя было привязать к этому составу.

Общее для всех этих гибких методологий/методов и соответствующих им видам жизненного цикла в том, что они используют в части управления работами управление кейсами (case management, http://ailev.livejournal.com/946134.html) . Кейс -- ситуация, обстоятельства или начинание, которые требуют набора действий для получения приемлемого результата или достижения цели. Кейс фокусируется на предмете, над которым производятся действия (например, человек, судебное дело, страховой случай), и ведется постепенно появляющимися обстоятельствами дела.

Управление кейсами по факту обобщает управление проектами и процессами. В кейсе сначала мы имеем вопрос контрольной точки (формулировку кейса), после этого формулируется работа для прохождения этой контрольной точки (ибо формулирования задания на работу – отдельная операция, но контрольная точка может быть учтена задолго до этого), потом отдельно назначение ресурса на работы и тем самым разбирательство с планированием и графиком. Тут могут быть использованы удобные для управления кейсами методы планирования, например, канбан (Kanban for development, https://en.wikipedia.org/wiki/Kanban_(development), для управления кейсами прежде всего, для планирования производственных процессов используется обычно Kanban for manufacturing, https://en.wikipedia.org/wiki/Kanban). И даже тут жизнь контрольной точки в управлении кейсами не заканчивается, потому как в рамках управления изменениями конфигурации нужно сообщить участникам проекта, что кейс закрыт: состояние системы изменилось, и всем остальным нужно ориентироваться на новую ситуацию.

Технологии, используемые для гибких методов в управлении жизненным циклом и управления кейсами в управлении работами – это технологии трекинга контрольных точек (issue tracking, часто их называют «системы управления задачами», «системы отслеживания ошибок», «системы отслеживания поручений»). Название отражает тот факт, что контрольные точки появляются не в плановом порядке, они изначально представляют собой вопрос/проблему (issue), требующую своего решения. Трекеры (issue trackers, софт для трекинга контрольных точек) учитывают эти контрольные точки по мере их появления.

Конечно, если появляется возможность что-то спланировать, в управлении кейсами это делается. Часто тут план – это просто опыт прохождения какого-то кейса, шаблон. Вот этот план и будет называться шаблоном (template). Если шаблоны готовят не специально обученные программисты таких шаблонов, а сами участники команды проекта, то такое управление кейсами называют адаптивным (adaptive), а шаблоны – шаблонами сообщества (community template).

Мы различаем управление жизненным циклом и виды жизненного цикла (например, водопад, спиральный жизненный цикл, параллельную инженерию, гибкие методы – способы назначения работ на типовые практики разработки прежде всего, т.е. когда в проекте выполняются инженерия требований, инженерия системной архитектуры прежде всего) и соответствующие им методы управления работами (например, управление программами и проектами, управление кейсами) и в рамках управления работами методы планирования работ (например, метод критического пути или критической цепи для планирования в управлении проектами или канбан в управлении кейсами).

Вот схематическое изображение жизненного цикла одного из самых распространённых методов гибкой (agile) работы, SCRUM (https://en.wikipedia.org/wiki/Scrum_(software_development)):


В этой диаграмме бросается в глаза её нелинейная форма, в которой выделяются наличие циклов ежедневной работы и месячных «спринтов». Нелинейность, отсутствие предписанной чёткой стадийности выполнения практик -- верный признак "принципиальной схемы". Суть диаграммы в том, чтобы показать, откуда берутся выполняемые работы. Если бы речь шла о чистом управлении работами, на диаграмме не было бы слов "выбор требований", "демонстрация заказчикам", а просто обсуждались бы безымянные работы: менеджерские практики не работают с содержанием работ, они работают только с оптимизацией выполнения множества работ в рамках имеющихся ресурсов. Содержание работ при этом затрагивается управлением жизненным циклом. Гибкие методы -- это про управление жизненным циклом прежде всего, в них нужно обсуждать организацию инженерной работы, а не просто вопросы планирования и контроля исполнения работ.

Тренды в практиках управления работами
В более современных методах управления работами провозглашается, что практики назначаются на работы по мере возникновения потребности, ибо любые «итерации» представляют собой замаскированные гейты и означают, что какие-то ресурсы будут ждать назначения на работы после содержательных проверок конфигурационных коллизий. Нет, конфигурационные коллизии должны проверяться «в рабочем порядке», а не в специально отведённые времена окончания стадий или окончания итераций в жизненном цикле. Этот вопрос обсуждается на стыке управления работами и управления жизненным циклом и методы управления работами и жизненным циклом должны как-то соответствовать друг другу: проектное управление плохо сочетается с управлением кейсами, а вот канбан для разработки – хорошо.

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

При этом в случае гибких методологий и связанных с ними моделей/видов жизненного цикла (принципов назначения работ на практики) речь идёт сегодня не о классическом проектном управлении как методе управления работами – но продолжает использоваться слово «проект» (project). Слово «проект» ведь использовалось и до появления дисциплины управления проектами, и продолжает использоваться вне связи с этой дисциплиной.

Сегодня «проектом» часто называется и процесс (особенно экземпляр процесса – процессом ведь называют тип), и кейс, и программа со множеством классических проектов внутри, и вообще любая инициатива, любое предпринятие (https://ailev.livejournal.com/1388412.html).

Современные проекты (если это не проект стадии воплощения системы – например, строительства здания по заранее разработанному проекту/design) отличаются отсутствием предварительно составленного плана, но железной дисциплиной инициирования работ на базе каких-то практик (дисциплин и поддерживающих их технологий), железной дисциплиной выделения ресурсов этим работам в рамках какой-то методологии управления работы. Гибкие методы/методологии в плане соблюдения дисциплины очень жестки, в них довольно много разных правил, и если под словом «гибкие методы» какая-то команда не в состоянии указать конкретный вариант жизненного цикла своего проекта (способы, которым практики жизненного цикла начинают разворачиваться во времени, чтобы из этих работ получился содержательный результат), то верить в успешное завершение проекта этой командой нельзя.

При указании варианта жизненного цикла команде не нужно говорить SCRUM, или DSDM (https://en.wikipedia.org/wiki/Dynamic_systems_development_method), или Open Kanban (https://github.com/agilelion/Open-Kanban), или приводить ещё какие-то названия больших методологий со многими практиками. Вряд ли сегодня какая-то команда использует эти методологии во всей их полноте. Но нужно явно и осознанно сказать, какие команда использует практики управления жизненным циклом и практики работы.

Какой выбрать вид жизненного цикла, какую гибкую методологию? Ответ на этот вопрос зависит от профиля рисков проекта, а этот профиль рисков определяется субъективно командой. Нет двух похожих проектов, нет двух похожих видов жизненного цикла. Даже если вы делаете подряд два похожих проекта, то в результате выполнения первого проекта команда получает опыт, и профиль рисков для команды будет другим. Это означает, что команда может для следующего похожего проекта (или даже в ходе текущего проекта!) подкорректировать практики своей работы, изменить вид жизненного цикла, изменить практики управления работой для того, чтобы учесть полученный опыт.

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

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10211939483976518
2019

lytdybr

К такси в аэропорт пришлось идти пешком аж на садовое кольцо -- и это в шесть утра! Репетиция парада. Всё пытался вспомнить, чем отличается первобытный культ предков от его современных разновидностей. Мне кажется, что масштабом: в современности культ гораздо организованней, чем в доисторических обществах. В остальном не сильно поменялось. Дикое количество КАМАЗов, перекрывающих ленинградку аж на третьем кольце в порядке подготовки к ритуалам -- это сильное зрелище.

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

По прилёту купил переходник на американскую розетку (тут они простейшие стоят по $22 прямо в гостинице, но в супермаркете я видел и по $35, и по $39). Сам виноват: вспомнил про необходимость переходника практически на выезде, в шесть утра.

В Сан-Хосе хорошо, солнышко и тепло. Вот он я, уже на месте (и не спрашивайте, каким именно образом фотоаппарат в режиме селфи вдруг переворачивает фото -- это мне неведомо, а разворачивать назад мне лень update: перевернул, спасибо al_kur):
IMG_20170507_173257[1]

Гугль подсказывает, что я нахожусь в местной кафешке и показывает меню этой кафешки. Моим собеседникам он тоже это показывает. Большой Брат нервно кусает локти в сторонке. Хотя о чём это я! Какая там сторонка!

В программе самой конференции http://www.gputechconf.com/ дикая эклектика, ибо речь идёт о самых разных технологиях, опирающихся на вполне понятную платформу ускорения вычислений. Про это нужно говорить как про "платформенное дерево", "сад расходящихся технологических стеков". Всё это кипит и создаётся прямо на моих изумлённых глазах. Но думать об этом буду потом. В Москве уже 10 утра, а я ведь ещё и не ложился -- по местному времени всего только полночь. Ну, или аж полночь, ещё не разобрался.
2019

8 рабочая встреча Русского отделения INCOSE в Бекасово

На восьмой рабочей встрече в Бекасово я был не все три дня, а на полдня меньше: в воскресенье у меня неотменяемый тренинг. Что не помешало мне сделать докладов суммарно на восемь часов!

В первый же вечер опытным путём установил, сколько без спешки я рассказываю материал по системному фитнесу (слайды в http://ailev.livejournal.com/1341660.html) системным инженерам и менеджерам, уже хорошо знакомым с понятиями "холархия" и "эмерджентность" -- два с половиной часа.

Основные акценты в моём докладе были сделаны на сути системного мышления: работе с системными уровнями в холархии, учёт эмерджентности. Системный финтес тут был, конечно, только красочным примером. Ещё обсуждалась платформенность, соотношение функционального и конструктивного рассмотрений в процессных системах. Это самые азы системного подхода, но это очень труднопонимаемые азы, они абсолютно контринтуитивны. Я в текущем курсе системного мышления, наверное, удвоил по объёму разъяснения по этим вопросам, воткнул несколько дополнительных слайдов. Но и этого мало. Нужен какой-то суровый тренинг сержантским методом, иначе работа с системными уровнями, эмерджентностью и функциональностью в голову людей не заходит. Танцы с их процессностью и человеком и как стейкхолдером, и как рабочим продуктом отличный учебный материал, всё больше и больше в этом убеждаюсь.

Запись по традиции не велась, а кто не доехал тем вечером до Бекасово, тот сам себе злобный Буратино. Urban tarraxo я танцевать прямо там не стал, но показал документальный фильм со мной в главной танцующей роли. В этот вечер четверга в очередной раз получил комментарии, насколько я устный отличаюсь от себя письменного. Ага, как говорят в Одессе, две большие разницы.

Пятница была днём авиационным, печальным. Общее место всех буквально докладов -- неполный жизненный цикл, его стадии путались с процессами и практиками, проекты носили непонятный статус, непонятки с людьми в системах (вплоть до попыток объявить "системой" совокупность целевой и обеспечивающих систем, а ещё отдельно к ним "процессы" как отдельную сущность) и отсутствие обсуждения собственно инженерных проблем, о чём чуть дальше.

В докладах шли "инженерия систем", "системная инженерия" вперемешку и как синонимы (скажем, у этих добрых людей control systems engineering была бы не инженерия систем управления, а управленческая системная инженерия, ага). Да ещё и вольность перевода всего этого на русский. Тяжело и печально в содержании, ничего нового, темы ровно те, что мы в том же Бекасово обсуждали лет шесть-семь назад. Фронтир не обсуждается, всё как на обычных конференциях, "окружающая печальная действительность". Докладчики-практики рассказывают о своих бедах немногим присутствующим системным инженерам и методологам, разработчики-практики заняты примерно тем же. Флип-рабочая встреча, докладчики и слушатели в этот раз поменялись местами. Для меня это потерянное время, ибо я в Бекасово езжу обсуждать фронтир и прогресс, а тут получился филиал авиационной конференции на уровне начальников отделов и их консультантов.

Тем не менее, было два доклада по управлению требованиями, в которых явно было содержание, они были интересны и явно имели отношение к управлению жизненным циклом, управлению конфигурацией -- то есть были очень близки к системной инженерии. Доклад НИАЭП-АСЭ был особенно приятен лично, ибо в нём рассказали, что по итогам 2016 года они получили от FIATEC первое место в номинации "мегапроект" ровно по той теме, которую мы в TechInvestLab им помогали стартовать несколько лет назад.

Я предложил оценить содержание пятничной секции (модератором там был В.Батоврин) по тому, насколько услышанное за день соответствует основным дисциплинам системной инженерии: инженерии требований, инженерии системной архитектуры, управлению конфигурацией и изменениями (управление жизненным циклом), проверке и приёмке (V&V). В.Батоврин высказал предположение, что в российской почве не вырастает ничего, кроме инженерии требований -- и нужно тогда на этом и сфокусироваться. Но я заметил, что два "профильных" доклада из целого дня посвящены были не инженерии требований, а управлению требованиями! Не обсуждался вопрос о выявлении требований, их анализе, их проверке, реализации -- но лишь вопрос об управлении (учёте, предоставлении базисов, обеспечению трассирования, и т.д., без обсуждения содержания требований, чисто менеджерский аспект логистики требований в разных их состояниях по жизненному циклу). И, если продолжать логику В.Батоврина, то нужно вообще оставить идею системной инженерии и говорить только о менеджменте.

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

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

Часть, где В.Батоврин призывал молодёжь высаживать в каменистую почву нежные цветы системной инженерии и пропагандировать её направо и налево -- эту часть я опускаю.

После ужина я в пятницу я сделал доклад про тренды будущего и подрывные инновации. Прогнал 52 слайда за два часа. По факту это был немного модифицированный дайджест однодневного семинара про будущее. Краткий вывод доклада: где-то в 2020 (тут я согласен с Тони Себа) жизнь начнёт сверхстремительно и масштабно меняться, и не от какой-то одной "экспоненциальной технологии" (т.е. которая падает в цене вдвое за год и находится достаточно низко в технологическом стеке мира, чтобы взорвать всё над собой), а от сочетания этих технологий. Воодушевлённые тем, что огромного мирового кабума ждать уже недолго, мы пошли в бар "Лабиринт", где я спел выжившим от шока будущего казачью песню, на правильных народных ладах. Знай наших!

В субботу я три часа рассказывал краткое содержание четырёх дней тренинга системного мышления и стратегирования (давал краткий обзор). Тем самым я выполнил решения пары предыдущих встреч в Бекасово: потихоньку двигаться в сторону инженерии систем людей, инженерии предприятий. По факту, это был отчёт об этой работе: я создал учебный курс, прошло уже пять потоков, сделана конференция (совместная с Русским отделением INCOSE) по теме системного менеджмента, сейчас идёт шестой поток. Всё реализовано ровно так, как задумывалось.

После меня выступал В.Мизгулин и рассказывал буквально чудеса, которые происходят с преподаванием системной инженерии в УрФУ. Сотни студентов, десятки курсов, лаборатория машинного обучения и даже agile подготовка студентов! Я просто в полном восторге, этот доклад нужно будет ещё долго осмысливать.

Перед отъездом сфотографировал вид из окна зала заседаний, там была радуга. Я радовался, все радовались:
bekasovo
2019

Тренды в инженерии требований и кому они интересны

После вчерашнего доклада "Тренды в инженерии требований" (слайды и видео: http://incose-ru.livejournal.com/53170.html) один из участников заседания прислал мне письмо о потенциальных стейкхолдерах, которые могли бы быть заинтересованными в тех новинках инженерии требований, о которых я говорил в докладе. Сам он не смог сообразить, кто бы это мог быть -- ибо по его опыту работы в крупной авиастроительной российской корпорации "(несмотря на то, что об управлении требованиями постоянно говорят) могу сказать, что перед управлением требованиями (или вообще любой системноинженерной дисциплиной) заинтересованные стороны говорят о проблемах, которые решаются внедрением элементарного планирования и контроля (то есть, то,что можно было бы исправить инженерией требований, вовсе не в первом приоритете)".

У меня тут сразу несколько ответов:

1. Да, когда корабль тонет, если в одной из его кают срочно и серьёзно займутся инженерией требований, обитателям этой конкретной каюты может не свезти точно так же, как и обитателям любых соседних кают, в которых вместо работы выбирают sex, drugs and rock'n'roll. Имкрыш настанет, несмотря на импортзамещение (точнее, ровно поэтому).

2. Если посмотреть содержательно на новинки инженерии требований, то заниматься ими нужно только, если действительно хочется победить в международной конкуренции. Если хочется огромные проекты делать дешевле и быстрее. И первое, что в этих новинках -- там слошные исследования и разработки, нет ничего отлаженного, это фронтир, bleeding edge. Про долю затрат на исследования и разработки в российских инженерных фирмах я даже говорить не хочу. Нет таких стейкхолдеров, которым нужны исследования и разработки по методологии инженерии, и не только инженерии требований.

3. Инженерия требований -- это часть системной инженерии. На отечественных предприятиях системная инженерия неизвестна. Заинтересованных в каком-то кусочке неизвестного нет. Стейкхолдеров, у которых есть интерес к трендам в неизвестном -- массово таких нет. Единственное что, так это IT-фирмы. Им инженерия требований известна как отдельная дисциплина, часть их собственной дисциплины (а не как часть системной инженерии). Но IT-фирмы самолёты не выпускают. Зато в них вполне могут найтись правильные стейкхолдеры (прошлого поколения -- "аналитики". Я как раз в докладе говорю, что жизнь изменилась, и они ответственны теперь отнюдь не только за выявление и анализ требований -- нет, у них ещё и решение всех проблем со стейкхолдерами, это активная деятельность и вмешательство в жизнь, а не "аналитическая работа пониманию и выдаче советов"). Вопрос, насколько крупны эти IT-фирмы, чтобы позволить себе исследования и разработки на фронтире инженерии требований?

4. Нашим клиентам мы сначала всегда предлагаем наладить управление конфигурацией и изменениями. Они спрашивают в ответ: "Что это такое?". А ведь это и есть то самое "элементарное планирование и контроль" из вопроса. Кстати, в инженерии требований то же самое: сначала управление требованиями, а потом уж их инженерия. Ибо если в суматохе самое распрекрасное требование будет открыто, но потом потеряно в обычной суматохе и текучке, толку от этого распрекрасного требования -- ноль. Не задокументировано, не учтено -- значит нету. К инженерии требований это всё тоже относится. Требование -- это приписанное к части системы утверждение (assertion). Контрольная точка -- это достижение этого требования к какому-то моменту. Если нет учёта частей системы, то и приписывания к ним утверждений нельзя сделать. Если нет контрольных точек, то выполнение требований гарантировать нельзя. Остальное всё потом: никакое моделирование бардака или переговоры по поводу бардака не помогут.

5. Можно предположить, что заинтересованные в новинках инженерии требований стейкхолдеры есть -- но они просто об этих новинках не знают. Да, теоретически они есть. А практически -- это похоже на сказки про царя, который просто не знает об ужасах, которые творятся в его царстве. В век интернета и почти поголовного владения английским в эту сказку трудно поверить. Но теоретически такая возможность есть, так что пусть этот пункт тут побудет.

6. Тем не менее, бывают ситуации, в которых у отдельных людей просыпается личный (обусловленный биографией, человеческими качествами, любопытством и т.д.) интерес к инженерии требований. Иногда у таких людей бывает даже достаточно полномочий, чтобы реализовать проект по постановке практики (скажем, наладить моделирование какого-то вида требований с использованием Modelica или даже Julia, как у заморских авиаторов в примере из доклада). Иногда коллеги-начальники даже этот проект не срывают по совокупности причин. Иногда вместо дела получается пара-тройка учебных курсов (хотя реализовать полученные знания на практике всё равно не получится -- по той же "совокупности причин"), иногда этот личный интерес реализуется вообще вне какой-то инженерной организации, как личное хобби. В любом случае, тут речь про людей, а не про стейкхолдеров. С людьми всё в порядке, с людьми я и работаю. Так что для таких людей я и сделал доклад, и выложил слайды и видео -- http://incose-ru.livejournal.com/53170.html

* * *
Мне было приятно делать этот доклад: то, о чём я догадался ещё несколько лет назад, наконец-то начало закрепляться в стандартах и появляться в моделерах. Так что в некотором роде этот доклад ещё и хвастовство по поводу собственной прозорливости.

Сами тренды тут прописывать не буду, их оказалось неожиданно много, изменений буквально за пару лет в инженерии требований произошло много каких. Если интересно, можете пролистать слайды (там картинок мало, но зато есть какие-то тезисы и некоторое количество ссылок на литературу) и послушать мои комментарии на видео.
2019

Может ли самолёт летать (как птичка!), может ли машина мыслить (как человек!).

Как только компьютерная программа демонстрирует поведение сложнее калькулятора, то ей сразу навешивают сравнение с именно человеческим разумом -- и там тупик пустопорожних разговоров (про разум молотка, или экскаватора -- и по какому пути его неведомые инженеры должны были бы делать по мнению очередного не-инженера). С психологическим, социологическим, экономическим и прочим гуманитарным аппаратом к задачам современного слабого искусственного интеллекта (это термин, но я уже зарёкся его использовать, он как масла в огонь подливает каждым словом -- и "искуственным" и "интеллектом" и даже "слабым", мало ведь кто знает его изначальное значение. Но увы, нового слова для данной предметной области пока не придумали) подходить нельзя, вредно. Нет задачи смоделировать именно человеческий или животный или инопланетный разум, есть задача научить компьютер решать отдельные классы сложных задач.

Даже поговорить о смысле жизни -- это просто сложная задача, никакого разума, никакого интеллекта не подразумевает. Обсуждать можно лишь содержание высказываний, ничего более. Если машина слишком врёт, дообучить её (скормить какой-нибудь дополнительный текст, а хоть и от психологов). Но никак не антропоморфизировать молотки и будильники и дальше нагонять страху, как это делают в попсовых статьях типа http://rusbase.vc/story/eto-zhenshina/ (там даже заголовок "Искусственный разум от Google заговорил. И это женщина").

Журналисты -- зло. Им покажешь молоток, а они ему приписывают злобу и ненависть, а также выражение лица рукоятки, с которым она направляет боёк не на гвоздь, а на палец. С умными железками, напичканными софтом, всё то же самое. Покажешь журналисту, или психологу, или литератору и уж тем более философу (а иногда даже и программисту! тоже ведь философски настроенные натуры бывают!) интересную программу -- ей тут же навесят человеческий разум, женскую сущность. При этом всё навешиваемое убедительно и конкретно опишут (профессиональные же писатели, властители дум!) -- и тут же прибегают толпы самых разных троллей и начинают мочить, мочить, мочить непонятно кого по надуманному поводу. А журналисты -- это профессиональное зло, они вызывают бурные философские дискуссии о ни о чём. Ты им говоришь "нет никакого скайнета в молотке", а они тебе будут задавать три десятка вопросов, чтобы хоть что-то бодренькое из фильма-ужастика было. Много вы знаете игр и кинофильмов, чтобы никого не убивали-грабили-насиловали? Я понимаю, иначе "не продать". Так вот не нужно таких продаж для "умных программ". Не нужно требовать от самолёта птичности, а от программ полноценной (то бишь человечьей -- включая всю человечью универсальность, равно как и дурость) разумности. Самолёт должен летать, но не как птичка -- его задача не насекомых в воздухе хватать! А программы должны решать сложные задачи -- но не как человек, им увязывать личную жизнь с работой не нужно, и демонстрировать универсальность и всеохватность разума тоже никому не нужно.

Дополнительно см. комменты к посту http://ailev.livejournal.com/1204972.html -- там мысль простая: мы пришли в такие времена, когда вместо "поболтать на философские темы" нужно просто закатать рукава, и годик-другой поработать. А потом спланировать следующий шаг. Ибо learning by discovery -- нарыли новые удачные классы алгоритмов и вычислительных архитектур, давайте их поисследуем. Можно поглядеть ещё длиннющую дискуссию тут, я тоже там поучаствовал немного: https://www.facebook.com/groups/nevronet/517636148402711/ (там топик тоже хорош -- "инженеры разрабатывают первый рабочий прототип компьютера-мозга", для меня это звучит как "инженеры разрабатывают первый рабочий прототип самолёта-махолёта").

У нас не философская и не научная задача. У нас чисто инженерная задача: изобретение самолётного типа думалки для сложных задач -- холодной, железной, грузоподъёмной и летящей на 8.5тыс. км без перезаправки, а не думалки птичной -- мясной и несущей яички, а также громко чирикающей и приземляющейся на веточку дерева. У нас не теоретическая машина тьюринга (в которой нет, например, прерываний), у нас не китайская комната (мы другого сорта задачи решаем!) -- я думаю, после демонстрации каких-то достижений нейронных сетей придётся переосмысливать все эти расхожие попсовые байки про "разум".

Ну, достаточно написал, чтобы прекратить все эти пустопорожние дискуссии о том, "может ли машина мыслить", "настоящего творчества/разума/интеллекта ваш подход не обеспечит" и "как добиться повторения работы мозга"? Эти дискуссии непродуктивны! Не нужно задавать на эти темы вопросов!

Боюсь, что опять недостаточно.
2019

Больше PLM-систем хороших и разных!

Красота, кто понимает: Airbus и Aras заключили соглашение об использовании более 30тыс. рабочих мест PLM Aras Innovator (сам софт опенсорс, но Aras получает подписку на поддержку) -- http://isicad.ru/ru/articles.php?article_num=17858. Вот презентация Airbus на эту тему (старенькая, ибо обсуждается версия Aras Innovator 9.0 и надеются на 10.0, сегодня же уже отгружается 11.0) -- http://isicad.ru/ru/pdf/SLIDES-airbus-plm-test-management-aras-plm-ace-2014-europe.pdf

У Олега Шиловицкого сегодня для всех желающих поучаствовать в ломке устоев нынешнего CAD/PLM рынка инструкция, чем заняться: пост How to Innovate and Compete with CAD and PLM behemoths -- http://beyondplm.com/2015/07/09/how-to-compete-with-cad-and-plm-behemoths/ (Aras там поминается только в предпоследнем абзаце как пример влезания в рынок через оригинальную бизнес-модель).

PLM это очень интересный софт, ибо отражает основные принципы системного подхода:
-- в PDM части он содержит различные view на целевую систему (product model)
-- в issue tracker части поддерживает различные view на обеспечивающую систему (project model)
-- имеет развитые средства онтологической работы (моделирования данных), ибо должен быть "грамотным", читать и интегрировать самые разные view. Так что "из коробки" в нём обычно уже есть upper ontology.
-- в нём реализуются разные функции поиска и запросов, а отсюда до "интеллектуальных запросов" один шаг. Впрочем, тут можно договариваться, движок интеллектуальных запросов входит в состав PLM-системы или он отдельный и цепляется к информационной модели системы снаружи, как любая другая CAD-система или система моделирования (раньше любили говорить "АРМ -- автоматизированное рабочее место").

По поводу PLM-систем также много мифов. Так, не все в состоянии сказать соотношение между PLM-системой, ERP-системой и EAM-системой. Ибо с одной стороны PLM-система вроде бы используется по определению на всём жизненном цикле системы, но ERP и EAM сильно смущают на этом настаивать -- и все соглашаются ограничиться проектированием/разработкой. Парадокс решается, если взглянуть на схему из слайда 11 в http://www.slideshare.net/ailev/asset-lifecycle-systemsengineeringoct14 (рассказываю об этом подробнее на видео вот тут -- http://ailev.livejournal.com/1152679.html).
2019

Социализм как рассадник вранья

Меня давно интересует тема официального вранья -- начиная ещё с корейского боинга, кто помнит. Но официальное враньё питается враньём народным. "Близнецовое исследование" на странах http://www.economist.com/news/finance-and-economics/21607830-more-people-are-exposed-socialism-worse-they-behave-lying-commies показывает в эксперименте, что пожившие при социализме немцы более склонны врать, чем немцы чисто капиталистические -- "The longer the participants had been exposed to socialism, the greater the likelihood that they would claim improbable numbers of high rolls".
2019

Чеклисты

Книжка Atul Gawande "The Checklist Manifesto", http://gawande.com/the-checklist-manifesto крайне интересна. Её суть: "мало что более эффективно в сверхсложных коллективных проектах, чем дисциплинированно проходимые чеклисты, но это мало где признаётся, кроме авиации и проектного управления".

Тут нужно заметить, что автор трактует чеклисты более чем широко: от "классического" авиационного или (с подачи самого автора) хирургического чеклиста до... диаграммы Гантта и графика совещаний строительного проекта, а также любых других систематических процедур (например, списка проверок due diligence в инвестиционных фондах -- из 70 позиций), если прохождение всех пунктов этих графиков и процедур нужно декларировать публично, и есть дисциплина реальной проверки их прохождения. По сути, GTD (где вы вынимаете список дел из кортекса в экзокортекс, а затем дисциплинированно просматриваете этот список в заданные моменты) -- это на 100% техника чеклистов, как её понимает автор чеклистового манифеста.

"Чеклистом" автор книжки называет короткий (пять-семь, но и одногда и семьдесят) список действий, каждое из которых должно быть обязательно сделано по мере зачитывания списка (чеклист типа READ-DO), или условие/действие, которое должно быть подтверждено по мере зачитывания списка (DO-CONFIRM).

Использование чеклиста происходит во время "точек паузы" (pause points, как они называются в авиации), где вся рутинная и сложная деятельность прекращается, и происходит прогон чеклиста. При ближайшем рассмотрении оказывается, что речь идёт о переходе с одной из стадий жизненного цикла кейса к другой его стадии (смена cognitive framework, прохождение разных "точек невозврата", в которых система/кейс существенно меняет состояние), а чеклист "прочти-подтверди" (DO-CONFIRM) представляет собой верификацию того, что сделано на предыдущей стадии, чтобы попасть в слеюдующую стадию. Ну, или чтобы попасть в следующую стадию, нужно прогнать чеклист "прочти-сделай" (READ-DO, этот тип чеклиста обычно выполняется при попадании во внештатную ситуацию). Поэтому в каждом деле главных чеклистов обычно буквально несколько штук, а вот "аварийных" -- сотни.

Прохождение одного "классического" подтверждающего чеклиста (опять же -- недаром его выполнение происходит в точке "паузы"!) занимает одну-две минутуы нужно вслух подтвердить для всего коллектива выполнение указанных в нём условий (типа "снято с ручного тормоза", "выпуск релиза происходит не вечером пятницы", "антибиотик введён не раньше часа до операции, и не позже момента начала операции"), а самих условий обычно 5-9. Конечно, "неклассические" варианты отличаются разнообразием, особенно в случаях, когда всё проектное управление автор книжки упаковывает в формат прохождения списка работ из диаграммы Гантта проекта в прохождение чеклиста (ибо есть формальное подтверждение того, что работы были действительно выполнены).

Дисциплина чеклистов выглядит очень бюрократической -- но это ровно то же самое, что отличает системных инженеров, которых совершенно недаром с их приверженностью к формальным процедурам (aka прогону чеклистов) называют "бюрократами от инженерии", что они признают, и чего они не стесняются. Объясняют это своё нестеснение они просто: зато ракеты долетают куда надо, а атомные станции начинают давать ток и даже более безопасны в целом, чем угольные в рассчёте на киловатт-час.

Чеклисты, тем не менее, существенно отличаются от похожих на них описаний работ (например, описанных по традициям ситуационной инженерии методов, или традициям архитектуры предпринятий, или традициям описания лучших практик, или просто пошаговых инструкций по выполнению работ). В чеклистах приводится не 100% описания работ, а только самое существенное, что может быть упущено и приведёт к epic fail -- главным образом чеклисты делаются на основе анализа статистики, в в более редкие "аварийные" чеклисты шаги включаются на базе расследований крупных катастроф. Ибо 10% провалов происходит не из-за чрезвычайной сложности какого-то процесса, а именно из-за того, что очевидные шаги пропускают на основе того, что "всё тут обычно бывает гладко", а то и банально из-за отвлечений, надежды, что кто-то другой это сделал, общей суеты вблизи смены стадий жизненного цикла, плохого знакомства команды друг с другом. Теория швейцарского сыра (http://en.wikipedia.org/wiki/Swiss_cheese_model) -- это как раз про чеклисты. Утверждается, что в 9 случаях из 10 чеклист будет пройден без сучка и задоринки, а в одном из десяти случаев будет что-то обнаружено, что исправится за несколько секунд, но убережёт от дорогостоящих и трудно исправляемых ошибок.

Фишка в чеклистах не в том, что их разрабатывают и отлаживают. Да, их честно разрабатывают, а не просто пишут формальные какие-то банальности). Отладка чеклистов крайне важна (чёткость формулировки, применимость общей формулировки к различным конкретным ситуациям, краткость формулировки, малость самого списка), также важна адаптация к условиям применения (если идёт заимствование чеклиста). Чеклисты часто отлаживают на тренажёрах и имитаторах, но обязательно отлаживают -- в дело идёт отнюдь не первая версия, написанная каким-нибудь "аналитиком", который ни разу не был сам в описываемых этим чеклистом ситуациях.

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

Неявный посыл книжки -- что не уставы написаны кровью, а чеклисты. Ибо уставы наизусть выучить -- дело бесполезное, и требует сверхгероя. Никто не способен прочесть всю нормативную документацию, запомнить все требования ("уставы") и вспомнить в критической ситуации. Но короткий чеклист имеет шанс быть вытащенным и прогнанным -- это не заменяет учебников, требования высокой квалификации людей и непрестанного тренинга, уставов (чтобы было кого наказывать за их несоблюдение, и чтобы было где-то хранилище полного знания). Но чеклисты позволяют из сверхгероев делать просто героев, а потом и рутинизировать процесс. По мере внедрения в инженерную и лётную практику чеклистов особость генконструкторов перестала волновать, и их именами перестали называть самолёты, пилоты-испытатели перестали быть национальными героями. А сейчас примерно то же самое происходит с медицинскими светилами (и об этом подробно рассказывает в своей книжке Atul Gawande -- эпоха Master Builders заканчивается, на смену ей идёт эпоха командной работы).

А уставы и чеклисты отличаются хотя бы тем, что уставы требуется выполнять полностью в их целостности, а чеклисты -- прогонять (например, проговаривать вслух вопросы и проговаривать вслух ответы -- причём в присутствии всей команды), прогонять всегда.

Важно прохождение чеклиста всей командой, это средство убедиться, что "все на одной странице книги", "играют одну и ту же партию", имеют "одну и ту же версию правды". При прохождении чеклиста важен как раз консенсус, что все согласны с тем, что чеклист пройден, и принимается решение "go -- no go" для возможного перехода к следующей стадии жизненного цикла кейса.

В самом чеклисте проверяется/делается в обязательном порядке не только производственные акты, но и коммуникационные акты (проверяется/делается не только суть дела, но и обеспечивается коммуникация -- по факту происходит командообразование, вплоть до обязательно представления команды друг другу перед началом работы и требования вот прямо сейчас, во время точки паузы и прогона чеклиста предъявить план действий на следующей стадии, а также рассказать о подозрениях каждого члена команды о возможных трудностях в ходе реализации плана). Важно, что зачитывание чеклиста производится не самым главным в команде, а самым свободным -- но имеющим достаточный статус, чтобы мочь возразить главному при "проскоке" каких-то шагов.

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

Короткий список критических шагов (или критических выполненных условий) должен быть извлечён из кортекса супергероев и перенесен в экзокортекс (т.е. записан на бумажку, или засунут в компьютер). Чеклисты -- это одна из мер по повышению успешности решения сверхсложных задач не за счёт супертренинга супермозга супергроссмейстеров, а за счёт введения дисциплины коллективной деятельности и усиления кортекса в виде экзокортекса. Гроссмейстеры играют в уме, простые игроки играют за доской, "записывая" на ней результаты ходов -- чтобы у обоих игроков не было ни малейших сомнений, что они играют одну и ту же партию, а не разные. Чеклисты позволяют синхронизировать командное понимание по поводу важнейших шагов деятельности, в разы и разы уменьшая количество ошибок.

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

Что ещё похоже в "чеклистоведении" и системной инженерии -- это отсутствие внимания к проблеме предотвращения глупых ошибок и интереса профессионалов к работе с чеклистами, несмотря на драматические улучшения (по сравнению с любыми другими менеджерскими и инженерными новинками) в поднятии качества работы.

Мне кажется, что киборгизация/"упорядочивание, которое бьёт класс за счёт использования экзокортекса"/использование систем управления кейсами рассматривает формальное удостоверение в прохождении каких-то шаблонов деятельности "из коробки". Всякие issue trackers -- они же именно про это. Но поддержка "классических" чеклистов авиационного типа, в отличии их от "процессов" и "проектных работ" (т.е. принципиальная неполнота и несводимость к инструкциям/уставам/регламентам/учебникам, требование командного подтверждения, создание каких-то аналогов "вербального зачитывания", прогон в специальных точках жизненного цикла кейса) накладывает вполне определённые требования к софту adaptive case management. Мало что из issue trackers поддерживает это, хотя, например, проход по открытым issues в ходе проектных совещаний подозрительно напоминает проход по чеклисту. Да и сама "постановка вопроса/issue -- закрытие вопроса" с командным обсуждением тоже вполне себе работа с чеклистом, только асинхронная. Но вот функционал поддержки "классического" READ-CONFIRM чек-листа, доступный во время совещаний, а также функционал разработки и отладки таких чеклистов -- это было бы очень интересной фичей для ACM. И тут мне кажется, что совершенно неслучайно как ACM, так и генерализация чеклистов из авиационной практики отрабатывались именно на ситуации медицинской клиники, где сочетаются крайняя повторяемость отдельных процедур и операций с крайним разнообразием кейсов.

Собственно, системная инженерия устроена так же, в "повторении неповторяемого", в устранении супергероев-генеральных конструкторов и переходу к рутинной работе специалистов по каким-то отдельным проблемам. И софт должен это поддерживать явно. И описание метода должно содержать не только "процедуры", но и чеклисты, как first class object.