суббота, 14 декабря 2019 г.

Соломенный учитель

by Keith Devlin, the Executive Director of the Human-Sciences and Technologies Advanced Research Institute (H-STAR) at Stanford University and The Math Guy on NPR's Weekend Edition.


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

Первые часто прибегают к тактике соломенных человечков. Это особо часто происходит во время Математических войн в США, обсуждение в которых сейчас сосредоточено вокруг Основных Стандартов Штатов по математике.

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

Возможно, такие учителя существуют, но я пока их не встречал. То же самое можно сказать про соломенных учителей, для которых получение правильного ответа неважно. Учителя так не поступают, для них важны знания, процедуры и правильные ответы.

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

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


В практическом плане это означает, что вам надо:

- с одной стороны в совершенстве изучить базовые процедуры до того, как у вас появится концептуальное понимание,
- а с другой стороны вам необходимо концептуальное понимание, чтобы ваши инструментальные навыки укоренились и вошли в привычку, а не исчезли через какое-то время.

И это то, что делает хороший учитель математики. И еще раз, для протокола, оба этих навыка описаны в Основных Стандартах, которые все так обсуждают.

воскресенье, 8 декабря 2019 г.

Минимально жизнеспособный желтый. Когда маркетинг тупит с неймингом

Минимально жизнеспособный желтый, минимально жизнеспособная любовь, минимально жизнеспособный принцип Гейзенберга. Что не так с этими терминами? К абстракциям неудобно применять понятие жизнеспособности. Можно, конечно, сказать, что идея нежизнеспособна или подход неприменим к данной ситуации, но смысл такого выражения все равно будет далек от точного смысла концепции MVP. 

Поэтому когда я увидел текст:
В новой книге ITIL ® 4 Create, deliver and support, которая, правда, пока что доступна только по подписке, описан довольно «простой» подход к определению охвата любой практики. Он называется «минимальная жизнеспособная практика» (minimum viable practice, MVP). Источник.
То сразу зацепился за эту формулировку. И потом стал думать, а что же конкретно мне здесь не нравится и какой термин точнее передаст смысл понятия minimum viable practice


Мой вариант - минимально полезное знание. Объясню ход мыслей:

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


MVP - это такое воплощение системы, которое способно хоть как-то конкурировать в конкретном контексте использования с теми штуками, которые уже есть. 

То есть, пользователь может переключиться с использования своего текущего продукта на наш и его потребности будут удовлетворены. Такую минимальную конфигурацию, набор функционала, фич, мы называем MVP.

MVP характеризует орг. способность (system capability). Конкуренция среди систем идет по уровням сервиса в конкретных контекстах использования.
Минимальная конфигурация не означает, что ваш продукт проще конкурирующих, как может показаться с первого взгляда. Нет, я говорю про минимальную конфигурацию конкретно вашего продукта. Представим ситуацию, что легалтек расцветает и вы можете в большинстве юридических ситуаций отказаться от юриста с "Консультантом Плюс" в пользу облачного бота с думателем и нейронкой просто потому, что он дешевле, быстрее и его консультации качественнее. Конфигурация и архитектура облачного бота может быть намного сложнее, чем конфигурация "Консультант Плюс", даже если вы сделаете MVP такого бота. 
Точно также MVP авиалайнера, который стал совершать трансатлантические перелеты и заменил корабли, был технически сложнее конкурирующих продуктов, но проще, чем Боинг 747 или Айрбас А380, к которым в итоге все пришло. 


Какой вывод отсюда следует сделать?
Конкурируют сервисы, а не сами продукты. Правильнее говорить, что MVP - это воплощение системы в такой минимальной конфигурации, которое активирует орг. способность достаточную для замещения конкурирующей (текущей) орг. способности.

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

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


Итак, ключевой вывод всех этих рассуждений заключается в том, что MVP относится к воплощению системы. 


Резюмирую рассуждения первого пункта:
Орг. единица приобретает (acquire) целевую систему (system of interest), чтобы заменить (retire) текущую систему или комплекс (конкурирующие с целевой системы). Такая замена называется внедрением или освоением технологии (technology insertion, implementation) работы с новой системой. 
И текущая и новая технология дает орг. единице возможность (capability) выполнять какие-то рабочие задачи с каким-то уровнем качества и в каких-то объемах. Такая орг. способность зависит как от характеристик системы (systems performance), так и от того, насколько хорошо орг. единица владеет технологией использования. Поэтому системы по результатам внедрения валидируют (validation) - проверяют, насколько полно новая система закрывает потребности приобретающей стороны (user needs). 
Те системы, которые более-менее успешно закрывают типовые потребности в каком-то классе ситуаций и контекстов, называют "продуктами" (product). Продукт отличается от системы именно массовостью, которая позволяет делать типовой маркетинг и продажи для разных исполнений системы (marketing and sales pipeline), потому что ясно, что скорее всего, после внедрения проблема будет решена, и валидация пройдет успешно. Единичный экземпляр продукта называется изделием (good). 
Минимальная конфигурация продукта, который способен успешно заместить конкурирующие системы, называется MVP.


Практика - знание, модель, которая объясняет класс фактов. У знания нет сервиса и нет контекста.
Вопрос - насколько вообще можно переносить понятие минимальной жизнеспособности на практику? Для этого необходимо понять, что же такое практика
Обратимся к OMG Essence как наиболее авторитетному исследованию в этой области.
9.3.2.15 A practice is a repeatable approach to doing something with a specific objective in mind. A practice describes how to handle a specific aspect of a software engineering endeavor, including the descriptions of all relevant elements necessary to express the desired work guidance that is required to achieve the purpose of the practice. A practice can be defined as a composition of other practices.Практика - это повторяющийся подход к исполнению, направленный на получение заранее известного результата. Практика описывает как работать с определенным аспектом проекта по созданию ИТ-системы, включая описание всех относящихся к делу элементов. Практика дает указания по тому, как исполнять работу так, чтобы достичь целевого результата. Практика может состоять из других практик.
Казалось бы, это очень похоже на определение процесса. Он ведь тоже повторяющийся, тоже нацелен на получение заранее запланированного результата. В чем разница между процессом и практикой? Обратите внимание на первые два слова определения. "Повторяющийся подход". А процесс это "последовательность действий". 
Подходы абстрактны, процессы конкретны. 
Подходы работают с отвлеченными объектами: Скрам, спринт, клиент, потребность. Процессы преобразуют конкретные рабочие продукты в другие рабочие продукты: письмо от клиента в коммерческое предложение по установленной форме, которое должно быть выдано в течение 6 рабочих часов, принятое коммерческое предложение в план проекта, техническое задание и бюджет и все это за 3 дня, план проекта и ТЗ в готовый к поставке продукт и план приемочного тестирования. 

Процессы это "делай раз-два-три", желательно думать поменьше, автоматизировать побольше. Практика - это про содержательную часть процесса. Что конкретно и в каких формулировках писать в договор? От каких типовых задач плана проекта можно отказаться для конкретного проекта, если будем не успевать? Как  пропатчить KDE2 под FreeBSD?

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


Процессы про форму, практики про содержание. 

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


И форма и содержание важны.

Примечание: для разделения практик и процессов я рекомендую соблюдать принципы наименования. Процессы именуются по шаблону "от [основной вход/стартовое событие] до [выход, результат процесса]". Например, "От заявки на подбор до завершения испытательного срока", "От запроса на коммерческое предложение до получения ответа от клиента". Практики именуются как функции, по виду деятельности, например "Анализ рисков договора", "Производственное тестирование сайтов", "Подбор персонала".

