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