Вячеслав Мизгулин - Системный инженер. Как начать карьеру в новом технологическом укладе

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

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

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

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

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

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

Репутация системных инженеров складывается из успешных и провальных систем, которые были реализованы в результате их деятельности.

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

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

Вы заметили, что представители заказчика не интересуются вашим проектом: не звонят, не ругаются? Это верный признак того, что им этот проект не нужен.

Возможно, у кого-то из партнеров внезапно оказались неосвоенные деньги, а вашей компании перепало оказаться каналом их освоения. Конечно, никто ничего не успел толком согласовать, поэтому интерес у стейкхолдеров весьма формальный, однако для вашей организации это отличный способ инвестировать в молодые кадры. Этот проект можно доверить неопытным специалистам. Хорошо организованная команда молодых специалистов может даже из такого «заброшенного» проекта получить пользу. Возможно, это будет какая-то инновационная разработка. Может быть, удастся отработать «слабые места» технологии. Там, где другие видят проблему, постарайтесь разглядеть возможность.

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

Разделяйте зоны ответственности команды проекта и зоны интересов стейкхолдеров, чтобы понимать, какая реальная задача перед вами стоит, и сколько ресурсов вы реально можете в нее вложить.

Предположим, ваш срок «устаканивания» в компании прошел за 3 месяца, и теперь вам доверили поучаствовать во вполне себе реальном проекте. Ваша компания решила сделать новый продукт – умный дом , а вам предложили поучаствовать в этом проекте в качестве системного аналитика.

Для начала вопрос – что должен делать системный аналитик? Что является результатом его работы? Не факт, что вам кто-то будет объяснять, что, собственно, от вас требуется. И не факт, что обязанности системного аналитика в предыдущих «учебных» проектах будут как-то коррелировать с новыми обязанностями в реальном проекте, где на кону – деньги и репутация компании. Я бы на вашем месте не задавал никому подобных вопросов, а начал тщательно разбираться со стейкхолдерами, их потребностями и требованиями.

Потребности и требования – принципиально разные понятия. Сначала, надо разобраться, какие стейкхолдеры есть у системы с рабочим названием умный дом . Нас пока даже не должно интересовать, что это такое – умный дом. Вопрос исключительно в стейкхолдерах.

Называть стейкхолдеров нужно в честь их роли относительно целевой системы.

Не путайте с ролью в проекте, должностью, названием организации, ФИО и чем-угодно другим. Роль относительно целевой системы должна быть однозначно интерпретируемой, подразумевая конкретный интерес. Например, стейкхолдером может быть: инвестор, заказчик, пользователь, сервисный инженер, но не может быть: Константин Константинович, ООО «яКомпания», начальник отдела сбыта.

Самое главное – не путайте заказчика проекта и заказчика целевой системы.

Вспомните определение системы из введения и отметьте для себя, что заказчик целевой системы – это тот, кто просит собрать/поставить целевую систему в ее физическом воплощении (обычно еще на определенной территории). Заказчиком проекта может быть ваша же ИТ-компания в лице директора, который вкладывается в разработку и производство опытных образцов. Как правило жизненный цикл проекта значительно короче жизненного цикла системы. Поэтому, чтобы не запутаться между проектами, стейкхолдеров надо называть в честь ролей относительно целевой системы на всем ее жизненном цикле. Не менее важный момент заключается в том, что за проект не всегда платит заказчик. Инвестировать работы может совершенно другая организация или несколько организаций с разными интересами. Начать можно с таблицы.