Обсуждение

_Пока не замечено плотного общения между системными инженерами и специалистами в работе с людьми_ Приходилось мне наблюдать подобные отношения как из одного лагеря, так и из другого. IMHO, отношения эти хорошо иллюстрируются сказкой "Лиса и журавль". Причем выход из взаимного непонимания находится путем естественного отбора, когда появляются такие голодные журавли, которые-таки умудряются поесть манной каши, размазанной по тарелке. Тогда лиса и скажет, мол вот видите, значит все было правильно, может, если захочет. Или наоборот, находятся лисы, исхитряющиеся поесть из кувшина с узким горлышком... Поиск таких экзотические примеров и понимается как путь правильного, успешного взаимодействия между инженерами и психологами. Можно ли удивляться тому, что реальный обмен знаниями между системной инженерией и психологией близок к нулю?

Я тоже регулярно бывал в этих двух лагерях с разных сторон баррикады (которая декларируется, как несуществующая -- но она ого-го какая!). Разговор глухих со слепыми -- разные цели, средства, язык, понимание мира, метафоры, приоритеты и т.д. Но что-то делать нужно. Мы попробуем.

Если в систему включена переменная "человек", то вся история превращается в сказку про мотивацию. В принципе, я б смотрел на опыт Тойоты. Пока что у них лучшее, что я видел. Правда, это для рутинной работы. Как начинается творчество и сама инженерная деятельность, начинаются траблы и интересная информация оказывается закрытой. Кстати, банальный пересказ модели "водопад" не полон, потому как при переносе из древних источников потеряли обратные процессы корректировки. Спираль - это просто последовательность маленьких водопадиков. В принципе, основная модель идёт не для мелкого построения процесса, а для планирования бюджета. Про RUP и SCRUM скромно промолчу. Кстати, есть эргономика, есть Usability Engineering. Хотя, последнее ещё более шаманство, чем идущее под лейблом agile.

_Разговор глухих со слепыми -- разные цели, средства, язык, понимание мира, метафоры, приоритеты и т.д._ Да, ситуация примерно такая. Если говорить о сближении... Думается, что серьезное сближение не возможно, пока человек в инженерной системе рассматривается как необходимый, но вредный элемент. Тот, кто может что-то испортить, чему-то помешать своей непредсказуемостью. И, наоборот, машины своей ориентированностью на что-то свое воспринимаются человеком как что-то чуждое (либо ниже меня -- тупые, либо выше меня -- монстры). Сближение нужно искать не в ограничениях, а в возможностях. Исходить не из того, что человек, вынужденно появляющийся в инженерной системе -- это проблема, а наоборот, искать плюсы в появлении человека в системе, стремиться к тому, чтобы появление человека увеличило возможности системы в целом. Разные есть подходы к этому. Посмотрите, например, книжку Грановской. Кстати. В предыдущих постах Вы выражали скепсис по поводу использования UML как графического языка. Зачем вообще нужно какое-то рисование картинок, если текст будет более строгим и точным... Может быть эта книжка как-то объяснит, какие задачи решаются рисованием картинок в инженерной документации.

Да, дальше все переходит к сказкам, увы. И выигрывают лучшие рассказчики, и даже не лучшие сказки. Наш клиент работает с Тойотой. Но это правда, у них хорошо там, где логистика и ручной труд -- но и то, если фокусировать их усилия по Голдратту. А где мозговой труд и непонятки с процессом там у них не так получается. Но это вообще пока не решаемая задача, с умственным трудом (хотя иногда обсуждается как concurrent engineering, но работ по описанию явно успешных методов я пока не видел). Насчет agile, так тут в лидерах ICM (incremental commitment model, я немного писал об этом у себя в блоге). Это очень свеженькое, полтора годика всего, но очень убедительно -- и по сути это гибрид "водопада" и agile, в котором необходимая степень гибридизации должна быть построена соответственно профилю рисков конкретного проекта (т.е. для некоторых проектов получается жесткий план, а для некоторых -- полный экстрим). Usability сейчас в раздрызге: с одной стороны там humans-systems integration как самая свежая попытка обозначить проблему (ибо не все сводится к usability -- не только ведь систему под людей нужно подгонять! Нужно ведь еще и людей под системы как-то подгонять, это только сейчас сообразили), а в чистом виде usability стремительно уходит в user experience, и это отражено в соответствующих стандартах ISO, там в текущих проектах поменяли уже термин usability на user experience в силу более широкого значения этого experience. Я от этого шаманства стараюсь пока держаться подальше, хотя и отслеживаю немного, мне более перспективным кажется именно двустороннее взаимодействие, что отражается в human-systems integration (а в пределе там ставится вопрос киберфизической системы как hardware+software integration -- http://www.infoq.com/presentations/Model-Based-Design-Janos-Sztipanovits, а затем еще и учет в этом людей, с учетом того, что людей тоже бы нужно готовить по особому жизненному циклу).

> Это мы стремительно переходим от рассказа о том, как хороша и что из себя представляет системная инженерия к рассказу о том, как перейти к ней в условиях конкретной организации. Наконец-то я понял, чем занимается системная инженерия :)

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

размышления на тему - немного длинно, чтобы писать комментарием: http://bowin.livejournal.com/791785.html

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

Анатолий, данную проблему также трогает за вымя теория деятельности. Кстати во вторник (31.03) в Мск будет семинар на эту тему, вот анонс: http://sigchi.ru/Seminars/20/index.htm

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