Обсуждение

Спасибо. Звук немного рассинхронизован с изображением -- чуть-чуть не удобно.

В исходном файле было все нормально, это что-то при конверсии внутри vimeo произошло.

Возможно использование другого кодека поможет избежать этой напасти в след. раз.

Я использую одну и ту же программу перекодировки для всех видеопубликаций на vimeo, а влиять на выбор кодеков внутри vimeo у меня нет возможности. Я проверил еще раз: в подсунутом туда оригинале никаких задержек звука нет.

Анатолий, очень интересная для общего развития лекция и я буду ждать второй части. Однако я считаю, что то, о чем Вы говорите, никогда не заработает в том виде, в котором Вы себе это представляете. Постараюсь сформулировать почему. Сразу скажу, что в своей терминологии я буду использовать слова, привычные мне. Их смысл будет понятен из контекста. Вы говорите о том, что, дескать, то, что мы видим не самые удачные попытки придти к системной инженерии, не делают сам подход неудачным, а лишь говорит о том, что попытки эти предпринимаются не совсем правильно. Вполне возможно, но вот вы говорите о Shell и их удачном опыте, однако я заправлялся на их заправках и могу сказать, что процесс заправки организован у них ужасно неудобно (а ведь я клиент – один из самых главных стейкхолдеров, я приношу деньги). Посмотрим на загибающийся GM, МКС в которую вложили кучу денег и теперь хотят похоронить в ближайшем будущем, сорвавший все сроки и бюджеты A380, сломавшийся коллайдер и так далее и тому подобное. Почему системная инженерия не помогла избежать всех этих проблем? Потому что она просто практически не может этого сделать. Конкретные проблемы Роль крупных проектов преувеличена Я уже спрашивал как-то, каким образом можно практически полностью удовлетворить интересы большой социальной группы. Вы не ответили, потому что простого ответа не существует. Хотя на самом деле в большинстве случаев можно ответить «никак». Чем больше группа, тем на больший компромисс приходится идти в отношении интересов конкретных людей. А люди не хотят компромисса. Люди хотят, чтобы удовлетворялись именно те потребности, которые они хотят удовлетворять. Это то, почему загибается GM – они-то хотят производить универсальные машинки из универсальных деталей. Подход изначально обреченный на провал в современном мире. Абсолютное большинство проектов из больших можно превратить в набор маленьких и позволить им развиваться независимо. Все большие проекты должны сводиться только к созданию инфраструктуры. Среди стейкхолдеров таких проектов должны рассматриваться только маленькие проекты, а никак не конечные потребители. Маленькие проекты уже рассматривают интересы людей и затачивают его узко под определенные ниши. Неплохой пример проекта, работающего в этом ключе сейчас – GPS, хотя создавался-то он, конечно, иначе. А вот из A380 можно смело выкинуть две третьих деталей, не отвечающих непосредственно за полет. Airbus мог бы создавать только саму летающую тушку самолета, а создание конкретных экземпляров с конкретными внутренностями передать другим компаниям. В наиболее успешных из них он мог бы покупать пакет акций. Результат – масса разных самолетов удобных для разных целей и более симпатичные финансовые показатели. Но деталей все равно остается много. Но вы ведь тоже лукавите. Есть же инкапсуляция. Ни один инженер не работает с конкретными деталями. Уровень абстракции можно повышать довольно долго. Все что нужно – следить за тем, чтобы у абстракций не было каких-то побочных эффектов, чтобы они точно описывали свои свойства и легко тестировались. Вот это действительно важная область работы – как этого добиваться и как обеспечить удобный механизм поиска «деталей» по заданным свойствам.

