Альфа системы
Альфа системы (иногда для акцентирования физичности, «вещности», материальности — альфа воплощения системы) весьма разнообразна: состояния воплощения системы будут абсолютно разные для атомной электростанции, мобильного приложения, стартапа, магазинной доставки, игрового сеанса, лесопосадок, гражданского общества, танцевального перформанса, гончарной мастерской, сталелитейного завода.
Вот пример очень общего списка состояний (определяемых событиями достижения их контрольных точек, отражённых в контрольных вопросах чеклиста) для «железной» системы в заказной разработке. Его нужно тщательно адаптировать для каждого отдельного вида систем, и даже для разных видов «железных систем» в разных вариантах инженерного процесса заказной разработки. «Железная» система (или её версии, или инкременты, фичи, опции — «непрерывное всё») при заказной разработке может проходить следующие состояния:
- В виде модели (asamodel): «рабочка» (описание с точностью, достаточной для изготовления) готово для изготовления; BoM (bill of materials, сводно-заказная спецификация) готова для закупок, технология изготовления с инженерами внутренней платформы разработки согласована.
- В виде сырья (asarawmaterial*)😗 материалы для воплощения системы наличествуют и позволяют создать части системы с нужными характеристиками; оборудование для переработки материалов в детали наличествует; график производства и логистики частей системы согласован; возможны работы по изготовлению частей системы.
- В виде частей (asparts*)😗 части воплощения системы созданы и/или закуплены и проверены; график интеграции/сборки/монтажа/строительства из частей согласован; возможны работы по интеграции/сборке/монтажу/строительству.
- Демонстрируемо (demonstrable): воплощение системы может быть опробовано в отдельных функциях и ключевые характеристики могут быть измерены; ключевые характеристики могут быть продемонстрированы внешним проектным ролям; критические интерфейсы системы к окружению были продемонстрированы; система готова к испытаниям в порядке инженерного обоснования успешности; необходимые внешние проектные роли согласны, что систему нужно испытывать.
- Готово (ready): функциональность испытана; уровни дефектов для внешних проектных ролей приемлемы; установочная и другая пользовательская и операторская документация доступна; представители/исполнители внешних проектных ролей удовлетворены системой; состав/конфигурация передаваемой системы известен; представители/исполнители внешних проектных ролей готовы эксплуатировать систему; эксплуатационная поддержка создателей наличествует; операторы и пользователи наличествуют; системное/рабочее окружение для критических интерфейсов готово.
- Эксплуатируется (operational): доступна внешним проектным ролям для эксплуатации/использования в рабочем окружении; есть как минимум один пример работающей системы (при серийном выпуске); поддерживается на согласованном уровне сервиса обслуживания.
- Выведено из эксплуатации (retired): Воплощение целевой системы было заменено или прекращено в использовании; система больше не поддерживается; нет «официальных» внешних проектных ролей, которые до сих пор используют систему; доработки/доделки системы больше не будут производиться; все материальные компоненты системы либо повторно используются, либо надлежащим образом уничтожены.
Удивительно, но у многих людей при обсуждении воплощения системы так мысль и не доходит до физической реальности, всё остаётся в виде описаний (типичная ошибка: «целевой системой нашего проекта является аналитический отчёт», а ведь отчёт — это описание!). Напомним, что это проявление симпатической магии: убеждение в том, что для изменений в физическом мире достаточно изменить описание (скажем, колоть булавкой или целовать модель человека — куклу Вуду, надеясь, что с описанным этой куклой человеком произойдёт что-то плохое или хорошее. Изменить строчку программного кода ERP-системы, игнорируя, как это повлияет на планирование потоков ресурсов в предприятии — это проявление того же мышления, «симпатическая магия»)[1].
Если ваше воплощение системы не находится в материальном мире, вы не можете для вашей системы указать место в пространстве в какие-то моменты во времени, то велика вероятность, что у вас фантазийный проект. Если его сделать, то ничего в физическом мире не изменится. Ну вот и не делайте, бросьте его, ничего ведь в мире не изменится!
Убедитесь, что в вашем проекте воплощение системы в конечном итоге физично! «В конечном итоге» — это, возможно, уже не в рамках вашего проекта, а позже, в ходе выполнения какого-то другого проекта другой командой, но вы должны понимать, что ваша работа направлена на изменения в физическом мире, в поддержку этих изменений, а проводится не сама по себе. И после этого понимания — действовать, не считать, что ваша работа заканчивается там, где вы выдали какое-то описание. Нет, вам надо проследить, что это описание реально повлияло на то, чтобы появилась успешная система. Думать «потом пусть пришлют замечания, если что-то не понравится» — это неправильно, контрпродуктивно. Если завод выпустил неработающий станок, ресторан кормит вас несъедобным борщом, то вряд ли им за такое надо платить. За выпуск описаний надо платить только тогда, когда эти описания тоже привели к чему-то успешно работающему в физическом мире, тут та же логика.
Ваша работа должна быть рациональна, то есть вы должны привести причинно-следственное (контрфактическое) рассуждение о том, каким образом ваша работа поддерживает изменение физического мира (создание и/или развитие какой-то системы::«физический объект»). Нерациональные работы лучше не делать, нерационально (без понимания причинно-следственных связей с выпуском успешной системы) устроенные проекты лучше закрывать сразу, платить деньги за выполнение таких проектов неэтично, получать деньги за выполнение работ в таких проектах — неэтично.
Когда вы обсуждаете альфу воплощения целевой системы, обращайте внимание и на создателей. Описания самой системы могут быть хороши, но изготовить вы её не сможете: инженерная команда приготовила описания, не заботясь о том, как система будет изготавливаться, не продумали, как система будет появляться в физическом мире. Обычно неудача с производством возникает тогда, когда в команде отсутствует технолог или аналогичная роль для «нежелезных» систем. Потом оказывается, что нет таких станочков для «железа», непонятно как учить для образовательных проектов, нет нужной вычислительной мощности в компьютерах для проектов программной инженерии и т.д.
Если ваш предмет интереса только в описании системы, не забывайте, что это описание нужно только постольку, поскольку система будет воплощена в физическом мире, займёт там место в пространстве-времени. Отслеживайте альфу воплощения системы в ходе всего проекта, с самого его начала, а не только в момент, когда нужно начинать воплощение! И ещё не забудьте: воплощение системы эксплуатируется/используется, всё делается для этого состояния (а не для состояния в момент окончания изготовления или в момент продажи. Воплощение самолёта в рабочем состоянии летит высоко в небе, перевозит грузы и пассажиров, зарабатывает деньги для авиакомпании**, а не «готово» или даже «отгружено для** использования**»!).**
Альфой системы в графе создателей может быть альфа организации проекта, для краткости мы назовём эту организацию «командой», хотя это может быть один человек, небольшая команда, «которую можно накормить двумя большими пиццами»[2], коллектив из нескольких команд, большое предприятие, кооперация/«расширенное предприятие»/«extended enterprise» из нескольких предприятий. Вот состояния, по которым можно отслеживать изменения альфы «команда» (тут состояния для небольшой команды, для большой организации из многих команд придётся неминуемо всё адаптировать, всё переписать по-другому — и памятуем, что оргизменения в ходе постоянного развития тут по факту опущены, каждое из них требует создания отдельной подальфы или использования текущей альфы для каждой новой создаваемой оргвозможности):
- Намечена *(seeded):*стратегия (функция) команды в ближайшей надсистеме (организации, бизнес эко-системе) определена и роль команды тем самым известна; ограничения и их причины известны и явны; механизмы роста и развития команды наличествуют; инженерный процесс в общих чертах известен и тем самым состав внутренних ролей в команде определён; обязанности команды по отношению к надсистемам обрисованы в общих чертах; уровень принятых командой обязательств ясен; требуемый уровень мастерства определён; размер команды определён; методы надзора за деятельностью определены; вид/форма оргзвена (подразделение, рабочая группа проекта, иное) выбрана.
- Сформирована (formed): Было набрано достаточное число членов команды; роли в команде понимаются её членами; все понимают инженерный процесс; члены команды узнают друг друга при встрече; члены команды понимают индивидуальные обязанности и как они увязаны с их мастерством; члены команды принимают результаты работ друг друга и смежников; внешние смежники (организации, команды и отдельные люди) определены; механизмы общения и удержания коллективной собранности в команде определены; каждый член команды принял обязательство работать так, как это принято в команде; технологии развёрнуты; ресурсы для работы выделены, полномочия получены.
- Сотрудничает (collaborating): команда работает как одно сплочённое оргзвено (распределённое лидерство); общение в команде открытое и честное; команда сфокусирована на реализацию стратегии (миссии/задания) команды; члены команды знают друг друга и сотрудничают.
- Производит (performing): команда постоянно выполняет обязательства; команда непрерывно адаптируется к изменяющемуся контексту; команда определяет и решает проблемы без внешней помощи; минимум возвращений к сделанному и переделок; работа команды рациональна и элегантна: работа впустую (waste) и причины для работы впустую постоянно устраняются.
- Распущена (adjourned): стратегия была реализована; обязанности были выполнены; члены команды доступны для участия в других командах.
Обращайте внимание на смысл, а не терминологию. Так, для первого состояния «железной» системы была выбрана формулировка «в виде модели», но это же состояние для команды названо «намечена» (термин взят из примера альфы team в OMG Essence). Можно было бы назвать это состояние «в виде оргмодели», по образу и подобию «железной системы», можно взять более подходящее для вашей ситуации имя состояния. Всегда адаптируйте материал наших руководств****для использования в вашем проекте!
Подальфы для команды, конечно, это описания ролей членов команды, поэтому хорошая тут идея — использовать табличку для описания ролей из руководства по системному мышлению и наборы типовых проектных ролей из руководств по системной инженерии, инженерии личности, системному менеджменту или какой-то аналогичный набор культурно-обусловленных ролей для инженерного процесса в вашей предметной области.
Не забудьте проверить, есть ли у членов команды (оргзвеньев, исполнителей ролей — конструктивов для ролей) мастерство в методах работы, которые будут указаны в альфе «метод». Если инженерный процесс требует такого метода работы, как «программирование на Julia», а у вас в команде на исполнение таких работ назначен мастер в операционном менеджменте, который говорит, «ОК, я займусь, заодно научусь программировать», то в этом проекте не ждите успеха.
Проверьте, где в вашей оргмодели можно найти ответы на вопросы, нужные для определения состояния альфы «команда». Например, «общение в команде открытое и честное» — это же нельзя вывести из оргмодели, данной как список фамилий, расписанный по их должностям? Если открытость и честность в команде как-то не документированы, они останутся невидимы, и тогда не будут запланированы работы по каким-то методам лидерства, а не будет лидерства, то и ситуация с общением в проекте может оказаться плохой и нервной, и об этом мало кто будет думать как о чём-то, что надо поправить лидерской работой, а не просто сетованиями на «плохую атмосферу». Чеклист как раз для того, чтобы про такую работу не забывали!
Работать в банке с пауками мало кто хочет, мало кому так работать приятно. На проекте это скажется не лучшим образом: в подобных ситуациях часто людей «подставляют» (делают так, чтобы какой-то кусок проекта провалился, и было известно, по чьей вине). Вам надо, чтобы какой-то кусок проекта провалился, даже если будет известно, по чьей вине?! Альфа «команда проекта» заставит обратить внимание на эту ситуацию, заставит запланировать работы для решения этой проблемы.
Системное мышление, методология**— это** фундаментальные методы мышления, обращающие внимание на важное. Альфы — это и есть самое важное в проекте, что вы должны интенсивно менять в ходе всего проекта**, их изменения надо согласовывать в масштабах команды проекта и непрерывно** отслеживать в течение всего проекта**. Их нельзя упускать из виду****,** о них нельзя забывать, поэтому не надейтесь на ненадёжный и забывчивый человеческий мозг, используйте чеклисты для альф в каком-то операционном софте.