Компоненты, модули и путающие их проектные менеджеры
Пару недель вокруг меня сплошняком идут путанные разговоры, порождаемые неразличением модулей (конструктивных единиц) и компонент (функциональных единиц). Идёт ли речь о каталогах (в которых пытаются обнаружить компоненты), функциональных классификаторах (в которых неожиданно оказываются закодированы модули), обнаруживаются ли два разных по структуре классификатора (компонент и модулей), и люди начинают настаивать, чтобы остался только один -- ситуаций было много.
Такое впечатление, что различию компонент и модулей никто напрямую не учит, и люди бьются об это место головой массово. У меня-то это в курсе есть, в учебниках есть (например, в http://techinvestlab.ru/systems_engineering_thinking/), разъясняется в куче стандартов (например, ISO 81346), но никто этого не читает! В последних версиях курса я удвоил количество материала про компоненты/функции и модули/конструкцию (даже по сравнению с версией http://system-school.ru/wp-content/uploads/2016/11/system_thinking_11nov2016.pdf): материал важный, он не должен пройти мимо.
Вот главный мой слайд на эту тему, и он обманчиво утверждает, что компоненты и функции совпадают (да, но только в случае системы в целом):
А дальше там несколько слайдов, где чётко показывается, что в общем случае они не совпадают -- в силу проводимого функционального анализа (декомпозиции компонент) и модульного синтеза (сборки системы из модулей, назначаемых на выполнение функций). И там ещё есть размещения, о которых тоже нельзя забывать.
Беда в том, что инженеры этот материал знают, но на уровне "опыта" (когда "нутром чую, но объяснить не могу"). А менеджеры с этим вообще не сталкиваются. В том же Архимейте функциональные и конструктивные элементы у менеджеров вызывают ступор: они не понимают, зачем и как их использовать при моделировании предприятия. Программисты в этом месте тоже тупят порядочно: им в голову не приходит, что рассмотрение архитектуры предприятий ведётся с использованием того же мышления, что и рассмотрение их программ (т.е. на базе системных представлений, зафиксированных в ISO 42010).
Александр Турханов подкинул ещё одну ситуацию: проектные менеджеры мыслят модульно (ещё бы!), а планирование ведут в компонентах и от этого много бед -- https://www.facebook.com/photo.php?fbid=10213456653987835&set=a.10207920196819866.1073741826.1145074069&type=3
Я дал пару комментов:
-- Проектные менеджеры очень часто из "управления проектами", т.е. когда идёт стройка-сборка и обсуждается логистика модулей. Отсюда и модульность в мышлении, ведущее описание. При проектировании же функциональность ведёт поначалу, но управляющие проектом вообще не при делах, их по факту извещают о том, что "мы вам уже сделали модульный синтез, закупайте модули" или "мы закончим работать дня через три, про модули после этого расскажем". Но когда менеджеры приходят в проект -- первое, что они пытаются сделать, это купить компоненты. И очень удивляются, что у инженеров от этого предложения начинается нервный тик, истерика и т.д.
-- Планирование должно быть модульно, если речь идёт о сборке. Ибо можно проверить готовность проекта компоненты, но сборку и прочую логистику можно проконтролировать только модуля. По-хорошему, конечно, функциональная структура там должна присутствовать, если модули хорошо проработаны и совпадают с компонентами в главных частях. Но для этого нужно специально думать.
[есть ещё много других проблем в общении менеджеров и инженеров: например, менеджеры запросто превращают выданные для них предварительные оценки в сделанные им обещания -- типичное бандитское "никто тебя за язык не тянул" использует ровно этот же приём]
-- Вы просто не встречались с ситуациями, когда менеджеры предъявляют сделанную инженерами функциональную декомпозицю, затем указывают на каталог модулей и требуют немедленно написать скрипт, выбирающий модули для функций. Что это модульный синтез и всё не так просто, им невдомёк: разница между фукнцией и конструкцией для них незначима. У меня за последнюю пару недель было несколько таких случаев. Плохо, когда инженеры на это ведутся (и, например, функциональную кодировку вдруг применяют к модулям, а потом удивляются чудесам и принципиальным нестыковскам).
-- Мы не обсуждаем всё необъятье нестыковок между менеджерским и инженерным описанием мира. Обсуждаем только одно: понятие компоненты инженерам ведомо, ибо им нужно, чтобы вещь работала. А менеджерам не нужно, вообще. И когда им попадает в руки компонента, то они с ней себя ведут как с модулем. Это фатально, но даже у инженеров не хватает знаний, чтобы это объяснить -- они нутром чуют обычно, что что-то не так, но объяснить внятно не могут.
UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10210837191499895
Такое впечатление, что различию компонент и модулей никто напрямую не учит, и люди бьются об это место головой массово. У меня-то это в курсе есть, в учебниках есть (например, в http://techinvestlab.ru/systems_engineering_thinking/), разъясняется в куче стандартов (например, ISO 81346), но никто этого не читает! В последних версиях курса я удвоил количество материала про компоненты/функции и модули/конструкцию (даже по сравнению с версией http://system-school.ru/wp-content/uploads/2016/11/system_thinking_11nov2016.pdf): материал важный, он не должен пройти мимо.
Вот главный мой слайд на эту тему, и он обманчиво утверждает, что компоненты и функции совпадают (да, но только в случае системы в целом):
А дальше там несколько слайдов, где чётко показывается, что в общем случае они не совпадают -- в силу проводимого функционального анализа (декомпозиции компонент) и модульного синтеза (сборки системы из модулей, назначаемых на выполнение функций). И там ещё есть размещения, о которых тоже нельзя забывать.
Беда в том, что инженеры этот материал знают, но на уровне "опыта" (когда "нутром чую, но объяснить не могу"). А менеджеры с этим вообще не сталкиваются. В том же Архимейте функциональные и конструктивные элементы у менеджеров вызывают ступор: они не понимают, зачем и как их использовать при моделировании предприятия. Программисты в этом месте тоже тупят порядочно: им в голову не приходит, что рассмотрение архитектуры предприятий ведётся с использованием того же мышления, что и рассмотрение их программ (т.е. на базе системных представлений, зафиксированных в ISO 42010).
Александр Турханов подкинул ещё одну ситуацию: проектные менеджеры мыслят модульно (ещё бы!), а планирование ведут в компонентах и от этого много бед -- https://www.facebook.com/photo.php?fbid=10213456653987835&set=a.10207920196819866.1073741826.1145074069&type=3
Я дал пару комментов:
-- Проектные менеджеры очень часто из "управления проектами", т.е. когда идёт стройка-сборка и обсуждается логистика модулей. Отсюда и модульность в мышлении, ведущее описание. При проектировании же функциональность ведёт поначалу, но управляющие проектом вообще не при делах, их по факту извещают о том, что "мы вам уже сделали модульный синтез, закупайте модули" или "мы закончим работать дня через три, про модули после этого расскажем". Но когда менеджеры приходят в проект -- первое, что они пытаются сделать, это купить компоненты. И очень удивляются, что у инженеров от этого предложения начинается нервный тик, истерика и т.д.
-- Планирование должно быть модульно, если речь идёт о сборке. Ибо можно проверить готовность проекта компоненты, но сборку и прочую логистику можно проконтролировать только модуля. По-хорошему, конечно, функциональная структура там должна присутствовать, если модули хорошо проработаны и совпадают с компонентами в главных частях. Но для этого нужно специально думать.
[есть ещё много других проблем в общении менеджеров и инженеров: например, менеджеры запросто превращают выданные для них предварительные оценки в сделанные им обещания -- типичное бандитское "никто тебя за язык не тянул" использует ровно этот же приём]
-- Вы просто не встречались с ситуациями, когда менеджеры предъявляют сделанную инженерами функциональную декомпозицю, затем указывают на каталог модулей и требуют немедленно написать скрипт, выбирающий модули для функций. Что это модульный синтез и всё не так просто, им невдомёк: разница между фукнцией и конструкцией для них незначима. У меня за последнюю пару недель было несколько таких случаев. Плохо, когда инженеры на это ведутся (и, например, функциональную кодировку вдруг применяют к модулям, а потом удивляются чудесам и принципиальным нестыковскам).
-- Мы не обсуждаем всё необъятье нестыковок между менеджерским и инженерным описанием мира. Обсуждаем только одно: понятие компоненты инженерам ведомо, ибо им нужно, чтобы вещь работала. А менеджерам не нужно, вообще. И когда им попадает в руки компонента, то они с ней себя ведут как с модулем. Это фатально, но даже у инженеров не хватает знаний, чтобы это объяснить -- они нутром чуют обычно, что что-то не так, но объяснить внятно не могут.
UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10210837191499895