Предположение о возможности удовлетворения всех стейкхолдеров ошибочно Как можно предполагать, что одним проектом можно удовлетворить три страницы стейкхолдеров? Да это в принципе невозможно. Уже 4 из них будут пребывать в жестком конфликте. Все что можно сделать – опять же разбить проект на маленькие проекты и позволить им развиваться независимо, удовлетворяя очень ограниченное количество стейкхолдеров каждым. Роль планирования преувеличена Даже если человек, работающий над проектом – гений и он сможет учесть почти все, что влияет на проект, это займет такую кучу времени, что когда проект будет готов, он уже никому не будет нужен. Современный мир слишком быстро меняется. Слишком быстро менялся уже тогда, когда проектировали станцию Мир, поэтому и забили на размышления о том, как ее спускать. Это действительно не ошибка, а суровая правда жизни. Нет никакого смысла тратить силы на то, что потребуется в далеком будущем. В топку подробное долгосрочное планирование и проектирование. Разбиваем проект на части. Каждой части выпадает максимум по 3 важных стейкхолдера. Развиваем части независимо. Объединяем по заранее стандартизированным протоколам, если это необходимо. Не для всех проектов применимо, но для гораздо большего количества, чем кажется на первый взгляд. Роль требований преувеличена Ни один стейкхолдер никогда не сможет сформулировать все свои требования. Потому что он даже еще не подозревает о некоторых из них. Это примерно как требования к женщине или к музыке. Мы можем знать, что в принципе придется нам по душе, но по-настоящему нас зацепит что-то совершенно иное, но которое при этом проберет нас до кончиков пальцев ног. Это не учитывается практически никакими методологиями. Да, кто-то упоминает про такие вещи, как дизайн, удобство использования, рождение эмоций, приятные ощущения и так далее. Но реально фактически никто этим не занимается. Поэтому мы и имеем уебищные одинаковые бесхарактерные продукты на рынке и только отдельные герои вроде Apple знают в чем соль и как без всякой системной инженерии сделать казалось бы невозможное. А какой-нибудь SAP до сих пор производит интерфейсы, от которых мне хочется блевануть на монитор. А потом топ-менеджмент организации, купившей SAP, бегает и спрашивает, почему у наших сотрудников мотивация низкая. Да потому что ни один нормальный человек подсознательно не хочет 8 часов в день смотреть на эту убогую серость и делать те бессмысленные действия, которые напридумывали внедренцы. Извините за эмоциональное отсупление ;)

Роль стандартов преувеличена Я не люблю стандарты. Там где слишком много правил зарождается посредственность. Ну нафига описывать каждый чих формально? Да еще не договорившись об общей терминологии (огромный минус стандартизующим организациям, зачем они тогда вообще нужны?). Я согласен, что нужны стандарты, описывающие некие протоколы взаимодействия. А вот стандарты, описывающие конкретные реализации не нужны. Вместо них нужны просто неформальные описания лучших практик. Протоколы, кстати, должны изначально иметь потенциал расширения. Сейчас же мы имеем бессмысленное болото стандартов. Большая часть из них уже давно устарела. Но люди пытаются их реализовывать, не понимая, что стандарт = то, что у кого-то уже реализовано = отсутствие конкурентного преимущества. Мозг дан человеку, чтобы думать. Все что должен делать архитектор – почитать лучшие практики в предметной области, с которой он сейчас работает (доступные и простые, а не это многостраничное унылое говно, которое зовется стандартами); посмотреть характеристики протоколов, которые могут помочь ему связать свою систему с внешним миром; подумать; сделать собственную реализацию, подбирая «детали» с нужными характеристиками по специальному удобному и доступном справочнику. Все – компания получает систему, заточенную под их нужды, дающую компании конкурентное преимущество, а не то же самое, что уже есть у конкурентов. Быстро и качественно. Вполне осознаю, что инфраструктурные компоненты вполне могут и не нести в себе конкурентного преимущества, но тут совсем все просто – в таком случае из нашего репозитория «деталей» подбирается уже готовая деталь с нужными свойствами. Если архитектор не может уложиться в стандартный протокол, то он регистрирует его расширение. Или совершенно новый протокол. Все это должно стать массовым, удобным и открытым. Примерно как публикация проекта на Google Code или SF. Непонимание того, что свойства продукта определяются свойствами разработчиков Говорю прямо: сама системная инженерия и рядом лежащие вещи – унылое болото. Я не знаю, как в нем оказались Вы (на удивление интересный и позитивный человек), но глядя на других варящихся в нем людей, мне становится страшно. Я реально не хочу, чтобы эти люди производили что-то на свет, потому что на свете и так слишком много серости и уныния. И таких как я будет становится все больше. Людям нужны впечатления. Вот такой вот радикальный взгляд. Он, впрочем, не отрицает все, что есть в системной инженерии. Он лишь говорит о том, что нужна новая методология, построенная на миксе из системной инженерии, гибкости, скорости, индивидуальности и впечатлениях. На самом деле подобная методология уже почти сформировалась, потому что сформировался проект, который строится по ней. Один из самых крупных в мире. "Интернет" называется. Спасибо за внимание :)

