September 5th, 2009

2021 год

Мои заметки с двенадцатого заседания Русского отделения INCOSE

Вот мои заметки с 12-го заседания Русского отделения INCOSE, на котором рассматривалась история строительства завода пестицидов в Беларуси (http://community.livejournal.com/incose_ru/6610.html):

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

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

Еще нет культуры договаривания, которая предусмотрена даже на уровне стандарта ISO 15288 (там нужно избавляться от "непрактичных" требований заинтересованных лиц, посредничать в переговорах между заинтересованными лицами с противоречивыми требованиями и т.д.). Вместо культуры договаривания, близкой Западу, у нас в России чаще всего можно встретить культуру "подвига проталкивания своей идеи" (докладчик тут ссылается на работу Лефевра про две этические системы, сверхкратко изложенную в http://www.reflexion.ru/Library/Lefebvre_2002_1.htm). Тем самым задача освоения системной инженерии в России неожиданно может превратиться в практически нерешаемую задачу культурной политики -- изменения этической системы с совковой на иную. Ну, или нужно смириться со следующими двумя вариантами:
-- проекты будут делаться во время и в рамках бюджета. Но сколько при этом будет расстреляно людей, и какое у участников этих проектов настроение -- не нужно спрашивать. "Битва за урожай" -- это говорилось совершенно не случайно.
-- для занятий системной инженерией нужно поменять страну (или даже глобус).
Очень интересно, насколько эта страновая культура может быть преодолена на отдельных предприятиях, чтобы вместо "совковой инженерии" мы получили инженерию системную.

Еще один интересный аспект -- это вечная дискуссия про отличие agile-проектов от анархических, в которых работы не планируются никаким образом, и не используются никакие методы хранения. Интересно наблюдать, как сторонники дисциплины "водопадного" подхода не могут вообразить наличие любой другой дисциплины. С их точки зрения, если игра не идет по правилам шахмат, то игра обязательно идет без правил вообще -- и тогда она вообще не игра. Игры в футбол или в Го они не могут себе представить вообще. Объяснить, что у agile планирование и архитектурная работа подчиняются не менее жесткой дисциплине, чем при водопадном подходе, оказывается практически невозможным. Тем не менее, в жизни более чем регулярно встречаются ситуации, когда водопадный подход не применяется -- и эти ситуации почему-то автоматически приписываются к agile. Как будто, если я пишу не правой рукой, значит я автоматически пишу левой. Нет! Я ведь могу при этом писать ногой (с соответствующим ноге качеством письма), или даже вообще не писать. В ситуациях неприменения водопадного подхода agile чаще всего тоже не применяется, что бы об этом не говорили (например, если нет регулярных релизов, связанных с ними пересмотров выделения ресурсов, планирования итераций, то при чем тут agile?). Основные беды в проектном управлении не от водопада или agile-подхода, а от полного отсутствия метода.

Еще мне понравился подход системных инженеров к применению пестицидов (как я понял, огромное большинство народу их именно так и применяет) -- "лекарства для растений" при "самолечении" используются так же, как и любые другие средства: "пробовал я от насморка ваш фталазол -- насморк остался, хотя я и выпил сразу полпачки!".
2021 год

Визуализация управления кофигурацией: кино про историю разработок

Удивительные фильмы про историю таких проектов, как Python, PostrgeSQL, Eclipse, Apache -- http://vis.cs.ucdavis.edu/~ogawa/codeswarm/. Сценарии к этим фильмам брались из базы данных репозиториев: кто когда что коммитил.

Все проекты совершенно уникальны. Python чудесен тем, что там много лет код правил один человек, а затем вдруг (через много-много лет) пришла популярность, и разработчиков стало много. Apache интересен тем, что довольно долго разработка продолжалась в виде планирования (т.е. много людей писало много документации). В Eclipse пришлось вставить ремарку, что такая картинка была, очевидно, из-за огромной финансовой и организационной поддержки из коммерческого сектора.

Интересно бы реализовать такую штуку для САПРовских (а не софтовых) репозиториев типа SmarTeam или SmartPlant Foundation. Хотя там жизнь может быть чуть другая: разрабатывает кто-то один, а коммитит другой. Ну, или коммитит всех подряд с одного логина какая-нибудь "девушка из архива". Есть и еще вариант, что визуализация хороша для документо(файло)центричной разработки, а вот для датацентрики нужно придумывать что-то другое. Но это все детали, а сама мысль про историю разработки как историю работы вовлеченных в нее людей -- рулит. Что такое разработка? Это коммиты (или, как говорят САПРовцы, "публикации"). Кто делает публикации? Люди. Тем самым, разработка -- это а) история б) сделанных людьми в) публикаций (да, я знаю, что это лишь одна из многих важных тематических групп описаний разработки).

Для меня это хороший пример учебного видео: дается "общая картинка" разработки. Лес, который можно разглядеть за деревьями. Только нужно также обязательно помянуть факт, что "история учит лишь тому, что ничему не учит".
2021 год

На всех не наупрощаешься. Будет следующая версия грамотности.

Снова и снова встает вопрос: нужно ли нам предельно упрощать методы (т.е. способы получения "гарантированно превосходного результата" в какой-то предметной области), или все-таки подтягивать пользователей до такого уровня, чтобы он нашими сложными методами мог воспользоваться?! Вновь и вновь звучит аргумент, что пользователи даны такими, какие они есть, и слишком сложные методы не имеют шансов. Упрощать, без вариантов.

Но ведь не все методы можно упростить! Некоторые описания имеют огромную сложность в восприятии не потому как они еще не упрощены, а потому как без необходимой сложности этих описаний нельзя отразить сложность мира. Есть предел упрощениям!

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

Аргумент у меня исторический: когда-то большинство "пользователей" не могли ни читать, ни писать. Тем самым для них было закрыто огромное количество самых простых моделей. Жизнь потребовала, чтобы умение читать и писать появилось практически у каждого "пользователя". Мир не смог упроститься, чтобы им было удобно пользоваться без умения читать и писать. Я думаю, что следующим шагом будет умение читать и писать не только "просто тексты", но модели. Ага, чтение разных моделей и моделирование будут (о чем и говорит все время Алан Кей, http://ailev.livejournal.com/470473.html) элементами обычной (для будущего) грамотности (тут я не вдаюсь в подробности, будет ли эта "грамотность" уделом пользователей-людей, или киборгов, или ИскИнов, ибо понимаю, что говорю о довольно длительных промежутках времени -- пары десятков лет вблизи сингулярности достаточно, чтобы эта оговорка могла быть важной, а такие культурные сдвиги за меньшее время не происходят).

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

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

Почему речь идет именно о моделировании? Да это же просто продолжение письма и чтения (способов описывания мира) другими средствами, более точными и мощными, чем "просто текст". Это просто грамотность, следующая версия.

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