Методологическая действительность и действительность предпринятия

Когда мы обсуждаем деятельность, дисциплины, практики — это обсуждение "вообще", не относимое к конкретному проекту, начинанию (предпринятию). Говорят о "методологической действительности/реальности" (не будем отвлекаться на тонкие философские нюансы отличия действительности от реальности), в которой идёт это "обсуждение вообще". Мы описываем деятельность, но пока ничего не делаем. Мы описываем, как оно бывает “вообще”, говорим о типах и классах предметов, но не о самих предметах из реальной жизни. Эти типы и классы предметов в тачку не положишь, ногой не ударишь — это абстрактные объекты.

В "реальности предпринятия" обсуждаются уже конкретные объекты и дела этого предпринятия (так называемые “индивиды”, individual — которые можно ударить ногой, или погрузить в тачку, т.е. которые имеют протяжённость в пространствевремени).

Так что какая-нибудь “сборка газодинамического подшипника” может быть описана два раза: в методологической действительности (как вообще собирают такие подшипники) и в действительности предпринятия (как собирается конкретный подшипник с серийным номером №123456).

Семь основных альф инженерного проекта

Основы системной инженерии: альфы инженерного проекта

Основы (kernel из OMG Essence) включают в себя семь альф трёх дисциплин. Все эти альфы тесно связаны друг с другом, на диаграмме приведены лишь некоторые основные связи. Нужно чётко понимать, что представление инженерного проекта через эти основные альфы — это существенное огрубление реальности. Но именно это огрубление реальности позволяет из “цветущей сложности” выделить главное, на чём нужно будет сосредоточить мышление — какие-то детали при этом неизбежно потеряются, но ситуация “слона-то я и не заметил” будет встречаться реже. В каждом инженерном проекте минимально нужно отслеживать семь альф в трёх дисциплинах, меньше объектов внимания и дисциплин работы с ними иметь нельзя.

Это отслеживание и работа по изменению всех семи основных альф происходит в течение всего проекта. Когда в проекте происходит “пожар”, люди работают по ночам и всё внимание уделяется провальной составляющей проекта, знание этого простого факта — необходимости удержания во внимании всех семи альф на протяжении всего проекта — позволяет уберечься от “глупых ошибок”.

Стейкхолдеры

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

Стейкхолдеры — это “действующие лица” как в театре) проекта, а исполнители этих ролей — конкретные люди и организации. Мы назовём это “театральной метафорой”, при работе со стейкхолдерами всегда нужно помнить формулировку из театральной программки: “действующие лица и исполнители”. Нельзя путать “архитектора” и “Василия Петровича” — так же нельзя, как нельзя путать “принца Гамлета” и исполняющего его роль “Василия Петровича”.

Стейкхолдеры условно делятся на “внешних” и “членов команды”. Стейкхолдеры дают возможности (opportunity) для проведения инженерного проекта: если проект никого не затрагивает (никому не нужен), то его попросту невозможно делать. Если команда может делать проект, но пользователям он не нужен, то такого проекта не будет — разве что члены команды будут работать бесплатно, и будут исполнителями также и других ролей (инвесторов, владельцев, пользователей, клиентов и т.д.).

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

Простейший рабочий продукт, отражающий альфу “стейкхолдеры” — это список стейкхолдеров. Из информационных систем со стейкхолдерами работают CRM

(customer relationship management).

Специально нет никаких особых дисциплин, которые позволяют работать со стейкхолдерами, но можно выделить:

●Конфликтологию (например, метод “принципиальных переговоров” или “гарвардский метод” — найдите в Сети литературу по этому вопросу), чтобы снимать противоречия между требованиями различных стейкхолдеров.

●Коммуникации (communications) для налаживания продуктивного диалога со стейкхолдерами

