Тема 10.3 — Управление знаниями и документация

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

Почему это важно в здравоохранении и уходе#

Команды цифрового здравоохранения малы, специализированы и часто сшиты из штатных сотрудников, подрядчиков и инженеров поставщиков. Человек, понимающий, почему интерфейс патологоанатомической лаборатории повторяет попытку три раза, прежде чем отказать, или какой флаг в электронной медицинской карте подавляет дублирующее предупреждение об аллергии, часто один — и он уходит, выходит на пенсию или болеет в ту неделю, когда интеграция ломается в 2 часа ночи. Когда знание уходит с ним, система становится не просто труднее в сопровождении; она становится труднее в безопасной эксплуатации. Недокументированный обходной путь, на который полагался клиницист, может тихо исчезнуть, и никто из оставшихся не знает, что он был несущим.

Ставки специфичны для сектора. Неверно понятая конфигурация может породить запись не того пациента, пропущенное предупреждение или сломанное направление — вред, измеряемый результатами пациентов, а не тикетами простоя. Государственные органы также несут законные обязанности: медицинские записи должны храниться определённые сроки, а решения об уходе и общественных деньгах должны быть аудируемыми спустя годы и находимыми, когда приходят коронер, регулятор или запрос Freedom of Information. Хорошее управление знаниями поэтому отчасти клиническая безопасность, отчасти управление и отчасти уважение к следующему человеку, которому придётся поддерживать услугу в работе. Оно неотделимо от того, как вы ведёте живую эксплуатацию (см. тему 3.8 — Управление услугой и живая эксплуатация) и как проектируете команды (см. тему 7.0 — Структуры команд, роли и ответственность).

Ключевые понятия#

Управление знаниями как дисциплина. Управление знаниями — набор практик, посредством которых организация создаёт, фиксирует, распространяет и повторно использует то, что знает. Оно балансирует три компонента — люди и культуру, процессы и структуру и технологию — и проваливается всякий раз, когда руководители считают его покупкой инструмента, а не привычкой. «Знание» простирается от того, как клинический путь реально работает в конкретном трасте, до того, как настроен конкретный интеграционный движок.

Неявное против явного знания. Неявное знание живёт в головах и руках людей — суждение, интуиция и с трудом заработанное «надо знать, что этот траст кодирует выписку иначе», которое трудно записать. Явное знание — то, что артикулировано и кодифицировано в документах, диаграммах и ранбуках. Большая часть знания, удерживающего услугу безопасной, начинается неявной; работа управления знаниями — преобразовать достаточно его в явную форму, чтобы услуга не зависела от одной головы.

Модель преобразования знаний SECI. Модель SECI (Socialization, Externalization, Combination, Internalization — социализация, экстернализация, комбинация, интернализация) Нонаки и Такеучи описывает, как знание перемещается между неявной и явной формами: обмен через совместную работу (социализация), запись неявного знания (экстернализация), объединение явных фрагментов в более крупные документы (комбинация) и усвоение документированного знания обратно в беглую практику (интернализация). Она полезна, потому что напоминает: одной документации недостаточно — парная работа, наблюдение за работой и сообщества важны не меньше вики.

Зависимость от ключевого человека и bus factor. Bus factor — число людей, которых пришлось бы потерять, чтобы услуга встала из-за отсутствия кого-либо, кто её понимает. Bus factor, равный единице, — состояние по умолчанию большинства малых цифровых команд и серьёзный операционный риск в услуге, от которой зависит здоровье людей. Высокая текучесть персонала, активное использование подрядчиков и привязка к единственному поставщику сдвигают число вниз; осознанная документация, перекрёстное обучение и парная работа поднимают его обратно.

Документация как первоклассный результат. Относитесь к документам как к продуктам, а не побочным продуктам. Руководство по услуге описывает, что такое услуга и как она себя ведёт; ранбук (или плейбук) даёт пошаговые процедуры запуска, остановки и восстановления; запись об архитектурном решении (ADR) фиксирует, почему сделан значимый выбор, чтобы будущие сопровождающие не раскручивали его, не зная причин. Единый источник истины означает, что каждый факт ведётся мастером ровно в одном месте, чтобы люди не гонялись за противоречивыми копиями «текущей архитектуры».