Но вот проблема. Если практика - это знание, которое позволяет ориентироваться и действовать в ряде ситуаций, то у него нет физического окружения. У процесса (орг. способности) есть - ИТ-системы, формы, заявки, должности, исполнители, совещания и комитеты, это все физически существующий контекст. А у практики такого нет, это же подход, отвлеченный от конкретных 4Д-индивидов. Какой там может быть MVP? Какие могут быть конкурирующие системы? Какой уровень сервиса? Если кит на слона залезет, кто кого заборет?


Ошибочное понимание практики приходит из непонимания концепции жизненного цикла системы и связи стадии использования и орг. способности.
Я заметил, что многие люди неправильно понимают формулу 
практика = дисциплина мышления + технология
Представьте, что вы внедряете CRM, но при этом набираете людей в отдел продаж с улицы и не учите их тому, что такое воронка продаж, лиды, референс визиты, выставление счетов, инфлюэнсеры, ЛПРы, не объясняете, в чем разница между RFQ и RFP и почему ТЗ на проектирование отличается от ТЗ к договору. Даже если вы очень хорошо пропишете все процессы отдела продаж, и сделаете идеальное внедрение с нужным функционалом, такой отдел будет продавать мало и плохо потому что орг. единица не владеет практикой продаж.


Как пишет про это OMG Essence:
A practice addresses a specific aspect of development or teamwork. It provides the guidance to characterize the problem, the strategy to solve the problem, and instructions to verify that the problem has indeed been addressed. It also describes what supporting evidence, if any, is needed and how to make the strategy work in real life. A practice provides a systematic and repeatable way of work focused on the achievement of an objective. When the practice is made up by activities, the completion criteria derived from them are used to verify if the produced result achieves the practice’s objective. To evaluate the practice performance and the objectives’ achievement, selected measures can be associated to it. Measures are estimated and collected during the practice execution.Практика отвечает на вопрос как коллектив (sic! Shared ontology detected) организует определенный аспект разработки (и любой другой деятельности). Она дает руководство по уточнению специфики решаемой проблемы, определяет стратегию ее решения и инструкции по тому, как проверять, была ли решена проблема до конца или нет. Практика также описывает  какие свидетельства и факты подтвердят решение проблемы и как привязать исполнение стратегии к реальным ситуациям. Практика предоставляет повторяемый и воспроизводимый способ работ, направленный на достижение заданной цели. Когда практика собирается из отдельных видов деятельности (activities), то критерии успешного завершения этих видов деятельности используются для проверки того, привела ли практика к нужному результату. Для оценки результативности практики и степени достижения конечного результата, с практикой можно связать показатели (метрики). Тогда во время исполнения практики для этих показателей собирается массив значений.
Практика-как-знание (абстрактное, отвлеченное понятие) равна способности коллектива (орг. единицы) использовать имеющиеся ресурсы и средства как функциональные объекты практики (есть микроскоп, значит им можно колоть орехи) плюс наличие этих самых ресурсов и средств, которые можно использовать для исполнения практики (для разработки нужны компьютеры, среда разработки, стенды и Git, для проведения операций нужна операционная, хирургические инструменты, материалы и медикаменты, для проведения тренинга нужно помещение, мебель, флип-чарты, фломастеры и проектор с презентацией). 
При этом как дисциплина так и технологии понимаются в абстрактном смысле. Когда логист планирует мультимодальную перевозку, он не думает, как он будет перекладывать конкретный груз из конкретного склада в конкретный грузовик, а потом их грузовика в конкретный корабль. Это мышление прораба, который не способен подняться над конкретикой конкретной стройплощадки, но ее-то понимает во всех деталях. Логист мыслит категориями учебника по INCOTERMS, а не конкретными бортами и контейнером, на котором несмываемым маркером написано слово "ВАСЯ".

Поэтому когда говорят про жизненный цикл 2.0 в противоположность жизненному циклу 1.0, речь идет ровно об этом - замене мышления с 4Д-индивидов стадий, конкретных воплощений работ "Технический проект", "Опытный образец" и т.д., на мышление абстрактными объектами, альфами практик (OMG Essence ALPHA). Жизненный цикл 1.0 был очень близок по смыслу к верхнеуровневому графику проекта, к процессной модели, к рабочим продуктам метода. И уже в силу этого его переносимость из проекта в проект была хуже, чем у модели жизненного цикла 2.0. Привязка жизненного цикла 1.0 осуществляется за счет того, что он напрямую описывает какие рабочие продукты и результаты будут созданы и где их найти в реальном проекте. Привязка жизненного цикла 2.0 к реальности происходит за счет механизмов практик, из которых он состоит, при этом сам жизненный цикл абстрагирован от конкретных ситуаций конкретных проектов.

Жизненный цикл 1.0 составляется из орг. способностей, из воплощений, высокоуровневых процессов. Жизненный цикл 2.0 составляется из практик, конкретный смысл, содержание и контексты работ появляются только после его привязки к конкретному проекту. Видите путаницу? MVP существует только в стадии использования. Вы передали продукт пользователю, и у вас появился MVP. А практика, даже привязанная к контексту, существует в каждой стадии жизненного цикла. Минимально жизнеспособная практика начинает иметь смысл только если мы сделаем классический мыслительный ход из ГОСТ Р ИСО 57193 (ИСО15288), и скажем, что каждая практика, которую мы используем, была в какой-то момент задумана, создана и передана нам в использование, что у нее есть свой жизненный цикл, что она как-то воплощена в конкретных рабочих продуктах, процессах (имеет форму, конструкцию), в орг. способностях. 
Но ведь одно описание практики воплощается в разных контекстах, имеет множество воплощений, то есть мы должны рассматривать жизненный цикл практики как какую-то разновидность итеративного либо инкрементного жизненного цикла.


И тут нас подстерегает вторая ловушка непонимания, в которую тоже часто попадаются.


Инкрементальные модели жизненного цикла как привязка к реальности, когда архитекторов не хватает.
Когда говорят про жизненный цикл, могут иметь в виду три принципиальные разные вещи - саму физическую эволюцию воплощения системы от замысла до вывода из эксплуатации, концепцию жизненного цикла как набор идей и мировоззрений о целостном взгляде на систему на всем протяжении ее существования, и модель жизненного цикла как описание эволюции системы. 
Представьте себе архитектора здания, который работает над конкретным проектом. Сам процесс возведения, эксплуатации и вывода здания из эксплуатации: от возникновения замысла в голове архитектора до сноса здания и будет воплощением жизненного цикла. Воплощение жизненного цикла межсубъектно, доступно для восприятия множеству людей, его можно использовать по назначению. Когда архитектор идет по стройке, он видит надземную и подземную часть здания, несущие конструкции, пилоны, распределение нагрузок и зоны, карты освещенности, возможные человеческие потоки и прочие штуки, которые необученный человек в здании не увидит. Понятия обычно субъективны, содержимое одной головы очень сложно переложить в другую голову. Это знают все, кто воспитывал детей или обучал взрослых. Но если команда использует практику, то подразумевается, что у нее есть разделяемые понятия (shared ontology), которые команда видит в реальности проекта (разделяемые понятия являются частью области рассмотрения, shared ontology is part of universe of discourse). 

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


Непривязанное к реальности понятие смысла не имеет, его обсуждение почти наверняка будет спором о терминах. 


Вывод: чтобы понять смысл термина minimal viable practice, надо привязать практику к конкретной области рассмотрения, к конкретной орг. способности.