●Особые техники представления стейкхолдеров (например, “метод персонажа” из книги Алана Купера “Психбольница в руках пациентов” — http://rutracker.org/forum/viewtopic.php?t=1227489, который обобщается с пользователей на любых других стейкхолдеров — http://praxos.ru/index.php/%D0%98%D0%B4%D0%B5%D0%B0%D0%BB%D1 %8C%D0%BD%D1%8B%D0%B9%D0%90%D0%BA%D1%86%D0%B8%D0% BE%D0%BD%D0%B5%D1%80).

Возможности

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

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

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

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

Из задействуемых для изменений в состоянии возможностей дисциплин нужно указать прежде всего:

●Маркетинг и продажи, стратегирование и предпринимательство — для установления user needs;

●Управленческий (финансовый) учёт — для обоснования прибыльности.

Конечно, в возможностях важны не только нужды/потребности/ожидания пользователей (user needs), но и нужды/потребности/ожидания и остальных стейкхолдеров. Как вы помните, успешная система (точнее, воплощение системы)

— это та, которая реализует возможности, т.е. отвечает нуждам/потребностям/ожиданиям стейкхолдеров инженерного проекта.

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

Определение системы

Перед тем, как сделать любую систему, её нужно определить (define), ибо нельзя сделать то, что “неопределено” (задача “пойди туда, не знаю куда, найди то, не знаю что” — это больше ведь исследовательская задача, а не инженерная. Чтобы воплотить в нашем четырёхмерном пространстве-времени какую-то систему, нужно как минимум иметь представление об этой системе, “определить” её). Альфа “определение системы” (system definition) служит как раз для этой цели.

У альфы определения системы (system definition) главные подальфы (части) прежде всего:

●Требования (описание назначения системы в её операционном окружении. Требования определяют систему как “чёрный ящик”)

●Архитектура (набор ключевых инженерных решений/decisions по тому, как будет устроена система — описание “прозрачного ящика”. Изменение каждого из архитектурных решений на поздних стадиях проектирования

ведёт к существенному перепроектированию всей системы).

●Неархитектурная часть проекта (все остальные решения/decisions, т.е. изменение которых на альтернативные не приводит к существенному перепроектированию всей системы)

С определением системы работает прежде всего наука: если какая-то часть системы (или аспект системы) определены, то это означает, что выбран соответствующий метод описания. Наука — это как раз про создание методов описания. Научное знание позволяет определять системы, описывать их в рабочих продуктах — описаниях (descriptions). Но, конечно, определять и описывать системы можно и на основе эвристик, не прибегая к научному знанию. Более того, переход от определения системы (идеального объекта) к описанию системы (материальному объекту) возможен с использованием нотационной инженерии — т.е. для записи определения системы как “мыслей по поводу системы, свойств системы” можно создать инженерный артефакт: нотацию.

Итого: определение системы — это про биты, про информацию, про то, как мы говорим о системе.

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

Альфой определения системы занимается системный инженер. Основной рабочий продукт – это описание системы, чаще известный как «проект системы» (design), часто бьётся на множество отдельных документов, баз данных, презентаций, докладных записок, цитируемых стандартов и даже физических макетов.

Воплощение системы

Воплощение системы (system realization, буквально: вынос в реальность) — это четырёхмерное воплощение системы в нашем материалом мире, это про организованные в пространстве-времени хитрым образом вещества и поля, атомы (а не биты!). Это не про информацию о системе, это сама система. Конечно, воплощение системы будет называться везде по-разному:

●У конструкторов это чаще всего “изделие” или “продукт” (product)

●У проектантов это часто “установка” (plant)

●У проектантов очень крупных объектов (например, атомных станций) это “сложный инженерный объект”

Мы принимаем, что когда мы пишем название системы (”насос”), то мы имеем тут ввиду сам насос как он есть в реальном мире, а не описание насоса (рабочий продукт определения системы).

Пользователям прежде всего нужно воплощение системы, для получения воплощения системы и создаётся инженерный проект.

Очень часто говорят об инженерном проекте по созданию сервиса — например, “сервис стрижки волос”. Но это не должно смущать: на самом деле это не проект по созданию сервиса, а проект по созданию системы, оказывающей сервис, например, “парикмахерская”, которая будет оказывать “сервис стрижки волос”.

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