Обсуждение

Спасибо. Как раз в тему. Не планируется ли выкладывание видеолекций? Кстати, офтоп, один глупый вопрос по лекции "Подход системной инженерии к управлению жизненым циклом": Почему говорят "инженерИя", а не "инженЕрия"?

Так ты уточни назание: "Отношения между управленцем и держателем инженерной онтологии через три специальных артефакта"

Если у нас случится видеолекция, то обязательно выложим. Насчет того, как говорят инженЕрИя: когда я был маленький и глупый, то я считал, что именно словари определяют то, как говорят люди ("откуда ты знаешь, как надо? О, про это написано в газетах!"). А когда я вырос, то понял: это словари составляются по тому, как говорят люди. И словари всегда отстают от жизни. Язык живой, в нем все меняется. Я не знаю ни одного человека, который бы говорил "инженЕрия". Но знаю, что в словарях записано не так. Это так же, как с тЕфтелями.

Военность заметна не в терминологии, а в том, что предполагается наличие безграничного резервуара ресурсов. И метод не стабилен по отношению к авралам.

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

Я б сказал, что проектная ориентация скрывает другие аспекты развития. Мультипроектность даст более ясную картину, но она всё равно будет не полна. Есть ещё маленькая проблемка с авралами: они пугают менеджмент. (По крайней мере, я несколько раз был свидетелем совершенно анекдотических историй.) Одно дело, когда потрачено уже 120% ресурсов и надо "доделать" и другое, когда потрачено всего треть, а уже повсюду горят красные сигналы. Велика вероятность того, что начнут менять коней на переправе.

Понятно. Профессиональный сленг. :) Просто как раз первый раз услышал. По написанному ударения не увидишь. И про словари согласен.

У меня там есть слайд, который указывает на одну из причин авралов и отставаний: сознательное уплотнение графика так, чтобы не было незагруженных ресурсов. Тогда каюк. Как учит Голдратт, в правильно построенном графике всегда кто-нибудь должен сидеть без дела. Когда таких людей нет, то любой сбой обязательно приведет к отставанию всего проекта на величину сбоя в любой его ветке (т.е. все пути будут критическими). Но это я бы обсуждал в других топиках. Это не связано с формой артефактами жизненного цикла, путем которых инженеры договариваются с менеджерами, а связано с содержанием отражаемого в этих артефактах. Опять же, можно скептично заметить, что как и в ISO9000 будут отчитываться формой артефактов, и плевать на их содержание -- но я опять флегматично замечу, что рассчитываю на использование всех этих знаний вдумчивыми людьми, а не профанирующими профессию. Про это я недавно уже писал: http://ailev.livejournal.com/747683.html. Так что я бы обсуждал тут не смену коней на переправе, а содержательные причины ошибок (а не "по общей глупости") и механизмы, позволяющие этих ошибок избежать.

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

Я просто отметиться, как человек, говорящий "инженЕрия", и "тЕфтели". Ну и тут в теме про язык и словари вроде очень удачная возможность немного попиарить новый проект http://community.livejournal.com/RUSCRIPTA/

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

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

произношение "комунИзЬм" в советские времена однозначно характеризовало принадлежность человека к касте замполитов (армейских политработников)

Признаться, неплохое описание. Но появилось пара вопросов: 1. Стр.10 Странно отсутствие ссылки на PMBoK - ведь в нем приводятся вполне внятные практики, как бороться с предлагаемыми проблемами. 2. Стр.11 ICM возникает из воздуха без сравнительного анализа подходов (и без указания области применимости). Что, как минимум странно, особенно например, для эксплуатационной стадии ЖЦ, когда сервисная работа, основанная на Service Support, порождает скорее триггерную терминологию (например, в практиках обработки SR и RfC). Я надеюсь, что очевидно, что процессная модель эволюции уже действующей системы - намного сложнее, чем запуск первой очереди или пилота (который вроде делать научились более-менее)? 3. Стр.19 evidence-base модель, кстати, располагает к триггерному завершению стадии либо открытию новых процессов по требованию (в т.ч. процессов интеграции), иначе, кстати, не совсем понятно, откуда вообще могут браться процессы внепланового завершения (я уж не говорю про гораздо более богатую жизнь). И снова была бы полезна ссылка на методы проектного управления - анализ освоенных объемов один из ярчайших (и притом понятных) примеров непрерывного мониторинга. 4. Стр.21 - тоже более корректно смотрелась бы в сравнении проектных и процессных подходов, особенно вопросы верификации, которые в проектном менеджменте ИМХО рассматриваются строже, и более конкретны (хотя, не исключено, что я упускаю где-то большую полноту ISO 15288 - но вроде бы пока не вижу, где).