Я думаю, что в том виде, в каком я это себе представляю, все как раз и заработает -- а не работает часто именно потому, что это совсем не тот вид, который я себе представляю ;) Роль крупных проектов не преуменьшена и не преувеличена. Она есть. Если много-много мелких рыночных агентов начнут что-то сами по себе делать, то вовсе не факт, что из их поделок соберется крупный объект. Кто-то должен будет сделать архитектурный дизайн, кто-то должен прогарантировать, что денег хватит на постройку и взять на себя риски, что заработанных на этом проекте денег должно будет хватить на то, чтобы постройка окупилась. В любой такой постройке участвуют тысячи и тысячи мелких фирм, и именно для налаживания этой кооперации предназначены стандарты системной инженерии (прежде всего такая работа с требованиями, которая позволяет отделить требования заинтересованных лиц от требований к системе, а их от требований архитектурного проекта). Бардак на заправках Shell мало связан с тем, что нефть реально выкачивается со дна моря (что считалось бы лет тридцать назад настоящим чудом), а затем преобразуется в бензин где-то на этой бардачной заправке. В этом участвует отнюдь не только Shell (которая, например, не добывает руду для металла труб, по которым течет эта нефть и этот бензин, или не делает компьютеры, которые сейчас встроены во все эти установки), а участвуют тысячи и тысячи предприятий. Системная инженерия как раз про то, чтобы эти тысячи и тысячи предприятий смогли сработать вместе в сверхкрупном технически проекте. Нефть сама из-под воды не выскочит, ее нужно добыть. На маленькой лодочке крошечного бизнеса этого не сделаешь, а требования всяких экологов, потребителей, ограничения геологов, материаловедов и т.д. выполнять нужно в любом случае -- а этих требований набирается более чем достаточно, и вовсе не факт, что "рынок" вдруг позаботится об этом балансе требований в подобном проекте автоматически. Все эти "инкапсуляции", конечно, работают -- и являются существенной частью инженерного знания. Но никакая инкапсуляция не закрывает всех инженерных проблем, в природе "все со всем связано", и эти неожиданные связи прорываются в разных частях проекта и требуют своего решения. Поиск деталей делается при проектировании. Но регулярно случается конструирование, при котором известно, что деталей такой формы и с такими свойствами нет, и ее нужно сконструировать, а потом изготовить специально -- иначе такой детали в мире просто не будет, ее никто не задумывал и не делал раньше. Таких деталей достаточно много (иногда очень больших, типа корпуса реактора).

Про стейкхолдеров вы не все правильно понимаете. Главная задача системного инженера -- это обеспечить переговоры между стейкхолдерами, снимающие между ними противоречия. Считается, что люди разумные, и могут договориться. Придумывание технических решений для удовлетворения противоречивых требований является только маленькой частью. Вы по-прежнему считаете, что много-много маленьких лодочек выкачают нефть со дна моря или много-много моделей ракет вдруг доставять пару тонн груза на Луну. Нет, такого не бывает. Размер имеет значение. Это не значит, что в таких проектах не принимают участие тысячи и тысячи маленьких (да и больших) фирм. Роль планирования не преувеличена, когда вам нужно получить нефть со дна морского, или построить мост. Не будете планировать, в последний момент может не хватить секции моста: сам он поперек реки не соберется, сами по себе нужное число секций не будут изготовлены, много-много маленьких фирм без заказа никогда не начнут вдруг производить этот мост. А если они "договорились", то есть кто-то, кто их договаривал -- и договорился заодно о проекте и деньгах. Он и есть обычно заказчик (а по-западному owner). Проекты бывают хорошие и плохие, методы разработки бывают "все требования в начале" и "все требования по ходу дела". Рыночный успех вовсе не означает хорошего продукта, хороший проект вовсе не означает хорошей его реализации, хорошие требования вовсе не означают, что по ним будет сделано что-то достойное. Собственно, я об этом и говорю: нужно много чего предусмотреть, чтобы проект оказался хорошим -- а потом еще и иметь дисциплину соблюдения всего предусмотренного. В хороших методологиях разработки (т.е. в системной инженерии) предусмотрено, что требования меняются в течение всего хода проекта. Более того, в хорошей методологии говорится о разных (минимально -- трех) видах требований и разных процедурах проверки: верификации и валидации как минимум. Ваш пример с SAP эмоционален, но кто-то должен придумать альтернативу этой убогой серости. Если альтернатива неизвестна, будете пользовать SAP -- ну, или укажите, что можно использовать для нормального решения тех задач, которые ставят перед этой системой управленцы (и тут выяснится, что проблема в самой постановке задачи. Но это уже выходит за предмет обсуждения "плохого SAP", так ведь?).

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

