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

Целевой системой будем называть тот конечный продукт, подлежащий эксплуатации, за работу над которым инженерным организациям платят деньги или выдают еду (в зависимости от места работы).

В начале пути вам никто не скажет «спасибо» за модель организации как обеспечивающей системы. Основная польза от этой работы заключается в разделении зон интересов членов команды, как стейкхолдеров.

Присутствуя на периодических совещаниях, вы скорее всего заметите, что руководитель проекта очень часто берет на себя роль системного архитектора, продавца и даже заказчика. Системный архитектор порой ведет себя как менеджер. А еще иногда приходит какой-нибудь заместитель директора, который к проекту относится очень условно, и начинает констатировать конструкторские решения, потому что он человек опытный.

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

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

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

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

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

Если вы решились взять на себя роль системного инженера, придется помогать всем остальным ролям «не выходить из себя», то есть из роли. Итак, вам следовало бы первым делом завести табличку, в которой каждому сотруднику из штатного расписания, с которым приходится совместно работать ставились бы в соответствие те роли, которые сознательно или несознательно взяли на себя эти люди во всех проектах, в которых они принимают участие. Из этой таблички будет видно, какие роли в каких проектах представлены минимально. По иронии судьбы так часто получается, что, например, роль менеджера проекта зачастую представлена хуже всех, потому что сам менеджер любит хвататься за все задачи подряд, забывая свою основную компетенцию. В итоге страдает командный дух, сроки нарушаются, бюджеты превышаются. Исходя из ситуации в вашей компании, вы могли бы постепенно занять самую критичную роль в соответствии со своими полномочиями. Такой шаг дает быстрый результат: проекты разгружаются, эффективность работы растет, настроение поднимается, в том числе у руководства.

Ниже пример таблицы, которая может получиться в результате. Не надо пугаться, на практике в проектах, к сожалению, бывает по 3 менеджера, 5 архитекторов и 1 программист.

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