1. В PMBoK очень много разных практик, в том числе и те, которые могут помочь в описываемых проблемах -- но они не заточены именно на эти проблемы. PMBoK -- это как "общая гигиена", а тут рассматривается абсолютно конкретный набор взаимосвязанных практик, предназначенных для использования в сверхсложных технических проектах. 2. ICM возникает из множества других рассмотрений, в моем блоге много об этом писалось в течение всего года (в том числе самому ICM было посвящено несколько постингов -- в приложении к презентации, например, просто был воспроизведен один из постингов). Более того, в самом ICM довольно много говорится о том, как он появился -- поучительная история. "Процессная модель эволюции" -- фраза должна быть существенно проинтерпретирована, ибо и слово "процесссная", и слово "модель", и слово "эволюция" в системной инженерии существенно перегружены, поэтому мало понятно, о чем идет речь. Так "эволюционная форма жизненного цикла" -- это выпуск многих версий системы, когда полный состав фич конечной версии неопределен, и никто не знает, что именно делается в проекте. С тем, что "пилот" научились делать, равно как и первую очередь -- не соглашусь. Не научились, конечно. 3. Анализ освоенных объемов имеет богатейшую критику (например, можно взять критику со стороны приверженцев Элияху Голдратта). Методы проектного управления не сводятся только к PMBoK, есть еще и методы теории ограничений, и методы lean project management. Там другая теория. 4. Я предпочитаю проектные и процессные подходы рассматривать совместно, начиная с "горбатой диаграммы". С другой стороны, нельзя не признать наличие многих парадигм описания жизненных циклов (см., в частности, анализ из http://ailev.livejournal.com/745469.html). Вопросы верификации в ISO 15288 не рассматриваются (кроме факта их наличия). Но они особо рассматриваются в ICM и в ISO 15026.

Относительно пилотов, все же их делают ИМХО несопоставимо лучше, чем системы, которые потом должны жить и развиваться. И когда я говорил про процессную модель эволюции действующей системы, я в голове держал Service Delivery / Service Support в ITSM, хотя конечно пытался сформулировать более общее представление. Представление о системе, которая своей частью живет, в то время, как другой своей частью развивается. Причем мне показалось интересным видение процессной модели (уже как описание в качестве примера конкретного экземпляра) развития системы, в которой RfС приходят постоянно - в разных методиках подход к организации процесса развития в этом случае весьма различен. Относительно анализа освоенных объемов - мне просто показалось уместным, если бы в Вашей презентации эти вопросы (плюсы и минусы конкретных распространенных технологий) и были рассмотрены (большинство широкой публики, в т.ч. и ваш покорный слуга разве что о них и их многочисленных собратьях слышали краем уха). Хотя возможно, этот вопрос не является предметом презентации, и для сетевой аудитории может быть решен просто ссылками на соответствующее описание. В целом, мои вопросы - скорее попытка взглянуть на эволюцию системы как на континуальный процесс, и что из этого получится в терминах ICM и ISO 15288.

В этом-то и проблема, чтобы получить общее описание, пригодное для разных типов систем. Так, есть проблема развития систем, которые работают 24*7, а есть системы, которые даже испытать нельзя, они однократного применения, хотя и жутко дорогие (космический корабль, который либо долетел на Марс, либо не долетел). Стандарты ICM и ISO 15288 не накладывают никаких ограничений на методы выполнения конкретных практик. Ваши вопросы как раз про методы выполнения конкретных практик, но обсуждаются они в совсем других презентациях -- каждая технология в рамках обсуждения своей практики. Так, требованиями можно управлять очень и очень по-разному, но обсуждать это нужно в рамках обсуждения практики определения требований заинтересованных сторон или анализа требований, но не на таком общем уровне, как данная презентация. То же относится к практикам контроля и выполнения проектов, где можно и до анализа освоенных объемов дойти. Тут же уместно обсуждать другие вопросы (например, как "спираль" разворачивается в линейный жизненный цикл -- инкрементами, или итерациями, и чем инкременты отличаются от итераций).