Docs-as-code. Хранение документации в том же репозитории под контролем версий, что и работа, — в простом тексте или Markdown, с рецензированием как у кода и автоматической публикацией — держит документы близко к тому, что они описывают, и делает их куда более вероятно актуальными. Когда диаграмма живёт рядом с кодом и меняется в том же pull request, она гниёт медленнее.

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

Управление записями и хранение. Управление записями управляет информацией на протяжении её жизненного цикла, включая то, как долго её надо хранить и когда её можно уничтожить. В здравоохранении это частично предписано законом: клинические записи имеют определённые сроки хранения по NHS Records Management Code of Practice. Это отличается от документации команды, и смешение двух вызывает реальные ошибки — мы вернёмся к этому ниже.

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

Лучшие практики#

1. Сделайте документацию частью определения готовности, а не запоздалой мыслью. Функция, интеграция или изменение конфигурации не «готовы», пока не существуют запись в ранбуке, ADR (если принято значимое решение) и обновление руководства по услуге. Встройте это в способы работы, чтобы писалось, пока знание свежо, тем, кто им владеет. Ретроспективная документация системы спустя полгода по памяти — место рождения неточностей и опасных пробелов.

2. Держите единый источник истины и ссылайтесь на него. Решите для каждой области, где живёт авторитетная версия каждого факта — архитектура, график дежурств, диаграмма потоков данных, — и пусть всё остальное указывает на неё, а не копирует. Дублированная документация дрейфует, а в клиническом контексте устаревшая копия, говорящая «проверка аллергии включена», когда она выключена, хуже отсутствия документа. Безжалостно удаляйте или перенаправляйте устаревшие дубликаты, которые у вас уже есть.

3. Принимайте docs-as-code и держите документацию рядом с работой. Храните ранбуки, ADR и руководства по услугам под контролем версий рядом с описываемыми системами, рецензируйте изменения документации в том же pull request, что и изменение кода, и публикуйте автоматически. Это делает обновления дешёвыми, изменения рецензируемыми, а историю аудируемой — и означает, что человека, меняющего систему, подталкивают менять и документы тем же движением.

4. Пишите ранбуки, которым мог бы последовать уставший незнакомец в 3 часа ночи. Ранбук должен предполагать, что читатель устал, не знаком с системой и под давлением — потому что при крупном инциденте он таким и будет. Используйте нумерованные буквальные шаги, называйте точные экраны и команды и указывайте ожидаемый результат каждого шага и что делать, если он не получился. Проверяйте их, поручив тому, кто их не писал, выполнить восстановление на учениях.

5. Фиксируйте «почему», а не только «что», в записях об архитектурных решениях. Короткая ADR — контекст, решение, последствия — сохраняет обоснование значимого выбора, чтобы будущие сопровождающие не отменили решение, не поняв ограничения, которое его вызвало. В здравоохранении это остро важно: конфигурация, выглядящая странной, может существовать из-за анализа опасностей клинической безопасности или решения по управлению информацией. Запись причины не позволяет доброжелательной «чистке» вернуть известный риск.

6. Осознанно поднимайте bus factor каждой критичной системы. Определите системы с bus factor, равным единице, и считайте это риском в вашем реестре с названным владельцем и планом. Объединяйте людей в пары, ротируйте знание дежурств, проводите сессии «teach-back», где эксперт документирует, а коллега следует за ним, и запретите, чтобы любой один человек был единственным, кто может развернуть или восстановить критичную для безопасности услугу. Это дешевле, чем обнаружить пробел во время сбоя.

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

