Обсуждение

п2 - актуально весьма ....

Анатолий, Когда в понедельник я сидел и слушал Вас в зале (в Нижнем) я ещё больше утвердился в своём понимании проблемы нашей компании, да и отрасли в целом. Ниже коменты по вашему тексту: 0. Вы забываете повторять свой тезис, который я услышал от вас ещё при первой нашей встречи и целиком его поддерживаю. Тезис про то, что если что-то попадает в руки ИТишникам, то сразу становиться софтом. (примерно такой вольный перевод) Если вы обратили внимание то СУЖЦ у нас занимаются в большей степени именно ИТишники и им не понятны слова про системы управления и т.д. Отсутствие знаний по теории менеджмента и системного подхода превращает любую систему в их глазах в программу. 1. Мне кажется вы не с того начали. Вот тут вы всё правильно пишете. Так объясните нашим начальникам, что первоочередная задача нарисовать чёрный ящик и определить потоки входящей и выходящей информации. А чёрный ящик это и есть СУЖЦ, который по мере понимания проблематики будет раскрываться. Со своей стороны я пытался это объяснить, но не был услышан (это к вопросу о пророках в своём отечестве). 2. И опять трудно не согласиться. Однако все эти высокие слова не понятны рядовому инженеру. Когда представители IBS рассказывали (и показывали очень странные картинки), как они проводили собеседования с сотрудниками компании на предмет выявления коллизий они упустили важную деталь: мало кто из опрошенных вообще понимал о чём их спрашивали. Для инженера существует один вид коллизий – проектные (труба на трубу). Что такое, например, организационные коллизии для них тёмный лес. Поэтому сначала нужно проводить легбез и чётко ставить цели и задачи опроса. 3. Про управление изменениями. Это вообще самая больная мозоль всей российской промышленности (да может быть и всёй России). Помните что вам сказал товарищ из зала: «мы не можем ни чего менять после того как определено ТЗ и т.п. – государственные нормы не позволяют!» Это говорит о том, что наши люди не могут мыслить вне рамок условностей. Ни кому даже в голову не приходит, что если гора не идёт к Магомету, то Магомет уж точно может пойти к горе. Именно поэтому у нас буксуют все инновационные начинания. Мы пытаемся подстраиваться под систему, а не систему перестраивать под реалии сегодняшнего дня. Это, я думаю, Вы тоже обязаны объяснить. PS В очередной раз понимаю, как Вы правы, когда говорите про наше верхнее образование. Отсутствие инженеров-менеджеров очень сильно тормозит наше развитие. И пока нами управляют инженеры, чувствуешь себя как последним из племени, которого ещё нет.

0. Я не забываю повторять свой тезис: я потратил в том самом помянутом зале битых пару часов, тыкая пальцем в табличку из трех слоёв (рисунок 5 из http://www.opengroup.org/archimate/doc/ts_archimate/chap3.html) и обращая внимание на невозможность формулирования архитектуры исходя только из средней полосочки applications (то есть софта). Я согласен, что это моё тыкание по большому счёту было проигнорировано -- но обсуждение функций (как критериев пригодности софта заявляемым целям) таки пошло. Но всё одно обидно, если даже вы не услышали моего многократного повторения тезиса про подчиненную организации работ ("бизнесу") роль софта, и неполноценность архитектурного описания с "чиста софовым содержанием" не услышали -- значит мне еще тренироваться и тренироваться в донесении этой мысли... 1. А вот тут я как раз был успешен: я сумел развернуть обсуждение к подробному рассмотрению функций. Функции же как раз и определяют систему, как "чёрный ящик" (в отличие от конструкции/механизма, которые определяют проектные решения, т.е. "белый ящик"). Это неважно, что функции рассматривались не сами по себе, а "в приложении к софтине". Главное, что список функций был обсуждён до конца (обсуждение шло еще и несколько часов второго дня). Это и есть работа по норме, явное выделение "чёрного ящика". Функции же не сводятся только к детальному описанию входящей и исходящей по интерфейсам информации и ее обработке, это только в IDEF0 "функции" так определяются. И тут не нужно забывать мою оговорку, что в связи с сервис-ориентированным подходом потихоньку появляются методы, в которых явно говорится о важности рассмотрения "белого ящика" с самого начала -- но я еще не слишком с этим подходом разобрался (пункт 5 в http://ailev.livejournal.com/938820.html). 2. Я, вроде, специально написал этот пункт для разъяснения: зачем вводить понятие "коллизия", когда уже есть понятие "изменения". Помянутый вами опрос, конечно, показал непонимание. Вполне возможно, что нужно было больше уделять внимания разъяснению понятия "коллизия" -- доводя это разъяснение до уровня "лифтового теста" (т.е. умения разъяснить отличия "коллизий" и "изменений" за одноминутную поездку в лифте так, чтобы собеседник понял всё на 100%). Надеюсь, этот постинг чуть приблизил к такой цели. 3. Я бы отдельно объяснял про управление конфигурацией, отдельно про коллизии и управление изменениями. Ибо отсутствие в головах терминологии управления конфигурацией (прежде всего -- базис) и жизненного цикла (прежде всего -- понимание разнообразия видов жизненного цикла и методов разработки) приводят к невозможности обсуждения иных способов работы, кроме уже имеющихся и утвержденных допотопными ГОСТами докомпьютерной эпохи. Воевать с этими "писаными кровью уставами" сегодня -- это как воевать с уставами времен лошадей, стрел и луков во времена вертолётов и пулемётов. Время "писания уставов кровью" важно, и нужно не промахнуть мимо поворота. Я соглашусь, что обсуждаемые в постинге вопросы затрагивают не только собственно системную инженерию и архитектуру, но и инженерный менеджмент. Но многосотстраничные учебники и по первой дисциплине, и по второй не засунешь в головы одномоментно. Нужно время...