Комментарии 22
Забавно: только что проходил немецкоязычные курсы по Agile — так там прямо говорится, что необходимы инструменты обмена и управления знаниями.
И что одно из наиболее удобных — внутренняя Вики. Ну, и всяческие сетевые диски с документацией и складом информаций от прошлых и текущих проектов, системы контроля версий в том числе и для документации и т.д.
И ещё во многих крупных PLM-пакетах есть встроенные хранилища и инструменты управления потоками информаций.
Передача из головы в голову через рот хорошо работает в мелких командах и на коротких промежутках времени. В длинных проектах с распределенными командами (взять тот же опенсорс, который у все на слуху) хорошая систематизированная документация с картинками ценнее несовершенства кода. А ещё пиар, шум на конференциях, статьи во всех уголках интернета.
знания – это не документация, а опыт, полученный при выполнении конкретного проекта конкретным сотрудникомтакие знания пролюбливаются только так, если совсем не обращать внимание на документирование. я не призываю оформлять всё по ГОСТ 666-1488 от 1984 г. с правильными отступами, шрифтами и т.д., но хотя бы подводные камни, костыли, особенности этого самого проекта и, вообще, неочевидные моменты должны быть зафиксированы в доступном месте в мало-мальски удобочитаемом виде.
Ну само собой, я и не ударяюсь во вторую крайность. Без доков будет непонятна база — как, в принципе, функционирует продукт. Конечно, доки — это часть управления знаниями. Просто тут надо разделять понятия знаний и информации. Доки — это информация, данные, факты. Знания — это результат использования этой информации.
Закидывайте меня тапками, но кроме команды разрабов есть ещё куча людей, которым надо понимать что происходит под капотом ПО. А если после устной передачи опыта остаётся 3 строчки ченчьлога "ну мы починили тут пару багов и запили 1,5 фичи", то это явно не передача знаний.
Потому что не интересуется никто больше :) Таски в джире двигаются, закрываются и никому ничего не надо больше. Редкий тестировщик может иногда в код залезть и что-то там посмотреть
Ну, я привык таких вопросов особо не задавать. Интересуется кто-то — ради бога, мне не жалко (пока особо мою работу не аффектит). Вопрос "а зачем?" только для понимания на каком уровне объяснять.
Но, может быть, потому что я и сам привык запрашивать информацию, вроде к разработке особо не относящуюся, от той же поддержки до бухгалтерии и юротдела, не говоря об основных подразделениях. И да, бывает очень сложно объяснить, а зачем мне это. Очень многие отделы во многих компаниях работают "в вакууме". Или на неформальной, личной основе происходит шаринг знаний. Хорошо если при увольнении человек передаст приемнику контакты сотрудника из другого отдела, с которым он решал те или иные вопросы "негласно".
А не возникало желания где-нибудь зафиксировать ответы на самые часто задаваемые вам вопросы (возможно, на разных уровнях детализации), и потом просто шарить ссылку на пост в корп.блоге или что у вас используется для корп.коммуникаций?
Полезная штука — не надо много раз расписывать одно и то же и терять на этом время.
Желание возникало, но не встречало поддержки у руководства в плане выделения ресурсов под это.
Мне в какой-то момент, например, становится лень каждый раз одно и то же расписывать. Я себе в бложек ответ забрасываю, и когда меня опять о том же спрашивают, я просто ссылку даю.
Это не про ресурсы, а про мою личную лень и комфорт :)
Новички пишут код, а инженеры кто по старше — разрабатывают архитектуру и документацию. Вроде логично. Потом старшие уходяд и их места занимают бывшие новички, с большим опытом написания кода и отсутствием других инженрных навыков.
но ведь не инженеры занимаются обслуживанием клиентов, раскаткой продукта, маркетингом. А без понимания того, как продукт работает, продавть не так-то просто.
А как принять решение, в какую сторону дальше развивать продукт? Какие фичи туда добавлять? Это же нужно собрать обратную связь, проанализировать, оценить в деньгах, спланировать. Потому и странно, что разработка часто себя отгораживает от остальных и пытается что-то у себя внутри запилить самостоятельно, но не ввязаться в кросс-командную историю про обмен знаниями и опытом.
А еще интересный момент с тем, что пилить внутренние инструменты как-то не очень хочется — они же не продаются. Но без эффективного взаимодействия «под капотом» компании надолго на рынке удержаться не получится.
Хранение знаний в головах прочно привязывает жизнь продукта к команде. Потому, что поддерживать другими ресурсами его нереально. Ребята, которые писали манифест знали, что говорить. Бизнес нашел свой выход. Время от времени ситуация на рынке меняется и продукт сливается вместе с командой. На освободившиеся места нанимаются новые люди и новая улучшенная версия пилится с нуля.
Бэклог — знания о планах ПО и хотелках стейкхолдеров
Груминг — шаринг знаний о планах и хотелках со стороны ПО и стейкхолдеров и шаринг знаний о необходимых для этого ресурсов со стороны разработки
Бэклог спринта — знания о согласованных содержании работ на спринт
Плэнинг — собственно согласование этих знаний
Демо — шаринг знаний о том, что было сделано за спринт
Дружат ли Agile и Knowledge Management?