8. Инвестируйте в информационную архитектуру и находимость. Структурируйте базу знаний так, чтобы новичок находил ранбук дежурства меньше чем за минуту, и агрессивно прореживайте — устаревшая страница — обязательство, а не актив. Согласуйте соглашения об именовании, ясную иерархию и владельца каждой области и ставьте дату «последний пересмотр» на важных страницах, чтобы читатели могли судить о свежести. Поиск — не замена структуре, а её дополнение.

9. Растите сообщества практики, чтобы распространять неявное знание. Создавайте межкомандные гильдии для значимых ремёсел — клиническая безопасность, безопасность, фронтенд, инженерия данных — с лёгким мандатом: делиться тем, чему учитесь, согласовывать общие паттерны, наставлять новичков. Эти форумы переносят неявное знание, которого не фиксирует никакой документ, и сокращают дублирующиеся ошибки между командами (см. тему 7.5 — Развитие людей и организации). Дайте им время в рабочей неделе, иначе они зачахнут.

10. Отделяйте документацию команды от законных записей — и управляйте обоими. Будьте явны о том, что есть знание команды (ранбуки, ADR, вики), а что — запись, подлежащая законному хранению (клинические записи, решения об уходе, финансовые одобрения, решения по управлению информацией). Применяйте к последнему графики хранения NHS Records Management Code of Practice и не позволяйте случайному удалению вики уничтожить то, что вы были обязаны по закону хранить. Равно не копите всё навсегда «на всякий случай» — избыточное хранение само по себе риск управления и защиты данных.

11. Сделайте онбординг проверкой вашей документации. Относитесь к каждому онбордингу как к живому аудиту: если компетентный новый инженер или клиницист не может стать продуктивным по вашим письменным материалам плюс немного парной работы, ваша документация провалилась, а пробелы, на которые он наткнулся, — ваш бэклог. Просите новичков исправить первое, что их запутало, как первый вклад. Это превращает онбординг из односторонней стоимости в непрерывную петлю улучшения непрерывности знаний.

Вопросы для обсуждения с командой#

1. Если бы единственный человек, понимающий нашу самую критичную интеграцию, ушёл завтра, как скоро мы оказались бы уязвимы и чего именно мы не знали бы? Это превращает абстрактную идею bus factor в конкретный стресс-тест ваших важнейших систем. Проработайте реальный пример — поток из патологоанатомической лаборатории, конфигурацию единого входа, логику сопоставления общей записи ухода — и честно спросите, кто ещё мог бы эксплуатировать, менять и восстанавливать её без этого человека. Напряжение, которое надо вывести, в том, что самое глубокое знание обычно сидит у вашего самого занятого, самого доверенного человека, а давление поставки делает рациональным для него никогда не останавливаться и не записывать. Отличайте знание, подлинно неявное и трудно кодифицируемое, от знания, просто никогда не зафиксированного, потому что никто не нашёл времени. Хороший, честный ответ вслух называет ваши системы с bus factor, равным единице, признаёт, какие пробелы реальны, и выдаёт просчитанный по стоимости план — парная работа, спринты документации, перекрёстное обучение, — а не расплывчатое заверение «всё в головах людей, и это нормально». Если разговор комфортен, вы были недостаточно конкретны.

2. Когда мы что-то записываем, как мы знаем, что кто-то когда-нибудь это найдёт, доверится и сохранит актуальным — и где наша документация уже нам лжёт? Устаревшая документация не нейтральна; в критичной для безопасности обстановке она активно вводит в заблуждение уставшего оператора, подталкивая к неверному действию. Обсуждение должно столкнуться с разницей между наличием документов и наличием документов, которые люди могут найти, которым могут доверять и по которым могут действовать, — вопрос информационной архитектуры, владения и свежести, а не объёма. Обсудите, есть ли у вашей базы знаний реальная структура или это разрастание, по которому никто не ориентируется, и живут ли документы достаточно близко к работе (docs-as-code), чтобы оставаться актуальными, или дрейфуют в отдельном инструменте, который никто не обновляет. Спросите каждого, когда он в последний раз полагался на внутренний документ и обнаружил его неверным и чего это стоило. Сильный ответ определяет конкретные страницы, о которых вы знаете, что они устарели, назначает владельцев и даты пересмотра и согласует единый источник истины для самых важных фактов — и готов удалять больше, чем добавлять.