Чтобы привязать понятие к жизни как можно раньше на жизненном цикле (in life cycle upstream), используются разные модели жизненных циклов, которые и будут актуальны для minimal viable practice. Речь идет об итеративных и инкрементальных моделях. 
Основное отличие между этими двумя видами моделей, которое люди чаще всего не понимают, заключается в следующем: и в том и в том случае жизненный цикл делится на части (спринты, релизы, инкременты, итерации), вопрос в том, что происходит внутри этой части. 
Инкрементальные виды моделей жизненного цикла в каждой такой части обеспечивают изменение воплощения. Типовой пример - Скрам. Уточнили потребности - уточнили требования - сделали доработку новых фич - протестировали - предъявили заказчику - сделали релиз. И левая и правая часть V-модели происходят внутри одного спринта. В результате понятия из практик модели жизненного цикла все время привязываются к конкретным индивидам в области рассмотрения проекта, это наполняет их смыслом. Инкрементом становится реальный прирост воплощения системы. Такая модель жизненного цикла еще называется эволюционной оппортунистической моделью жизненного цикла. В том смысле, что увидели возможность - реализовали ее. При этом в каждой итерации принимаются в том числе и архитектурные, принципиальные решения.
Итеративные модели жизненного цикла обычно подразумевают формирование и утверждение архитектурных требований и согласование системной архитектуры, а затем в каждой итерации идет разработка и построение частей системы. Важная особенность такой модели жизненного цикла заключается в том, что пока не закончилась разработка одной части системы, разработка другой части системы не начинается. Такие модели жизненного цикла еще называются заранее определенными многошаговыми.
Приведу пример как эти разные модели можно использовать применительно к проекту возведения здания. Скрам мог бы выглядеть так - команда беседует с заказчиками, определяет, допустим, какими должны быть кабинеты и переговорки. Потом ищет реальные здания, в которых кабинеты и переговорки больше всего похожи на то, что описали заказчики, организует референс-визиты, получает обратную связь, и дальше работает над столовой, комнатами отдыха, коридорами, туалетами, входной группой. В результате финальными итерациями проектирует здание по точным требованиям и архитектурным решениям и строит его. Либо создает подробные BIM-модели, и делает виртуальные туры по спроектированным помещениям. 
Заранее определенная многошаговая модель выглядит чуть более привычно - делается архитектурный проект, а затем прорабатываются объемно-планировочные решения и рабочие проекты для каждого помещения, по ним строятся BIM-модели, организуются виртуальные туры по спроектированным помещениям либо строятся полномасштабные макеты в павильоне. Когда все рабочие проекты по всем помещениям проработаны, финализируются проекты инженерных сетей, и собирается общий комплект проектной документации.
Когда какой вариант вида модели жизненного цикла выбирается? Зависит от того, насколько можно оценить целевую орг. способность по отдельным системным элементам. Например, понятно, что офис в промзоне будет куда больше зависеть от правильных проектных решений столовой, чем офис в центре Москвы, где вокруг множество вариантов пообедать. В случае промзоны орг. способность заводоуправления будет сильно зависеть от результата итерации/спринта проектирования и строительства столовой, поэтому аргументов в пользу итеративной модели жизненного цикла для завода в промзоне будет больше. В целом подход к выбору подходящей модели описан в статье.

Что это означает применительно к minimal viable practice? Если рассмотреть системы в обеспечении как воплощение жизненного цикла 2.0, то у вас есть два пути постановки практик - ставить по одной практике за раз, от определения до воплощения (инкрементальный подход к MV practice), и определять, какую практику вы берете в жизненный цикл каждый раз с учетом вновь открывшихся обстоятельств, либо выбрать все практики, которые вы планируете применять на старте проекта, и прорабатывать их по одной.

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


Практики, как и любые другие знания, живут в носителях - стейкхолдерах. Они и определяют границы MVP.
Приведу пример. Здание, которое несколько лет служило офисом X5 Retail Group, изначально было складом. Потом, когда стало понятно, что гораздо выгоднее переоборудовать его в офис, его переделали и это здание худо-бедно выполняло свою функцию даже несмотря на то, что архитектурные решения не очень это предполагали. Теперь его расселяют и, может быть, опять переоборудуют под склад. В данном случае, здание склада послужило MVP офиса. Почему это было возможным? 


Напомню один из начальных тезисов этой статьи:
Практика-как-знание равна способности коллектива использовать имеющиеся ресурсы и средства как функциональные объекты практики плюс наличие этих самых ресурсов и средств, которые можно использовать для исполнения практики . При этом как дисциплина так и технологии понимаются в абстрактном смысле.
Применительно к ситуации переделки склада в офис, был стейкхолдер, который посмотрел на склад и сказал "а ведь в нем можно не только хранить товары, но и устроить работу". Да, конечно, орг. способность склада не подразумевает наличие 2 тысяч человек на территории и поэтому с туалетами будет проблема; да, конечно, столовая не будет рассчитана на такой поток, а поскольку это промзона, то вокруг будет не так много вариантов; да, вентиляция не будет вытягивать образующийся оксид углерода, и поэтому все будут засыпать на рабочих местах, особенно под вечер, но это же MVP, так что сойдет, другие варианты еще хуже.


Вывод: границы и конфигурацию MVP определяют стейкхолдеры.

Применительно к MV practice это означает, что для каждой практики надо определить, какие стейкхолдеры будут ее оценивать и с каких позиций они будут смотреть на орг. способность MV practice, для чего она им нужна.


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

Поэтому я предлагаю переводить minimal viable practice как минимально полезное знание (МПЗ). МПЗ появляется в результате применения концепций практики к реальным ситуациям. Допустим, можно прочесть книгу "Пирамида Минто", распечатать картинку со структурой пирамиды и страницу с принципами делового текста, и применить их к своей презентации, которую вы сейчас делаете. Это и будет МПЗ практики "деловое письмо по пирамиде Минто". МПЗ практики "Анализ проекта по 7 альфам" может заключаться в прохождении этих чек-листов на еженедельных встречах команды с записью поручений в протокол встреч.

Что самое смешное, МПЗ всего лишь минимизирует затраты на получение минимально полезной функции, но не гарантирует эффективного решения проблемы. Это стратегия минимизация цены ошибки, а не максимизации выигрыша. Сделать офис из склада дешево, но в эксплуатации, с учетом всех негативных эффектов такого решения, такое решение может быть намного дороже, чем правильно полностью спроектированные системы в обеспечении. Скупой платит дважды.


Так что МПЗ полезны для корпоративных и государственных проектов, где не ошибиться важнее, чем выиграть. Живите теперь с этим.

суббота, 30 ноября 2019 г.

Платья::фасоны Объекты::Атрибуты

