Часть 1. Тренировка на салфетках
Глава 1. Разделение зон ответственности
Давайте представим, что вы попали в новую организацию, и вам предстоит выполнять какую-то новую работу. Первым делом, вы понимаете, что ваша должность не имеет ничего общего с теми задачами, которые вам реально нужно решать в этой организации. Например, вы устроились на должность системного аналитика в ИТ-компанию. В лучшем случае, вас попросят первые три месяца доделывать прошлогодние отчеты по каким-нибудь псевдопроектам, потому что ни у кого не доходят руки. И вообще, дело понятное, что удел новичков – залатывать дыры.
Работа над прошлогодним отчетом, впрочем, как и любая другая работа, падающая на плечи новичка, является отличным поводом к моделированию вашей организации. На языке системной инженерии – вы имеете ценнейшее время, чтобы определить обеспечивающую систему для будущих проектов, то есть ту систему, которая будет, например, проектировать и воплощать целевые системы.
Целевой системой будем называть тот конечный продукт, подлежащий эксплуатации, за работу над которым инженерным организациям платят деньги или выдают еду (в зависимости от места работы).
В начале пути вам никто не скажет «спасибо» за модель организации как обеспечивающей системы. Основная польза от этой работы заключается в разделении зон интересов членов команды, как стейкхолдеров.
Присутствуя на периодических совещаниях, вы скорее всего заметите, что руководитель проекта очень часто берет на себя роль системного архитектора, продавца и даже заказчика. Системный архитектор порой ведет себя как менеджер. А еще иногда приходит какой-нибудь заместитель директора, который к проекту относится очень условно, и начинает констатировать конструкторские решения, потому что он человек опытный.
Присутствие различных стейкхолдеров на совещании – это, действительно, очень хорошо, но только в том случае, когда они свою «стейкхолдерскую» роль осознают и не играют других ролей, и другие им не потакают. Замдир может своим авторитетом полностью перегнуть палку, в результате чего вся команда согласиться на совершенно непродуманное решение, а сам этот замдир, в силу своей занятости, на совещаниях в ближайшие полгода не появится. В большинстве случаев может оказаться, что он, вообще, стейкхолдером не является.
Если у вас в команде есть системный архитектор, то конечное решение о системной архитектуре принимает именно он, а не коллективный разум программистов. На деле мы всегда наблюдаем такую картину, что рядовые инженеры с удовольствием готовы порассуждать над вариантами архитектуры. И вот эти самые абстрактные рассуждения, иногда претворенные в бумажных почеркушках, и любят называть системной архитектурой.
Мы будем говорить, что системная архитектура – это принципиальные инженерные решения, изменение хотя бы одного их которых приводит к существенному изменению всей конструкции.
Если двигатель внутреннего сгорания в автомобиле заменить на электрический двигатель, то менять надо практически всё. Поэтому системная архитектура часто представляется в виде структуры принципиальных решений, поскольку одни изменения тянут за собой другие.
Другим примером ролевой болезни в инженерной практике является изображение из себя заказчика. Часто этим заболеванием страдает руководитель проекта. Опять-таки, умение руководителя интерпретировать потребности заказчика – важнейшая составляющая успеха проекта, но злоупотребление этим прекрасным умением приводит на практике к тому, что заказчика и вовсе перестают спрашивать о чем-либо, а еще чаще, просто, со временем забывают о его существовании, дистанцировавшись огромной бюрократической машиной. Тем временем, присутствие реальных представителей заказчика на ключевых совещаниях по проекту могло бы существенно снизить риски, и не позволить впасть в придумывание чужих потребностей, чем так часто болеют инженерные команды.
Если вы решились взять на себя роль системного инженера, придется помогать всем остальным ролям «не выходить из себя», то есть из роли. Итак, вам следовало бы первым делом завести табличку, в которой каждому сотруднику из штатного расписания, с которым приходится совместно работать ставились бы в соответствие те роли, которые сознательно или несознательно взяли на себя эти люди во всех проектах, в которых они принимают участие. Из этой таблички будет видно, какие роли в каких проектах представлены минимально. По иронии судьбы так часто получается, что, например, роль менеджера проекта зачастую представлена хуже всех, потому что сам менеджер любит хвататься за все задачи подряд, забывая свою основную компетенцию. В итоге страдает командный дух, сроки нарушаются, бюджеты превышаются. Исходя из ситуации в вашей компании, вы могли бы постепенно занять самую критичную роль в соответствии со своими полномочиями. Такой шаг дает быстрый результат: проекты разгружаются, эффективность работы растет, настроение поднимается, в том числе у руководства.
Ниже пример таблицы, которая может получиться в результате. Не надо пугаться, на практике в проектах, к сожалению, бывает по 3 менеджера, 5 архитекторов и 1 программист.
Таблица 1. Неудачный (как обычно бывает) вариант распределения ролей в текущих проектах
Не надо думать, что проблема в неправильном назначении ролей. Менеджер, вполне возможно, все правильно распределил. Проблема в том, что на деле сотрудники берут на себя совсем иные роли, чем было предусмотрено.
Когда менеджер проекта начинает на совещании предлагать системно-архитектурные решения, то он играет роль системного архитектора – не свою. Учитывая, что время ограничено, то, скорее всего, такой менеджер не успеет полностью отыграть свою роль, в результате чего сорвутся сроки.
Ниже приведена другая таблица распределения ролей. Если вам со временем удастся добиться такой организации команды, будет здорово.
Таблица 2. Удачный вариант распределения ролей в текущих проектах
Работа системного инженера начинается с упорядочения среды, в которую он попал. Чтобы сформировать целостное представление о системе, которую вам предстоит делать, надо, прежде всего, четко разделить зоны ответственности членов команды проекта. Это нужно сделать сначала в своей голове, а потом в действительности. Необходимо следить за тем, чтобы каждый член команды «играл» свою роль. Здесь вам потребуется деликатность и лидерство, а также поддержка руководства. По моему скромному опыту (и богатому опыту моих коллег), большинство срывов проектов связано именно с конфликтами на почве зон ответственности. Системный инженер, являясь посредником между менеджерами и различными специалистами, должен следить за тем, чтобы члены команды действовали в соответствии со своими ролями, но делать это так, чтобы никого не обидеть и не разозлить.
Даже если вы предлагаете рациональные решения, кто-то обязательно будет «против», потому что затрагиваются его интересы. Кто-то из стейкхолдеров (среди которых всегда есть и члены команды проекта) имеет определенного рода интерес, чтобы всё было именно так «как есть». А еще именно этот стейкхолдер обычно старается сделать так, чтобы остальные не смогли увидеть ситуацию в целом. Это может касаться чьих-то скрытых доходов или того хуже.
Прежде чем браться за дело, нужно взвесить все интересы вокруг. На первом этапе не надо никому ничего доказывать. Главное, что надо сделать – понять, существует ли возможность реализовать успешную систему в рамках проекта или в будущем (на основе результатов вашего проекта)? Если такая возможность есть, то системный инженер должен эту потенциальную систему четко определить. Она, скорее всего, будет существенно отличаться от заявленной в исходном техническом задании.
Репутация системных инженеров складывается из успешных и провальных систем, которые были реализованы в результате их деятельности.
Если ваша система изначально не имеет шансов на успех из-за чьих-то интересов или их отсутствия, либо эти шансы очень малы… решать вам. Обеспечивать проект тоннами документации, в которой невозможно разобраться, – не самая привлекательная перспектива. Поэтому давайте сразу договоримся, что тут мы будем говорить именно про инженерные проекты, а не про бумажные.
Вот на совещание пришел заместитель директора по проектам и начал доказывать системному архитектору системы, что надо все переделать, потому что много инноватики. У компании, по мнению замдира, достаточно опыта, чтобы решать задачу проверенными классическими методами. Если вы обратитесь к нежданному гостю с вопросом: «А какая твоя роль в проекте?», – он может быть фраппирован. Вся команда должна понимать, что человеку иногда надо выговориться. Возможно, имеет смысл искать полезную политическую информацию между строк. Потом всегда можно составить протокол, зафиксировать предложение и обосновать на бумаге отказ с подписью технического директора, например. К сожалению, такое бывает. Да, на это приходится тратить время.
Вы заметили, что представители заказчика не интересуются вашим проектом: не звонят, не ругаются? Это верный признак того, что им этот проект не нужен.
Возможно, у кого-то из партнеров внезапно оказались неосвоенные деньги, а вашей компании перепало оказаться каналом их освоения. Конечно, никто ничего не успел толком согласовать, поэтому интерес у стейкхолдеров весьма формальный, однако для вашей организации это отличный способ инвестировать в молодые кадры. Этот проект можно доверить неопытным специалистам. Хорошо организованная команда молодых специалистов может даже из такого «заброшенного» проекта получить пользу. Возможно, это будет какая-то инновационная разработка. Может быть, удастся отработать «слабые места» технологии. Там, где другие видят проблему, постарайтесь разглядеть возможность.
Если вас достают звонками – это нормально. Если все время требуют что-то – это очень хорошо. Значит, скорее всего, заказчик заинтересован в результате, и система будет эксплуатироваться. Значит, вы работаете не зря. Значит, надо проявить максимум своих компетенций.
Разделяйте зоны ответственности команды проекта и зоны интересов стейкхолдеров, чтобы понимать, какая реальная задача перед вами стоит, и сколько ресурсов вы реально можете в нее вложить.
Глава 2. Потребности и требования
Предположим, ваш срок «устаканивания» в компании прошел за 3 месяца, и теперь вам доверили поучаствовать во вполне себе реальном проекте. Ваша компания решила сделать новый продукт – умный дом, а вам предложили поучаствовать в этом проекте в качестве системного аналитика.
Для начала вопрос – что должен делать системный аналитик? Что является результатом его работы? Не факт, что вам кто-то будет объяснять, что, собственно, от вас требуется. И не факт, что обязанности системного аналитика в предыдущих «учебных» проектах будут как-то коррелировать с новыми обязанностями в реальном проекте, где на кону – деньги и репутация компании. Я бы на вашем месте не задавал никому подобных вопросов, а начал тщательно разбираться со стейкхолдерами, их потребностями и требованиями.
Потребности и требования – принципиально разные понятия. Сначала, надо разобраться, какие стейкхолдеры есть у системы с рабочим названием умный дом. Нас пока даже не должно интересовать, что это такое – умный дом. Вопрос исключительно в стейкхолдерах.
Называть стейкхолдеров нужно в честь их роли относительно целевой системы.
Не путайте с ролью в проекте, должностью, названием организации, ФИО и чем-угодно другим. Роль относительно целевой системы должна быть однозначно интерпретируемой, подразумевая конкретный интерес. Например, стейкхолдером может быть: инвестор, заказчик, пользователь, сервисный инженер, но не может быть: Константин Константинович, ООО «яКомпания», начальник отдела сбыта.
Самое главное – не путайте заказчика проекта и заказчика целевой системы.
Вспомните определение системы из введения и отметьте для себя, что заказчик целевой системы – это тот, кто просит собрать/поставить целевую систему в ее физическом воплощении (обычно еще на определенной территории). Заказчиком проекта может быть ваша же ИТ-компания в лице директора, который вкладывается в разработку и производство опытных образцов. Как правило жизненный цикл проекта значительно короче жизненного цикла системы. Поэтому, чтобы не запутаться между проектами, стейкхолдеров надо называть в честь ролей относительно целевой системы на всем ее жизненном цикле. Не менее важный момент заключается в том, что за проект не всегда платит заказчик. Инвестировать работы может совершенно другая организация или несколько организаций с разными интересами. Начать можно с таблицы.
Таблица 3. Стейкхолдеры целевой системы с рабочим названием умный дом
На самом деле стейкхолдеров гораздо больше, но не надо думать, что вам удастся сразу составить полный список. Уточняйте список по ходу работы. Тем более, пока вы не начали прямые контакты с людьми, все эти списки являются лишь заготовкой, которая может помочь вам составить список вопросов для проведения интервью или модерации совещания. Реальное положение дел может оказаться совсем не таким, как вы думаете сейчас.
Есть некий потенциальный собственник, который желает улучшить свой дом (пока не понятно, какой дом) – имеем определенного рода спрос. Ваша ИТ-компания желает выйти на этот новый рынок, поэтому готова вложиться в разработку. У компании есть партнеры, которые могут поставлять комплектующие. Есть программисты, готовые реализовать алгоритмы поведения системы. Есть необходимые специалисты для сборки, монтажа и обслуживания системы. Имеется также коммерческая структура, способная обеспечить продажи системы. В этом контексте главным источником информации о потребителе будет стейкхолдер-продавец (СХ7), но забывать об остальных стейкхолдерах категорически нельзя.
Рассматриваемая ситуация может показаться очевидной, но могла быть другая. Заказчиком умного дома и проекта в одном лице мог быть вполне конкретный человек (например, автоматизация конкретного дома под заказ). Тогда не нужно было бы делать предпродажную работу, исследовать рынок. Жизненные циклы таких двух проектов существенно отличаются.
Начинается первая и самая непредсказуемая часть разработки – определение границ системы. Вам надо дать системе название.
В системной инженерии принято называть систему по основной функции, которую она выполняет.
Как известно, система выполняет функции на стадии эксплуатации. Какую главную функцию выполняет умный дом?
Очень часто проекты называют беспредметно и абстрактно. Часто приходится слышать такие названия проектов как «Система управления сервисами платформы того-то» или «Сервис управления системами сего-то». Чаще всего целью проекта является разработка какого-нибудь маленького модуля, а в названии пишут чуть ли не «Разработка системы управления миром».
Система, которую заказал директор, совсем не дом. Насчет «ума» у меня тоже есть сомнения. Речь идет, скорее всего, о датчиках, контроллерах, каких-то управляющих механизмах, проводах, компьютерах и ИТ-коммуникациях. Все это вместе в одной коробке – умный дом. На деле это автоматизированная система управления освещением, тепловым оборудованием, звуковым оборудованием или чем-то еще в этом роде. Вряд ли кто-то сможет сразу ответить нам на вопрос, чем эта система должна управлять. В такой ситуации я бы предложил начать с формулирования потребностей.
Анализ потребностей мог проводиться ранее отделом маркетинга. Результатами этой работы нельзя пренебрегать. Порой очень ценная информация о потребностях стейкхолдеров есть у директора и топ-менеджеров компании. Потребность, на начальном этапе, будем определять через выражение следующего вида:
Я, как <стейкхолдер>, хочу <потребность>, потому что <проблема>.
Например, я, как владелец умного дома, хочу меньше платить за электричество, потому что сейчас приходится платить слишком много из-за неэффективно использующегося оборудования, например, ночью.
Коммерческий отдел или отдел маркетинга вряд ли будет формулировать потребность именно в такой форме. Ваша задача, как системного инженера, привести к одной форме все потребности. Однако надо учесть, что коммерсанты могут перевернуть вам представление о проекте в один счет.
На очередном совещании выясняется, что спрос на системы типа умного дома резко вырос у бизнес-центров. Этот рынок достаточно новый и большой. Вопрос заключается в том, есть ли принципиальная разница между умным домом для коттеджа и для бизнес-центра? Вероятно, потребности стейкхолдеров умного бизнес-центра будут значительно шире. Ценник будет отличаться, возможно, на порядок. Требования будут значительно жестче. Тем не менее, если бизнес-центр научится экономить ресурсы, оставив стоимость арендной платы на прежнем уровне, это позволит увеличить прибыль.
Обычно выявлением потребностей занимаются отдельные специалисты. Системный инженер должен структурировать потребности относительно стейкхолдеров системы (простейшая форма дана выше), а затем для каждой потребности сформулировать набор требований. Требование формулируется относительно самой системы или ее элементов.
Потребность должна оставаться актуальной вне зависимости от целевой системы.
Пользователь хочет платить меньше независимо от существования умного дома. Требование актуально относительно целевой системы и ее элементов. Будем использовать следующую переходную конструкцию от потребности к требованию:
Я, как <стейкхолдер>, считаю, что система должна <требование>, чтобы <потребность>.
Например, я, как владелец умного бизнес-центра, считаю, что система должна автоматически выключать кондиционеры после часа работы в пустых помещениях, чтобы мне меньше приходилось платить за электричество.
Итак, вам понадобится для старта набор базовых потребностей, чтобы понять, какую систему предстоит сделать. Потом вы сможете задавать стейкхолдерам правильные вопросы, чтобы сформулировать требования. Повторюсь, что стейкхолдеры будут формулировать потребности и требования как-угодно, только не по форме. Приведение к форме – задача системного инженера. Слова, которые произносит стейкхолдер в ответ на ваши вопросы, можно называть по-разному в зависимости от ситуации: интервью, лозунги, протокол, стенограмма и др.
Требования бывают очень разные, но все они начинаются одинаково: «Система должна…». В разных отраслях промышленности требования группируют по-разному (требования к назначению, к показателям функционирования, к функциональным характеристикам, к безопасности, к защите интеллектуальной собственности, к документации и т.д.). Иногда выделяют еще ограничения. Они отличаются от обычных требований тем, что направлены на внутреннее устройство системы, то есть на системную архитектуру или того конкретней. Нет ничего хорошего в том, что стейкхолдер настаивает на определенных ограничениях. Системный инженер должен стараться эти ограничения снять в процессе переговоров и согласований. Однако, бывают ситуации, когда ограничения снять нельзя. Например, как в нашем случае с умным бизнес-центром. У нас есть стейкхолдер – поставщик комплектующих. Соответственно, уже на начальном этапе известен список возможных комплектующих, из которых нам предстоит собирать систему.
Итак, допустим, что в результате переговоров с коммерческим отделом и другими стейкхолдерами, вам удалось сформулировать следующие потребности (таблица 4). Очевидно, что контекст этих потребностей пока еще очень размыт. Тем не менее, не бойтесь делать различные описания системы. Со временем они будут становиться более строгими и конкретными.
Таблица 4. Потребности стейкхолдеров системы с рабочим названием умный бизнес-центр
Для каждой потребности необходимо предложить сценарии использования системы, по которым можно будет судить об удовлетворении потребности, а также о степени удовлетворения, если необходимо. Именно сформулированные потребности помогают системному инженеру спланировать валидацию системы, например в рамках приемочных испытаний. На практике я часто встречался с ситуациями, когда проверочные и приемочные испытания представляли собой примерно одно и то же, поставленное в календарном плане друг за другом. Сейчас, когда вы формулируете потребности и требования, давайте зафиксируем:
систему верифицируют на соответствие требованиям (на проверочных испытаниях), а валидируют (например, на приемочных испытаниях или еще до них) систему на предмет удовлетворения потребностей.
Если системному инженеру удается обосновать целесообразность проекта набором непротиворечивых потребностей/проблем, заставляющих стейкхолдеров проявлять активность, значит можно идти дальше. Чаще всего идея приходит внезапно, поэтому на практике целесообразность нового проекта доказывают уже постфактум с помощью анализа потребностей, хотя, казалось бы, логичнее формулировать идею проекта исходя из предварительного анализа потребностей, то есть наоборот.
Остановимся на потребности (П1) – меньше платить за электричество и водоснабжение. Важной способностью системного инженера должно быть сценарное (или алгоритмическое) мышление. Можно выделить несколько основных видов мышления по времени приложения: рассуждения о настоящем времени; рассуждения о прошедшем времени; рассуждения о будущем времени. Думаете, это все? Можно еще рассуждать о прошлом из прошлого, о прошлом из будущего, о будущем из прошлого и т. д. Успешный системный инженер должен думать во всех временах с одинаковой изворотливостью и быстротой.
В прошлом, владелец бизнес-центра переплачивал за электричество и водоснабжение, потому что арендаторы неэкономно пользовались ресурсами. Арендная плата учитывала возможные переплаты, но сейчас настали тяжелые времена, поэтому необходима оптимизация расходов, иначе бизнес может стать убыточным. Если владелец бизнес-центра купит и внедрит целевую систему, то фактические затраты на электричество и водоснабжение сократятся, следовательно, при сохраненной арендной плате владелец сможет получать дополнительную прибыль с арендаторов. Первый вопрос заключается в сроке окупаемости целевой системы. Второй вопрос – какие конкретные функции должна выполнять система, чтобы сокращать затраты? Этот вопрос адресует нас напрямую к требованиям.
Таблица 5. Требования владельца и пользователя системы (СХ1) для потребности (П1)
Вариантов требований может быть очень много. Можно вспомнить про парковки, про влажность воздуха, про авторегулирование освещения и многое другое. Требования всегда имеет смысл ранжировать. Уровень важности того или иного требования может оценить каждый стейкхолдер. При этом, каждый стейкхолдер может быть «по секрету» взвешен, на предмет собственной важности. Снимать требования в зависимости от их низкого ранга «просто так», конечно, нельзя. Но так легче понять, какие требования можно вынести на обсуждение со стейкхолдерами, как необязательные. А уже потом – убрать.
Требованиям должна в конечном итоге соответствовать реализация, поэтому даже в начале проекта необходимо иметь некоторое представление о вариантах архитектуры системы. Это во многом ограничивает требования и их фокусирует.
Всегда фиксируйте каждое новое требование в процессе работы над проектом. Когда новые требования начнут противоречить исходному техническому заданию – идите к менеджеру. Это очень серьезная проблема, которую нельзя игнорировать.
Составьте список стейкхолдеров целевой системы, определите их реальные потребности в ходе переговоров, маркетинговых исследований, консультаций с экспертами. Отталкиваясь от потребностей, вы сможете точнее формулировать требования к системе и быстрее согласовывать их со стейкхолдерами.
Глава 3. Функциональное моделирование
Сбор и анализ требований будет гораздо эффективнее, если кроме «послойного осаждения» в документации, они еще отразятся в функциональной модели системы.
Иногда о функциональной модели говорят: «Взгляд снаружи внутрь». То есть, в какой-то мере, функциональная модель представляет собой структуризацию и уточнение требований до той степени, когда не возникает вопросов, что именно должна делать целевая система. Давайте попробуем нарисовать функциональную модель системы умный бизнес-центр. Для этого нам необходимо назвать ее основную функцию. Мы снова вернулись к этому вопросу. Можно было бы нарисовать вот такую схему «на салфетке» (рис. 3).
Рис. 3. Контекстная функциональная модель системы управления потреблением электроэнергии и воды в бизнес-центре
Если мы напишем все функции системы через запятую в одном названии, то, фактически, мы словом «система» подменим, просто, некоторое объединение. На самом деле, мы будем проектировать в таком случае несколько разных систем, которые работают в некоторой связке: одна управляет электроэнергией, а другая – водоснабжением (может быть еще несколько аналогичных систем). Никакого системного эффекта здесь не просматривается. Можно было бы обобщить до понятия «ресурсы», но, опять таки, это обобщение не раскроет системного эффекта, возникающего при связанном функционировании перечисленных систем.
Еще одна неувязка заключается в том, что большинство требований относятся не столько к «коробочке с проводами», как мы охарактеризовали умный дом, сколько к некоторой инфраструктуре всего здания. То есть наших стейкхолдеров интересуют не сигналы управления на выходе, а конкретные действия по регулированию воды или электричества. Должен ли входить в нашу систему, например, кондиционер? И все-таки, кто же наши пользователи? Владельцы бизнес-центров, персонал, арендаторы или системные интеграторы, монтирующие «коробочку с проводами» в инфраструктуру здания? А может быть, мы должны проектировать всё здание «под ключ» вместе с умным бизнес-центром внутри?
Первый вариант, который мы рассмотрим, будет заключаться в укрупнении задачи. Давайте назовем функцией системы – поддержку комфорта в бизнес-центре (рис. 4). Таким ходом мы ставим себе задачу четкого определения термина «комфорт», вплоть до математической формулы. Для начала давайте декомпозируем комфорт, например, вот в такой кортеж:
Комфорт = <Температура воздуха, Влажность воздуха, Уровень автоматизации, Экономия>
Можно декомпозировать дальше:
Уровень автоматизации = <Включение и выключение эскалаторов, Автоматическая подача воды порциями и т.д.>
Когда мы знаем структуру, можно предложить различные математические критерии оценивания этого самого комфорта, например с помощью развесовки и суммирования. Каждый из субкритериев можно привести к нормализованному виду от 0 до 1, тогда задача оценки уровня комфорта не составит никакого труда. Но не будем углубляться в оценку – это предмет системного анализа, а не системной инженерии. Проблема в том, что поддержать тот или иной уровень комфорта система может только тогда, когда в неё входят приборы, взаимодействующие со средой, например, тот же кондиционер. Коробка с проводами сама по себе комфорт не обеспечивает – это не ее функция. Системный инженер должен обязательно обсудить с менеджерами такую проблему. Скорее всего, будет предложено не выходить за рамки идеи – коробки с проводами. Оборудовать здание кондиционерами, электроприборами и батареями – не совсем та задача, которую мы хотели решать сначала.
Рис. 4. Контекстная функциональная модель системы поддержки комфорта в бизнес-центре
Второй вариант функции системы (в сторону уменьшения задачи) – минимизация денежных расходов на ресурсы в бизнес-центре в реальном времени (рис. 5). Чем интересен этот вариант? Во-первых, в названии появились деньги. Мы говорим не о разных системах, которые регулируют разные ресурсы, а пересчитываем всё в деньги – тут просматривается системный эффект. Во-вторых, минимизация, как любая оптимизация, может решаться при заданных ограничениях, например, на тот самый уровень комфорта. Но для целевой системы не важно, что будет стоять за этими ограничениями. В-третьих, мы указали, что всё происходит в реальном времени, то есть целевая система не подводит итоги в конце квартала, чем мог бы заниматься рядовой специалист, а принимает и воплощает решения непосредственно в процессе потребления ресурсов. Такая формулировка уже наводит на мысль, что этим занимается компьютер, потому что, в противном случае, пришлось бы нанимать слишком много персонала и организовать их коммуникации с помощью, например, комплекта раций: один на электрощитке, а другой – у стояка и т. д. Обратите внимание, что, по сравнению с первой схемой, изменилось только название, но как принципиально это отразится на всей дальнейшей работе.
Рис. 5. Контекстная функциональная модель системы минимизации денежных расходов на ресурсы в бизнес-центре в реальном времени
Интуитивно может показаться, что сейчас самое время начать функциональную декомпозицию системы, чтобы понять, как она должна работать, но это не так. Я настоятельно рекомендую выполнить обратное действие – давайте представим функцию нашей системы в составе функциональной декомпозиции использующей системы, то есть той системы, которая использует целевую систему. Чтобы это сделать, надо понять – что есть использующая система? В русскоязычной литературе часто встречается термин «надсистема», но он мне не нравится, поскольку не задает «потолок» рассуждениям о границах. Мы будем говорить именно о той системе, которая использует целевую систему «умный бизнес-центр», то есть «коробочку с проводами», то есть «систему минимизации денежных расходов бизнес-центра в реальном времени». Судя по всему, использующая система и есть бизнес-центр, но какая у него функция?
Мы уже вели рассуждения о комфорте. Если немного переформулировать функцию, связанную с комфортом, получим неплохую формулировку для использующей системы – система поддержки комфортных условий для ведения бизнеса. Вполне логично, что для комфортного ведения бизнеса нужна близкая к комнатной температура, продуманное управление потоками людей, наличие санузлов, электричества и многое другое. Немаловажно – чтобы все это укладывалось в реалистичный бюджет. Было бы неплохо весь список этих условий включить в новый кортеж, характеризующий уровень комфорта. Он будет похож на предыдущий, но более полный, потому что мы теперь правильно определили системные уровни для поставленной задачи.
Основной критерий правильного использования функциональной модели – резкое ускорение процесса проектирования. Если у вас возникают трудности в разработке, вернитесь к функциональной модели. При этом неважно, занимались вы функциональным моделированием «на бумаге» или нет. Все равно в вашей голове есть какая-то функциональная модель. Нарисуйте то, что у вас в голове, используя один из формализмов функционального моделирования.
Что вы делаете? Систему, которая обеспечивает комфорт или систему, которая экономит деньги? Это же два абсолютно разных проекта. Какой бюджет у модернизации бизнес-центра, а какой – у создания «коробочки с проводами»? Самые частые ошибки в инженерных проектах, которые я наблюдал на практике, были связаны с неверными представлениями о функции целевой системы. Когда в голове «комфорт», а проект про «коробочку с проводами», будут большие сложности с принятием решений.
Итак, обратимся к использующей системе – бизнес-центру. Мы определили функцию использующей системы и можем выполнить функциональную декомпозицию следующим способом.
Определяем входные потоки:
– внешние условия, включая погоду, механические воздействия, городской шум и другое;
– ресурсы, приходящие к нам через инженерные коммуникации: вода, электричество, газ или еще что-то;
– запросы на сервисы – в любом бизнес-центре нужны санузлы, уборщицы или что-то более специфичное типа эскалаторов (сервис транспорта), центров печати.
Определяем выходные потоки:
– мы ожидаем, что здание обеспечит нам внутренний комфортный климат, огородив от внешней среды;
– мы ожидаем, что услуги/сервисы будут оказаны, в результате чего мы получим воду, напечатанные документы, поменяем местоположение и т. д.
Обращаю внимание, что рассуждение про потоки идет параллельно рассуждению о конструкции: здание, инженерные коммуникации, эскалаторы и т. д. То есть мы немного забегаем вперед, простраивая логическую архитектуру. Для системной инженерии это обычное дело, когда приходится перескакивать между разными точками зрения (частными методами описания), чтобы удержать в голове целостность системы. Для кого-то, возможно, было бы удобно нарисовать схему логической архитектуры уже сейчас в каком-то виде: показать стены, инженерные коммуникации, эскалаторы, санузлы и т. д. Я этого делать не буду. К логической архитектуре мы подойдем чуть позже. На данном этапе нам не столько важны варианты воплощения, сколько общая идея того, что происходит внутри использующей системы. Важно – использующая система пока существует без «коробочки с проводами».
Рис. 6. Функциональная диаграмма использующей системы без целевой системы (как есть)
Далее нам надо понять, какие изменения претерпевают потоки, пока они доходят от входа к выходу, и как они влияют друг на друга внутри использующей системы. Это творческая задача, требующая хорошей технической подготовки. Каждый факт изменения потока мы фиксируем в виде той или иной функции, которую использующая система должна выполнять, чтобы реализовать свою главную функцию. Так и получается декомпозиция использующей системы.
Это один из возможных способов. Более академический вариант – выполнить поиск аналогов, а также (что гораздо сложнее) найти описания функционирования этих аналогов, потом выбрать наиболее близкое к вашему случаю описание и представить его в виде функциональной модели.
Стейкхолдер (СХ1), то есть владелец бизнес-центра, хочет экономить. То есть хочет регулировать использование ресурсов так, чтобы ему это обходилось дешевле, а условия ведения бизнеса при этом держались на заданном уровне. Вставляем целевую систему в качестве новой функции и смотрим, что получилось (рис. 7). Будем целевую систему и потоки, связанные с ней, рисовать жирными линиями, чтобы смотрелось нагляднее. Введем идетификаторы для элементов: ПТ – потоки; ИС – использующая система; СОО – системы в операционном окружении; ЦС – целевая система, которую вы сейчас проектируете.
Рис. 7. Функциональная диаграмма использующей системы с целевой системой
Каждый поток, входящий или выходящий из использующей системы, может быть ассоциирован с потребностью.
Например, «ПТ3. Внешние условия» может быть ассоциирован с потребностью обеспечивать комфортные условия в условиях пустыни. «ПТ1. Запросы на сервисы» может быть ассоциирован с потребностью в определенном количестве людей, которых должен обслуживать центр. «ПТ2. Результаты сервисов» может быть связан с потребностями ускорения процессов, повышения качества. Условия среды в (ПТ6) сами по себе являются важной потребностью, ведь если мы просто будем экономить на всём, в бизнес-центре может стать, например, душно и жарко. Потоки (ПТ8) и (ПТ9), с одной стороны внешние, а с другой – относятся к целевой системе. Эти потоки могут быть связаны с потребностями сервисного обслуживания, то есть дополнительно – (СХ6) техобслуживание.
Требования к целевой системе мы можем теперь разделить на 4 группы:
– требования к управлению сервисами (Т2, Т3);
– требования к управлению средой (Т1, Т4);
– требования к мониторингу среды;
– требования к мониторингу сервисов.
В скобках приведены идентификаторы тех требований, которые мы уже писали ранее. Как видно, мы интуитивно заметили только две группы требований. Требования к мониторингу сервисов могут быть связаны, например, с количеством сервисов, которыми система должна управлять, типами сервисов и их результатов; это могут быть расстояния, время, частота получения информации и многое другое. Мониторинг среды также имеет свои особенности, например: количество точек сбора информации, конкретные измеряемые характеристики, периодичность измерений и многое другое.
Самое время определиться с тем, какие именно ресурсы и сервисы будут связаны с целевой системой. Это приведет к декомпозиции как самой функции системы, так и к декомпозиции потоков. Важно заметить, что каждый элемент схемы нуждается в спецификации, включающей как минимум:
– идентификатор;
– короткое название;
– полное название;
– входные параеметры;
– выходные параметры;
– иные функциональные связи.
У начинающих системных аналитиков часто возникает вопрос: «А когда нужно прекращать декомпозировать? Сколько уровней должно быть?». Если спецификация функции занимает меньше A4, значит её уже не надо декомпозировать. Еще вариант – если по спецификации можно найти и купить соответствующий модуль.
Когда функциональное описание использующей системы вместе со встроенной целевой системой будет закончено, нужно вспомнить, что было на рисунке 1. У нас есть первый вариант плана. Самое время оценить осуществимость такого плана. На данном этапе, конечно, рано выполнять подсчет затрат на весь проект. Требования совсем «сырые». Однако, имеет смысл пересмотреть список стейкхолдеров. В частности, существуют стейкхолдеры, связанные с системами в операционном окружении, от которых очень сильно зависит успех проекта. Как видно из рисунка 7, целевая система взаимодействует с системами обеспечения комфортных внутренних условий (вентиляция, отопление, увлажнение и проч.) и системами обеспечения сервисов (санузлы, эскалаторы, центры печати и проч.). Наша «коробочка с проводами» начнет использоваться только тогда, когда будет подключена ко всем требуемым системам в операционном окружении. Если отталкиваться от того, что валидация должна выполняться на предмет удовлетворения потребностей стейкхолдеров, то становится не очень понятно, как это сделать, когда система еще не встроена в использующую систему, но уже произведена и должна быть продана, чтобы компенсировать затраты на производство. Валидация, с точки зрения системной инженерии, возможна лишь в условиях эксплуатации (или максимально приближенных) и должна проводиться с участием пользователя и заказчика.
Если вы проектируете «коробочку с проводами», а ваша компания не планирует выполнять монтажные работы, потому что это другой бизнес, то, выходит, вы не можете гарантировать удовлетворение потребностей в рамках текущего проекта.
Получается, что успешность нашей системы зависит от того, как сработают еще две группы стейкхолдеров, относящихся к системам обеспечения сервисов и к системам обеспечения комфортных внутренних условий (среды). Это огромное количество различных стейкхолдеров, занимающихся эскалаторами, принтерами, кондиционерами, инженерной инфраструктурой, проводкой и т. д. Их то мы и забыли включить в таблицу 3. Надо это обязательно сделать. Тем не менее проблема зависимости от этих стейкхолдеров в вопросе успеха «коробочки» остается нерешенной. Как выполнять валидацию? Валидация – это практика жизненного цикла системы. Может быть, сейчас правильнее задать вопрос – а какой у целевой системы жизненный цикл?
Определите основную функцию целевой системы, выделяющую ее среди других систем в операционном окружении. Определите использующую систему, найдите стейкхолдеров на уровне использующей системы. Свяжите потребности с входами и выходами использующей системы, а требования – с входами и выходами целевой системы.
Глава 4. Жизненный цикл системы и проекта
Конечно, менеджеры к этому моменту уже должны были согласовать жизненный цикл, но есть ли в нем валидация? Обычно менеджеры без особых проблем решают организационные вопросы с помощью модели жизненного цикла. Часто его выбирают исходя из опыта управления и не ждут сюрпризов, но сейчас возникла ситуация, в которой успех целевой системы «повис на волоске» из-за неоднозначности приемки и валидации, а это, между прочим, непосредственно относится к модели жизненного цикла, то есть инженерные и менеджерские задачи теперь неразделимы.
Допустим вы пойдете к менеджеру проекта и попросите показать выбранную модель жизненного цикла. Самое частое представление, которое я наблюдал на практике в ИТ-компаниях, может быть изображено так (рис. 8).
Рис. 8. Типовой жизненный цикл проекта
Часто проект не любят официально заканчивать. Вообще, у нас понятие проекта иногда имеет под собой какой-то мистический смысл. Ну и, как следствие, есть путаница между жизненным циклом проекта и жизненным циклом системы. В результате, а где, вообще, в жизненном цикле – валидация целевой системы? Если бы всё было так просто – взять и перерисовать этот жизненный цикл – но проблемы заключаются в деньгах.
Каждая стадия жизненного цикла имеет свой бюджет, во многом связанный с различными интересами вполне конкретных стейкхолдеров. Добавить еще одну стадию – забрать деньги из другой.
Рис. 9. Типовой вариант спирального жизненного цикла проекта
Вам могли показать другой вариант жизненного цикла, например как на рисунке 9. Спиральный жизненный цикл часто используют в индустрии программного обеспечения и информационных систем, даже чаще, чем это официально преподносится. Идея такого жизненного цикла предельно проста. Каждый виток – полный набор стадий от замысла до, иногда, продажи и сопровождения. Переход на новый виток выполняется в том случае, когда завершенный виток был успешен и есть благоприятный прогноз развития проекта. Обычно каждый новый виток значительно дороже предыдущего, разрабатываемый функционал шире, сама система сложнее. Вопрос в том, сколько должно быть приемок и валидаций в таком жизненном цикле?
В целом, впечатление от знакомства с жизненным циклом проекта у любого инженера обычно сумбурное и смутное, как будто речь идет не о том, чем занимается инженер, а о какой-то другой реальности. Это очень плохо, когда так происходит.
Часто валидацию осуществляют путем имитации условий эксплуатации. Например, чтобы выполнить валидацию двигателя, надо где-то взять несколько автомобилей, соответствующих выявленным потребностям, вставить туда новые двигатели, провести тесты, то есть поездить на этих автомобилях, проанализировать результаты, подвести итоги.
То же самое, с точки зрения системной инженерии, нужно сделать и для вашей «коробочки умного дома». Надо где-то взять несколько домов, соответствующих выявленным потребностям (то есть это будут бизнес-центры определенного класса), вставить туда ваши «коробочки», подключить, провести тесты, проанализировать результаты, подвести итоги. В процессе валидации обязательно должны участвовать люди, поэтому надо быть готовым к обработке анкет. Все это довольно масштабное мероприятие, порой даже самое дорогое в проекте.
Если не обговорить необходимость в таких крупных затратах «на берегу», что остается делать в середине проекта? Можно просто сделать «коробочку», а потом продавать её – сразу. Как вы думаете, если сделать новый двигатель, пропустить стадию испытаний на разных, например, автомобилях, и сразу выставить продукцию на продажу – будет ли проект успешен? Какие могут быть последствия от выбора такого жизненного цикла? Самое время обсудить проектные риски с руководством.
Системному инженеру было бы интереснее взглянуть на модель жизненного цикла такого рода (рис. 10).
Рис. 10. Вариант совмещения жизненного цикла системы и жизненного цикла проекта
На представленном рисунке видно, насколько могут различаться жизненные циклы проекта и системы.
Жизненный цикл системы – это набор связанных процессов, реализуемых одновременно, а жизненный цикл проекта – разовая последовательность работ. Проект – это, как бы, один проход через полный или частичный жизненный цикл системы.
Самый главный вопрос, который возникает при просмотре этой диаграммы, заключается в том, когда должен закончиться проект? Это любимый вопрос менеджеров проектов, отводящий нас к цели проекта. Хорошие менеджеры обычно планируют заработать денег на проектах, благодаря чему они отлично знают, когда нужно остановиться. Но это далеко не всегда так. Бывают случаи, когда проект перерастает в другой проект, в новый процесс, в программу, а иногда он просто кончается, порой внезапно. Прогнозировать подобные исходы весьма затруднительно, поэтому инженеру нужно стараться всегда делать системы как можно лучше. Используя наработки по успешным системам, гораздо проще инициировать новые проекты.
Менеджер будет стараться экономить деньги. Инженер должен стараться сделать систему лучше, а для этого потребуются дорогие материалы, модули, участие экспертов. Валидация может стать корнем раздора между менеджером проекта и системным инженером, особенно когда системный инженер подключается к проекту не с самого начала, потому что уровень затрат на валидацию может стать сюрпризом для менеджера.
Между делом выяснилось, что группа специалистов уже давно проектирует умный бизнес-центр без вашего участия. Так получилось, что ваша работа проистекает в команде менеджера проекта и отвечаете вы за документацию, а настоящая разработка идет в другой комнате третий месяц подряд – возможно даже она началась до формальной инициации проекта. Ваша реакция?
Скажем так, это неплохо, когда разработка и концептуализация идут параллельно. Плохо – когда они не связаны между собой в рамках проектирования. Само слово «проектирование» в России имеет несколько значений:
– чаще всего это слово означает любую работу на бумаге, включая концептуальный этап, разработку инженерных решений, иногда даже работу конструктора;
– иногда под проектированием понимают именно написание документации;
– редко, но встречается такой вариант, когда проектирование смешивают с управлением проектом, что нас, как системных инженеров, не устраивает.
Путаница связана с тем, что слово «проект» можно перевести на английский как project и как design. Когда я буду говорить про проект, я обычно буду иметь в виду project, а под проектированием я буду понимать design, при том я буду понимать под проектированием любую работу на бумаге (в компьютере), предшествующую непосредственному изготовлению изделия. Если изделие изготавливается в процессе проектирования – будем называть это конструированием. Если изделие изготавливается серийно, когда проектирование завершено – это уже производство.
Итак, группа специалистов уже запроектировала «коробочку с проводами», которая оперирует набором условий типа:
«Если (выполняется комплекс условий по входам), то (выходной вектор преобразуется по определенным правилам)».
Многие специалисты искренне не понимают, зачем нужны системные специалисты, ведь и так всё понятно, что надо делать. С точки зрения группы специалистов – этот продукционный решатель является, собственно говоря, конечным продуктом. Ну и чего же в нем не хватает? Даже не важно на каком уровне решена задача: микросхемой, программным обеспечением, либо, вообще, механически или гидравлически. Самое удивительное на данный момент заключается в том, что эти специалисты собрали готовый, с их точки зрения, продукт, когда мы с вами еще только обдумываем жизненный цикл системы. Упрекать их в этом, конечно, нельзя.
Вас не должна пугать параллельность в работах. Для того, чтобы уместить в голове такой жизненный цикл и управлять им, используйте горбатую диаграмму (рис. 11).
Рис. 11. Горбатая диаграмма жизненного цикла проекта
На горбатой диаграмме представлены распределения человеко-часов по стадиям и практикам жизненного цикла проекта. Практика разработки концепции применяется на стадии исследований и немного захватывает разработку. Инженерия требований идет с некоторой периодичностью вплоть до производства итерациями согласований. Архитектура обычно прорабатывается «большим горбом», потому что изменение архитектуры ведет к непредсказуемым последствиям – прорабатывают один раз и надолго. Дизайн, изготовление, сборка и проверка идут взаимозависимыми колебаниями довольно часто, поскольку речь идет о постоянном выпуске прототипов (опытных образцов). Валидация выполняется в конце разработки (в т.ч. имитационно).
Надо понимать, что между стадиями жизненного цикла есть интервалы времени (гейты) для принятия решения о переходе на следующую стадию. В этом, собственно, и состоит смысл планирования, чтобы расставить интервалы (гейты) принятия решений. Как правило, следующая стадия дороже предыдущей, поэтому решение принимается долго, иногда дольше самой стадии. Системный инженер должен это понимать, и читать планы проектов и диаграммы жизненного цикла правильно.
Часто реальная продолжительность стадии жизненного цикла вдвое меньше запланированной именно из-за согласований, которые «сжирают» основное рабочее время.
Вот, вы пришли к руководителю проекта и начали тяжелый разговор:
– Ингеборг Карлович, есть несколько проблем.
– Каких? – недовольно пробурчал менеджер проекта.
Конец ознакомительного фрагмента.