3. Что реально изменилось в нашей работе после последнего серьёзного инцидента — и если ответ «не многое», зачем мы продолжаем проводить разборы? Разборы после инцидентов обычны; разборы, меняющие практику, редки, и в разрыве между ними повторяются те же провалы. Это проверяет, подлинная ли петля обратной связи ваш процесс извлечения уроков или ритуал, производящий документ и никаких изменений. Честно изучите культурные условия: разборы выявляют правду только если они безобвинительны, а люди скроют реальную причину, если процесс их наказывает, так что психологическая безопасность — предпосылка, а не любезность (см. тему 8.1 — Управление изменениями). Посмотрите на последние несколько инцидентов и проследите каждое действие: выполнено ли оно и предотвратило ли повторение. Хороший ответ может указать на конкретное изменение — переписанный ранбук, новое оповещение, исправление проекта, — которое произвёл прошлый разбор, и откровенен о действиях, которые были зафиксированы и тихо заброшены, с планом закрыть эту петлю.

4. Что из того, что мы держим, — законные записи, которые мы обязаны хранить, а что — рабочие заметки, которыми мы управляем ради актуальности — и уверены ли мы, что не удаляем первое и не копим второе? У организаций здравоохранения и ухода есть обязанности по хранению, которые большинство цифровых команд выполняют по инстинкту, а не по правилу, и обе ошибки реальны: случайно удалить страницу вики, которая оказалась документирующей решение об уходе, или копить всё навсегда «на всякий случай», создавая обязательство по защите данных и находимости. Обсуждение должно провести ясную черту между записью, подпадающей под NHS Records Management Code of Practice, — клинические записи, решения об уходе и финансировании, постановления по управлению информацией, — и знанием команды вроде ранбуков и ADR, которыми вы управляете ради свежести, а не законного хранения. Выведите неудобные промежуточные случаи, например ADR, документирующую, почему была принята опасность клинической безопасности, — она может быть и тем и другим. Напряжение в том, что инженеры оптимизируют аккуратную актуальную документацию, а управление — защитимое хранение, и два инстинкта тянут в противоположные стороны. Честный ответ может сказать, кому принадлежит график хранения, где проведена граница и что произошло бы с конкретной записью, если бы её запросили коронер, регулятор или запрос Freedom of Information спустя годы.

5. Что в наших способах работы реально приводит к тому, что документация пишется, пока знание свежо, — и где мы всё ещё полагаемся на добрую волю и благие намерения? Каждая команда соглашается, что документация важна; куда меньше имеют механизм, делающий это по умолчанию, а не героизмом. Этот вопрос проверяет, встроена ли запись в поток работы — определение готовности, блокирующее «готово» без записи в ранбуке или ADR, документация, рецензируемая в том же pull request, что и изменение, docs-as-code, чтобы диаграмма жила рядом с описываемым, — или это зависит от того, что отдельные люди выбирают остановиться и писать, когда давление поставки говорит «выпускай». Честно изучите стимулы: ретроспективная документация системы по памяти спустя полгода — место рождения опасных неточностей, так что ценность почти целиком в фиксации в момент. Посмотрите на последние несколько изменений и спросите, писал ли документацию человек, владевший знанием, в то время или кто-то пристроил позже, реконструируя. Сильный ответ указывает на конкретные уже работающие механизмы и называет пробелы, где процесс всё ещё опирается на память и силу воли, с планом их закрыть.