Системный инженер Борис гулял с Сашей и ее младшей сестрой в парке. Была ранняя теплая осень, девочки о болтали о чем-то своем, а Борис просто шел по дорожке, отключив голову. Вдруг к нему подбежала Женя, его младшая: "Папа, я хочу, чтобы ты мне купил фасон, как у Саши, черный такой!" "Купить тебе фасон?" "Да, фасон, черный такой, с кружевами". "Фасон нельзя купить. Может, тебе купить платье?" "Нет, фасон, ну как ты не понимаешь!" - Женя чуть не плакала. Тут в разговор вмешалась Саша: "Ей нужна кофточка. -  И повернувшись к Жене, добавила. Фасоны бывают только у платьев, у одежды. Это свойство, а не вещь, ее купить нельзя". Тут уже не выдержал Борис и он задал уточняющий вопрос Саше: "То есть ты считаешь, что фасон может быть только свойством и не может быть вещью?" "Конечно, - удивилась Саша. - Фасоны, цвета, крой, борта - это все свойства одежды. Глупость же говорить, что есть такая вещь как цвет. Это свойство". 
"Но вообще-то цвета как отдельные вещи существуют же? Мы же можем их обсуждать? Говорить про зеленый, белый, оранжевый цвет?" "Кому надо говорить про цвета вне привязки к каким-то вещам? Можно обсуждать цвет одежды, машины или лака для ногтей, но обсуждать цвет сам по себе - это какая-то ерунда. Может, дизайнеры будут это делать, но нормальные люди нет". Борис кивнул в знак того, что он понимает о чем идет речь, но не отставал: "А как нормальные люди относятся к фразе дизайнеры обсуждали какие фасоны будут  модными в будущем сезоне?" "Нормальные люди понимают, что дизайнеры обсуждают фасоны платьев, а не фасоны сами по себе. Нельзя обсуждать свойства в отрыве от предметов, у которых эти свойства есть, это заумь какая-то". 

"Представь, что ты хозяйка магазина платьев, у тебя что, в рабочем каталоге будут позиции артикулов по строкам, а в столбцах все-все-все свойства, характеристики платьев? Фасон, силуэт, стиль, вырезы, ткань, и еще что там бывает, я не специалист?" "Да, конечно. Вещь и ее свойства". Тут Борис прищурился и задал следующий вопрос: "Хорошо, а у свойств бывают свои свойства?" Саша посмотрела на него с недоумением: "Нет, конечно". "А платье разве не свойство одежды в целом? Точно также, как фасон - свойство платья?" "Э-э-э нет, точно нет. Платье - это категория одежды. Есть одежда, у нее есть категории - куртки, штаны, платья, шапки". 

"Хорошо, категории вещь есть только для вещей?" "Ну да, конечно". "Окей, а какие есть категории платьев?" "Классические, народные, деловые, вечерние, коктейльные, слипы, их миллион". "А вот то, что ты сейчас перечислила, разве не фасоны? Мне так показалось". Саша ненадолго впала в ступор: "Ну да, конечно, такие фасоны тоже есть. Не вижу проблемы, что у категории вечернее платье будет вечерний фасон". Борис улыбнулся: "Хорошо, вернемся к тому, что ты владелица магазина платьев и у тебя есть большая табличка, где перечислены все артикулы платьев, которые ты продаешь, а в столбцах у тебя есть свойства - размеры, фасоны, силуэты, цвета. И теперь ты решила расширить бизнес и торговать еще и куртками. Что делать с табличкой?" Саша нисколько не растерялась: "Заводить вторую, с куртками". "Но ведь там тоже будут фасоны, цвета, ткани, ведь у разных категорий одежды есть общие наборы свойств?" "Ну, значит, буду вести две таблички с одинаковыми полями". "А какой-нибудь Вайлдберрис, по-твоему, ведет стотыщмиллионов табличек для всей своей номенклатуры в каталоге?" 

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

"Логика, она знаешь, вся построена на удобстве. Никто не придумывает логику, которая неудобна для рассуждений, все хотят упростить рассуждения с помощью логики, а не усложнить. И базовая логика заложена в структуру таблиц - по строкам вещи, по столбцам их свойства. Если ты поместила категории одежды в столбец, то ты сделала вещь атрибутом другой вещи". "Ну да, для другой вещи это может быть атрибутом, хотя слово то же самое". "То есть фасон может быть вещью, объектом?" "Да нет, фасоны у одежды, это всегда атрибут, как и цвет". 

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

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

"Подожди, папа. - Саша замедлила шаг. А у этих новых объектов - у фасона, ткани, есть категории? Ведь должны же быть, если они есть у одежды?" "Если есть необходимость, то да, только обычно говорят не о категориях, а о классах. Объекты группируются в классы. У платьев есть суперкласс одежда и подклассы - коктейльное, свадебное и т.д. У фасонов, наверное, нет суперкласса, зато точно есть подклассы, мы про них говорили. У ткани есть суперкласс - материал, ведь одежду делают не только из тканей, но и из кожи, например, и есть подклассы - льняные, хлопковые, синтетика". "И у каждого класса-суперкласса-подкласса есть свой набор атрибутов?" "Ну да, и тут главное как сделать такую структуру классов и атрибутов, чтобы они между собой не перемешивались, чтобы не получилось как у тебя, что одно и то же слово одновременно является классом объекта и его атрибутом. Этим занимаются онтологи, инженеры данных, они придумывают такие вот модели предметных областей, чтобы было удобно и точно описывать объекты этой предметной области". 

"А ты онтолог?" "Не, когда мне нужна онтология, я всегда ищу готовую, их много разных лежит в Интернете, надо просто поискать. Каждый раз, когда я захожу на проект, я всегда изучаю типовые онтологии, ищу, например, banking ontology, aviation ontology или retail ontology. И сразу становится намного проще разговаривать с командой, потому что ты понимаешь, о каких вещах они говорят, что для них важно, о чем еще надо поговорить". "А я всегда удивлялась, как это ты можешь советовать что-то людям, если ты по этой теме ни дня не работал". "Ну, некоторые мыслительные приемы и ходы довольно универсальны. Скажем так, что в 80% случаев мой подход работает, но в 20% я ничем помочь не могу. Но 80% - это неплохой результат, не правда ли?" "100% лучше". "100% лучше. Согласился Борис. Эй, куда Женя убежала?" И они побежали искать младшую.

воскресенье, 3 ноября 2019 г.

Цена вопроса - тренажер коллективного принятия решений

Условия: 6 часов, в субботу с 11:30 до 17:30, есть домашнее задание, есть проверочные тесты.

Цена: 1000 руб. + тариф антикафе. Возврат денег, если ожидания не оправдались.

Что получаете за эти деньги?

1. Саму игру
2. Домашнее задание и его проверку
3. Доступ к тестам на освоение материала.

Кратко о тренажере. 

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

Какие решения надо принять?

1. Какой из двух вариантов производственной линии выбрать?
2. В какой очередности строить и запускать производственные участки производственной линии?
3. В какой комплектации выпускать автомобиль?
4. Какой должна быть ценовая политика?
5. Какой размер кредита по какой ставке и на какой срок надо взять для организации серийного производства?
6. Какой будет размер дивидендной выплаты и в каком диапазоне будет находиться прибыльность проекта?

В чем сложность?

Каждое решение надо будет обосновать и оформить по шаблону. Для этого надо будет постараться объяснить себе и другим почему решение должно быть именно таким.
Порядок игры.

1. Проходит совещание по запуску программы проектов (kick-off meeting). На нем руководитель программы проектов рассказывает про цели программы, объясняет замысел и планы программы, знакомит участников команд, распределяет роли и проводит обучение работе в симуляторе.
Календарный план программы в PDF.
2. Участники строят минимальную производственную линию, начинают опытное производство и начинают проектирование полномасштабной производственной линии.
Так выглядит проект полномасштабной производственной линии. Голубые фрагменты - минимальная производственная линия, которую участники строят на старте.
3. После завершения проектирования производственной линии команда организует серийное производство и выпуск автомобилей. Вам надо вести отчетность по проекту и использовать данные отчетности для принятия оперативных и стратегических решений. Всего есть четыре роли - директор по производству, директор по разработкам, маркетингу и продажам, директор по финансам и генеральный директор. У каждого свои отчеты и эти отчеты связаны между собой, чтобы их вести, вам надо будет наладить общение друг с другом.
Шаблоны отчетов - раз, два, три.
4. После завершения инвестиционной фазы программы, в конце 5-го часа игры, проходит жеребьевка и начинается аукцион. На аукционе команды делают прогнозы по доходности программы на конец 10-го дня. На каждом шаге аукциона команда может только уточнить оценку доходности программы, которую она сделала до этого. Когда одна из команд отказывается дальше уточнять свою оценку доходности, другая команда может еще раз уточнить оценку и аукцион завершается. Руководитель программы записывает текущие прогнозы по доходности каждой из команд.
5. Прогнозы и обязательства проверяются в дальнейшей симуляции работы завода до окончания игрового сценария, итоговые показатели фиксируются и сравниваются с прогнозными.
6. Побеждает та команда, которая управляла программы с фактической прибылью, уложившейся в границы прогноза. Если угадали обе команды, выигрывает та, чей диапазон прогноза доходности программы уже.
7. Участники получают доступ к тестовым заданиям и могут закрепить полученные знания, пройдя тесты.