Ну как координировать много мелких рыночных агентов уже давно придумано -- есть, например, диспетчерские службы. Сейчас набирают обороты всякие краудсорсинговые вещи. Сегодня это скорее баловство -- юзеры скинулись и купили футбольную команду, например, но, думаю в недалеком будущем мы с Вами вполне сможем проинвестировать баксов 200 в стоительство ракеты, просто зайдя на специальный сайт. С таким же успехом мы сможем предложить и свои услуги в этом проекте, а сообщество решит можно ли нам доверять голосованием. Это как раз способно решить проблему крупного финансирования и взятия рисков. Очень крупные проекты будут разбиваться на куски и создаваться отдельно. Конечно, Вы правы, что это будет применимо не всегда. Но реально количество очень масштабных проектов, которые невозможно раздробить на части не так уж велико. Тот же Shell разбить очень легко. А если мы учитываем у Shell только добычу, но не учитываем продажу топлива конечным потребителям, то где же тут системность? Какие-то обычные костыльные подходы. И да, я понимаю проблему с дырявыми абстракциями и сложными связями между различными частями систем, поэтому и говорю, что нужно больше работать над техниками, позволяющими избегать побочных эффектов и прозрачно показывать то, от чего избавляться нельзя. Не знаю как насчет реального мира, а в программерском для этого существует множество технологий и они достаточно успешны. Ну а в изготовлении собственных деталей я особо проблемы не вижу. Ну вот есть реактор, ну сделали к нему корпус. Все, готовый реактор, дальше его нет особого смысла рассматривать на уровне деталей, если он используется в другой части системы.

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

Действительно множество фирм принимает участие в работе над крупными проектами. Но они работают как подрядчики и делают одну общую систему. А ведь могли бы работать как свободные компании и создавать различные вариации одного и того же продукта, заточенные под различные нужды. Вот в чем основная разница. Это потребует разработки какой-то новой системы взамен акционерной, но в итоге все должны остаться в выигрыше. Когда я говорю, что роль планирования преувеличена, я имею ввиду, что его тыкают везде, не глядя на то нужно оно там или нет. Так вот в большинстве задач долгосрочное планирование не нужно. Нужно только там, где что-то будет очень сложно и дорого исправить. Таких задач мало. Что касается SAP -- да. То, что альтернатива чему-то отсутствует не должно мешать обсуждать недостатки существующего решения. К счастью, тренд Enterprise 2.0 набирает обороты и скоро мы, возможно, увидим вменяемые продукты.

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

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

В переводе ISO 15288 мы stakeholder передали "заинтересованные стороны", инжeнерия так и осталась (инженеры в России были еще в царское время, но говорить "системное инженерное дело" будет явно не лучше "системной инженерии"), а вот глоссарий -- это словарь с толкованиями, так и придется оставить.

Врядли это поможет, но у меня специализация в универе "system engineering" переводилась как "системотехника". Инженер ведь занимается практическими задачами, следовательно оперирует техническими понятиями. Как вариант.

Перевод systems engineering (и его происхождение) как "системотехника" уже неоднократно критиковался (см., например, http://ailev.livejournal.com/671455.html).

Ну, скажу за SAP (как никак работаю я в нем сейчас). Тема интерфейсов SAP всплывает регулярно, потому в общем и мнение мне не нужно каждый раз формулировать. Классический пример, который постоянно ставят в пример интерфейсов, противопоставляя их SAP, это Apple. Я сам поклонник этой марки и именно за счет ее интерфейсов и гениального понимания потребностей пользователя. Проблема в том, что яблоки нужно сравнивать с яблоками, а комбайны с комбайнами. ERP (или как угодно назовите современную систему управления бизнесом) это один из наиболее сложных продуктов сегодня. Может ОС и сложнее по числу связей внутри системы, но проблемы интерфейса модуля "№;%:Н? с модулем *?:%;№ пользователя не очень волнуют. А вот SAP сложнейшая система именно по числу возможных ветвлений и действий пользователя. Сделать такую работающую систему архисложно. На сегодня это удалось очень небольшой группе компаний - SAP, MS, Oracle и поглощенные им... Т.е. сравнение нужно проводить среди существующих, а не воображаемых систем. И тут вопрос простой - что лучше? ИМХО, выбор потребителя отражен в доле рынка ))

Эээээ, вы уверены, что знаете значение слова Enterprise 2.0???