Создание новых технологий дело очень затратное, исследования, опытно-конструкторское производтсво, испытания, обнлвление оборудования для серийного производства. Примерно 8-10 лет на цикл и потребуется.
В ИТ ситуация похожая,
время когда гений мог за вечер на коленке состряпать новую технлогию уже давно прошло,
сейчас ИТ это тоже битва промышленных гигантов.
Вот попробуйте оценить сколько ресурсов надо на создание и внедрение нового типа поиска Google, или скажем новой Java-машины, нового Spring, новых интернет-протоколов.

Для меня остается загадкой почему в инженерной деятельности и медицине процессы накопления и сохранения знаний уже отлажены,
а в ИТ каждое новое поколение разработчиков снова идет по тем же самым граблям, вот ровно по тем же самым что и предыдущее поколение 10 лет назад)

никто не утверждал, что они отлажены)

Добрый день!
Интересное суждение о процессах накопления и сохранения знаний в инженерной деятельности. Можете раскрыть подробнее, что подразумевается под "инженерной деятельностью" и какие там лучшие практики на Ваш взгляд?

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

В ИТ пока так не принято. Возможно это незрелость отрасли, не накоплен еще достаточный уровень сложности.
Медицине, как области деятельности, уже тысячи лет. Сохранение опыта поколений там критически важно.

— в IT технологии появляются, становятся общепринятыми, устаревают и умирают гораздо быстрее, чем в каком-нибудь строительстве. Нет времени документировать каждый чих, конкуренты сожрут. А в сотрудниках ценится не столько объём накопленных знаний, а скорее скорость обучения и адаптации. @i_tsupko в прошлом году примерно про это рассказывал.
— сейчас все отрасли — это IT.
— «опыт поколений» вообще сомнительная ценность. Предки строили дома из глины и соломы, а все болезни лечили кровопусканием. Зачем нам этот опыт?

Мне кажется, все немного проще. ИТ - это "1" и "0", влияние которых на жизнь людей очень сложно оценить. Отсюда и весьма "спокойное" отношение к накоплению и анализу истории. Как следствие, низкая востребованность процесса управления знаниями. Это в дополнение к перечисленным выше граблям.

Сейчас всё — IT. Единички и нолики есть в самолётах, медицинских приборах, машинах, атомных реакторах. И там процессы строже, чем в доставке пиццы. А в доставке пиццы важнее скорость разработки, потому что пока мы корпоративный университет организуем, нас конкуренты выдавят с рынка.

Думаю, что пренебрежение накопленными знаниями — это и цена, и даже необходимое условие быстрого роста. Галилей пренебрёг  накопленными знаниями и провёл свои опыты по падению тел. А мог бы поверить Аристотелю, что тела падают тем быстрее, чем они тяжелей.

Конечно, накапливать знания полезно для прогресса, но что если и забывать/игнорировать тоже полезно?

Вы не путаете технологии и продукты для конечного потребителя?
Продукты появляются и умирают за год,
технологические платформы нет. Я пока не вижу примеров как новые операционные системы, классы мобильных устройств, языки программирования (демо для конференций не считается) появляются за несколько месяцев.

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

Так можно делать только для очень простых задач, например продажи пиццы.
Совсем не так в страховании, финансовом планировании, авиастроении, навигации, прогнозировании

Правда, правда, если была бы возможность сообществу ознакомиться хотя бы с частью текста, то это принесет огромную пользу сообществу и большой плюс в карму. Опыт Росатома по управлению знаниями это отличный кейс для ИТ.

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

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

не сочтите за критику изначальной мысли. просто попытался дополнить Вашу картину своей.

Все-таки, я думаю, что по конструкторской документации можно понять как работает устройство. По программному коду некоторых ИТ продуктов понять как они устроены и работают невозможно, без специальной документации.

>> меня учил эксперт, который чертил от руки и на "солиды эти ваши" плевался) в целом,
Таких персонажей и в ИТ достаточно)

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

Могу согласиться отчасти. Вторая часть реальности заключается в том, что в КД тоже может быть бардак.

увы, первый тезис далёк от истины.
по КД точно можно понять, что устройство состоит из деталей, каждая из которых имеет определённые характеристики
но всё остальное - не всегда

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

Расскажите, может у вас есть конкретные примеры компаний-представителей отрасли - я бы с удовольствием изучил их опыт.

Что такое "наставничество" в понимании участников?