Мы будем говорить, что системная архитектура это принципиальные инженерные решения, изменение хотя бы одного их которых приводит к существенному изменению всей конструкции.
Если двигатель внутреннего сгорания в автомобиле заменить на электрический двигатель, то менять надо практически всё. Поэтому системная архитектура часто представляется в виде структуры принципиальных решений, поскольку одни изменения тянут за собой другие.
Другим примером ролевой болезни в инженерной практике является изображение из себя заказчика. Часто этим заболеванием страдает руководитель проекта. Опять-таки, умение руководителя интерпретировать потребности заказчика важнейшая составляющая успеха проекта, но злоупотребление этим прекрасным умением приводит на практике к тому, что заказчика и вовсе перестают спрашивать о чем-либо, а еще чаще, просто, со временем забывают о его существовании, дистанцировавшись огромной бюрократической машиной. Тем временем, присутствие реальных представителей заказчика на ключевых совещаниях по проекту могло бы существенно снизить риски, и не позволить впасть в придумывание чужих потребностей, чем так часто болеют инженерные команды.
Если вы решились взять на себя роль системного инженера, придется помогать всем остальным ролям «не выходить из себя», то есть из роли. Итак, вам следовало бы первым делом завести табличку, в которой каждому сотруднику из штатного расписания, с которым приходится совместно работать ставились бы в соответствие те роли, которые сознательно или несознательно взяли на себя эти люди во всех проектах, в которых они принимают участие. Из этой таблички будет видно, какие роли в каких проектах представлены минимально. По иронии судьбы так часто получается, что, например, роль менеджера проекта зачастую представлена хуже всех, потому что сам менеджер любит хвататься за все задачи подряд, забывая свою основную компетенцию. В итоге страдает командный дух, сроки нарушаются, бюджеты превышаются. Исходя из ситуации в вашей компании, вы могли бы постепенно занять самую критичную роль в соответствии со своими полномочиями. Такой шаг дает быстрый результат: проекты разгружаются, эффективность работы растет, настроение поднимается, в том числе у руководства.
Ниже пример таблицы, которая может получиться в результате. Не надо пугаться, на практике в проектах, к сожалению, бывает по 3 менеджера, 5 архитекторов и 1 программист.
Таблица 1. Неудачный (как обычно бывает) вариант распределения ролей в текущих проектах
Не надо думать, что проблема в неправильном назначении ролей. Менеджер, вполне возможно, все правильно распределил. Проблема в том, что на деле сотрудники берут на себя совсем иные роли, чем было предусмотрено.
Когда менеджер проекта начинает на совещании предлагать системно-архитектурные решения, то он играет роль системного архитектора не свою. Учитывая, что время ограничено, то, скорее всего, такой менеджер не успеет полностью отыграть свою роль, в результате чего сорвутся сроки.
Ниже приведена другая таблица распределения ролей. Если вам со временем удастся добиться такой организации команды, будет здорово.
Таблица 2. Удачный вариант распределения ролей в текущих проектах
Работа системного инженера начинается с упорядочения среды, в которую он попал. Чтобы сформировать целостное представление о системе, которую вам предстоит делать, надо, прежде всего, четко разделить зоны ответственности членов команды проекта. Это нужно сделать сначала в своей голове, а потом в действительности. Необходимо следить за тем, чтобы каждый член команды «играл» свою роль. Здесь вам потребуется деликатность и лидерство, а также поддержка руководства. По моему скромному опыту (и богатому опыту моих коллег), большинство срывов проектов связано именно с конфликтами на почве зон ответственности. Системный инженер, являясь посредником между менеджерами и различными специалистами, должен следить за тем, чтобы члены команды действовали в соответствии со своими ролями, но делать это так, чтобы никого не обидеть и не разозлить.
Даже если вы предлагаете рациональные решения, кто-то обязательно будет «против», потому что затрагиваются его интересы. Кто-то из стейкхолдеров (среди которых всегда есть и члены команды проекта) имеет определенного рода интерес, чтобы всё было именно так «как есть». А еще именно этот стейкхолдер обычно старается сделать так, чтобы остальные не смогли увидеть ситуацию в целом. Это может касаться чьих-то скрытых доходов или того хуже.
Прежде чем браться за дело, нужно взвесить все интересы вокруг. На первом этапе не надо никому ничего доказывать. Главное, что надо сделать понять, существует ли возможность реализовать успешную систему в рамках проекта или в будущем (на основе результатов вашего проекта)? Если такая возможность есть, то системный инженер должен эту потенциальную систему четко определить. Она, скорее всего, будет существенно отличаться от заявленной в исходном техническом задании.
Репутация системных инженеров складывается из успешных и провальных систем, которые были реализованы в результате их деятельности.
Если ваша система изначально не имеет шансов на успех из-за чьих-то интересов или их отсутствия, либо эти шансы очень малы решать вам. Обеспечивать проект тоннами документации, в которой невозможно разобраться, не самая привлекательная перспектива. Поэтому давайте сразу договоримся, что тут мы будем говорить именно про инженерные проекты, а не про бумажные.
Вот на совещание пришел заместитель директора по проектам и начал доказывать системному архитектору системы, что надо все переделать, потому что много инноватики. У компании, по мнению замдира, достаточно опыта, чтобы решать задачу проверенными классическими методами. Если вы обратитесь к нежданному гостю с вопросом: «А какая твоя роль в проекте?», он может быть фраппирован. Вся команда должна понимать, что человеку иногда надо выговориться. Возможно, имеет смысл искать полезную политическую информацию между строк. Потом всегда можно составить протокол, зафиксировать предложение и обосновать на бумаге отказ с подписью технического директора, например. К сожалению, такое бывает. Да, на это приходится тратить время.
Вы заметили, что представители заказчика не интересуются вашим проектом: не звонят, не ругаются? Это верный признак того, что им этот проект не нужен.
Возможно, у кого-то из партнеров внезапно оказались неосвоенные деньги, а вашей компании перепало оказаться каналом их освоения. Конечно, никто ничего не успел толком согласовать, поэтому интерес у стейкхолдеров весьма формальный, однако для вашей организации это отличный способ инвестировать в молодые кадры. Этот проект можно доверить неопытным специалистам. Хорошо организованная команда молодых специалистов может даже из такого «заброшенного» проекта получить пользу. Возможно, это будет какая-то инновационная разработка. Может быть, удастся отработать «слабые места» технологии. Там, где другие видят проблему, постарайтесь разглядеть возможность.
Возможно, у кого-то из партнеров внезапно оказались неосвоенные деньги, а вашей компании перепало оказаться каналом их освоения. Конечно, никто ничего не успел толком согласовать, поэтому интерес у стейкхолдеров весьма формальный, однако для вашей организации это отличный способ инвестировать в молодые кадры. Этот проект можно доверить неопытным специалистам. Хорошо организованная команда молодых специалистов может даже из такого «заброшенного» проекта получить пользу. Возможно, это будет какая-то инновационная разработка. Может быть, удастся отработать «слабые места» технологии. Там, где другие видят проблему, постарайтесь разглядеть возможность.
Если вас достают звонками это нормально. Если все время требуют что-то это очень хорошо. Значит, скорее всего, заказчик заинтересован в результате, и система будет эксплуатироваться. Значит, вы работаете не зря. Значит, надо проявить максимум своих компетенций.
Разделяйте зоны ответственности команды проекта и зоны интересов стейкхолдеров, чтобы понимать, какая реальная задача перед вами стоит, и сколько ресурсов вы реально можете в нее вложить.
Глава 2. Потребности и требования
Предположим, ваш срок «устаканивания» в компании прошел за 3 месяца, и теперь вам доверили поучаствовать во вполне себе реальном проекте. Ваша компания решила сделать новый продукт умный дом, а вам предложили поучаствовать в этом проекте в качестве системного аналитика.
Для начала вопрос что должен делать системный аналитик? Что является результатом его работы? Не факт, что вам кто-то будет объяснять, что, собственно, от вас требуется. И не факт, что обязанности системного аналитика в предыдущих «учебных» проектах будут как-то коррелировать с новыми обязанностями в реальном проекте, где на кону деньги и репутация компании. Я бы на вашем месте не задавал никому подобных вопросов, а начал тщательно разбираться со стейкхолдерами, их потребностями и требованиями.
Потребности и требования принципиально разные понятия. Сначала, надо разобраться, какие стейкхолдеры есть у системы с рабочим названием умный дом. Нас пока даже не должно интересовать, что это такое умный дом. Вопрос исключительно в стейкхолдерах.
Называть стейкхолдеров нужно в честь их роли относительно целевой системы.
Не путайте с ролью в проекте, должностью, названием организации, ФИО и чем-угодно другим. Роль относительно целевой системы должна быть однозначно интерпретируемой, подразумевая конкретный интерес. Например, стейкхолдером может быть: инвестор, заказчик, пользователь, сервисный инженер, но не может быть: Константин Константинович, ООО «яКомпания», начальник отдела сбыта.
Самое главное не путайте заказчика проекта и заказчика целевой системы.
Вспомните определение системы из введения и отметьте для себя, что заказчик целевой системы это тот, кто просит собрать/поставить целевую систему в ее физическом воплощении (обычно еще на определенной территории). Заказчиком проекта может быть ваша же ИТ-компания в лице директора, который вкладывается в разработку и производство опытных образцов. Как правило жизненный цикл проекта значительно короче жизненного цикла системы. Поэтому, чтобы не запутаться между проектами, стейкхолдеров надо называть в честь ролей относительно целевой системы на всем ее жизненном цикле. Не менее важный момент заключается в том, что за проект не всегда платит заказчик. Инвестировать работы может совершенно другая организация или несколько организаций с разными интересами. Начать можно с таблицы.