Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Чего в СУЖЦ нет, и не должно быть

Система управления жизненным циклом предотвращает и выявляет коллизии, возникающие в ходе коллаборативной и параллельной инженерии (http://ailev.livejournal.com/929655.html, функции СУЖЦ -- http://ailev.livejournal.com/939303.html).

Чтобы быть способным создать СУЖЦ, нужно как можно чётче провести границы системы -- чтобы определить, чем СУЖЦ не занимается, на что разработчики СУЖЦ не должны отвлекаться, что является не их делом. Увы, разговоры про создание СУЖЦ часто напоминают знаменитое "дайте воды напиться, а то так есть хочется, что и переночевать негде!". Стейкхолдеры -- они такие стейкхолдеры! Каждый из них мечтает добавить в СУЖЦ функциональность, и тут нужно быть стойким оловянным солдатиком, чтобы не соблазниться и не прихватить лишнего, даже если при этом сулят добавить в проект денег и времени.

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

1. "Учитываете ли вы мою любимую модель? Пойдите, найдите или создайте и учтите! Иначе у вас не жизненный и не цикл! И не управление!"
Выяснилось, что многие люди не могут обсуждать СУЖЦ безотносительно состава моделей самой системы -- примерно так же, как люди могут оказаться не в состоянии обсуждать фотоаппараты вне зависимости от художественных качеств объектов съемки -- со всеми сопутствующими дискуссиями про красоту пейзажа, маленький ротик модели, плюс обязательные реплики про важность сохранения традиции черно-белой фотографии.

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

СУЖЦ помогает найти коллизии для тех моделей, до которых может дотянуться, данные которых может интегрировать. Интегрируются те модели, которые есть, нельзя интегрировать модели, которых нет. Дискуссия про модели -- это другая практика, не управления жизненным циклом. Дискуссия про потребные для инженерии системы модели -- это дискуссия прежде всего о методах разработки, о междисциплинарности, о полноте представления системы, о специфике самой системы, об архитектуре системы и потребных группах описаний. СУЖЦ с радостью учтёт любые модели, любые группы описаний, любой инструментарий, любое знание о системе -- и позаботится о том, чтобы интеграции этого знания не помешали не только междисциплинарные барьеры, но и разница методов работы и стандартов, инфраструктуры и организации работы, которые существуют на разных стадиях жизненного цикла. СУЖЦ позаботится, чтобы границы стадий жизненного цикла не мешали течь информации. Пряности и информация должны течь. Но не дело СУЖЦ добывать и сохранять эту информацию, которая по ней течет со стадии на стадию. Дело СУЖЦ -- обеспечивать свободный ток информации оттуда, где она есть туда, где она нужна. Если там, откуда информация должна течь, её нет -- это не вопрос СУЖЦ, это содержательный вопрос инженерии. Инженеры должны разобраться, где эту информацию взять, какие модели должны быть, какие данные с этой информацией связаны, и где они собираются и хранятся.
Если там, куда информация должна течь, ее никто не ждёт -- это не вопрос СУЖЦ, это содержательный вопрос инженерии -- и инженеры должны разобраться, почему одни люди игнорируют информацию, а другие от этого игорирования приходят в неистовство.

2. "Вы предотвращаете коллизии? Вы их выявляете? Тогда добавьте до кучи и устранение коллизий!"
Устранение коллизий -- это творческая деятельность инженеров. Это практики инженерии требований, инженерии системной архитектуры, практики проектирования (возможно, порождающего/generative, где проектируют уже не люди, а компьютер). Это практики интеграции, тестирования -- полный цикл технических практик системной инженерии. Если коллизии случились поздно по жизненному циклу, то в устранении коллизий задействовано значительное число практик инженерного менеджмента: ибо вполне возможно, что нужно шевелить бюджет и сроки проекта, менять график задействования ресурсов.

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

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

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

Но не дело СУЖЦ говорить, какой метод разработки выбрать - "водопад" или "спираль", какие модели использовать в системной архитектуре. Это собственно инженерия. Но это дело СУЖЦ говорить, что бумажные чертежи плохи: исправлять в них коллизии трудоёмко, и это чревато новыми коллизиями.

3. "Управление изменениями должно проходить по четко определенному пути! СУЖЦ должна поддерживать бизнес-процесс во всей его полноте!"
Да, это дело СУЖЦ поддержать "бизнес-процесс" внесения изменения -- в части присвоения номера версии измененного артефакта, оповещения других участников работ и прочих формальных моментов. Но это не дело СУЖЦ определять путь, которым идёт "изменение" от момента обнаружения коллизии до момента выработки этого "изменения" как инженерного решения, которое нужно интегрировать в состав системы. Так что СУЖЦ должна аккуратней относиться к тому, что за "бизнес-процесс" имеется ввиду (про трудности определения бизнес-процесса и четыре их вида см. тут: http://ailev.livejournal.com/904643.html). В PLM обычно имеется ввиду workflow, но и тут возможны расхождения в понимании: айтишники хотели бы видеть "обычный workflow", а инженеры описывают реальное "путешествие изменения" в стиле dynamic case management (http://ailev.livejournal.com/711517.html, плюс http://www.itbusinessedge.com/cm/community/features/interviews/blog/case-management-is-step-forward-in-bpm-evolution/?cs=39882 и много-много других работ), для которого традиционные практики BPM (business process management) непригодны -- работа по устранению коллизий (завершающаяся "управлением изменениями" в части учёта при этом происходящего) так же нестандартна, как прохождение пациента через разных специалистов клиники, как прохождение судебного дела, как решение клиентских споров по поводу неверно оплаченных счетов.

СУЖЦ должна адекватно отвечать на информационно-логистические запросы инженеров, решающих задачи технических практик, но непосредственно поддерживать не эти практики, а свои собственные. СУЖЦ -- это про склады, вагоны и рельсы, по которым идёт информация о системе, а не станки, на которых ведется содержательная обработка этой информации. Но горе, если кто-то думает, что основной объем проходит по этим рельсам. Нет, основной объем проходит по весьма замысловатому маршруту, в том числе грунтовым дорогам, тропинкам и звериным тропам. Вместо тележек часто можно увидеть переноску огромных объемов руками -- между самыми неожиданными станками. СУЖЦ должна дотянуть рельсы туда, где их еще нет. Но это не дело СУЖЦ заниматься станками. Хотя про станки знать нужно: чтобы заниматься планами собственного развития, прокладывать информационные магистрали там, где это нужнее всего.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 3 comments