Чему можно научиться?

1. Систематическому принятию решений и прохождению развилок на основании фактов, а не только мнений.
2. Поиску ошибок в решениях и структурированной аргументации в пользу того или иного варианта.
3. Полезному и адекватному абстрагированию и построению простой модели сложной ситуации.
4. Если пройдете тесты, то потренируетесь переносить эти знания в другие предметные области.
Фрагмент системной модели, по которой вы будете принимать инвестиционные решения.
Что может пойти не так и что я сделал, чтобы все было как надо?

1. Все. Все пойдет не так. - Я разрабатываю этот тренажер 7 месяцев и сделал 8 пилотных прогонов, собрал большинство шишек, море отрицательной и положительной обратной связи от игроков. Что-то все равно всплывет, и если это что-то вам не понравится, вы можете в любой момент выйти из игры с возвратом денег.

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

3. Производство автомобилей - это очень далеко от вашей области деятельности. - Логика симулятора линейная, все визуализировано, обычно понять, что происходит, не так сложно. Если все-таки не получается, можно в любой момент выйти из игры и забрать деньги. Кроме того, тренажер показывает действие универсальных принципов принятия решений, которые можно применить в различных областях от разработки ПО до ритейла.

4. Английский язык. - Увы, есть технические трудности русификации симулятора, с которыми пока ничего сделать не получилось. Мы работаем над этим, а пока тренажер для тех, кого минимальный технический английский не пугает. Чтобы было проще, я подготовил словарь терминов проекта. Кроме того, есть краткое руководство по игре на русском.

Хочу в игру!

1. Пока можно записаться на странице мероприятия в Facebook
2. Ссылка на ТаймПад будет завтра, 4 ноября.

понедельник, 21 октября 2019 г.

Онтология и технология

Процесс. От лат. prōcēssus «продвижение вперёд», далее из procedere «выходить; продвигаться», далее из pro «вперёд, для, за, вместо» + cedere «идти, ступать», восходит к праиндоевр. *ked- «идти, перемещаться». Русск. процесс — начиная с Петра I; заимств. через нем. Рrоzеss. 
1) последовательная смена явлений, состояний в развитии чего-нибудь.
2) Совокупность последовательных действий для достижения какого-либо результата (напр., производственный процесс).

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

Итак, у процессов есть входы и выходы. Рассмотрим для примера простой процесс продажи товаров в магазине. На входе этого процесса будет корзина покупок, а результатом будет сама покупка. Такое описание процесса не зависит от того, в каком магазине я буду закупаться, всегда у меня будет корзина покупок на входе, которая после оплаты становится покупкой, которую я могу забрать себе домой. Но, допустим, я заказываю товары по телефону в онлайн магазине, и хочу не забыть про весь свой список покупок, для этого я составляю перечень покупок, а после покупки отмечу те позиции, которые я купил, чтобы проверить, не забыл ли чего важного. Тогда моя корзина покупок будет уже выражена списком позиций магазина, а покупка выражена отметками по этому списку. Входы и выходы процесса поменялись. А если я зайду на сайт онлайн-магазина с личным кабинетом, то на входе процесса у меня будет заявка на покупку в личном кабинете, а на выходе подтвержденная заявка на покупку в личном кабинете. Входы и выходы процесса опять поменялись.
Если же я решу купить с того же магазина товары оптом, то на входе у меня будет заполненная ТОРГ-12, а на выходе подписанная ТОРГ-12, и сам процесс изменится, это скорее уже будет продажа товара со склада.
Во всех случаях можно описать происходящее первым шаблоном "Продажа товара в магазине", на входе корзина покупок, на выходе покупка, но формы входов и выходов будут все больше и больше конкретизироваться - от абстрактной информации до документов строгой формы, которые можно обрабатывать машинным способом. В первом случае мы имеем дело со общими понятиями о том, как происходит торговля, в последнем говорим о конкретных технологиях оформления акта покупки-продажи. Или, еще говорят об онтологии предметной области и технологии предметной области. Онтологию важно знать для понимания того, что происходит, что вы видите и к чему вас это обязывает, технологию важно знать, чтобы автоматизировать и выстроить процесс.
Можно рассмотреть процессы в паре, так, чтобы они образовывали транзакцию. Транзакция - это действие, которое либо может произойти от начала до конца, либо, если оно не может завершиться, возвращается к начальному состоянию. Такой возврат называется "откатом транзакции". В торговле такое может произойти если у покупателя не хватает денег либо если она заметила дефект товара на кассе. Тогда покупатель возвращает товар на полку, и транзакция прерывается. В бизнесе есть лишь небольшой набор таких ключевых транзакций, которые описывают бизнес-модель предприятия. Такая модель называется процессной архитектурой либо бизнес-архитектурой, первым про нее написал Dietz в книге Enterprise Ontology. Такая модель, описывающая ключевые транзакции для какой-то бизнес-модели, строится на базе онтологии, а не технологии. Она очень стабильная, компактная и слабо меняется даже при капитальных реорганизациях, смене ERP и руководства. Видеть эти ключевые транзакции очень полезно, т.к. в них заключается суть бизнеса, которая обычно скрыта за фасадом личных отношений, политики, сложной оргструктурой и запутанным ИТ-ландшафтом, и аналитик, который видит эти транзакции, может вовремя задать ключевые вопросы нужным людям. И может быть, эти вопросы и ответы станут началом дискуссии, которая ответит на ключевой вопрос современности: "А чем мы вообще занимаемся?"

воскресенье, 13 октября 2019 г.

Процесс, практика, метод, проект

Процесс - это непрерывная последовательность действий. Процессы не привязаны к функциональным/предметным областям (доменам знаний). Процессы преобразуют входы в результаты (выходы), то есть объект процесса сохраняет идентичность на всем протяжении процесса, меняя при этом свойства.
Практика = технология + дисциплина. Практика требует применения предметного мышления для определения последовательности действий. Практика всегда привязана к функциональной/предметной области.
Другими словами:
Процесс - воспроизводимый по результатам шаблон действий. Процесс необходим для структурирования обязательств и взаимодействия. "Я действовал как договорились" - это про процесс.
Практика - воспроизводимый по прогнозам шаблон мыслей. Практика необходима для структурирования фактов. "Я так вижу" - это про практику.
Примеры процессов:
1. Сборка и компиляция программного кода. Объект - исполняемый код, от состояния замысленного "должно работать" до состояния "работает на целевой конфигурации". При этом в процессе может быть задействовано несколько предметных областей - среды разработки, операционные системы, драйвера, автоматизированное тестирование.
2. Выпуск книги. Объект - книжное издание, от состояния маркетингово замысла "должно продаваться" до состояния "выложено на полку и рекламируется целевой аудитории". В процессе задействовано несколько предметных областей - создание сюжетов, верстка, реклама.
3. Реализация инвестиционных проектов. Объект - инвестпроект, от состояния "замыслен" до состояния "реализован". В процессе задействовано несколько предметных областей - финансовая оценка, календарно-сетевое планирование, бюджетирование и финконтроль, управление инвестициями.

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

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

