Pull to refresh
Comments 22

Забавно: только что проходил немецкоязычные курсы по Agile — так там прямо говорится, что необходимы инструменты обмена и управления знаниями.


И что одно из наиболее удобных — внутренняя Вики. Ну, и всяческие сетевые диски с документацией и складом информаций от прошлых и текущих проектов, системы контроля версий в том числе и для документации и т.д.


И ещё во многих крупных PLM-пакетах есть встроенные хранилища и инструменты управления потоками информаций.

То же самое в pmbok про необходимость.
Вики, истории проектов (проектный опыт) и прочие. Даже стартану через пару лет трудно будет разобраться в первых проектах, ибо текучка.

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

Шум, кстати, вообще ценная штука) он неформальный, а неформально люди чаще делятся всякими рассказами о костыльных решениях кмк :)

знания – это не документация, а опыт, полученный при выполнении конкретного проекта конкретным сотрудником
такие знания пролюбливаются только так, если совсем не обращать внимание на документирование. я не призываю оформлять всё по ГОСТ 666-1488 от 1984 г. с правильными отступами, шрифтами и т.д., но хотя бы подводные камни, костыли, особенности этого самого проекта и, вообще, неочевидные моменты должны быть зафиксированы в доступном месте в мало-мальски удобочитаемом виде.

Ну само собой, я и не ударяюсь во вторую крайность. Без доков будет непонятна база — как, в принципе, функционирует продукт. Конечно, доки — это часть управления знаниями. Просто тут надо разделять понятия знаний и информации. Доки — это информация, данные, факты. Знания — это результат использования этой информации.

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

Закидывайте меня тапками, но кроме команды разрабов есть ещё куча людей, которым надо понимать что происходит под капотом ПО. А если после устной передачи опыта остаётся 3 строчки ченчьлога "ну мы починили тут пару багов и запили 1,5 фичи", то это явно не передача знаний.

Зачем же закидывать?) Это, кстати, очень важная тема. У разработчиков довольно часто можно встретить непонимание, кому еще, кроме них, может пригодится инфа об их работе. Разработка в вакууме :) Это интересное и удивительное явление. Есть мысли, почему так происходит?

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

Это если мы разработкой ограничимся. Я вот не из разработки, а из техподдержки изначально. И знания с разработчиков начал собирать именно по запросу техподдержки, потому что по запросу скорость ответов разраотчиков была неприемлема для клиентского сервиса. клиенту просто очень долго ждали решения своих проблем. То есть вполне осязаемая пробема с довольно логичным решением: если реактивно получать информацию долго, надо обеспечить наличие этой информации 24/7 на постоянной основе. Но и при такой постановке проблемы с каждой новой командой разработчиков приходилось достаточно долго переписываться и объяснять, зачем нам от них нужна информация. Потому что «мы внутри себя пошарили, а остальным это зачем?»

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


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

Самые больные места обозначили :)
А не возникало желания где-нибудь зафиксировать ответы на самые часто задаваемые вам вопросы (возможно, на разных уровнях детализации), и потом просто шарить ссылку на пост в корп.блоге или что у вас используется для корп.коммуникаций?
Полезная штука — не надо много раз расписывать одно и то же и терять на этом время.

Желание возникало, но не встречало поддержки у руководства в плане выделения ресурсов под это.

Да я не про фиксацию на благо компании. Я про свое личное удобство. То есть вот есть конкретно вы, и у вас есть знания, которые у вас кто-то постоянно спрашивает. 5 раз. 10 раз и т.д. В почте, в слаке, в каких-то еще чатиках. И вам приходится каждый раз писать ответ, рассказывать на встрече и т.д.
Мне в какой-то момент, например, становится лень каждый раз одно и то же расписывать. Я себе в бложек ответ забрасываю, и когда меня опять о том же спрашивают, я просто ссылку даю.
Это не про ресурсы, а про мою личную лень и комфорт :)

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

Логично, ок :) А продукт потом сам себя продает и поддерживает? А анализ решений конкурентов вообще не проводится? Я о том и говорю, что инженеры и новички создают продукт, у них текучка, и наставничество для сохранения знаний тут хорошо заиграет.
но ведь не инженеры занимаются обслуживанием клиентов, раскаткой продукта, маркетингом. А без понимания того, как продукт работает, продавть не так-то просто.
А как принять решение, в какую сторону дальше развивать продукт? Какие фичи туда добавлять? Это же нужно собрать обратную связь, проанализировать, оценить в деньгах, спланировать. Потому и странно, что разработка часто себя отгораживает от остальных и пытается что-то у себя внутри запилить самостоятельно, но не ввязаться в кросс-командную историю про обмен знаниями и опытом.
А еще интересный момент с тем, что пилить внутренние инструменты как-то не очень хочется — они же не продаются. Но без эффективного взаимодействия «под капотом» компании надолго на рынке удержаться не получится.

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

Согласен полностью. Из ушедшей головы знаний не вытянешь. автобусный фактор никто не отменял. Работа со знаниями — это такой способ обезопасить себя от изобретения велосипеда.

Бэклог — знания о планах ПО и хотелках стейкхолдеров
Груминг — шаринг знаний о планах и хотелках со стороны ПО и стейкхолдеров и шаринг знаний о необходимых для этого ресурсов со стороны разработки
Бэклог спринта — знания о согласованных содержании работ на спринт
Плэнинг — собственно согласование этих знаний
Демо — шаринг знаний о том, что было сделано за спринт

Only those users with full accounts are able to leave comments. Log in, please.