?

Log in

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

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

У кого проекты, а у кого и прожекты. Попробуйте отличить одни от других. [20 Jun 2009|12:57am]
Закон Мура еще несколько лет будет действовать: в начале 2010 (т.е. меньше, чем через год) будет уже технология 28нм -- http://techon.nikkeibp.co.jp/english/NEWS_EN/20090618/171902/. А еще через четыре года будет остановочка в этой гонке нанометров (даже с учетом перехода к 3D-структурам, которые активно сегодня прорабатываются и показывают в опытных образцах примерно такую же плотность упаковки, как при 28нм -- http://techon.nikkeibp.co.jp/english/NEWS_EN/20090619/171977/). Остановочка будет потому, что стоимость оборудования для каждой новой проектной нормы существенно растет, и будет просто невыгодно производить чипы с высокими проектными нормами -- их никто не будет покупать в таких количествах, чтобы окупить новые производственные линии (http://techon.nikkeibp.co.jp/english/NEWS_EN/20090617/171857/). И придется менять архитектуры, чтобы выжать максимум из текущих проектных норм 2014 года.

Вот и развлечемся. Мы тут в комментах к предыдущим моим постам уже пообсуждали недавно возможный возврат к старым идеям типа лисп-машин и прочих "движков для логики", а не "для графики" или "для численных методов". Я бы начал делать COLA-процессор "в железе": если сейчас заложить стартап, то как раз к 2014 году можно уложиться, ибо в те поры уже будут разговаривать не о многих ядрах, а о совсем других вопросах -- в том числе и о смене традиционной системы команд для обеспечения мультипарадигмального программирования (и логического, и функционального, и объект-ориентированного).

Я в этих же тредах жаловался, что давно не слышал про "кремниевые компиляторы". Как же, вот они -- свеженькие поспели: http://techon.nikkeibp.co.jp/english/NEWS_EN/20090615/171747/. Компилятор из C прямо в кремний, C-to-silicon compiler.
* * *
В списке рассылки FONC/COLA/STEP/JOLT-и-т.д. сегодня промелькнуло интересное: один парень отмоделировал архитектуру этой системы прямо по исходным текстам статей на http://www.vpri.org (а не по кодам текущей реализации) на Python -- и в полном восторге.

А я бы построил на этой архитектуре полный стек, аналогичный OMG MDA, только бы не на MOF/UML, а на чем-то более гармоничном для COLA и мультипарадигмальном -- и наверняка получилось бы много компактней и красивей (особенно, если бы это делал не я сам, а команда из кого-нибудь помоложе. Я вот мучитально вспоминал сегодня: программировал ли я что-нибудь на каком-нибудь из прологов? Или только "изучал"? Давно ведь это было, всех языков и не упомнишь. Несколько месяцев на Форте, например, я точно помню. Но вот Пролог? Кажется, что сам ничего на нем так и не написал).

