@DasBotrek я бы делил активности на несколько, 1 - управление знаниями(конфлю), внутренние митапы, гильдии, аннонсы, 2 - определение знаний, стандартизации тех.документации, контроль стэка.
Ну вот тут по пунктам уже надо разбирать. Что такое управление знаниями и как оно ведется?
Мы выкатили фичу, а значит мы сделали: описание апишки, классов, пояснения к функционалу, описали бизнес логику, оповестили всех заинтересованных. Это можно делать, как и для простых смертных, так и в коде, но уже на более детальном уровне.
Мы выкатили фичу, а значит мы сделали: описание апишки, классов, пояснения к функционалу, описали бизнес логику, оповестили всех заинтересованных. Это можно делать, как и для простых смертных, так и в коде, но уже на более детальном уровне.
Это тоже вариант, да. Эдакая ковровая бомбардировка. Вот я и изучаю, есть ли более гибкие/простые подходы
Необязательно. Но я спрашивал не про конкретный кейс. Допустим все неплохо, у нас растет хороший лесс, команд уже 8, как шарить знания? Хп эффективно шарит на 60 разработчиков?
У меня была необходимость шерить знания. Создавали коммьюнити скрам-мастеров. В целом, знания в крупных компаниях часто шерятся созданием центров по компетенция.
Это тоже вариант, да. Эдакая ковровая бомбардировка. Вот я и изучаю, есть ли более гибкие/простые подходы
В какой-то момент связей становится слишком много. n(n-1), да? Тут уже надо выделять необходимый минимум, для будущего собственного комфорта. Чтобы по коленями не стрелять.
Я вот надумал, есть такая штука как атомарный дизайн, видел применение его для атомарных инсайтов, по идее, можно для шаринга и других знаний применить
У меня была необходимость шерить знания. Создавали коммьюнити скрам-мастеров. В целом, знания в крупных компаниях часто шерятся созданием центров по компетенция.
Комьюнити да, сразу приходят на ум. Но там внутри тоже много вопросов
Я вот надумал, есть такая штука как атомарный дизайн, видел применение его для атомарных инсайтов, по идее, можно для шаринга и других знаний применить
Прикольно рассматривать гильдии. Например фронт-гильдия. Нужна когда у нас, например, 10 команд и по 1 фронту в каждой. Тут уже и вопросы коллективного ревью и стандартизации, и т.д.
В какой-то момент связей становится слишком много. n(n-1), да? Тут уже надо выделять необходимый минимум, для будущего собственного комфорта. Чтобы по коленями не стрелять.
Прикольно рассматривать гильдии. Например фронт-гильдия. Нужна когда у нас, например, 10 команд и по 1 фронту в каждой. Тут уже и вопросы коллективного ревью и стандартизации, и т.д.
На разных этапах и контекстах нужно шарить разные знания и с различной интенсивностью. Разработка на 2ух человек не потребует детальное описание всего, а 50 разработчикам уже может не хватать примитивной документации в хаотичном виде.
На разных этапах и контекстах нужно шарить разные знания и с различной интенсивностью. Разработка на 2ух человек не потребует детальное описание всего, а 50 разработчикам уже может не хватать примитивной документации в хаотичном виде.
а я пришел воообще к выводу что шарить знания не надо ну например у вас сложный проект запускаете марсоход нафига шарить знания человеку который делает манипулятор или колесо для него