Пример из нашей реальной практики “Голован отказывается от сигналов с суффиксами _avv*, кроме _avvv
Xunistater умеет отдавать про себя информацию через служебную ручку. Все сигналы сигналы, ранее имевшие суффикс _avvx теперь имеют суффикс _avvv”

вот и попробуйте понять что тут написано, неформалы)

Без контекста сложно. Тут картинку бы.

ГОСТы это аналог ходить на работу в костюме

вот-вот. Без расшифровки птичьего языка новичку не понять. Поиск в такой системе тоже бесполезен, новичок не в курсе про голована и его сигналы, он даже вопрос задать не сможет

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

По крайней мере если нет схем и наставника, то жаргон в документации не самая большая ваша проблема:)

Чем больше и сложнее система, тем формальнее должна быть документация. Иначе будет как в притче про Вавилон и смешение языков. “Большие” системы это такие, знание о которых в принципе не помещается в одной голове.

На TeamLead Conf был доклад про Левелизацию. Команда придумала себе игру и организовала работу в команде в правилах настолки. И они потом перешли даже на ролевые отыгрыши в повседневной рабочей речи.
И ничего, успешно отработали. Кто-то конечно слился, но многие и остались.

Большой и сложный - это субъективно очень.

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

Нет мотива.
Я - мотивирую.

отсутствие быстрого доступа. если мне нужно пройтись по ссылкам из одного документа/папки несколько раз, вряд ли буду лезть. если в документе воды много, то тоже не круто. нужна удобная структура, возможность делать ссылки на конкретные параграфы.

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

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

Согласен. Отсутствие быстрого доступа - просто отбивает желание людей что-либо делать, читать, искать.

Простой пример: вики приветствует тебя логином,паролем.
И этого достаточно для отсева, например, в отделе эксплуатации.
А это ведёт к тому, что начинаются звонки разрабам.

Мне интересно на сколько РКД на Суперджет соответствует реальности)

https://m.habr.com/en/post/202184/

Нашёл статью. Финал истории прекрасен.
Там кстати по тексту ссылка на другую статью о том, как разрабатывают софт в авиации. Тоже прекрасно.

везде надо искать баланс в разработке, в документации, в закупках.

А кто-нибудь здесь перерос из стартапа в 20 человек до 300,500,700? Стали быстрее разрабатывать? Или наоборот медленнее?

Роман, про опыт Росатома по управлению знаниями много сказано. Вот один из моих докладов (аж 14 года), но за эти 30 минут детально разобраны все элементы СУЗ Росатома https://www.youtube.com/watch?v=EOec4Zvg_So

По конкретным документам скажу так. Делится ими не могу по соображениям конфиденциальности. На вопросы по конкретным технологиям и процессам с удовольствием отвечу

Первую ссылку прочитал. Очень интересная история. Написано тоже неплохо. Автор смог простыми словами объяснить сложное в достаточной для понимания истории форме. Это нынче редкое качество, мне кажется.

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

Очень интересно было в связи с этим прочитать о таком вот реальном кейсе. Обязательно прочитаю попозже вторую ссылку.

Я хочу оговориться, что с IBM DOORS я не работал и представляю себе эту систему условно. Так что не могу утверждать, насколько озвученная точка зрения верна. Но прослеживаемая в историях взаимосвязь мне как минимум любопытна:)

Например, надо принести доки ближе к пользователю. Прямо туда, где ему эти доки понадобятся.
Вот пример того, как доки про синтаксис языка принесли прямо в сообщения об ошибках в синтаксисе: https://elm-lang.org/news/the-syntax-cliff

Напишу-ка я в канал об этом, слишком хороший пример.