Уже несколько раз, общаясь с коллегами на конференциях и лекциях, я получал вот этот вопрос:
Кажется, пора зафиксировать где-то ответ на него и ссылаться при случае :)
Итак, нужно ли управление знаниями при Agile, где информация передаётся от человека к человеку? На самом деле, это тот случай, когда ответ содержится в самом вопросе. Информация передается от человека к человеку, то есть, происходит обмен знаниями. Устная традиция – это один из инструментов управления знаниями. Очень ненадежный, но, безусловно, самый популярный. Задача человека, отвечающего за управление знаниями – создать удобную для обмена знаниями среду. Само собой, в agile-командах среда будет отличаться от классических оргструктур. Но принципиально ответ, разумеется, «да, нужно». Давайте разбираться подробнее.
Начнем с самого манифеста Agile. Его авторы прямо говорят, что
«То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева»Agile-манифест не говорит нам «ничего не документируйте»! Он говорит, что заказчик платит деньги за работающий продукт. Если он его получил, то на отсутствие красивой документации он может закрыть глаза, но не наоборот. Манифест помогает выстроить приоритеты, но не ставит запретов. И даже если на большие доки времени не находится, в процессе работы создается огромное количество артефактов управления знаниями, которыми потом можно оперировать при принятии новых решений: тикеты, чейнж-логи и т.д.
«Люди и взаимодействие важнее процессов и инструментов».В одном из исследований, проведенных среди работников ИТ-сферы, четко видно, что люди в ИТ-индустрии ставят обмен знаниями (то есть взаимодействие) на второе место среди существующих в сфере разработки ПО вызовов.
По большому счету, результаты этого исследования подтверждают первый тезис манифеста. Мне кажется, что ноги у вопроса растут из того, что под управлением знаниями многими в разработке понимается документирование, а не взаимодействие между людьми по передаче опыта.
Да, кстати, в одном из прошлых постов я уже говорил, что знания – это не документация, а опыт, полученный при выполнении конкретного проекта конкретным сотрудником. Если даже вы не создали документацию к продукту, то определенный опыт во время выполнения проекта вы точно получили. Более того, инструменты Agile опосредованно способствуют тому, чтобы этот опыт постоянно шарился.
Например, ретроспективы. Что это, если не процесс обмена знаниями? Команда собирается, делится имеющимися проблемами (в сфере УЗ это называется «извлеченные уроки») и вырабатывает план изменений с целью решить эти проблемы. То есть, люди пошарили свой опыт друг с другом, обсудили его, выработали стратегию по преодолению неудобств на ближайший период и зафиксировали где-то этот самый план изменений (артефакт управления знаниями). Обычно результаты таких встреч где-то сохраняются. Не уверен, что есть эффективные команды, которые после завершения итерации удаляют данные обо всех прошлых ретро.
Или парное программирование. Даже Википедия говорит нам насчет этого инструмента следующее:
Преимущества:
***
Наставничество
Каждый, даже начинающий программист, знает что-то, чего не знают другие. Парное программирование — безболезненный способ распространить эти знания.
***
Обучение
Программисты постоянно обмениваются знаниями.
Два опытных программиста прокачивают друг друга, пользуясь собственным опытом. Сеньор прокачивает джуна, выполняя функцию наставника. Наставничество в команде – это вообще одно из самых популярных воплощений управления знаниями в сфере разработки ПО. Тот же Яндекс даже наружу начал обучать этому искусству.
Или возьмем ситуацию при использовании канбана. Предположим, тестировщики проверяют 10 функций в месяц, а разработчики успевают реализовать 20. Это приводит к накоплению работы у QA, а значит, рискам качества их работы. В таком случае можно, например, перераспределить ресурсы и подключить разработчиков к созданию автотестов. По итогам итерации команда получила негативный опыт по планированию и, основываясь на нем, может составить новый план таким образом, чтобы обеспечить максимальную пропускную способность конвейера при тех же ресурсах. То есть, в процессе разработки были получены знания (=опыт), проанализировав которые, команда пришла к оптимизации процесса.
Ну и совсем уж на поверхности вопрос: а команда не будет использовать полученный за время работы над проектом опыт при работе над другими проектами? То есть, экспериментальным путем за текущий проект они выяснили, что могут реализовывать с тестами в среднем 15 функций за месяц. Не будут же они в новом проекте снова изначально закладываться на 20?
Знания – это все, что происходило вокруг проекта. Процесс разработки проходит не в вакууме. Согласования, полезные ссылки, взаимодействие с другими командами, онбординг новичков и т.д. Любая команда через это проходит. С набором опыта появляются различные артефакты, вроде адаптационных чек-листов для новичков или базы полезных ссылок. Это зафиксированные знания или результат осмысления полученного опыта.
Мы все каждый день участвуем в процессах обмена знаниями (ну правда, мы же постоянно друг с другом общаемся!), и работа по методологии Agile не исключает нас из этого процесса. Более того, она уже включает в себя очень действенные инструменты управления знаниями. Остается только организовать работу команды так, чтобы эти инструменты давали максимальный выхлоп.
В посте я привел всего лишь несколько примеров. Давайте в комментариях обсудим, какие еще инструменты Agile в то же время являются и инструментами управления знаниями. Ну или обсудим, почему я не прав :)
Комментарии (21)
funca
22.10.2019 23:47Передача из головы в голову через рот хорошо работает в мелких командах и на коротких промежутках времени. В длинных проектах с распределенными командами (взять тот же опенсорс, который у все на слуху) хорошая систематизированная документация с картинками ценнее несовершенства кода. А ещё пиар, шум на конференциях, статьи во всех уголках интернета.
KnowledgeManager Автор
23.10.2019 08:24Шум, кстати, вообще ценная штука) он неформальный, а неформально люди чаще делятся всякими рассказами о костыльных решениях кмк :)
szelga
23.10.2019 06:32знания – это не документация, а опыт, полученный при выполнении конкретного проекта конкретным сотрудником
такие знания пролюбливаются только так, если совсем не обращать внимание на документирование. я не призываю оформлять всё по ГОСТ 666-1488 от 1984 г. с правильными отступами, шрифтами и т.д., но хотя бы подводные камни, костыли, особенности этого самого проекта и, вообще, неочевидные моменты должны быть зафиксированы в доступном месте в мало-мальски удобочитаемом виде.KnowledgeManager Автор
23.10.2019 08:27Ну само собой, я и не ударяюсь во вторую крайность. Без доков будет непонятна база — как, в принципе, функционирует продукт. Конечно, доки — это часть управления знаниями. Просто тут надо разделять понятия знаний и информации. Доки — это информация, данные, факты. Знания — это результат использования этой информации.
VolCh
23.10.2019 08:54Не просто использования, а осмысления
KnowledgeManager Автор
23.10.2019 09:21О да :) тут вообще цикличность процессов, так любимая нынче в бизнесе. Спланировал-сделал-проанализировал-снова спланировал. Если это ещё фиксировать систематически, то можно и по другим проектам принимать решения с учетом прошлого опыта по всему портфолио.
Cart00n
23.10.2019 14:52Закидывайте меня тапками, но кроме команды разрабов есть ещё куча людей, которым надо понимать что происходит под капотом ПО. А если после устной передачи опыта остаётся 3 строчки ченчьлога "ну мы починили тут пару багов и запили 1,5 фичи", то это явно не передача знаний.
KnowledgeManager Автор
23.10.2019 14:54Зачем же закидывать?) Это, кстати, очень важная тема. У разработчиков довольно часто можно встретить непонимание, кому еще, кроме них, может пригодится инфа об их работе. Разработка в вакууме :) Это интересное и удивительное явление. Есть мысли, почему так происходит?
VolCh
23.10.2019 15:40Потому что не интересуется никто больше :) Таски в джире двигаются, закрываются и никому ничего не надо больше. Редкий тестировщик может иногда в код залезть и что-то там посмотреть
KnowledgeManager Автор
23.10.2019 15:51Это если мы разработкой ограничимся. Я вот не из разработки, а из техподдержки изначально. И знания с разработчиков начал собирать именно по запросу техподдержки, потому что по запросу скорость ответов разраотчиков была неприемлема для клиентского сервиса. клиенту просто очень долго ждали решения своих проблем. То есть вполне осязаемая пробема с довольно логичным решением: если реактивно получать информацию долго, надо обеспечить наличие этой информации 24/7 на постоянной основе. Но и при такой постановке проблемы с каждой новой командой разработчиков приходилось достаточно долго переписываться и объяснять, зачем нам от них нужна информация. Потому что «мы внутри себя пошарили, а остальным это зачем?»
VolCh
24.10.2019 09:41Ну, я привык таких вопросов особо не задавать. Интересуется кто-то — ради бога, мне не жалко (пока особо мою работу не аффектит). Вопрос "а зачем?" только для понимания на каком уровне объяснять.
Но, может быть, потому что я и сам привык запрашивать информацию, вроде к разработке особо не относящуюся, от той же поддержки до бухгалтерии и юротдела, не говоря об основных подразделениях. И да, бывает очень сложно объяснить, а зачем мне это. Очень многие отделы во многих компаниях работают "в вакууме". Или на неформальной, личной основе происходит шаринг знаний. Хорошо если при увольнении человек передаст приемнику контакты сотрудника из другого отдела, с которым он решал те или иные вопросы "негласно".
KnowledgeManager Автор
24.10.2019 12:09Самые больные места обозначили :)
А не возникало желания где-нибудь зафиксировать ответы на самые часто задаваемые вам вопросы (возможно, на разных уровнях детализации), и потом просто шарить ссылку на пост в корп.блоге или что у вас используется для корп.коммуникаций?
Полезная штука — не надо много раз расписывать одно и то же и терять на этом время.VolCh
24.10.2019 15:44Желание возникало, но не встречало поддержки у руководства в плане выделения ресурсов под это.
KnowledgeManager Автор
24.10.2019 16:19Да я не про фиксацию на благо компании. Я про свое личное удобство. То есть вот есть конкретно вы, и у вас есть знания, которые у вас кто-то постоянно спрашивает. 5 раз. 10 раз и т.д. В почте, в слаке, в каких-то еще чатиках. И вам приходится каждый раз писать ответ, рассказывать на встрече и т.д.
Мне в какой-то момент, например, становится лень каждый раз одно и то же расписывать. Я себе в бложек ответ забрасываю, и когда меня опять о том же спрашивают, я просто ссылку даю.
Это не про ресурсы, а про мою личную лень и комфорт :)
funca
23.10.2019 22:19Новички пишут код, а инженеры кто по старше — разрабатывают архитектуру и документацию. Вроде логично. Потом старшие уходяд и их места занимают бывшие новички, с большим опытом написания кода и отсутствием других инженрных навыков.
KnowledgeManager Автор
24.10.2019 12:06Логично, ок :) А продукт потом сам себя продает и поддерживает? А анализ решений конкурентов вообще не проводится? Я о том и говорю, что инженеры и новички создают продукт, у них текучка, и наставничество для сохранения знаний тут хорошо заиграет.
но ведь не инженеры занимаются обслуживанием клиентов, раскаткой продукта, маркетингом. А без понимания того, как продукт работает, продавть не так-то просто.
А как принять решение, в какую сторону дальше развивать продукт? Какие фичи туда добавлять? Это же нужно собрать обратную связь, проанализировать, оценить в деньгах, спланировать. Потому и странно, что разработка часто себя отгораживает от остальных и пытается что-то у себя внутри запилить самостоятельно, но не ввязаться в кросс-командную историю про обмен знаниями и опытом.
А еще интересный момент с тем, что пилить внутренние инструменты как-то не очень хочется — они же не продаются. Но без эффективного взаимодействия «под капотом» компании надолго на рынке удержаться не получится.funca
25.10.2019 23:12Хранение знаний в головах прочно привязывает жизнь продукта к команде. Потому, что поддерживать другими ресурсами его нереально. Ребята, которые писали манифест знали, что говорить. Бизнес нашел свой выход. Время от времени ситуация на рынке меняется и продукт сливается вместе с командой. На освободившиеся места нанимаются новые люди и новая улучшенная версия пилится с нуля.
VolCh
23.10.2019 15:45+1Бэклог — знания о планах ПО и хотелках стейкхолдеров
Груминг — шаринг знаний о планах и хотелках со стороны ПО и стейкхолдеров и шаринг знаний о необходимых для этого ресурсов со стороны разработки
Бэклог спринта — знания о согласованных содержании работ на спринт
Плэнинг — собственно согласование этих знаний
Демо — шаринг знаний о том, что было сделано за спринт
kababok
Забавно: только что проходил немецкоязычные курсы по Agile — так там прямо говорится, что необходимы инструменты обмена и управления знаниями.
И что одно из наиболее удобных — внутренняя Вики. Ну, и всяческие сетевые диски с документацией и складом информаций от прошлых и текущих проектов, системы контроля версий в том числе и для документации и т.д.
И ещё во многих крупных PLM-пакетах есть встроенные хранилища и инструменты управления потоками информаций.
KnowledgeManager Автор
То же самое в pmbok про необходимость.
Вики, истории проектов (проектный опыт) и прочие. Даже стартану через пару лет трудно будет разобраться в первых проектах, ибо текучка.