6. Как мы переносим знание, которого никакой документ никогда не зафиксирует, — суждение и «надо знать, что этот траст кодирует выписку иначе», — и не становится ли это труднее каждый раз, когда заканчивается контракт подрядчика? Многое из того, что удерживает услугу безопасной, неявно: интуиция, распознавание паттернов и с трудом заработанный контекст, сопротивляющийся записи, а модель SECI напоминает, что одна документация никогда не экстернализует его полностью. Этот вопрос спрашивает, насколько осознанно вы распространяете это знание через парную работу, наблюдение, сессии teach-back и сообщества практики, а не предполагаете, что вики справляется. Напряжение острее всего там, где вы опираетесь на подрядчиков и нескольких поставщиков, потому что их глубочайшее знание уходит за дверь в конце каждого договора, если фиксация не договорное и культурное ожидание, а не услуга, о которой просят на последней неделе. Обсудите, есть ли у ваших ремёсел — клиническая безопасность, интеграция, инженерия данных — живые гильдии с защищённым временем или межкомандное обучение происходит лишь случайно. Честный ответ отличает знание, подлинно неявное и требующее передачи от человека к человеку, от знания, просто не зафиксированного, и может указать на реальные практики — график парной работы, план непрерывности знаний для уходящих подрядчиков, действующее сообщество практики, — а не стремление.

На практике: пример из здравоохранения и ухода#

Интегрированная система ухода (ICS) ведёт общую запись ухода, тянущую данные из трёх острых трастов, общинных услуг и системы управления случаями социального ухода. Интеграцию два года назад построил в основном один инженер-подрядчик, «Дев», понимавший каждую причуду логики сопоставления, решающей, когда две записи относятся к одному человеку. Контракт Дева заканчивается через шесть недель. Есть вики, но она последний раз существенно обновлялась во время сборки.

Руководитель поставки считает это риском bus factor, равного единице, и вносит в реестр рисков программы со своим именем напротив. В течение шести недель она финансирует небольшие усилия по «непрерывности знаний»: Дев каждое утро работает в паре с двумя штатными инженерами, и вместо прощального сброса мозгов они экстернализуют по ходу — пишут ранбуки для видов отказов, которые Дев знает наизусть, и ADR, объясняющие, почему логика сопоставления допускает определённые несовпадения (оказывается, одно кажущееся небрежным правило существует, чтобы избежать известной опасности для безопасности пациента, отмеченной в исходном деле клинической безопасности). Документы лежат в том же репозитории Git, что и код интеграции, рецензируются в pull request, так что версионированы и актуальны.

Через два месяца после ухода Дева поток из одного острого траста ночью начинает производить дублирующие записи пациентов. Дежурный инженер — никогда не встречавший Дева — открывает ранбук, следует нумерованным шагам, подтверждает ожидаемый результат на каждом этапе и в течение часа восстанавливает корректное сопоставление. В безобвинительном разборе после инцидента команда находит триггер (вышестоящее изменение того, как траст кодирует номера NHS) и превращает его в оповещение мониторинга и обновление ранбука. То, что было бы многодневной, высокорисковой суматохой — и подлинным инцидентом безопасности пациента, — стало документированным часовым восстановлением, потому что неявное знание сделали явным, пока человек, владевший им, ещё был на месте.

Секторные линзы#

Стартап#

Стартап цифрового здравоохранения живёт с наивысшим риском bus factor и наименьшим запасом, чтобы с ним справляться: горстка инженеров, глубокое знание в каждой голове и культура, ценящая выпуск выше письма. Прагматичный ход — лёгкая, дешёвая документация, встроенная в рабочий процесс: ADR как короткие файлы Markdown в репозитории, ранбуки, пишущиеся в первый раз, когда что-то ломается, docs-as-code с первого дня, чтобы привычка сложилась до того, как масштаб сделает её трудной. Основателям следует противиться соблазну отложить всю документацию «на после соответствия продукта рынку», потому что сбой клинического продукта или проваленная оценка клинической безопасности или DTAC (Digital Technology Assessment Criteria) из-за нехватки доказательств может быть экзистенциальным. Цель — не отполированная база знаний, а то, чтобы никакой один уход не мог потопить компанию.

Малый бизнес#