Примеры практик:
1. Отладка и оптимизация программного кода. Объект на входе определить нельзя, потому что заранее непонятно, что может не работать или плохо работать в программе. Входа как такого нет, потому что отлаживать можно программу, которая выдает невоспроизводимую, но критичную ошибку. Выход, результат, предсказать нельзя, он варьируется.
2. Лечение пациентов. Объект на входе определить нельзя, потому что непонятно, какая болезнь, есть ли болезнь вообще, и можно ли ее вылечить.
3. Маркетинг. Тоже штука непредсказуемая и планировать какие-то цепочки действий наперед сложно.

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

Есть тонкая грань между процессами, которые работают с абстрактными объектами типа "инвестиционный проект" и практиками. Всегда есть соблазн сделать обощение и сказать, что практика дечения пациентов - это процесс, где на входе недиагностированный пациент, а на выходе вылеченный человек, и что этот процесс состоит из условно "Диагностики", "Подбора лечения", "Лечения", "Подтверждения выздоровления". Как разделить процессы с абстрактными объектами и практики? Отличий два:
1. У процессов есть сервис, который предоставляется в точке контакта с клиентом процесса. У сервиса есть контракт - стоимость его оказания, результат и условия.
2. У процессов есть границы. Есть начало процесса, четко определенные входы и событие, по которому процесс запускается, и окончание, четко определенные выходы, событие, по которому он завершается.
Красным выделена орг.единица, которая оказывает сервис процесса, синим процесс верхнего уровня, который работает с более абстрактным объектом "паспорт гражданина РФ", голубым текстовыделителем выделены процессы более низкого уровня, которые описывают конкретные сценарии с более частными объектами "данные паспорта РФ", "фотография в паспорте РФ".
Подробности процесса скрыты от клиента, там есть процессы низких уровней - межведомственные запросы, оформления документов и т.п. Этот процесс задействует несколько предметных областей. Но входы и выходы торчат наружу и доступны клиенту процесса. У этого процесса есть контракт - не все могут заказать себе паспорт, а только граждане РФ, у которых нет ограничений на получение паспорта. У контракта есть условия - госпошлина и сроки выдачи и замены документа.
Если в процессе выдачи выявляется что-то, что вызывает прерывание процесса, то включается какая-то практика, в ходе которой разбирается, что же не так и что делать дальше. У этой практики нет границ, нет гарантий. И если процессом занимается орг.единица, то практикой занимается роль. И эту роль могут исполнять разные орг.единицы, люди разных должностей, разных ведомств. Например, если паспорт нельзя выдать из-за того, что нарушено иммиграционное законодательство, то практикой разбирательства будут заниматься чиновники разных ведомств, адвокат и правозащитник. Это все разные орг.звенья, но одна роль "юрист".
Процессами занимается процессный менеджмент, практиками занимается кейс-менеджмент.
По большому счету, можно помедитировать на горбатую диаграмм, чтобы понять разницу между процессами и практиками.
По мере публикации все большего количества книг и оформления все большего количества паспортов, команда накапливает опыт, который можно формализовать моделями процессов и практик. Такой набор оформленных процессов и практик называется методом. Метод нужен для того, чтобы команда могла что-то обосновано обещать своему заказчику. Про методы можете послушать хороший доклад Каждой фазе проекта – своя методология. Как и зачем (Филипп Дельгядо, SECR-2018).
Скоординированные усилия команды с наложенными внешними ограничениями по времени, деньгам, уровню риска и с требованиями к качеству результата называются проектом. Проектом выполняется с применением метода.
Если команда работает без четко определенного результата, просто ведет деятельность и зарабатывает на этом деньги, то это называется направлением деятельности (line of business). Направление деятельности тоже использует метод.

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

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

пятница, 11 октября 2019 г.

Системной архитектор как ключевой коммуникатор в техническом проекте

Почему бизнес-аналитик или проектный менеджер вряд ли вырастет в системного архитектора, что такое "серый ящик", чем solution architect отличается от systems architect и от чего зависит количество итераций в проекте.


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

Подкаст:
https://anchor.fm/alexander-turkhanov/episodes/ep-e6hkd0
https://podcasts.apple.com/
https://music.yandex.ru/album/8792620

