Category: путешествия

2019

Управление жизненным циклом и управление работами

Управление работами и управление жизненным циклом
Стадии жизненного цикла в водопадном виде жизненного цикла заканчивались предварительно запланированными гейтами, в которых независимыми экспертами оценивались собранные в единое целое результаты предыдущей стадии и принималось решение о продолжении проекта на следующей стадии (go/no-go). Если до момента назначенного рассмотрения проекта независимыми экспертами в рамках прохождения гейта кто-то из разработчиков частей системы не успевал закончить разработку своей части и проверку того, насколько она не нарушает работу всей системы в целом, то весь проект ждал окончания работ этого разработчика. Гейты как раз и были задуманы, чтобы выявить системные риски появления конфигурационных коллизий, неочевидных системных эффектов, непредвиденных трудностей в разработке отдельных частей системы. И если не включить в рассмотрение результаты чьей-то частной работы, то появляется риск неучёта каких-то системных эффектов в целой работе.

В ранних версиях жизненного цикла крупных (прежде всего аэрокосмических, традиционных для системной инженерии) проектов гейтов было порядка пятнадцати, и проект надолго останавливался во всех пятнадцати точках для сведения всех отдельных разработок в непротиворечивое и лишённое конфигурационных коллизий целое и последующего просмотра результатов работ стадии независимыми экспертами. По мере осознания того, что водопадная модель с гейтами является утопией, появления компьютерных систем управления конфигурацией и изменениями и уменьшения числа конфигурационных коллизий, перехода к параллельной инженерии, число гейтов сокращалось. В авиации гейтов сначала стало порядка семи, а нынче их всего три, при этом даже не все из них связаны с инженерией: например, решение о сворачивании проекта принимается, когда проектирование зашло уже довольно далеко, но не собран достаточный для уверенности в финансовом успехе проекта пакет предзаказов на новую модель самолёта (Altfeld, Hans-Henrich. Commercial aircraft projects: managing the development of highly complex products, 2010).

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

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

Виды практик управления работами
В управлении жизненным циклом в том числе принимается решение о том, какие практики управления работами выбрать, ибо существует большое разнообразие этих практик.
Классическое управление проектами (project management, проектное управление) подразумевает одномоментное планирование перед началом всех работ для всех контрольных точек как сроков их достижения, так и работ по их достижению (то есть назначение ресурсов на работы происходит в момент планирования всех работ сразу, а не каждой отдельной работы). По факту это означает составление плана-графика выполнения работ с назначением ресурсов на эти работы ещё до начала выполнения работ. Это часто называют предварительным (up-front) планированием работ, а весь проект просто считают уникальной работой, имеющей чётко определённые время начала и конца, а также выделенные для неё ресурсы.

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

Если непонятно, какие могут быть контрольные точки больших кусков работы, то речь идёт об управлении программами (program management). По мере понимания этих контрольных точек программой запускаются проекты ведения работ по их достижению, используя предварительное планирование достижения каждой из них. Но нет плана запуска отдельных проектов программы, ибо деятельность программы как раз и состоит в определении этих проектов и планировании их, дальше работы проектов управляются стандартными методами проектного управления. Управление программами отличается от остальных методов управления работами тем, что отношение часть-целое в них меняет тип управления работами, а в остальных методах нет: в программах обычно нет «подпрограмм», но есть «проекты». В проектах же обычно подпроекты, процессах подпроцессы, в кейсах подкейсы и т.д..

Если контрольные точки и ресурсы для их выполнения известны, но неизвестно, в какой момент происходит запуск большого числа однотипных работ, речь идёт о процессном управлении (process management). Процессом тут называют не уникальную работу, а типовую последовательность шагов, обычно определяемую не столько планом (и уж тем более не графиком), а регламентом.

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

Особенно это проявилось в проектах программной инженерии, где программные системы были очень непохожи, и нельзя было даже сделать предположений, какие работы нужно включать в план их разработки – в отличие от зданий, где заранее было известно, что нужно будет делать фундамент и возводить стены, а потом делать монтаж оборудования и внутреннюю отделку, в отличие от самолётов, где сразу понятно, что в составе самолёта будет фюзеляж, крылья, салон, в программных продуктах нельзя сразу было сказать его состав, и поэтому работы по разработке нельзя было привязать к этому составу.

