Когда менеджер проекта начинает на совещании предлагать системно-архитектурные решения, то он играет роль системного архитектора – не свою. Учитывая, что время ограничено, то, скорее всего, такой менеджер не успеет полностью отыграть свою роль, в результате чего сорвутся сроки.

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

Таблица 2. Удачный вариант распределения ролей в текущих проектах

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

Даже если вы предлагаете рациональные решения, кто-то обязательно будет «против», потому что затрагиваются его интересы. Кто-то из стейкхолдеров (среди которых всегда есть и члены команды проекта) имеет определенного рода интерес, чтобы всё было именно так «как есть». А еще именно этот стейкхолдер обычно старается сделать так, чтобы остальные не смогли увидеть ситуацию в целом. Это может касаться чьих-то скрытых доходов или того хуже.

Прежде чем браться за дело, нужно взвесить все интересы вокруг. На первом этапе не надо никому ничего доказывать. Главное, что надо сделать – понять, существует ли возможность реализовать успешную систему в рамках проекта или в будущем (на основе результатов вашего проекта)? Если такая возможность есть, то системный инженер должен эту потенциальную систему четко определить. Она, скорее всего, будет существенно отличаться от заявленной в исходном техническом задании.

Если ваша система изначально не имеет шансов на успех из-за чьих-то интересов или их отсутствия, либо эти шансы очень малы… решать вам. Обеспечивать проект тоннами документации, в которой невозможно разобраться, – не самая привлекательная перспектива. Поэтому давайте сразу договоримся, что тут мы будем говорить именно про инженерные проекты, а не про бумажные.

Вот на совещание пришел заместитель директора по проектам и начал доказывать системному архитектору системы, что надо все переделать, потому что много инноватики. У компании, по мнению замдира, достаточно опыта, чтобы решать задачу проверенными классическими методами. Если вы обратитесь к нежданному гостю с вопросом: «А какая твоя роль в проекте?», – он может быть фраппирован. Вся команда должна понимать, что человеку иногда надо выговориться. Возможно, имеет смысл искать полезную политическую информацию между строк. Потом всегда можно составить протокол, зафиксировать предложение и обосновать на бумаге отказ с подписью технического директора, например. К сожалению, такое бывает. Да, на это приходится тратить время.