Обсуждение

Страница 11 Назови назови хоть горшком 13 но нас будут интересоватью.

Я на основе данной книжки пытаюсь убедить разработчиков наших АИС в том, что: - Работа АИС это только компонент общего процесса, а не весь процесс; - В процессе могут принимать участие и другие АИС (также как компоненты), следовательно должна быть совместимость на уровне отдельных решений; - работа любой АИС в процессе - компонент вспомогательный, а не самый главный.

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

1. Давал книгу товарищу, который пока не уверен, что системная инженерия – это то, без чего ему не обойтись. Он тупо не смог прорваться до основного содержания книги и заскучал на параграфах с размышлениями про системных инженеров, их образование и отличия от других профессий. Возможно, имеет смысл перенести эти главы ниже. В то же время определение понятию «система», которое вообще является ключевым, дается ближе к середине книги. Получается, что 2 главы читаешь, не понимая про что. 2. Хотелось бы, чтобы в части про архитектуру был раздел про архитектурные фреймворки. Что это такое? Зачем и как возникло? Какое их место в контексте 42010? Полезно/бесполезно? Как выбрать? Как пользоваться (в том смысле, что чего можно ждать, а чего ждать не следует)? Если я не ошибаюсь, то incose’вском заседании по 42010 такие рассуждения были. 3. Не смог до конца разобраться с альфой «возможности». Возникло стойкое ощущение, что сюда запихали все, что не поместилось в другие альфы. Там примерно понятно какие именно подальфы существуют. Даже если они не описаны в явном виде. А здесь полная помойка и про стратегию, и про юзер нидс, и про деньги, и про вообще. Я у себя в голове не могу четко очертить границу, что включать в «возможности», а что нет. Хотелось бы, чтобы подальфы этой альфы были раскрыты более явно и полно.

Не планируете сделать книгу в формате epub ?

1. Непонятно, как относится к тексту просьбы (под словом "относится" -- как раз различение позиций). 1.a. Заявляется, что книга является только частью, при этом вспомогательной 1.b. Обратную связь ожидают от людей, которые в другой среде (для них других частей, кроме книги, вообще не существует) 1.c. Эссе, которые уже есть и которые являются критерием понимания книги в той среде, для которой книга и промысливалась -- не предоставляются. 2. С точки зрения инсайта, вопросов и ситуаций, к ним приводящих. 2.a. По опыту… системное инженерное мышление возникает как ответ на задачу "вот лучшие фирмы делают то-то и то-то. Ресурсов в распоряжении -- меньше на столько-то. Надо их обогнать"… Системное --как раз потому, что при других задачах достаточно изучать лучшее/копировать. 2.b. Если стоит задача обогнать, то возникает понимание, что пока будешь повторять (догонять) -- они уйдут дальше. Приходится мыслить системно ("целить в пустоту"). 2.c. В иных случаях будут в любой форме, хоть через написание эссе, повторять то, что научили, и так далее и так далее. Т.е. проблема ведь не в учениках, а в Учителе )))) Когда решаешь ситуации "надо обогнать" -- не можешь применять старые решения. Ситуация каждый раз в динамике. Каждый раз приходится находить новое решение. Приходится постоянно "разрушать утверждения" и свои и любого Учителя. 3. С точки зрения книги как материала для обучения 3.a. Книга должна строится как локальные пространства. Структура книги должна быть другой. 3.b. Книга должна содержать "пустой слайд". Нет задачи привести Кейс. Есть задача читателю дать возможность изложить себе свое представление о норме. А потом сравнить с тем, о чем пишет Автор. Задача (то, что и называют Кейсом) выполняет именно эту функцию. Поэтому и задачи/кейсы подбираются такие, чтобы эту разницу в "представлении о нормальном" сделать читающему очевидной за счет "пустого слайда". 3.с. Книга сейчас должна содержать видеочасть. Да и... данный текст писался не в логике "я прав". А в логике "вдруг пригодится". С уважением, АВ

