?

Log in

No account? Create an account
Лабораторный журнал -- Day [entries|friends|calendar]
Anatoly Levenchuk

[ website | Лабораторный журнал ]
[ userinfo | livejournal userinfo ]
[ calendar | livejournal calendar ]

Системный подход и жизнь [21 Nov 2012|04:45pm]
Один из форматов, в котором мы работаем с клиентами -- это "рассказы" (не хочется обзывать их лекциями, ибо тип работы не "магнитофонный", а диалоговый -- с вопросами в обе стороны, но акцент всё-таки на презентации некоторого содержания), сопровождающиеся "рабочими сессиями", где происходит попытка применения нового материала к реалиям жизни клиента. На этих "рабочих сессиях" происходит осознание рассказанного.

С понятием "система" происходит одно и то же: в рассказе (несмотря на многочисленные примеры, предупреждения и декларации) кажется всё понятным и "невинным" -- совершенно непонятно, чего это вдруг мы уделяем этому вопросу такое внимание, говорим, что это центральное понятие. Всем кажется, что рассказывается ровно то, что и так происходит: конечно, всё состоит из систем, системы сами являются подсистемами, имеют подсистемы, их можно представить и как жизненные циклы...

На "рабочих сессиях" вдруг оказывается, что в реальности никакого системного рассмотрения не велось: разные люди по чуть-чуть рассматривали разные аспекты системы, но никогда эти разные аспекты не обсуждались вместе. И это системное рассмотрение жизни оказывается крайне продуктивным, хотя зачастую и болезненным -- из этого рассмотрения выскакивают новые знания, а "многия знания -- многия печали".