Общее для всех этих гибких методологий/методов и соответствующих им видам жизненного цикла в том, что они используют в части управления работами управление кейсами (case management, http://ailev.livejournal.com/946134.html) . Кейс -- ситуация, обстоятельства или начинание, которые требуют набора действий для получения приемлемого результата или достижения цели. Кейс фокусируется на предмете, над которым производятся действия (например, человек, судебное дело, страховой случай), и ведется постепенно появляющимися обстоятельствами дела.

Управление кейсами по факту обобщает управление проектами и процессами. В кейсе сначала мы имеем вопрос контрольной точки (формулировку кейса), после этого формулируется работа для прохождения этой контрольной точки (ибо формулирования задания на работу – отдельная операция, но контрольная точка может быть учтена задолго до этого), потом отдельно назначение ресурса на работы и тем самым разбирательство с планированием и графиком. Тут могут быть использованы удобные для управления кейсами методы планирования, например, канбан (Kanban for development, https://en.wikipedia.org/wiki/Kanban_(development), для управления кейсами прежде всего, для планирования производственных процессов используется обычно Kanban for manufacturing, https://en.wikipedia.org/wiki/Kanban). И даже тут жизнь контрольной точки в управлении кейсами не заканчивается, потому как в рамках управления изменениями конфигурации нужно сообщить участникам проекта, что кейс закрыт: состояние системы изменилось, и всем остальным нужно ориентироваться на новую ситуацию.

Технологии, используемые для гибких методов в управлении жизненным циклом и управления кейсами в управлении работами – это технологии трекинга контрольных точек (issue tracking, часто их называют «системы управления задачами», «системы отслеживания ошибок», «системы отслеживания поручений»). Название отражает тот факт, что контрольные точки появляются не в плановом порядке, они изначально представляют собой вопрос/проблему (issue), требующую своего решения. Трекеры (issue trackers, софт для трекинга контрольных точек) учитывают эти контрольные точки по мере их появления.

Конечно, если появляется возможность что-то спланировать, в управлении кейсами это делается. Часто тут план – это просто опыт прохождения какого-то кейса, шаблон. Вот этот план и будет называться шаблоном (template). Если шаблоны готовят не специально обученные программисты таких шаблонов, а сами участники команды проекта, то такое управление кейсами называют адаптивным (adaptive), а шаблоны – шаблонами сообщества (community template).

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

Вот схематическое изображение жизненного цикла одного из самых распространённых методов гибкой (agile) работы, SCRUM (https://en.wikipedia.org/wiki/Scrum_(software_development)):


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

Тренды в практиках управления работами
В более современных методах управления работами провозглашается, что практики назначаются на работы по мере возникновения потребности, ибо любые «итерации» представляют собой замаскированные гейты и означают, что какие-то ресурсы будут ждать назначения на работы после содержательных проверок конфигурационных коллизий. Нет, конфигурационные коллизии должны проверяться «в рабочем порядке», а не в специально отведённые времена окончания стадий или окончания итераций в жизненном цикле. Этот вопрос обсуждается на стыке управления работами и управления жизненным циклом и методы управления работами и жизненным циклом должны как-то соответствовать друг другу: проектное управление плохо сочетается с управлением кейсами, а вот канбан для разработки – хорошо.

И помним, что огромные тяжёлые детальные методологии не выживают сегодня, они дробятся на более мелкие практики, в дисциплинах выделяются отдельные принципы – и в каждом отдельном проекте по факту собирается свой метод работы, нужно только следить, чтобы все эти отдельные практики и принципы были как-то совместимы друг с другом и с реалиями проекта.

При этом в случае гибких методологий и связанных с ними моделей/видов жизненного цикла (принципов назначения работ на практики) речь идёт сегодня не о классическом проектном управлении как методе управления работами – но продолжает использоваться слово «проект» (project). Слово «проект» ведь использовалось и до появления дисциплины управления проектами, и продолжает использоваться вне связи с этой дисциплиной.

Сегодня «проектом» часто называется и процесс (особенно экземпляр процесса – процессом ведь называют тип), и кейс, и программа со множеством классических проектов внутри, и вообще любая инициатива, любое предпринятие (https://ailev.livejournal.com/1388412.html).

Современные проекты (если это не проект стадии воплощения системы – например, строительства здания по заранее разработанному проекту/design) отличаются отсутствием предварительно составленного плана, но железной дисциплиной инициирования работ на базе каких-то практик (дисциплин и поддерживающих их технологий), железной дисциплиной выделения ресурсов этим работам в рамках какой-то методологии управления работы. Гибкие методы/методологии в плане соблюдения дисциплины очень жестки, в них довольно много разных правил, и если под словом «гибкие методы» какая-то команда не в состоянии указать конкретный вариант жизненного цикла своего проекта (способы, которым практики жизненного цикла начинают разворачиваться во времени, чтобы из этих работ получился содержательный результат), то верить в успешное завершение проекта этой командой нельзя.

При указании варианта жизненного цикла команде не нужно говорить SCRUM, или DSDM (https://en.wikipedia.org/wiki/Dynamic_systems_development_method), или Open Kanban (https://github.com/agilelion/Open-Kanban), или приводить ещё какие-то названия больших методологий со многими практиками. Вряд ли сегодня какая-то команда использует эти методологии во всей их полноте. Но нужно явно и осознанно сказать, какие команда использует практики управления жизненным циклом и практики работы.

Какой выбрать вид жизненного цикла, какую гибкую методологию? Ответ на этот вопрос зависит от профиля рисков проекта, а этот профиль рисков определяется субъективно командой. Нет двух похожих проектов, нет двух похожих видов жизненного цикла. Даже если вы делаете подряд два похожих проекта, то в результате выполнения первого проекта команда получает опыт, и профиль рисков для команды будет другим. Это означает, что команда может для следующего похожего проекта (или даже в ходе текущего проекта!) подкорректировать практики своей работы, изменить вид жизненного цикла, изменить практики управления работой для того, чтобы учесть полученный опыт.

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

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10211939483976518
2019

lytdybr

Вьюнош получил в своё расписание ещё одну школу -- глубокого обучения. Ага, это в том же Дворце Пионеров, тьфу, корпусе МФТИ на Климентовском переулке -- https://deepmipt.github.io/dlschl/. После первого же занятия что-то пытался мне рассказать про мелкие сети. Гад, ничего не сказал про домашнее задание, а оно на странице школы уже есть. Смотрю я на это задание, и думаю, что не факт, что он эту школу успешно закончит. Совсем не факт. Школа-то для старших классов, а он только в девятом. Но без боя не сдадимся.

Три недели подряд (с момента отъезда в Мюнхен) у меня была невообразимая суета, читать ничего не успевал -- зато писал не переставая. В ЖЖ у меня за это время только крошечная часть написанного, остальное всё по работе, непублично -- десятками страниц. Эх, если бы я учебник писал такими темпами, я ведь с 8 октября его не трогал! А ещё куча нечитанной свежатинки по ИИ в табах, да отложенные книжки по рациональности, без которых уже никуда. К учебнику вернусь в ближайшие дни, написание поставлю в приоритет, и ничего читать до момента написания учебника не буду. А потом устрою себе читальный марафон по лонгридам, и будет мне счастье -- если опять не приключится какая-нибудь суета. В любом случае, мультитаскинг нужно удавливать. И почистить GTD, ибо список дел распух до невменяемости. Нужно уговорить себя на какие-то дела плюнуть.

Из-за этой суеты пришлось пропустить много занятий кизомбой. Но что-то всё равно посещал. Пару недель назад в Москве был фестиваль, куда приехало много танцоров из Парижа -- и все партнёрши на этом фестивале побывали. Партнёров же срочно учили танцевать так, как эти парижане -- ибо партнёрши от этого "французского стиля" были без ума, и с этим нужно было что-то делать. Вот, например, моё резюме третьего занятия по "французскому стилю" у Алёны Фортуновой:
1. Basic 1 по два раза с переменой ног. Тазовая пластина не крутится в горизонтальной плоскости, только в вертикальной, но зато вес просаживается полностью. Плечи не крутятся. Ведение не корпусом, а на некотором расстоянии (руки в нижней рамке). Проблемы в сползании всех партнёрш вправо, оттаптывании ног (хотя казалось бы, что там оттаптывать?!), несимметричной просадке, перемены ног вовремя, ритмике переноса веса.
1а. Партнёрши при этом делают волну, а партнёры задают начало волны и акцент на возвращение руками. Это отдельный аттракцион.
2. Даблбит-шаги в свободной позиции с блокированием и прижиманием-вытягиванием вверх партнёрши, а затем отпусканием в свободную позицию. Сегодня у меня получалось почти всегда (кроме тех случаев, когда не получалось), хотя вытягивания вверх ещё нет и особого контраста расстояний тоже.
2а. Переход с блока на basic one, как отдельный аттракцион, а кому мало, так basic one с волной (у меня переход получался, а волна только на втором шаге после переноса веса).
3. Хождение дабл-битами буквой "Г" без промежуточных тепов. Фишка в том, чтобы не ходить по диагонали.
4. Тэп как в релоджике, только во французском стиле. Это просто.
5. Если всё это удалось, то можно получать удовольствие от танца. Если не удалось -- перейти к пункту 1, ибо танца ещё нет.
На третьем занятии это уже был не тот мрак и ужас, который был на первых двух занятиях. А на четвёртом занятии сняли видео -- я его посмотрел, и моё зарождающееся чувство собственной важности в кизомбе бесследно испарилось. Конечно, я уже не начинашка, но мой стиль до сих пор мрак и ужас. Нужно сосредоточиться и срочно его поправить. Хотя в танцах "срочно" в плане правки стиля -- это месяцы работы. Чудес не бывает, в двигательных практиках всё медленно.

Зато я за полный сегодняшний день тренинга сидел только полчаса -- за обедом. Но ноги к концу дня не устали. Раньше от такого я к вечеру просто валился с ног. Вот он, фитнес.
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

Интервью с Аланом Кеем для habrahabr

Вышло большое интервью с Аланом Кеем, в котором были и ответы на мои вопросы -- https://habrahabr.ru/post/333778/

Для меня Алан Кей ничего нового в ответах не сказал, но напомнил о своих тезисах:
-- компьютер удивительный музыкальный инструмент, на котором люди не играют удивительную музыку, а пищат и шумят (грубо говоря, используют компьютер как микроскоп, которым заколачивают гвозди -- и ситуация с этим всё печальней и печальней). Даже плохие сегодняшние компьютеры не используются по назначению, на них никто не учится быть умнее, на них учатся быть глупее. И тут дело не в компьютерах, а в людях: не пианино виновато, что на нём играют "Чижика" одним пальцем вместо Шопена. Если добавить нейроинтерфейс к компьютеру, то это не сделает человека умней в сегодняшней постановке задачи, так что неинтересно, нейроинтерфейсы не улучшат ситуацию. Если добавить нейропроцессор, то то же самое: человек от этого умней не станет, так что это пустое.
-- компьютерная революция будет не в тот момент, когда компьютер сумеет автоматизировать что-то ещё (разгрузит человека), а в тот момент, когда наоборот, компьютер сможет быть использован для того, чтобы человек смог выполнять более сложные задачки. Ну, типа компьютер из лестницы, ведущей мозг вниз, станет лестницей, ведущей мозг вверх. Конечно, для этого нужно будет дополнительно учиться, как учатся играть на скрипке (и тут я не могу не напомнить "Никто не хочет учиться играть на XYZ" -- http://ailev.livejournal.com/1158826.html, рынок такое не оплачивает). Но для этого нужно поменять всю систему образования, а для этого нужно осознать, что происходит развал цивилизации.
-- чтобы не происходил развал цивилизации, нужно учить человека всему контринтуитивному, что заложено в человеческую природу. Человеческую природу (в которой заложено враньё, жадность и т.д.) нужно из человека вытравлять, а для этого нужно придумать эффективные методы обучения новым способам жизни. Вот нужно брать идеи про новые способы культурной (а не дикой, не природной) жизни, потом оформлять их как образовательные программы, а потом массово учить им людей.
-- большинство новых языков программирования недостойны того, чтобы сажать их на текущее железо. Они плохи. Но если делать хорошие языки, то специально для них нужно делать хорошее железо. Ну, и это хорошее железо должно уметь эффективно работать с одним тредом, вся это многотредовость/мультиядерность -- тупик, резервы повышения производительности одного треда ещё далеко не исчерпаны, идей нет только у сотрудников текущих микропроцессорных гигантов. И за этими идеями идти нужно в 60-е, первые неправильные повороты в тупик были сделаны ещё тогда.

Читайте интервью сами, каждый там своё вычитает.

Удивительный человек, снимаю шляпу. Он продолжает грести против течения, много лет. И ужас в том, что его мысли мне глубоко симпатичны, я сам так считаю, но понимаю, что шансов этой утопической программе реализоваться нет. Ибо никто не хочет учиться играть на XYZ.
2019

Интеллект-стек 2016

Доложился сегодня по интеллект-стеку 2016 на конференции ICBDA'16 (бывшая BigData, http://icbda2016.org/), вот слайды (http://www.slideshare.net/ailev/2016-66091374):

Организаторы, как я понял, выложат для участников конференции видео, но это будет через некоторое время.

Предыдущий вариант этого доклада был ровно год тому назад, 25 сентября 2015 года (http://ailev.livejournal.com/1222210.html), и за этот год понапроисходило и продолжает происходить много чего интересного. Например, только за последнюю неделю (я не добавил это в слайды) ошибка распознавания речи в типичных условиях уменьшилась до 6.3%, что уже вполне сравнимо с человеческими 4% -- http://arxiv.org/abs/1609.03528, а ещё появилось исследование "что такое креативность" методами глубокого обучения (вы хотели ответа на вопрос "что такое творчество?", так вот искусственный интеллект вам, людишки, помогает на него ответить -- вытаскивает из ваших же текстах онтологию творчества -- 14 компонент "креативности", идентифицированных через анализ кластеров из слов в корпусе текстов по креативности): http://arxiv.org/abs/1609.03357, вытащенная онтология доступна в машиннообрабатываемом виде тут -- http://purl.org/creativity/ontology.

Примеры с экспериментами в области такси без водителей -- их уже два (Сингапур и Питтсбург) и следующий на очереди Бостон (http://www.ibtimes.com/self-driving-vehicles-boston-next-city-test-autonomous-vehicles-pittsburgh-testing-2416288).

Всё будет быстро, и даже ещё быстрее.
2019

Быстро ползёт улитка по глади воды

Видео моего прудовика -- как он выпускает из себя пузыри, ползёт по изнанке водной глади, и даже как его атакует сомик (снято вчера старинным Lumix GF1):
-- https://youtu.be/U5oON5THVQk
-- https://youtu.be/3XDdr4-kb6o

Никогда не думал, что улитки такие путешественники. Особенно интересны манёвры подводной лодки. Например, доплыть по поверхности на середину аквариума, быстро выпустить из себя пузырики и камнем пойти на дно, не спеша ползать там по камушкам, потом быстро-быстро вдруг выползти по стеклу на поверхность -- и опять резвиться на водной глади.
2019

Доклад "Будущее САПР"

Сегодня сделал доклад "Будущее САПР" на пленарке Autodesk University, слайды вот (http://www.slideshare.net/ailev/ss-53661321):


Доклад удался, хотя вряд ли вы поймёте его тезисы по картинкам на слайдах -- нужен ещё и рассказ. Видео снималось, обещали выложить через недельку или немного позже. Впрочем, я собираюсь рассказать этот доклад в чуть более подробном варианте на заседании Русского отделения INCOSE в следующую среду, там тоже планируется видеозапись, и выкладываем видео мы обычно быстро.

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

Было приятно узнать, что стартованная нами пару лет назад во ВНИИХОЛОДМАШе постановка практики управления жизненным циклом раскочегарилась так, что проект занял первое место на конкурсе Autodesk в России. Призом там поездка в Лас-Вегас на международный Autodesk University. Поеду в Лас-Вегас не я, но это немного и моя консалтерская победа. Вот:
P_20151007_124840
Поздравляю всю команду ВНИИХОЛОДМАША и помогавшую им в части продуктов Autodesk команду ProjectCom! Замечу, что УЖЦ -- это не единственная там стартованная нами практика. Думаю, скоро там будут ещё поводы ездить на зарубежные конференции -- чтобы не только на людей посмотреть, но и себя с докладом показать.

В этом году было чётко видно, что граница между проектным, процессным управлением и кейс-менеджментом потихоньку стирается. Я задавал некоторым докладчикам наводящие вопросы -- все они путались с показаниями насчёт "управления работами", "управления поручениями", "управлениями задачами" и т.д.. Уже большинство (но отнюдь не все!) знают про issue tracker, который есть в глубине их информационных систем, -- но на вопрос "вот у вас колонна, вот задача по заливке колонны, вот проектная работа по заливке колонны -- как они появляются?" ответ чаще всего -- "вручную", хотя и с разными мелкими нюансами. Контроль того, что каждая работа делается с частью системы, а каждая часть системы является предметом работы -- этого не предусматривается. Модели продукта/design и модели проекта/project "связаны" уже (что счастье по сравнению с прошлыми годами), но не "интегрированы". Задачи вежливо "экспортируются" из систем ведения дел/кейс-менеджмента в системы проектного управления, и дело с концом. ERP, как всегда, отдельная епархия (и не спрашивайте, как она используется -- модуль планирования в Enterprise Resource Planning обычно не задействован). Ладно, это я бурчу. Например, строителей и их айтишников нужно не ругать, а жалеть: отраслевое регулирование порождает ну очень специфические формы ведения деятельности и отчётности, тут не до жиру, быть бы живу. В любом случае, у строителей не столько "говорили о BIM", сколько "демонстрировали проекты BIM" -- прогресс очевиден, несмотря на все оговорки.

Поговорил в кулуарах с разными людьми: кто думает пообщаться с Autodesk насчёт их проектов Research и Labs? Никто. Не принято в России исследовать что-то самим и принимать участие в чужих исследованиях. Даже в университетах. No comments, я матом не ругаюсь.
2019

Десятые лебедевские чтения

Десятые чтения, посвящённые памяти Геннадия Лебедева, состоятся в субботу, 24 мая 2014 года, в 10:00, в Москве, гостиница Алроса: http://www.alrosa-hotels.ru/hotels/moscow/contacts/, это 5 минут от метро Полянка (и 7 минут от метро Третьяковка и Серпуховская).

Регистрация открыта на http://g-l-memorial.ice.ru

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

7-10 апреля меня нет в Москве, я в Бекасово

С завтрашнего вечера по воскресенье день -- я в Бекасово, на Рабочей встрече по проблемам системной инженерии, которую второй раз проводит Русское отделение INCOSE (http://community.livejournal.com/incose_ru/24241.html). Интернет там будет, ибо это пансионат Ростелекома.

Бюрократии в этом году много больше, бумажной волокиты по поселению -- в разы, толерантности к неопределенностям в заезде группы почти нет. "Мы теперь сертифицированы, поэтому у нас сейчас всё строго оформляется", так мне сегодня сказали в ответ на сравнение разницы процедур этого и прошлого года. Лекарство "процессного подхода" само стало болезнью, от которой уже впору лечить специально.

В воскресенье после обеда хочется успеть на ru_dreamflash, хотя это уже малореально. В прошлом году там люди крутились часов до восьми вечера, так что шанс застать что-то интересное имеется. Правда, к вечеру мыльных пузырей уже мало, только бродят усталые девушки с двухкилограммовыми камерами и длиннофокусной оптикой -- но в 2011 году они уже несколько лет как не экзотика...