СамоСМиИ-2024-АК. Безмасштабная, непрерывная системная инженерия

Мысли по главе

После методологии прямо чувствуется, что этот курс еще не переписан.
В целом в первой главе очень много повторений из предыдущих курсов. А именно:

  • инженерия это про изменение мира “к лучшему”
    • конечно лучшее это довольно субъективный момент
    • поэтому этика очень важна, при внедрении систем влияние идет на весь стек и далеко за “очевидные” границы проекта
  • системный подход безмасштабен и применяется на многих слоях и должен эту многослойность учитывать
  • непрерывность изменений. С началом эксплуатации ничего не заканчивается
  • инженерия - часть умной эволюции и/или ее ускоритель, создает новые, направленные мутации

Современные проекты слишком сложны для одного человека

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

Про недостаток творчества в инженерном образовании: Инженеров учат анализировать и критиковать, но не создавать

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

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

для меня прям замечание. Меня все постоянно тянет все просчитать, все спроектировать. Analysis-paralysis, оттягиваю от непосредственного внедрения все дальше и дальше, я это связываю со страхом, что не получится провалится, а пока анализируешь - провалится не выйдет, ничего же не делаешь.




Общие инженерные тренды, которые нужно учитывать:

  • малый инкремент
    • ну тут понятно - меньше инкремент - быстрее сделал - быстрее получил данные - быстрее понял что так/не так - быстрее попробовал еще
  • моделеориентированность против документоориентированности
    • переход к структурированным и машинообрабатываемым данным
  • численное моделирование
    • сейчас численного моделирования очень много и везде, пророчат существенное улучшение жизни за счет ускорения/удешевления разработки продуктов
  • цифровые двойники
    • модель важна не только во время разработки но и во время эксплуатации
    • но это разные модели!
  • стандартизация интерфейсов и открытая архитектура
    • в разработке софта применяется повсеместно
    • велосипедостроение, конечно никто не отменял, но чем дальше тем меньше - уже есть огромное количество готовых компонент, которые(скорее всего) подойдут лучше/дешевле
  • платформизация
    • тоже много обсуждали в предыдущих курсах: частично это та же стандартизация
    • универсальные компоненты/решения => удешевление конечного изделия
    • платформы постоянно развиваются/эволюционируют. В них столько ресурсов вкладывается, что небольшим коллективом и уж тем более в одиночку просто невозможно что-то подобное и приемлимое по цене вытянуть
  • готовые системы вместо сделанных на заказ
    • коробочное решение/ lowcode/nocode
    • платформы туда же
  • вариабельность продуктов
    • сочетание массового выпуска и платформизации но с возможностью кастомизации, которую не нужно слишком отдельно делать/заказывать
  • система с открытыми исходниками
  • порождающее проектирование
    • в индустрии, наверное, применяется, но я пока такое массовое применение видел только в играх: генерация пространств/карт/сюжетов под конкретные условия
    • видел робкие попытки дизайна всяких несущих изделий
      95884_original
    • утверждается что прочностные характеристики аналогичны. Поверим. Но меня, конечно, смущает момент с производством(но тут ладно, 3D принтер напечатает) и обслуживанием(вот как эти все загогулины обрабатывать/красить, хотя, наверное, это не везде критично)
    • в каком-то роде это не совсем проектирование, это направленная эволюция. Интересно, что детали созданные таким способом гораздо менее угловатые/прямые, в них гораздо больше видна “жизнь”
6 лайков

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

С инкрементами тоже интересно. Провалиться можно разными способами) Вышла же новая продукт манагер и там первый вопрос: как бы ускорить поставку ценности. Тихо любой инженер может сказать волшебное слово “continuous delivery”. Оставим за скобками сколько надо денег и времени, чтобы развернуть, если этого нет. Допустим волшебные парни из devops смогли сделать так, что любая фича теперь вливается в основную ветку и тут же едет к пользователям. И что у нас? У нас теперь непрерывная поставка багов! Обратная связь будет очень быстрая, но вряд ли хорошая. Ну конечно правильный CD может нам дать показывать новую фичу только на 1% пользователей и тут же откатывать, если вдруг. Но что-то мне думается, что до быстрых и коротких инкрементов надо чинить всё остальное везде. Быстрее поставлять брак не хотелось бы.

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

Как у вас с деливери, часто релизите, какой процент косяков?

2 лайка

Никто это, естественно, не проговаривает, ну есть роль - архитектор.

Я не вижу(но это не значит что этого нет), но тренд странный. Мы же вроде как раз от этого ушли, что какие-то “умные” люди все проектируют в UML, а потом передают обезъянкам-кодерам, чтобы это все закодировали?

Собираться и продумывать/проектировать все-все, наверное действительно слишком, но есть же(надеюсь) золотая середина, где и контекста достаточно и информации получили достаточно?

ну опять-же не надо впадать в крайности, а искать какой-то баланс

Так и вижу: килограмм ценности (цифра в табличке) и её поставка. Всё-таки value надо переводить всегда как “польза” – и каждый раз оказывается, что “поставка ценности” для 10 результатов на слух хорошо звучит, а вот “нанесение непоправимой пользы” из этих 10 результатов оказывается только парочкой, остальное – “ценность есть, пользы нет” (типа “привёз из отпуска статуэтку из ларька на пляже – прикольно, использована в целях привезения из отпуска, других использований не было, всё, отстаньте”. Ценность у статуэтки вроде есть, а вот пользы – нет).

1 лайк