Устоявшийся малый поставщик — общая практика, общинная аптека, дом ухода или клиника на одной площадке — несёт те же обязанности по клинической безопасности и хранению записей, что и крупный траст, но без выделенной ИТ-функции или функции управления знаниями и с малым запасом, чтобы её построить. Здесь практика должна быть радикально соразмерной: одно находимое место для горстки значимых ранбуков (как восстановить клиническую систему, кому звонить, когда общая запись ухода отказывает), простое соглашение о названных владельцах, чтобы критичное знание не сидело только у управляющего практикой или одной давно работающей медсестры, и ясная граница между законными записями, которые они обязаны хранить, и рабочими заметками, которые нет. Острый риск — bus factor, равный единице, под видом непрерывности: человек, знающий, как всё настроено, также ведёт ежедневную работу, и выход на пенсию или длительная болезнь могут оставить никого, способного эксплуатировать критичную для безопасности систему. Там, где системы поставляются и хостятся вендором, малому поставщику всё равно следует записывать собственную локальную конфигурацию и обходные пути, потому что поставщик не задокументирует, как эта организация реально использует продукт.

Предприятие#

Крупный траст NHS, ICS или поставщик технологий здравоохранения сталкивается с противоположным провалом: слишком много документации, разбросанной по SharePoint, Confluence, сетевым дискам и почте, без единого источника истины и с плохой находимостью. Задача предприятия — информационная архитектура, владение и прореживание: решить, где мастер каждого факта, назначить владельцев, вывести дубликаты и связать управление знаниями с управлением услугой и контролем изменений. Сообщества практики здесь отрабатывают своё, распространяя паттерны по десяткам команд, которые иначе каждая болезненно усваивали бы один и тот же урок. Риск, которым надо управлять, — активное использование подрядчиков и нескольких поставщиков, где знание уходит за дверь в конце каждого контракта, если фиксация не договорное и культурное ожидание.

Правительство#

Национальный или местный публичный орган — NHS England, DHSC, UKHSA или местный орган власти — действует под законными обязанностями управления записями, обязательствами Freedom of Information и публичным аудитом, так что управление знаниями отчасти вопрос закона и общественной подотчётности. Решения об услугах, деньгах и политике должны документироваться, храниться определённые сроки и быть находимыми спустя годы для специальных комитетов, проверок National Audit Office и публичных расследований; недавняя история крупных расследований показывает, как плохое ведение записей само становится скандалом. Правительство должно держать черту между законными записями (хранящимися и уничтожаемыми по графику) и рабочим знанием (управляемым ради актуальности), дисциплинированно применяя NHS Records Management Code of Practice. Прозрачность — лозунг: рабочее допущение должно быть, что документацию однажды может прочесть общественность.

Типичные виды отказов#

• Герой и bus factor, равный единице. Прославление человека, который «просто знает» систему, без финансирования работы по распространению этого знания. Кажется эффективным до дня, когда он недоступен, а у критичной для безопасности услуги нет никого, кто может её эксплуатировать.
• Документация «написать один раз». Документы, созданные во время сборки и никогда больше не тронутые, дрейфующие в уверенную ложь. Устаревшие документы опаснее отсутствия, потому что люди действуют по ним.
• Свалка вики. Тысячи страниц, нет структуры, владельцев, дат пересмотра — знание, технически существующее, но не находимое и не заслуживающее доверия. Объём принят за ценность.
• Документы вдали от работы. Документация в отдельном инструменте, который никто не открывает при кодировании, гарантирующая расхождение с реальностью. Docs-as-code — противоядие.
• Театр извлечения уроков. Разборы после инцидентов, производящие документ и список действий, которые никогда не закрываются, так что тот же инцидент повторяется. Процесс становится ритуалом, а не улучшением.
• Путаница записей и заметок. Либо удаление того, что вы были обязаны по закону хранить, либо накопление всего навсегда с созданием обязательства по защите данных и находимости. Оба происходят из неразличения законных записей и документации команды.
• Обвинение в комнате разбора. Разборы, наказывающие человека, ближайшего к сбою, что учит всех скрывать реальную причину и разрушает честность, от которой процесс зависит.

