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

С поощрением тоже не всё так просто, для кого-то это будет ощутимое поощрение, а для тех же разработчиков - мелочь и не так весомо, как работа по проекту и проектные бонусы.

У нас ispring. Вообще надо смотреть на то, что вам надо от платформы. В едмаркете есть исследования и кучу материала про это. Было конфа, где приглашали всех представителей платформ, хотя они и не про корпоративное обучение, а больше заточены под бизнес задачи. Но тут уже их называли, так что разделения мало кто делает. Я как-то тоже у себя на канале писала про особенности lms. Надо смотреть все и тестировать. Особенно, если вы делаете курсы в scorm или собираетесь делать или их покупать. Только пробуя можно понять, что удобно и что закрывает задачи.

Ого, какой приток людей. Всем рады. Расскажите немного о себе, может сразу есть какие-то вопросы на обсуждение вбросить? Какие у вас проблемы и потребности в управлении знаниями?

Здравствуйте, меня зовут Даниил и я Анонимный Ал... Аналитик

Слава богу, элита KM подтянулась... заживем теперь...

Здравствуйте. Я Борис Щуко, работаю в Targetprocess в комбинированной роли - TW / KM / BA.
Вопрос на обсуждение сходу только один:
как бы вы подошли к внедрению хорошего нейминга в ИТ-организации из 20...100 человек, стремящейся быть бирюзовой (плоская структура, самоорганизация)? 😃

(Под хорошим неймингом имею ввиду примерно такое:
* когда один и тот же объект (документ, сервис, продукт и т.д.) во всех его упоминаниях имеет одинаковое название;
* когда объекты, производные от других объектов, имеют имена, очевидно отсылающие к исходным;
* когда название хорошо отражает сущность объекта;
* когда названия объектов одного рода имеют одинаковый формат.)

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

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

Есть такая штука: BEM. Это про верстку от Яндекс. Но принципы по-моему универсальны

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

Я понимаю, что есть стандарты, какие-то семантические системы. Ещё в ГОСТах 1960-70-ых были.
Вопрос в том, как такую системность внедрять в бирюзовых и околобирюзовых организациях. Возможно ли это вообще, например.

Lana: "пытаемся отслеживать единство именования"
Кто (какие роли, люди) у вас отслеживают, какие у них полномочия? Как происходит отслеживание?

Именования отражают viewpoint (то, смотря откуда я вижу именно так) и является реализацией конкретного view.

Другими словами, важнее размечать и поддерживать в понятном состоянии view.

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

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

"Другими словами, важнее размечать и поддерживать в понятном состоянии view."
Могу ли попросить вас как-нибудь проиллюстрировать эту мысль? Какой-то пример из практики.

Разница между https://datavizcatalogue.com/index.html,
https://datavizcatalogue.com/search.html и https://datavizcatalogue.com/home_list.html

Первая ссылка - "всё, что есть", вторая ссылка - про view, третья - про формальные типы.

Проблемы у нас похожи. Час назад опять столкнулся с тем, что на UI юзер видит одно, в репе написано другое, а маркетинг оперирует третьим названием.
У меня есть дальнейшие вопросы; если на что-то из них ответите, буду благодарен.
1) На каком уровне (-ях), исходя из вашего стайлгайда, придумываются (либо могут придумываться) названия? Т.е. какие роли официально могут являться их источниками? (Неужели в основном sales???)
2) В чём технически реализован сам стайлгайд? (Т.е. в wiki, CMS или чём-то ещё.)
3) На каком существующем стандарте/фрейморке изначально основан стайлгайд? Или целиком с нуля придуман?

У нас ситуация попроще.Маркетинг и UI -- это одно, а rnd -- это другое (иногда несколько). Для юзера все понятно, а для RnD есть поисковик со словарем синонимов.

>>>неужели сейлз:)
Мне кажется, что маркетингу как раз виднее всех, как более catchy называть компоненты. В конечном итоге, продукт надо продать :)