Вообще-то через мой тренинг по этим материалам прошло в разных группах под сотню человек, так что я вполне могу ожидать реации и от них -- многие из них читают мой блог, хотя и отмалчиваются обычно. Эссе, конечно, через интернеты не предоставляются: там материалы по вполне коммерческим проектам плюс личные ошибки студентов, так что их не стоит раскрывать всем. Но в группах студенты обмениваются этими эссе, чтобы взаимно оценить уровень своей работы. Сотрудники обычно эссе не пишут, но у них весь проект сплошное эссе. Системная инженерия это необязательно "сделать лучше, чем у конкурента" и "догнать". Мне, честно говоря, такая даже мысль в голову не приходила, что это может быть основным её использованием. Традиционно системная инженерия была в аэрокосмосе, когда нужно было не столько кого-то догонять и перегонять, сколько соревноваться с матушкой-природой и прорываться в неизвестное: то есть делать всё время что-то впервые в мире, без шанса повторить "лучшие практики". Я поэтический язык типа "локальные пространства в книге" не понял совсем, увы. Подсказка "структура книги должна быть другой" не помогает, потому как можно предложить тысячи и тысячи "других" структур, каждая из которых будет "другой" к любой из остальных "других" -- сомневаюсь, что вас удовлетворять и какие-нибудь из этих "других" структур. Про "пустой слайд" не понял, но студенты и сотрудники делают доклады "у доски" -- и их ошибки корректируются по ходу дела. Может быть, это как раз оно. Видеочасть в книге непонятно, какая нужна. Видеокурс два года назад я делал, 24 часа видео. Мне это показалось крайне неэффектиным методом подачи материала (хотя многим очень нравится). Если хочется видео именно по материалам курса, то его полно тут: http://incose-ru.livejournal.com/

1. "Погонял тему"... подумал "чем могу пользу принести ;)"... выводы: 1.1. если намечен срок по книге, то мне обсуждение книги надо отставить в сторону (лучшее -- враг хорошего). 1.2. обсуждение того, что мне комфортно -- то, что условно называется "эссе". Тексты реальных эссе мне для этого не нужны ;) 1.3. есть какие-то мысли по первому Вашему абзацу (относительно 100 человек и обратной связи), но здесь подумаю и потом коротко изложу варианты. "Длинного обсуждения" пока не вижу. 1.4. зная свои особенности: 1.4.1. задействую свой ЖЖ. а) какие-то вещи надо раскрывать длинными текстами, а не "поэтическими образами"; б) отношусь с определенной иронией и к себе и своим текстам ;) , тексты получаются такие, какие получаются... в чужом ЖЖ часто "выпадаю из привычных текстов". 1.4.2. отвечаю долго. Часто перед ответом -- думаю ))))) Вроде бы по недостаткам -- все. Да и... любое мое мнение прошу считать ошибочным ))) право на ошибку отстаиваю. Есть еще четкое ощущение, что мне надо употреблять слова, отличающиеся от слов "системное мышление" и "системноинженерное мышление". Понимаем ли мы под этими словами одно и то же или разное -- будет понятно только по примерам и их толкованиям. Поэтому на первом этапе назовем то, о чем пишу именно я = "на обгон" (как название стиля мышления). Надеюсь, такое разделение позволит дополнять, рассматривая с разных сторон ситуации, а не спорить о смыслах термина. Да и... Если что-то будет с моей стороны некомфортным -- дайте знать. Могу просто не замечать... По вводной части вроде бы все. Необходимость ее: написать один раз целиком и не возвращаться к проговариванию этого больше.