Пару лет назад я уже приводил пример упражнения "системная медитация" для личной работы (http://ailev.livejournal.com/847044.html), а вот коротенький вариант для производства (выполняется обычно коллективно топами, детали не прописываю -- всё-таки это для тех, кто слушал наши рассказы):

1. Убедитесь, что вся работа делается на хорошо видимом всеми флипчарте. Вы не гроссмейстеры, для думания вам нужна доска с фигурами, "по памяти" играть трудно. Для взаимокоординации вам нужно табло, одна версия на всех. Если флипчарта там, где вы обычно совещаетесь, нет, то прервитесь и обеспечьте.

2. Без имён систем их обсуждать невозможно. Выпишите список систем, которые вы делаете. Что это -- индивиды (с серийными номерами?), классы (описываемые строчкой каталога серии)? Отдельные уникальные системы или платформы/продуктовые линии? Где границы этих систем, какие между ними отношения? Что между ними общего, а что разного?

3. Есть ли у вас люди, ответственные за поддержание такого списка? Контрольный вопрос: в чьём компьютере этот список лежит, кто уполномочен вносить изменения в список "чем занимаемся"?

4. Подсистемами каких систем ваших клиентов являются ваши системы? Что вы об этом знаете? Как вы помогаете вашим клиентам в проектировании их систем с использовании ваших систем в качестве подсистем?

5. Пересмотрите список ваших систем, вам обязательно захочется его поменять. Если ответственного за список нет, назначьте ответственного (в чьём компьютере этот список будет жить): этот пересмотр списка нужно делать постоянно, и он его и будет делать.

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

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

8. Понимаем, что система-как-жизненный-цикл является основным инструментом договорённостей между менеджерами (для которых стадии -- это проекты) и инженерами (для которых стадии -- это инженерные мероприятия), в том числе между менеджерами и инженерами клиентов и подрядчиков. У кого в компьютере живут описания/модели (полных!) жизненных циклов ваших систем?

9. Опять подумайте, какие у вас системы (напомню: платформы и продуктные линии, мелкие и крупные серии, уникальные системы, сервисы и т.д.). Вернитесь к списку и опять поменяйте его.

Теперь есть шанс, что при разговоре о вашем предпринятии (то бишь, "чего предпринимаем") принимавшие участие в этих обсуждениях хотя бы чуть-чуть понимают, что делают, до чего договорились, кто за что ответственен. И понимают, чего они не понимают, и о чём пока не договорились, и у кого на эту тему непониманий и недоговорок должна болеть голова.

Наш опыт показывает, что самостоятельно такую процедуру проделать очень сложно: она очень, очень болезненна, а люди предпочитают быть политкорректными -- и "для безопасности" тут же съезжают с обсуждения их реальных систем на обсуждение каких-то общеотраслевых генерализаций типа ЕСКД, или даже собственных беззубых (иначе бы их никто не утвердил) документов службы обеспечения качества. Ибо когда игра в производственный бисер начинает происходить "на доске" с отображением результатов "на табло", все нестыковки в понимании целевых систем, их границ "вверх" и "вниз" по цепочкам кооперации, нестыковки в приоритетах учёта интересов обеспечивающих систем тех или иных стадий жизненного цикла становятся очевидными -- и трудно удержаться от перехода обсуждения в традиционное "кто виноват" вместо конструктивного "что делать".

И только после такого первого прохода "называния систем" люди начинают подозревать, что "системный подход" -- это не совсем то (точнее, совсем не то), что они всегда думали.

И ведь это только самое начало работы, материал первых нескольких часов рассказа. Обратите внимание, ещё ведь не дошли ни до каких практик жизненного цикла, и даже вид жизненного цикла не обсуждали, только попытались его изобразить в самой примитивной нотации, и выяснить, для каких систем это нужно сделать.
5 comments|post comment

Глюки с табами в FireFox 17 -- это старая версия Tab Mix Plus [21 Nov 2012|05:21pm]
Глюки открытия табов в FireFox 17 -- верный признак старой версии Tab Mix Plus. Брать новую версию нужно не в базе данных Мозиллы (там обычно старая какая-то лежит), а тут: http://tmp.garyr.net/forum/viewtopic.php?t=15740 -- там качать файл по ссылке latest, и добавлять его через меню Tools -- Add-ons -- шестерёнку в правом верхнем углу страницы -- добавить из файла).

И всё немедленно наладится.
2 comments|post comment

Критерии оценки софта для моделирования [21 Nov 2012|10:30pm]
Вот некоторый чеклист оценки софта для моделирования, по литературе и из набитых собственноголовно шишек:
-- наличие поддерживаемого стандарта мета-модели (то есть не "уникальная мета-модель, придуманная поставщиком софта")
-- альтернативные представления (прежде всего -- графическое и текстовое)
-- полнота поддержки стандарта мета-модели
-- возможности расширения мета-модели (особенно, если стандарт предусматривает это в мета-модели)
-- поддержка модульности модели (часто модульность не предусмотрена стандартом моделирования, а каждый моделер понимает это по-своему), полноценная идентификация любой части модели
-- паттерны, шаблоны моделирования
-- интерфейсный сахар (типа autocomplete)
-- не падать и не замедляться на очень крупных моделях
-- контроль конфигурации (полноценная идентификация версионности частей модели), сравнение моделей
-- многопользовательская работа (эккаунты, блокировки, доступ через интернет к общему репозиторию для редактирования, секьюрити, бэкапы, доступ к репозиторию с мобильных устройств хотя бы для просмотра).
-- issue tracker с привязкой issue к модели
-- возможность локализации не только имён, но и самой метамодели (полезно, когда рядом с модельером сидит эксперт и смотрит "под руку" -- на родном языке эксперта дело идёт быстрее)
-- аннотирование объектов и отношений
-- авторазводка/авторазмещение на странице
-- редактирование размещения на странице (influence layout)
-- язык скриптования моделера, наличие плагинов (валидаторов, адапторов, солверов, оптимизаторов, альтернативных обработчиков и т.д.). Сюда же -- всякие "триггеры", business rules, наличие API и прочие "обработки" и "настройки на предметную область". То есть: это платформа моделирования, или таки "просто моделер"?
-- возможность создания форм для ввода (в том числе -- табличный ввод)
-- генератор отчётов,
-- рендеринг в векторном формате (например, .PDF) для крупных распечаток "на стену"
-- импорт-экспорт модели в понятном формате (и возможность импорта-экспорта понятных фрагментов модели)
-- адаптеры "из коробки" для экспорта/импорта моделей в/из других систем
-- поддержка разработчика, развитое комьюнити
-- анонимизация (чтобы иметь возможность послать кусок модели куда-нибудь на форум или в службу поддержки для получения помощи, но без раскрытия sensitive information)
-- стандартное бинарное представление, позволяющее реификацию (включая подпись и шифрование) без перекодирования
-- free as in beer (бесплатный софт, freeware),
-- free as in speech (доступность исходных кодов и свобода их использования)
-- ...

Я пока игнорирую возможное разбиение на "условную САПР-часть" и "условную PLM-часть".

Этот список можно добавлять бесконечно, но чеклисты должны быть не "для всего", а лишь "для самого важного, часто забываемого". Что я пропустил из важного?
33 comments|post comment

navigation
[ viewing | November 21st, 2012 ]
[ go | previous day|next day ]