Category: природа

2019

DEMO, лидерство и WBS

Александр Турханов высказал очень интересную идею по поводу DEMO как основании для обсуждения всех этих утопических идей про использование диаграмм Гантта и водопада в проектировании (https://www.facebook.com/ailevenchuk/posts/10211453008814943) -- там же всё на предмет прямых поручений, коммуникативная парадигма, волнуют контракты! А если работа множества стейкхолдеров, как в проектировании, то понятие "контракта/поручения" как диецовской трансакции рассыпается вдребезги, даже если менеджеры пытаются изобразить его наличие. Если никто не знает, что кому поручать, то какие контракты?! Какие трансакции?! Тут кейс-менеджмент с его "запиши проблему, потом пойми, что происходит, потом нарежь на задачи, а потом найди исполнителя и поручи" -- вот тут он и перебивает коммуникативные DEMO или RAD. Вот тут мы большой кусок DEMO на русский переводили: http://ailev.livejournal.com/644440.html, а вот знаменитый отчёт Cordys 2008 года с разбирательством в парадигмах описания деятельности: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.225.9160&rep=rep1&type=pdf. А вот тут ещё Турханов связывает DEMO с проблемами лидерства (там же про полномочия: кто кого на роль назначает и поручает затем дела в этой роли): https://www.facebook.com/groups/234341783638239/permalink/323481494724267/

Мы как-то моделировали в DEMO, купили даже платный моделер Xemod для этого (http://www.ee-institute.org/en/demo/tools -- похоже, уже этого редактора нет в природе). Результаты ну очень были интересные (показали безумность текущего состояния дел с распределением полномочий), только ни разу не могли быть использованы для постановки задачи на инструментальную поддержку со стороны IT. Они были про людей, их полномочия, распределение обязанностей -- ровно то, для чего DEMO предназначено. Но "советы начальникам" были никому (включая начальников) не нужны, нужно было только моделирование процедур для поддержки их каким-нибудь софтом. Это было совсем никак, и всё наше моделирование на DEMO надолго загнулось.

Интересно было бы перечитать все эти материалы по DEMO (а их -- тьма) с высоты сегодняшнего нашего понимания. Наверняка из этих материалов вычитается много нового. Например, десяток лет назад, когда мы всё это DEMO активно обсуждали, нас интересовала связь DEMO с процессным подходом в его классическом понимании. А теперь интересует связь с case management. И хоть исследование cordys говорит, что DEMO для кейсов ну никак не пригодно, это не означает, что нет продуктивного стыка -- интересно было бы получить прожекторную модель, из которой коммуникационное частное описание (view) получалось бы просто отфильтровыванием нужных элементов, равно как описание продукт-ориентированное получалось бы отфильтровыванием других нужных для него элементов. А часть элементов в них могла бы совпадать, те самые correspondence links из ISO 42010.
2019

Эволюция процессных стандартов: четыре поколения

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

На картинке изображена корова человеческого общества, которая переваривает разные "процессные" стандарты.

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

Второе поколение -- ISO 24774, 15504 и следующий им 15288, а также всякие PMBoK, CMMI и подобные -- находятся как раз в кишках. Идет активный процесс переваривания, нанесение корове общества этими стандартами непоправимой пользы. Суть: "не забывай, что хорошая работа подразумевает выполнение "хороших практик". Получи невнятное описание этих практик, а мы проверим, следуешь ли ты им". Очень скоро эти стандарты будут окончательно переварены, покинут корову, и тогда вся нынешняя экосистема ISO 9000 перейдет на них.

Третье поколение -- OMG SPEM и ISO 24744 -- корова жуёт, но еще не проглотила. Суть: "общего метода работы не существует. Вот тебе шаблон, по которому можешь внятно описать свой собственный метод работы, или уточнить для себя чей-нибудь удачный опыт. Можешь, конечно, писать ахинею, но мы проверим, что в описании этой ахинеи ты подумаешь о практиках, их использовании в каком-то виде жизненного цикла, модели продукта, акторах, профессиональных наставлениях и прочих чертах грамотного описания метода -- ну, а как ты будешь проверять выполнение написанного, нас пока не интересует, это твоя проблема. Нас больше интересует, как ты по шаблону описания будешь порождать конкретные проекты".

Четвертое поколение -- продукт консорциума SEMAT -- у коровы в мозгах. Она его еще не съела (ибо его нет), но она о нем уже задумывается, как бы его добыть. Суть: "а что вообще существенно для стандартизации деятельности? Из чего состоит метод? Когда мы это поймем, мы перестанем стандартизировать бессмысленные задачи, а затем контролировать их выполнение".
2019

Мои заметки с двенадцатого заседания Русского отделения 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-подхода, а от полного отсутствия метода.

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

Лебединое озеро. Танец маленьких лягушат.

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

Теперь ищу по торрент-сетям полную версию.