Модель зрелости#

Контрольный список#

• У каждой критичной системы есть руководство по услуге, актуальный ранбук и ADR для её значимых решений.
• Документация — часть вашего определения готовности и рецензируется в том же pull request, что и изменение.
• У каждой области есть названный единый источник истины; известные дубликаты удалены или перенаправлены.
• Системы с bus factor, равным единице, в реестре рисков с владельцами и действующим планом перекрёстного обучения.
• Ранбуки проверены тем, кто их не писал, на учениях или в реальном инциденте.
• Разборы после инцидентов безобвинительны и производят действия, имеющие владельцев и сроки, которые закрываются.
• У базы знаний есть ясная структура, владельцы страниц и даты пересмотра; устаревшие страницы прореживаются.
• Существует хотя бы одно действующее сообщество практики для ремесла, охватывающего команды, с защищённым временем.
• Законные записи отличаются от документации команды и управляются по корректному графику хранения.
• Новичков просят исправить первый встреченный пробел документации как ранний вклад.

Ключевые источники#

• NHS England / NHSX, Records Management Code of Practice 2021 — законные графики хранения и обязанности жизненного цикла медицинских записей и записей ухода.
• GOV.UK Service Manual (Government Digital Service) — руководство по написанию для цифровых услуг и их ведению, включая документацию и эксплуатацию услуги.
• NHS Digital Service Standard — ожидания к построению и поддержанию устойчивых, хорошо документированных цифровых услуг.
• Michael Nygard, «Documenting Architecture Decisions» (2011) — исходный паттерн записей об архитектурных решениях (ADR).
• Google, Site Reliability Engineering — безобвинительные разборы после инцидентов (postmortems), ранбуки и сокращение операционного риска ключевого человека.
• Etienne Wenger, Communities of Practice: Learning, Meaning, and Identity (1998) — основополагающий текст о сообществах практики.
• Nonaka & Takeuchi, The Knowledge-Creating Company (1995) — модель SECI преобразования неявного знания в явное.
• Сообщество Write the Docs — практическое руководство по docs-as-code и отношению к документации как к продукту.

Литература#

1. Knowledge management — Wikipedia — https://en.wikipedia.org/wiki/Knowledge_management
2. Tacit knowledge — Wikipedia — https://en.wikipedia.org/wiki/Tacit_knowledge
3. Explicit knowledge — Wikipedia — https://en.wikipedia.org/wiki/Explicit_knowledge
4. SECI model of knowledge dimensions — Wikipedia — https://en.wikipedia.org/wiki/SECI_model_of_knowledge_dimensions
5. Bus factor — Wikipedia — https://en.wikipedia.org/wiki/Bus_factor
6. Runbook — Wikipedia — https://en.wikipedia.org/wiki/Runbook
7. Architectural decision — Wikipedia — https://en.wikipedia.org/wiki/Architectural_decision
8. Single source of truth — Wikipedia — https://en.wikipedia.org/wiki/Single_source_of_truth
9. Community of practice — Wikipedia — https://en.wikipedia.org/wiki/Community_of_practice
10. Records management — Wikipedia — https://en.wikipedia.org/wiki/Records_management
11. Information architecture — Wikipedia — https://en.wikipedia.org/wiki/Information_architecture
12. Postmortem documentation — Wikipedia — https://en.wikipedia.org/wiki/Postmortem_documentation
13. Onboarding — Wikipedia — https://en.wikipedia.org/wiki/Onboarding
14. Records Management Code of Practice 2021 — NHS England / NHSX — https://www.nhsx.nhs.uk/information-governance/guidance/records-management-code/
15. Service manual — Government Digital Service (GOV.UK) — https://www.gov.uk/service-manual
16. Documenting Architecture Decisions — Michael Nygard — https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
17. Site Reliability Engineering — Google — https://sre.google/books/
18. Write the Docs — docs-as-code guidance — https://www.writethedocs.org/guide/docs-as-code/