Т. Всем привет. И сегодня мы с Александром Лучковым, системным архитектором. И тема нашего разговора - это как вообще системная архитектура помогает реализовать стратегию предприятия. И, знаете, я не так давно смотрел один фильм Кристофера Нолана, один из последних, "Дюнкерк". Это военная операция второй мировой войны, когда фашисты разгромили Францию на материке, разгромили Великобританию, и Великобритания вытаскивала свои войска с материка, 300,000 человек, к себе обратно на остров. И вот как этот замысел, большой, как он реализовывался в реальной жизни. Реальное месиво, ничего не понятно, что летает, что происходит, военные задания все рушатся, то есть ничего не работает, никакие планы не работают. И как центральным организующим элементом всего этого бардака там служил адмирал, который, собственно и удерживал выполнение замысла вот этой военной операции на земле. И в моем понимании системный архитектор - это тот человек, который во всем многообразии жизни в большом проекте как-то удерживает целостность и реализацию этого замысла. Вот что ты по этому поводу думаешь?
Л. По поводу системного архитектора можно растащить примерно следующие понятия для начала. Первое - это продукт, который вы поставляете в реальной жизни и его воплощение, физические штуки. Второе - знания об этом продукте. Третье - документация об этом продукте. Поскольку вот эти три штуки между собой редко синхронизированы, то нужен кто-то, кто будет за этим следить. Вот этот человек и есть системный архитектор. Если же говорить о том, какую же пользу он приносит организации, то следует упомянуть о законе Конвея, который был сформулирован в виде "структура организации точно копирует структуру создаваемого ею продукта", при этом он работает и в обратную сторону. То есть никакая организация не может создать продукт, который не соответствует ее структуре. Или, по крайней мере, она будет делать его очень неэффективно. Поэтому тот человек, который отвечает за структуру создаваемого продукта, его границы, описания и ограничения, которые на это накладываются, он, по сути, для организации является источником данных о необходимых компетенциях при проектировании и создании этого продукта, о необходимых затратах, планах работ ну и так далее. То есть, это человек, который по сути предоставляет организации основания для собственного самопроектирования.
Т. А чем тогда это отличается от руководителя проекта? Планы, прочее - это ведь все, чем занимается проектный менеджмент?
Л. Проектный менеджмент занимается планами на основании тех данных, которые системный архитектор предоставляет. Поскольку системный архитектор - это не студент со скамьи, это человек, выросший из какой-то глубокой технической экспертизы, у него есть опыт как работы в поле, так и в планировании деятельности, то его данные, его результаты труда, являются основаниями для того, чтобы проектный менеджер имел представления куда копать, куда направлять команду, как правильно приоретизировать распределение ресурсов.
Т. Ну не очень понятно. Вот смотри, ты занимаешься аэронавигационными системами. Ваш продукт - это какая-то аэронавигационная система бортовая или наземная.
Л. В нашем случае наземная или аэродромная.
Т. Наземная или аэродромная, окей. Чем занимается системный архитектор, где эта грань с проектным менеджером?
Л. Проектному менеджеру первое, что дает системный архитектор - это структуры продукта. То есть результат труда - это перечень кусков системы, которые надо сделать. Второе, что он дает - это перечень экспертизы, которую надо привлечь в проектированию и дальнейшей разработке. На каких этапах жизненного цикла какие эксперты должны привлекаться, какими компетенциями обладать, ну и как между собой, по идее, это должно взаимодействовать. Потому что структура продукта, опять же, отражает структуру коммуникаций внутри организации. Если у вас есть два куска системы, которые должны между собой общаться, логично, что два подразделения, которые их создают, должны между собой общаться, чтобы договориться об интерфейсах между этими кусками системы.
Т. То есть он вместе с руководителем проекта пишет эту концепцию эксплуатации, где есть в том числе разделение этих работ в проекте.
Л. Концепция эксплуатации появляется одновременно со следующими штуками. Есть такая замечательная модель, модель многих вершин, twin peaks model, она говорит о том, что у вас постановка задачи всегда появляется одновременно с неким видением, может быть ошибочным, ее воплощения и реализации. Поэтому план коммуникаций и структура продукта и постановка задачи и ограничения системы - это все аспекты одного большого процесса, в который вовлечены как минимум следующие люди. Это бизнес-аналитик, который со стороны заказчика или со стороны потребителя анализирует потребности и выкатывает требования к решению, которое они хотят к себе встроить. С другой стороны, это, конечно же, ребята, которые планируют проверку и приемку в эксплуатацию той продукции, которую вы будете делать. Третьи люди - это как раз проектные менеджеры, которые говорят, а вообще в состоянии ли мы это построить за те ресурсы, которые у нас есть. И четвертый чувак - это как раз системный архитектор, который говорит о способе, которым можно удовлетворить потребности вот этих всех разных, непохожих и зачастую противоположных людей.
Т. Другими словами, системный архитектор с точки зрения реализации стратегии он как раз задает рамку какие работы туда должны войти и как выставлять приоритеты с точки зрения того, как создать тот самый продукт?
Л. По сути, да. То есть он, конечно же общается со всеми остальными, которые там риск-инженеры, инженеры по требованиям, инженеры по испытаниям, но он поддерживает во-первых такую очень важную штуку как методология проектирования в целом, то есть какие картинки рисовать, какой у нас будет план документирования, какие проектные команды участвуют в согласовании каких моделей, какие интересы выражают эти модели ну и прочие вещи. И, соответственно, на основании тех моделей, документов и практик проектирования, которые он предоставляет, и ведется разработка, задается направление развития продукта.
Т. Окей, понятно. Ты обрисовал такую идеальную картинку, а как оно в реально жизни-то? Что не так в реальных проектах?
Л. В реальных проектах обычно есть слабое разделение зон ответственностей разных ролей. С одной стороны архитектурную практику, часть ее, может тащить руководитель проекта, тот, кто работает в должности руководителя проекта. Часть этой же архитектурной практики, определение ключевых решений, разбиение системы на компоненты, может тащить за собой ведущий разработчик, ну и так далее. Очень много людей, которые вступают в роль архитектора, играют роль архитектора, при этом не осознавая того, что это именно архитектурная практика согласно какому-то идеализированному представлению.
Т. Где про эти идеализированные представления можно прочитать?
Л. Идеализированные представления можно почитать в международных стандартах, это, например, ИСО15288, он же ГОСТ 75193, но я рекомендую обращаться к оригиналу. Сейчас действующий вариант от 2015 года, он достаточно качественно описывает архитектурную практику, то есть что сама практика из себя представляет. И если вы замечаете, что вы выполняете какую-то из деятельностей из состава этой практики, значит вы неосознанно или осознанно прыгнули в роль системного архитектора. 
Т. Если ты неосознанно выполняешь эту роль системного архитектора, то к чему это приводит? Вкратце, какие последствия?
Л. Неосознанность роли приводит к пропуску существенных аспектов деятельности. Например, вы теряете заинтересованные стороны, вы теряете ключевые требования, вы упускаете из вида жизненный цикл и его этапы, вы упускаете в первую очередь качество вашего продукта. Самый основной риск - это то, что будут ошибочно выстроены коммуникации, ошибочно приняты решения, которые на поздних стадиях жизненного цикла приведут вас либо к провалу либо к банкротству, либо к другим потерям, финансовым, репутационным, зависит от того, чем вы готовы будете платить за ошибочные решения.
Т. Если вспоминать ИСО15288, то там же говорится, что есть черный ящик системы, есть прозрачный ящик системы, и архитектор - это ведь тот, кто работает с прозрачным ящиком? С черным ящиком работает как раз инженер по требованиям?
Л. Если мы рассматриваем ту самую модель многих вершин и итеративную разработку, поскольку у нас по сути весь проект - это уточнение и переход от неопределенности к полной определенности.
Т. То есть мы по V-модели идем вниз?
Л. А потом еще и вверх! От непонимания мы всегда двигаемся к пониманию. За созданное понимание, что оно в принципе создано, описано, утверждено и так далее, за это отвечает системный архитектор, за его исполнение, наполнение, за описание полупрозрачного или серого ящика, который всегда лежит на пути движения от черного ящика к белому ящику тоже он отвечает, в том числе за то, каким образом уточнять описание системы и создаваемого продукта. Методики проектирования, нужные картинки, иногда нужные документы, в том смысле какие документы нам нужно создать и как между собой они должны быть связаны, чтобы наш проект развивался, мы могли его уточнять дальше, передавать на производство, заказывать детальки у поставщиков, собирать на месте, а потом еще денег заработать на том, чтобы это потом еще и утилизировать. 
Т. Когда ты так описываешь работу системного архитектора, может сложиться впечатление, что это какой-то методолог, но это же не совсем так?
Л. В частности, одна их функций системного архитектора методическая. Потому что он в том числе определяет набор моделей и средства моделирования. Например, мы делаем все в виде сплошного текста, мы делаем все в виде картинок и UML, или мы делаем все это на основе model-based systems engineering, моделеориентированной системной инженерии или просто на основе моделеориентированной разработки, MDD. Все эти частные подходы и компетенции в области выбора подхода к проектированию и лежат на исполнителе практики системной архитектуры, который, по сути, и есть системный архитектор.
Т. Если говорить про итеративность подходов, то возникает два вопроса - где разница между архитектором частного технического решения, solution architect, и системным архитектором, systems architect? Это первый вопрос. И второй вопрос - если это итеративная разработка, а проекты это всегда итеративная разработка, то от чего зависит количество итераций?
Л. Начнем тогда с первого вопроса. Чем отличается архитектор частного технического решения от архитектора системы в целом? Как несложно догадаться, это зависит в первую очередь от точки зрения. Если то, что я создаю, является частным техническим решением в рамках системы верхнего уровня, как это в умных книжках называется "уровни системной организации". Есть уровень системной организации "надсистема" и есть уровень системной организации "подсистема".7
Т. Это ведь тот самый закон Конвея? Есть проекты, подпроекты, эта картинка есть в ИСО15288?
Л. Есть, вот прямо есть картинка, которая показывает концепты, термины, в которых можно об этом мыслить. Он выделяет несколько типов систем, по сути все системы можно поделить на системы по иерархическому принципу, это как раз надсистема-подсистема-целевая система и системы можно еще поделить по принципу окружения. Потому что у меня есть системы в операционном окружении из тех, с которыми я взаимодействую в эксплуатации, есть системы в обеспечении, обеспечивающие системы, enabling systems, которые "тащат" мою систему по жизненному циклу. По сути, еще интересно было бы подумать в сторону того, что система - это совокупность всех ее моделей, но это уже как раз точка зрения системного архитектора. Так что если у меня есть набор моделей, таких как физическая модель системы, ее воплощение, описание, документальное воплощение, когнитивное, восприятие этой системной модели в голове, поддержание целостности и коммуникаций и соответствия всех этих моделей друг-другу - это прерогатива и суть работы системного архитектора. Чем меньше у нас затраты на коммуникации на проекте, на согласование этих моделей в головах разных людей, чем меньше мы на это тратим времени, тем быстрее движется проект от черного ящика к полностью прозрачному ящику и тем быстрее мы доходим до конечной реализации.
Т. Мне это напоминает метафору кого-то из великих методологов, по-моему Коуберн про это говорил. "Архитектура - это когда команда условно говоря идет по болоту и вешки, которые они оставили, и есть архитектуры. Вопрос, понятны они только этой команде или эти вешки и карты понятны другим тоже, насколько вы документируете этот путь?
Л. Да, именно так. По сути, у архитектурной практики есть несколько задач. Первое - она всегда должна соответствовать стратегии развития продукта. У вас есть цель вашего предприятия, цель вашего существования как предприятия, вашей команды, если у вас архитектурная практика противоречит вашим целям, то логично, что продукт, который вы создаете, методы, которыми вы пользуетесь, скорее всего приведут вас в очень неприятное положение.
Т. То есть надо согласовывать между собой стратегию, проектные планы и методологию системной архитектуры?
Л. Более того, точность и структура вашей организации, матрицы ответственности и тем более стоимостное разбиение работ, cost breakdown structure, априори всегда либо менее точны либо равны по точности определенности ваших технических решений.
Т. Это да. Меня, как руководителя проекта, всегда веселило, когда от меня менеджмент требовал бюджетов более точных, чем у меня было техническое решение. Теперь возвращаемся к итерациям. От чего зависит количество итераций и при чем тут архитектор?
Л. От качества коммуникаций. Качество коммуникаций определяется тем, насколько быстро и эффективно, насколько терминологически согласованы у вас документы, которые вы обсуждаете. Насколько хорошо проработан язык проекта. Так называемый ubiquitous language или project language, словарь проекта и так далее. Это большой кусок работы архитектора, который он делит обычно с системным аналитиком. По сути ведение глоссария, само ведение - это роль системного аналитика, а вот способ наполнения глоссария, способ выявления  концептов, сущностей и их определение - это методическая роль системного архитектора.
Т. А что мы подразумеваем под коммуникацией? Классический ППР или все-таки коммуникацию в прагматическом плане, что в ней должно быть что-то содержательное?
Л. Из моей практики видно, что если результатом коммуникации должны быть взятые на себя обязательства, планы или решения. В противном случае это не коммуникация, это что-то другое, это какое-то бесполезное времяпровождение, которое проект дальше по жизненному циклу не продвигает. Такое общение не ведет к успеху проекта.
Т. То есть коммуникация - это принятые решения и планы каждой из сторон, которая участвует в коммуникациях, по тому, как это решение будет реализовано?
Л. Да, это как раз про движение по жизненному циклу, уточнение "серого" ящика в сторону "прозрачного" и только когда такое уточнение необходимо, нужна коммуникация. Если у меня существует неопределенность, которую я не в состоянии снять сам, я спрашиваю других, что с этим делать. Вот у меня есть неопределенность, ее надо снимать. 
Т. То есть системный архитектор - это такой mastermind, который соединяет разных людей и способен их скоммуницировать так, чтобы они приняли решение, которое взялись бы дальше исполнить?
Л. Да, в том числе. Это человек, который владеет своей экспертизой в какой-то предметной области очень глубоко, он погружен в "предметку" того контекста деятельности, которую он осуществляет, то есть, например, если он создает метеорологические системы, он должен иметь опыт работы с информационными системами, метеорологическими системами и службами, понимать процессы, которые в них происходят. Если такого опыта нет, то ему будет крайне сложно предоставлять качественные технические решения и интегрировать команду вокруг своих методов работы и описаний. 
Т. Тогда сразу появляется вопрос, а с каких позиций в проекте можно вырасти в системного архитектора, а из каких нельзя?
Л. На практике выходит примерно следующее. Если у человека есть техническая экспертиза и он ее готов углублять до осознанного уровня применения, то вырастить можно практически из любого человека. Но если у человека есть только теоретическая база, например, экономическая, аналитическая, управленческая, то качественных системных архитекторов из таких людей, как правило, не выходит. Хорошие архитекторы выходит из ведущих разработчиков, из саппорта, из инженеров по эксплуатации, ну и так далее, то есть из тех людей, которые выполняли какие-то конкретные объемы работ, представляют конкретные стадии жизненного цикла, что должно быть на входе, что должно быть на выходе и какой контекст существует, в каких терминах можно общаться с командой. 
Т. "Контекст" имеется в виду контекст конкретной организации? Или можно нанять такого человека с рынка, хорошего разработчика, и выращивать из него системного архитектора?
Л. Я думаю, что последнее. Можно найти на рынке людей, которые будут хорошо ориентироваться и хорошо входить в предметную область деятельности компании и выстраивать траекторию их личного роста внутри компании в сторону системного архитектора.
Т. Что-нибудь еще можешь сказать по этому поводу? Как собеседовать таких людей, где их искать?
Л. Искать в первую очередь стоит не через кадровые агентства и не на рынках, а внутри профессиональных сообществ. То есть мы говорим про какую-то сферу банковских услуг и мы знаем, что у нас в стране есть четыре десятка людей, которые занимаются архитектурой в банковском и финансовом секторе, они все друг-друга знают, поскольку банки - это не такая обширная сфера. Мы можем к ним прийти, и через этих людей, через площадки их профессионального общения имеет смысл искать кадры для подготовки системных архитекторов в сфере банковских услуг. Если мы говорим про айтишную сферу, про продукты масс-маркет, то тут ситуация чуть проще, можно таких ребят выращивать на стартапах. Они буду понимать предметную область продукта, который вы создаете, и предметную область услуги, которую вы оказываете своим продуктом. Из таких стартапов тоже могут выйти качественные системные архитекторы. Но еще раз повторюсь, что архитектор очень редко бывает сразу "с колес" готов к полноценной работе в текущем производственном процессе. Это обязательно человек, который должен понимать, как методически устроен ваш коллектив, какие там есть процессы коммуникации внутри, какие процессы коммуникации должны быть для создания определенной системы или класса систем, если вы создаете новый продукт и иметь сильную техническую экспертизу, чтобы не попадать впросак на простых вещах.
Т. Ясно. Это было кратко и содержательно, спасибо тебе.
Л. На здоровье.

Что почитать по теме?
Model‐Based System Architecture
Author(s): Tim Weilkiens Jesko G. Lamm Stephan Roth Markus Walker

First published:21 September 2015
https://onlinelibrary.wiley.com/doi/book/10.1002/9781119051930
Documenting Software Architectures: Views and Beyond, Second Edition
Felix Bachmann, Len Bass, Paul C. Clements, David Garlan, James Ivers, Reed Little, Paulo Merson, Robert Nord, Judith A. Stafford
https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=513862
System Architecture: Strategy and Product Development for Complex Systems
by Edward Crawley Bruce Cameron Daniel Selva
https://www.amazon.com/System-Architecture-Strategy-Product-Development/dp/0133975347