1. Относительно эссе. 1.1. Как в реальности -- не знаю. С "моей колокольни" -- обязательные разделы и их последовательность формируют стиль мышления через многократное заполнение и обсуждение. Например, формирование самостоятельного мышления в немецкой армии начала ХХ века сопровождается проработкой документов (разделов, обязательных к заполнению). Необходимость самостоятельного мышления в немецкой армии является следствием парадигмы "туман войны" (начальник может предвидеть и отдавать адекватные ситуации приказы только до начала боевых действий. Дальше -- требуется самостоятельность мышления (учет реальной обстановки)). Тема мне была интересна. Пришел к ней после анализа отличий в понимании приказа командармом 5-ой армии Поповым и сравнении документов (советских и немецких) по изучению боевого опыта. 1.2. В моем представлении -- системное мышление инженера не может быть без самостоятельной постановки себе задачи. Тему можно развивать и развивать (поэтому и писал выше про свой ЖЖ) 2. Относительно "Традиционно системная инженерия была в аэрокосмосе". 2.1. Почему системная инженерия -- это аэрокосмическая? Возьмите в качестве примера Шухова, строительство им нефтеналивных барж. Он не просто рассчитал, какая баржа будет лучше. Он еще и крестьян обучил суда строить конвейерным способом задолго до Форда. Т.е. у него люди специализировались ТОЛЬКО на отдельных операциях. Эти операции они выполняли, переходя от одного строящегося судна к другому. Крестьяне. Времени "выращивать" из них мастеровых, которые могут одно судно с начала и конца построить качественно -- у него не было. Если отмотать еще историю… Древний Рим. Строительство дорог. Жизненный цикл эксплуатации дороги гораздо более длинный, чем даже жизнь строителя. Т.е. дело даже не в том, что дилемма заплатят/не заплатят или будет следующий заказ/не будет (что обсуждается как критерий в рыночной экономике). Даже дилеммы голову отрубят/не отрубят -- нет в принципе. Поэтому "постройка дороги на века" (что по факту с римскими дорогами и было) требует системного мышления (я бы даже сказал, что выделения/отделения инженерной системной деятельности как проектирования жизненного цикла от строительной деятельности как деятельности, ограниченной рамками строительства и оптимизирующей строительство) Можно сказать точнее. Те дороги, которые по факту были построены в Древнем Риме -- требуют отделения и = как задачи, и = как человека, ее решающего -- управления жизненным циклом эксплуатации дорог от жизненного цикла строительства дорог и оптимизации строительства в границах реального времени, необходимого на постройку и сдачу "заказчику". Почему отсчет от аэрокосмической? ;) 2.2. Не могли бы Вы привести примеры к "аэрокосмической" и "матушке-природе". Насколько я знаю, была либо ситуация "не известно в принципе" (первый полет космонавта; преодоление звукового барьера) (там одни решения), либо "полетит/не-полетит" (там другие решения, так как природа известна, неизвестно -- полетит ли именно эта конструкция... но она должна быть УЖЕ построенной). А у меня сложилось впечатление, что Вы под "системным мышлением" говорите об этапе "бумага и карандаш", а не готовое изделие. Точнее, даже так сформулирую вопрос. Ситуации "прорыва" (первые и никого нет) -- уникальны. Первый полет самолета. Все остальные -- это конкуренция с другими самолетами. Вы готовите инженеров, которые будут делать прорывы (уникальные события) или конкурировать с изделиями других инженеров?

Относительно моего "поэтического языка" ;) согласен... примеры нужны. а) Известная история про "большой и малый круг" знания и не-знания (чем больше я узнаю, тем больше граница того, что я не знаю). б) очевидный вывод, который не замечают ;) граница ("площадь") полезного материала разная для "первокурсника" (малый круг) и "профессора" (большой круг) (люди размышляют над разными вопросами и ценят разные ответы). в) почему то считается нормальным, сообщать человеку с "малым кругом" ответы НЕ на его вопросы. Например, Вы работаете с первыми лицами фирм. И Ваши консультации (темы; пространства анализа) ориентированы больше на условного "главного конструктора" (по полномочиям), чем на рядового инженера. Условный студент, закончив институт -- придет на производство рядовым инженером. И свое системное мышление ему надо проявлять из этого локального пространства, а не из пространства "главного конструктора". И если Вы, условно говоря, учите его на "главного конструктора" -- то Вы пропускаете целый ряд "локальных пространств", в которых у него получается "пустота". Шухов, как пример, вспомнился мне, когда я думал как раз об этой ситуации. Потому что, если Вы готовите сразу на "главного конструктора" или сразу группу, которая придет работать, например в один отдел КБ или один цех на предприятии -- то вместо Шухова можно/нужно приводить другие примеры. А если Вы готовите инженера, который придет и будет работать один -- то Шухов -- самый раз. Если не пересказывать его действия, а искать ответ на "почему он именно так делал?" Примеров можно еще много. Суть того, что я хочу сказать. Структура книги должна определяться не Вашими знаниями и/или заказами (практиками). А знаниями/реальными заказами студента/выпускника. С какими проблемами ему придется столкнуться? На какие вопросы искать ответы? Какие самостоятельные качества для решения проблем ему надо развить?

