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

Минимально жизнеспособный желтый, минимально жизнеспособная любовь, минимально жизнеспособный принцип Гейзенберга. Что не так с этими терминами? К абстракциям неудобно применять понятие жизнеспособности. Можно, конечно, сказать, что идея нежизнеспособна или подход неприменим к данной ситуации, но смысл такого выражения все равно будет далек от точного смысла концепции 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 альфам" может заключаться в прохождении этих чек-листов на еженедельных встречах команды с записью поручений в протокол встреч.

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

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