Обратим особое внимание: сама архитектура COLA предполагает плотную склейку ОО и функционального подхода, и немедленно после этого на ней был реализован язык представления знаний "логической" традиции (понятно, что и сам Prolog тоже попал в число первых же экспериментов).
* * *
Проект "Автономные [планетарные] поселения: комплексное проектирование и инфраструктура жизнедеятельности" (http://zv.innovaterussia.ru/project/476) и он же "Дизайн-концепция сервисного комплекса в контексте использования вахтового метода организации жизнедеятельности (http://zv.innovaterussia.ru/project/2536), он же "гечвоК" ("Ковчег" наоборот) имеют закрытый проектный сайт на team.ru -- с более чем полусотней участников. Рядом с заголовком на сайте проекта предупреждение: "разрабатывается ГИПОТЕТИЧЕСКОЕ РЕШЕНИЕ. Для понимания: "ЛУЧШИЙ ИСХОД ДЛЯ ЭТОГО ПРОЕКТА - ЕСЛИ ОН НЕ БУДЕТ ВОСТРЕБОВАН... НИКОГДА". Далее по тексту: "для автономного поселения подземного базирования, источником угрозы следует принять астероид размером в поперечнике 500 (пятьсот) метров («условно-базовая угроза»), а это определяет требуемую глубину размещения данного поселения как не менее 12-15 км в толще земной коры".

К вопросу о вероятности такой угрозы: репетиция по отслеживанию падения 80-тонного четырехметрового метеорита 7 октября 2008г. (еще и кусочки его нашли! Астероиды такого размера попадают в атмосферу Земли по несколько штук в год, но 2008 TC3 стал первым и пока единственным космическим телом, которое удалось обнаружить до столкновения с Землей. Обычно находят лишь уже упавшие метеориты): http://www.membrana.ru/articles/global/2009/03/27/154500.html. Для любителей всех возможных версий вымирания человечества можно заглянуть сюда: http://www.humanextinction.ru/. Но я почему-то всеми этими ужасами не впечатляюсь.

Как я понимаю, организаторы проекта тоже не слишком впечатляются возможными маловероятными ужасами, больше акцентируя не "внешние и внутренние угрозы Человечеству", а просто рассказывая о проекте в таком же плане, как ставятся задачи по полетам в Космос -- в надежде, что решение подобных задач породит множество заранее неизвестных научно-технических решений, форм международной кооперации и прочей побочной пользы. В Космос летают явно не за тем, чтобы в случае чего с Земли улететь. Или колонизировать Марс (зачем?!). Вот Дикий Запад колонизировали понятно зачем. Море тоже колонизируют понятно зачем (http://www.seasteading.org/). А зачем проводить этот depthsteading? Первая моя ассоциация про подземные города -- это нелепица из фильма про Матрицу, они там тоже "спасались". "Спасаться" от государства под землей -- это уж слишком, на водной платформе хотя бы есть ощущение курорта или морского круиза, а под землей? Хотя под землей от государства не спасешься: недра охраняются государством не менее тщательно, чем воздушное пространство над ними.

Настоящих буйных в природе мало, но в этом проекте планетарных поселений настоящие буйные. Жаль, что не все из этих буйных умелые. Профессионалы нефутуристы предпочитают строить неавтономные поселения, но не исключено, что такие профессионалы могут появиться и в этом проекте. Ибо профессионалы-футуристы часто сами не в состоянии спроектировать то, о чем говорят. Хотя тут все относительно: Артур Кларк придумал, как использовать геостационарные орбиты еще в 1945г., а вот средства доставки полезных грузов туда потом спроектировали уже совсем другие люди -- http://www.qrz.ru/satellite/geostationary.shtml. У Артура Кларка был проект, или прожект? Кларк ведь хорошо известен как писатель-фантаст, а не мастер капиталистического реализма.

Ума не приложу, почему у гечвоКовцев основной сайт с обсуждениями на team.ru закрытый. Совершенно ведь необязательно файлы выкладывать именно на тот сайт, где идут дискуссии, ежели хочется иметь и дискуссии и выкладку файлов. Ежели бы они перешли в Живой Журнал, то в их сообществе быстро бы набралось не полсотни, а полтыщи заинтересованных. Хотя опять-таки "заинтересованные" -- это не значит, что "те, кто могут". Но вероятность найти людей с совпадением заинтересованности и умений сильно вырастает при росте числа людей.

Пока они четко идут по "водопаду", пытаются "сфорумлировать ТЗ", используя техники дизайна на основе морфологических ящиков (http://www.metodolog.ru/00915/00915.html). Я им посоветовал подумать насчет формы жизненного цикла -- они неявно идут по традиционной для строительства линии "обин -- проект -- рабочая документация -- сооружение", что полностью бесполезно в такого сорта проектах. Хотя вряд ли я много буду им советовать, у меня совсем другие интересы, нежели зарываться в Землю или улетать на Марс.

Меня лично интересует использование нанотехнологий (например, проектных норм 28нм) для построения мегаобъектов (например, термоядерных электростанций) -- со всей промежуточной начинкой (например, http://ailev.livejournal.com/651423.html).
84 comments|post comment

Проектное управление и управление проектами: это все про логистику. [20 Jun 2009|09:08pm]
В четверг на седьмом заседании русского отделения INCOSE (http://community.livejournal.com/incose_ru/3312.html) спонтанно образовалась группа по интересам: несколько человек высказали интерес к управлению проектами в системной инженерии, vvagr их направил и возглавил, а я отгрузил некоторое количество электронной литературы (Koskela, Goldratt, Ballard и т.д.) на флешки участников этой группы и высказал несколько замечаний, которые свелись к следующему:

Вслед за амбициями "управителей качества" (которые говорят, что их претензции распространяются не на качество, а на управление -- quality management нужно переводить как "качественное управление", а не как "управление качеством") аналогичные претензии высказывают и проектные управленцы -- они именно "проектные управленцы", а не "управляющие проектами". Поглядите на PMI PMBoK -- вы увидите там полный и самодостаточный менеджерский набор практик, не меньше. Поэтому первым делом нужно понять, что же "проектного" (project, не design) в проектах, и не обращать внимания на "общеменеджерское" (типа "люди решают все" или "управлять знаниями").

Lauri Koskela пояснил, что разные заинтересованные стороны имеют в проектах (project) свои интересы, и поэтому предпочитают описывать проекты так, чтобы адресовались именно эти интересы (подробно и со ссылками на оригинальные работы я писал об этом тут: http://ailev.livejournal.com/603806.html). Koskela выделил три процессных (т.е. в развертке во времени) группы описаний (view) жизненного цикла (сам Koskela, правда, говорит о "строительстве", construction -- но сейчас-то мы понимаем):
-- логистика ("объективный" физический мир, поэтому иногда говорят о construction/factory physics): площадка, материалы, работа, законченные задания, зависимости между делами, буфера. Главным признаком логистики является "очередь" ("запас" или "дефицит").
-- мотивация (социальный мир): цели, желания, доверие, диалог, выделение ресурсов, полномочия. Теория о том, как управлять работой, чтобы работать и могло, и хотелось. Главное -- это люди, их обещания и их доверие.
-- полезность (value, субъективный мир): дизайны, описания, отчеты, требования, чертежи, практики -- в существенной мере это технические процесссы системной инженерии, как искусство ублажить заинтересованных лиц в их хотелках (не нужно забывать, что системная инженерия по определению способ мультидисциплинарного обеспечения получения заинтересованными лицами именно того, чего они хотят. Вопрос, почему они хотят именно того, а не этого, в системной инженерии не рассматривается: это субъективная полезность).

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

Истинная разница "процессного подхода" и "проектного подхода" -- это разница предмета обсуждения: процессники обсуждают главным образом организационные нормы (business rules), влияющие на последовательность работ ("процесс", о котором нужно думать как о записи последовательности действий и взаимодействий на каком-нибудь BPMN 2, http://www.omg.org/docs/bmi/08-09-07.pdf). "Проектники" обсуждают не последовательности действий, и почему они такие, а не другие (это пусть обсуждают "процессники"). "Проектники" обсуждают планы -- совокупность ресурсов и сроков, "свдиги вправо" и "свдиги влево", и контроль выполнения этих сроков (а не контроль прохождения правильной последовательности работ -- это "проектники" оставляют инженерам-технологам). Совершенно недаром в системной инженерии группа "проектных" процессов содержит всего два процесса: планирование проектов, и контроль выполнения этих планов. Планы (понимаемые как выделение правильных ресурсов вовремя, а не как "правильная последовательность работ"!) и контроль их выполнения: это и есть "проектность", которая сводится к логистическому аспекту во всех деятельнотсях.

Так же, как из трех цветов можно породить всю цветовую палитру, так и из логистической, мотивационной и полезностной (value) групп описаний, взятых в различных их сочетаниях, можно породить множество различных содержательных дискуссий. Вот примеры некоторых школ проектной мысли, каждая из которых предлагает свою группу описаний, и без которых нельзя обойтись при рассмотрении сложных проектов (чуть более ранняя версия этих же мыслей -- в слайдах http://www.slideshare.net/ailev/ss-presentation-615257):

1. PMI PMBoK, PRINCE2, P2M и прочие "проектные управления" -- о том, что описания всякие важны, описания всякие нужны, никто не должен уйти обиженным и "менеджер проекта" должен быть прежде всего менеджером, а затем уже проекта (что еще делает "просто менеджер", если не выполняет сутками те или иные проекты -- не достигает каких-то целей, ограничивая себя временем и бюджетом)? Ежели приглядеться еще внимательней, то от "прочих учебников менеджмента" PMI PMBoK и другие "всеохватные методики" отличаются более подробными описаниями логистики. Другое дело, что собственно "логистика" может быть описана очень по-всякому. PMI PMBoK просто говорит о важности ее рассмотрения, оставляя конкретный выбор логистической школы адептам "проектного подхода". PRINCE2 настаивает на примате плана над фактом, а P2M намекает, что методы Голдратта рулят.

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

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

3. Собственно логистика работ и материалов: распределение ресурсов для того, чтобы уложиться в бюджет и сроки при заданных ресурсах. Тут и исследование операций, и планирование ограничений, и factory phisiс с крутой математикой, и эвристики Голдратта с вычислениями "на пальцах". Я (по совокупности причин) рекомендовал бы ознакомиться с работами Голдратта.

4. Как ни странно, "процессы" нельзя исключать, когда говоришь о проектах. Грань между логистикой проектов и логистикой процессов очень зыбкая и немедленно исчезает при переходе к мультипроектному рассмотрению. Все оговорки, что "проект -- это когда один раз" напоминают мне анекдот "Абрам, ты живешь с Сарой? -- Ой, один раз живнул, и уже живу?!". Смысла управлять одним проектом никакого нет, а управлять (перераспределять ресурсы -- т.е. перепланировать, изменять практики) можно и нужно только, рассматривая все проекты организации ("мультипроектное управление"). Любимая тема Голдратта -- это обсуждение типичных "проектных", индивидуальных работ (заводское производство отдельных изделий "под заказ") с немедленным переходом к мультипроектному управлению и вслед за этим подробным обсуждением типичных "процессных" алгоритмов планирования логистики -- MRP II, ASP и т.д. (а затем еще и появляются и более тонкие различия, порождающие целые классы систем, например MES -- http://erpnews.ru/doc2592.html). Нельзя забывать, что проекты и процессы -- это две стороны одной медали, "типовой проект = процесс" и "проект = экземпляр процесса", даже если мы говорим только о выделении ресурсов и времени исполнения.

5. Логистические рассуждения тесно увязаны с содержательным (с точки зрения "полезности", value для заинтересованных лиц) определением последовательности работ, "процесса". Эту последовательность не всегда рисуют в BPMN. Например, последовательность работ в конструировании определяется корректно определенной модульностью системы -- именно этот факт учитывают школы аксиоматического конструирования и матриц структуры конструкции (http://ailev.livejournal.com/692349.html). После того, как оптимальная последовательность (ну, или можно сказать "оптимальная параллельность") работ определена, результат-"процесс" можно выгрузить в формате программ проектного управления и отдать "проектникам-планировщикам" для мониторинга.

6. В какой-то момент выясняется, что планы и графики абсолютно не отражают реальность, но мало кого это волнует. В этот момент и вспоминается, что "ресурсы" -- это люди, которые законтрактовались этими ресурсами быть, и стоило бы поинтересоваться, как они принимают решения о том, что им делать в условиях несоответствия плана и реалий жизни. Это обсуждает Ballard в методе LastPlanner (http://ailev.livejournal.com/573953.html) он же -- Lean Project Management. В применении к "процессам" (с учетом того, что "процесс -- это типовой проект") суть выполнения содержательной последовательности работ несколькими акторами обсуждает Jan Dietz в подходе DEMO (http://ailev.livejournal.com/644440.html). Если перевести мысль Dietz на язык "процессников из клана BPMN", то она крамольна: он утверждает, что не бывает оркестровки, а бывает только хореография. И тем самым немедленно попадает в стан "проектного управления", для которого "планирование ведется с тем уровнем гранулярности, на котором выделяются ресурсы". Ага, говорит Dietz -- один человек, один ресурс, один контракт. Организация -- это сплошная хореография. И далее по мотивам этого "процессного" якобы подхода для крупных строительных проектов предлагается стандарт обмена информацией по ходу проекта VISI (http://ailev.livejournal.com/609556.html, тут же см. про COINS, как связь проектного управления, методов управления жизненным циклом и интеграции данных -- но это уже глубоко выходит за собственно "логистику", хотя и обеспечивает ее).

7. Но все это буйство "планового подхода" и расчетов "логистиков" убивается замечанием, что 80% (или 60%, или 90% -- в зависимости от того, кто измеряет, и какой это был проект) времени коллективной работы в сложных и непонятных проектах любого масштаба тратится не столько на работу, а на взаимное выяснение того, что будет группа делать следующим. Жизнь устроена более динамически и спонтанно, чем предполагается во всех этих BPMN-workflow или "диаграммах PERT и Gantt". Но дискуссия эта идет уже не в "проектном" (логистическом), а в "процессном" языке -- и совершенно необязательно это сведется к обычным разговорам про agile и методам управления жизненным циклам. Например, можно пытаться создать "проект-на-лету", как это обсуждает Keith Harrison-Broninski (http://ailev.livejournal.com/569827.html). Вообще, оппозиция "игры по нотам" (недаром говорят про "оркестровку") и игры без нот -- она в проектном управлении центральная. Ибо искусство нотной записи и игры по нотам важны, но любой джазист затем показывает, что не так уж и важны (в приложении к управлению процессами см. про эту метафору в http://ailev.livejournal.com/517723.html и пункт 6 в http://ailev.livejournal.com/519176.html). С другой стороны, все эти "динамические творческие работы" вполне могут сводиться к разработке ППР (плана производства работ), который -- к радости и счастью логистиков -- на следующем этапе будет просто выполняться по Goldratt и Ballard. И эту разницу между стадиями "разгула творчества" и "выполнения директивного графика, который нам спустили эти творческие люди" можно обсудить в рамках выбора формы жизненного цикла...
2 comments|post comment

navigation
[ viewing | June 20th, 2009 ]
[ go | previous day|next day ]