Про пустой слайд Как пример. Вот у Вас в книге (стр. 29, если правильно помню) пример про детей и их обучение компьютерному языку. У Вас это построено в виде истории. Разрыва нет. А ведь пример интересный для анализа. а. Вы берете тему, которая может быть известна читающему из опыта (программирование), а может и не известна. б. Вы ссылаетесь на группу специалистов и свои контакты с ними и их утверждения. Соглашается ли студент с Вами или нет? Есть ли у него "пространство", где он может "изложить" свое мнение или он просто "скользит взглядом" и сразу переходит к правильному ответу, минуя вопрос "а действительно ли так на самом деле?" Ведь самостоятельное мышление (вот, буду употреблять это слово вместо "системное" ;)) требует обязательно нахождение в своей памяти известных фактов, которые не укладываются в утверждение. Любое. Даже свое привычное. Например, если вернуться к Вашим утверждениям. Вы ведь утверждали в первой части Вашей истории, если сделать перевод "выбор в неопределенном будущем" -- что дети до 7 класса не могут играть в шахматы (так как в шахматах нужно предполагать -- а что будет, если противник пойдет так). Что, конечно, не так. Если сравнивать на привычном материале ;) Ваша книга построена как кинофильм. Счастливый конец обязательно будет известен во время посещения кинотеатра. А должна строится как сериал -- задачи должны обрываться на самом интересном месте. И сообщаться ответы где-то "далеко-далеко" при чтении. Пустой слайд = пауза в информационном потоке. С целью построения слушающим/читающим = своего предположения (изложение своего "здравого смысла"). Если гипотеза самостоятельно не строится -- все... получается натаскивание. Относительно видеочасти. Здесь я полностью "неточно написал" (без шансов догадаться). Исправляюсь. 1. Студенты часто делают (и это где-то можно собирать) конспекты (изложения в виде инфографики, карт ассоциаций или других способов "сжатия информации"). 2. Важны не видеоматериалы (вообще не имеет значения, в какой форме это будет). Важна ситуация перевода и сжатия линейного текста книги на "другой язык". Важно разбить книгу на "смысловые кусочки" (например, я это делаю через разбивку текста на абзацы и вставку их потом в Freeplane как отдельных ветвей) для того, чтобы комфортно было быстро менять местами и искать другие способы группировки/отсева текста. Таблицы, схемы, видео, и т.д. -- все это дает пользу не тому, кто это воспринимает, а тому, кто это создает из книги. Т.е. не тому, кто воспринимает только "один язык" (без разницы какой), а тому, кто видит (соотносит) сразу два языка. Тема перевода и создания "внутреннего переводчика". Для самостоятельного мышления -- важна. Примеры -- возможно, подобрал не совсем удачные. Посмотрю по реакции. 3. Краткое изложение книги -- важно. Немцы это делают в виде вопросов и ответов или ключевых словах на полях и вначале главы.

У меня глубокое впечатление, что вы путаете системноинженерное мышление (очень специфическое мышление системных инженеров, существенно использующих особенности понятия "система" из системного подхода) с разными другими видами мышления, приложимыми к инженерии -- в том числе разными вариантами личностных уникальных стилей мышления отдельных выдающихся инженеров прошлого. Конечно, любимое дело системных инженеров -- это взять какого-нибудь известного инженера 18 века и продемонстрировать, что он уже в то время делал "всё по уму". Но ведь в 18 веке люди не использовали понятия "система" в инженерном мышлении, и это использование не передавалось осознанно в учебниках. Что касается приводимых вами многочисленных примеров -- это всё про "мышление вообще", а не про системноинженерное мышление. То есть для меня вы обсуждаете вообще инженерию как таковую, в том числе включающую и альтернативы системной инженерии. Я готовлю системных инженеров, которым доступны в том числе и "прорывы", в том числе и "повторы". Современная системная инженерия занимается всеми стадиями жизненного цикла, отнюдь не только разработкой и даже отнюдь не только изготовлением (во всём их разнообразии), но и эксплуатацией, и выводом из эксплуатации. Поскольку я говорю именно о системной инженерии, то появилась и развилась она имено в aerospace, далее пошла в автомобильный транспорт, инфраструктуры, медицинское оборудование и сейчас по факту уже везде. Я тут не рассматриваю развитие "наколеночной", "гениальной", "специальной", "имени Шухова", "задачно-ориентированной", "проблемно-ориентированной" и прочих возможных инженерий. Меня волнует только системная инженерия, и мышление меня не интересует "вообще", "любое", "талантливых инженеров". Меня волнует мышление системных инженеров, оно очень специфическое, оно позволяет не-гениям добиваться вполне приличных результатов. В этом-то и фишка, что имена системных инженеров Дримлайнера, зонда Розетты и прочих подобных проектов не такие уж и знаменитые. Пафос "великих гениев" ушёл, этому нужно радоваться и развивать вполне рабочую дисциплину, развивать не на древних исторических примерах, а на сегодняшних практиках, с использованием САПРов.

Я бы предпочёл не искать ответ на вопрос "почему Шухов так сделал". Я бы предпочёл сразу учить системноинженерному мышлению. Как сделал Шухов без современных САПРов -- это не лучший опыт на сегодняшний день. Я пытаюсь учить мышлению, а не технологиям. Мышление, надеюсь, будет более-менее одинаково для людей разной квалификации. Технологии потом будут осваиваться в опоре на это дисциплинарное мышление. Поэтому на производстве или даже в студенческом проекте люди будут получать своё технологическое знание, а мыслительное знание будут получать одинаковое. В этом, кстати, фишка системноинженерного мышления, что оно должно позволять справиться с огромным кругом самых разных проблем -- помогать создавать самые разные виды систем. Содержание книжки должно определяться так, чтобы не переприцелиться. Хорошо бы эту книжку вообще в школе средней давать, чтобы потом её содержание всю жизнь использовать (как в школе дают 2*2=4, а потом даже седенький профессор это знание использует).

