Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Из разговора с Rob Hamann

Позавтракали сейчас с Rob Hamann из Дельфтского университета, в прошлом системного инженера по проектам аэрокосмических роботов. На EuSEC2010 он был сопредседателем academic (образовательной? исследовательской? и не переведешь...) секции. Просто, чтобы не забыть некоторые мысли из разговора:

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

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

Выяснилось, что огромное количество системных инженеров не любят INCOSE Handbook (я уже писал, что Мартон Форкош хвастается, что аналогичный NASA Handbook лучше). Rob Hamann использует какую-то древнюю версию середины 90-х, потому как в ней еще сохранились следы обсуждения структуры (продукта) и инструментов (акторов). В текущей версии 3.2 не осталось ничего, кроме процессов -- а это только часть метода! И действительно, текущая версия -- это переписанный ISO 15288, в котором намеренно выкошено все про акторов (роли и инструменты) и продукты (софт, железо и в том числе модели). То есть не учебник, а одна треть учебника. Тем не менее, Роб не пользуется понятием "метод", когда приводит такое рассуждение, "целое" изо всех этих частей у него безымянно и не слишком структурированно. Поэтому он в разговоре пропускает роли, но выпячивает инструменты, а про продукт говорит только "структура" (в оппозицию процессу).

Он считает, что должен быть Главный Системный Инженер во всех проектах, чья задача в диалогах (не путем выдачи команд, а путем убеждения) снимать противоречия между разными "предметными" специалистами (в числе которых он называет Главного по железу, Главного по софту и т.д. -- он приводил в пример свои робототехнические проекты). Должна быть строгая иерархия в принятии решений, иначе по версии Роба будет каюк проектам. Я с ним не соглашался, приводя в пример менеджеров крупных компаний (в их инженерной ипостаси -- они ведь организационные инженеры, а не проектные менеджеры по большей части!): еще пару десятков лет назад про них думали как о строгой иерархии, а теперь общепризнано, что на верхушке менеджерской "пирамиды" не остиё, а ровная площадка небольшой команды с разными мыслительными стилями. Так и в системной инженерии: должна быть команда из людей с разными мыслительными стилями и предпочтениями, и разным тренингом. Роб согласился, что расхождение по факту мыслительных стилей инженера по требованиям и инженера-архитектора неизбежно, но требовал для них одинакового тренинга, "чтобы они лучше понимали, что делает каждый из них в команде" -- и даже в этом случае он считает, что нужен какой-то "командир, снимающий противоречия". Явно в этом месте "коллективного системного инженера" нужно еще копаться и копаться: мне лично кажется, что воззрения "олдовых" системных инженеров тут явно не соответствуют современным хорошим практикам и копируют мыслительный стиль двадцатилетней давности (с точки зрения развития мышления на человеческом коллективном субстрате) прошлого. Одно дело мыслительные прорывы в одной дисциплине (математике, алгоритмическом дизайне), другое дело мыслительные прорывы по всему жизненному циклу и всем дисциплинам: армии, бывало, из-за гвоздя в подкове пропадали -- и "главный командир" тут вряд ли сможет помочь, нужны другие методы организации мышления.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 2 comments