Пример с обучением программирования я унесу в конец книги, он получился чересчур развёрнутым и отвлекает. Если мне удастся сделать не столько "проблемное обучение", сколько свести всё к натаскиванию -- я буду счастлив. Мыслительным приёмам я буду учить натаскиванием, а проектные работы студентов буду использовать для оживления "натасканного знания". С сотрудниками так будет сложней, они натаскиваться не любят, забыли уже как учиться (и это беда: они почему-то думают, что можно сразу работать, без выполнения упражнений и прочих тренировок). Паузы у меня в книжке есть: по каждой главе проводятся занятия, где материал книжки соотносится с материалом из жизни студентов или сотрудников. Но это, конечно, не паузы в нарративе. Меня нарративность и вообще средства преподнесения знаний на данной стадии меньше волнуют, чем необходимость собрать в одном тексте минимальный набор диаграмм и соответствующих им мыслительных конструкций и эвристик, составляющих основу системноинженерного мышления. Конечно, instructional design и дидактикой я займусь, но потом. Про "видео" (если я опять-таки догадываюсь, о чём вы пишете). У меня используется схемное мышление: книга предполагает мышление прямо по приводимым в ней концептуальным схемам (диаграмма семи альф инженерного проекта, обобщённая диаграмма описания системы и т.д.). Я думаю, как показать, что Essence Language (а потом SysMoLan) и есть язык, на котором можно записывать инженерное знание -- в том числе и материал книжки. И дальше его пакетировать/перепакетировать по потребности (в том числе использовать projectional способ реализации множества view -- выписывать только ту махонькую диаграммку, которая нужна для обсуждения того или иного конкретного вопроса). Текст же в книге -- это демонстрация разворачивания схемы. То есть для меня ваши "два языка" вполне присутствуют. Ну, плюс я по всей книжке аккуратно стараюсь приводить примеры терминологии и аналогичных понятий из самых разных школ мысли -- чтобы всё время было сравнение того, что в моей книжке и в других книжках. Если читать, прорабатывая ссылки на литературу, то вся эта "многоязычность" будет очевидной. Краткое изложение (синопсис) важно, вписал в план. По факту у меня есть 25-страничный англоязычный текст краткого изложения книжки, но это не совсем то, что нужно.

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

попридираюсь к некоторым формулировкам обе на стр.80 1. Команда создаёт определение и воплощение системы, команда выполняет работы, команда применяет технологии (практики, поддержанные инструментами) С учётом того, что ранее практики определялись как дисциплины + технологии, то выглядит как рекурсивное определение. 2. Как-то неоднозначно сформулировано: "Так и в случае софта: воплощение программной системы—это исполняющаяся (иногда в тысячах и миллионах экземплярах) программа, а не исходный её код. Воплощение системы используется стейкхолдерами, оно реализует возможности. Воплощение системы удовлетворяет определению системы. Основная дисциплина работы над воплощением системы--это производство. Альфой воплощения системы занимается системный инженер." Так и хочется съязвить, что воплощением программной системы (если уж мы определяем воплощение как поля и вещество) занимается компилятор, а не системный инжинер.

1. Тут хитрый момент: Way of Working я перевёл как "технологии" (ибо они находятся в менеджерской зоне ответственности -- и там просто инструменты и рабочие продукты). Но на самом деле там, наверное, должно быть методы целиком (наборы практик, в которые входят и технологии тоже. Плюс набор практик в методе должен закрывать всё нужное для выполнения работ полностью). Так что там корявость сидит изначально, а формулировку вы правы, нужно бы поправить. Я вот думаю, не поправить ли мне радикально, честно написав "методы" -- но явно не инженерный менеджер ответственен за методы в целом. Хотя если это technology manager, то почему бы и нет. Но в этом случае диаграммку альф придётся перерисовывать. Так что -- больная тема, вы правы. 2. Из инструментов воплощением системы занимается launcher, а не компилятор (после которого ещё и мейкер обычно трудится, перед лончером). Практики эти -- практики deployment, запуска в эксплуатацию. Ключевое слово "запуск" в любом случае, а не "преобразование данных". Ибо даже откомпилированная программа это только описание, и адреса в ней относительные, а не абсолютные.