Решил, что будет хорошей идеей поразмышлять о том какие маркеры могут помочь в ответе на вопрос:

— В моей базе знаний я делаю все правильно или у меня есть какие‑то существенные проблемы и недостатки?

Рассуждения хоть и субъективные, но они написаны достаточно абстрактно, чтобы всяк читающий смог примерить мысли из статьи на себя и перенести вынесенную пользу на свою уникальную, персонализированную базу знаний и свой рабочий процесс.

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

Структура статьи (оглавление)

• Маркеры хорошей базы знаний

  • Нет сомнений

  • Нет проблем с откладыванием

  • Отлаженные механизмы

  • Разнородная информация под одним куполом

  • Работоспособный поиск информации

    • База знаний НЕ как интернет

    • Релевантная информация

    • Протаптывание путей

  • Цели меняются, а база все равно работает

    • Откладывание на любой срок

    • Стабильность важнее продуктивности

      • Тестовый репозиторий

      • Сегодня и завтра без изменений

  • Не следовать за модой

  • Достаточное пространство

    • Пространство для изменений базы

    • Пространство для работы

  • Рассуждения на основе базы знаний

• Почему не получается?

  • Слишком много о себе думаю

  • Не учусь и не меняюсь

  • Имею технический долг

  • Не разделяю процессы

• Вместо итога

• Лирическое отступление

Маркеры хорошей базы знаний

Наверх

Нет сомнений

Наверх

Начну с наиболее общего маркера. Далее я приведу пример сомнения и тут же формулировку, которая бы это сомнение могла развеять. Если последняя у вас ничего не развеяла, то значит у вас есть проблемы в базе знаний. Итак, у нас не должно быть сомнений в том, что

• работать в базе знаний или не работать

  • однозначно работать, потому что...

• добавлять новые материалы или не добавлять

  • конечно, добавлять, так как...

• полезна ли база знаний или она мне вредит

  • несомненно полезна, ибо она мне...

• мне нужно будет что-то в будущем глобально переделывать

  • я меняю все небольшими и обдуманными шагами, поэтому не будет у меня ситуаций, когда все вдруг сломается и мне придется что-то переделывать

• рано или поздно мне придется начать сначала

  • я последователен в своих действиях и потому базу знаний только модифицирую, от чего она не может стать разом непригодной

  • у меня есть резервные копии и я всегда могу откатиться назад

Короче говоря, если мы просто и легко начинаем работу с базой знаний, то всё хорошо, значит мы в ней уверены, она приносит нам пользу и у нас есть продуктивная тяга постоянно к ней возвращаться.

Нет проблем с откладыванием

Наверх

Этот пункт является продолжением предыдущего. Так под откладыванием я имею в виду то, что работа в базе знаний для нас является уже некоей привычкой, само разумеющимся. Мы добываем знания, используем их по необходимости и уже не замечаем, что всё это делаем в пространстве базы знаний.

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

Отлаженные механизмы

Наверх

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

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

• Поиск, агрегация и фильтрация (потенциальных) источников знаний

  • К источникам относятся не только формальные источники знаний по типу книг, статей и прочего, но и какая-то последовательная рабочая деятельность, наблюдения и эксперименты

• Обработка информации и последующее изъятие из неё знаний

  • Этот процесс включает в себя сконцентрированное использование уже имеющихся какие-то ментальных моделей, установок, алгоритмов обработки

• Переработка, связывание, обобщение, интерпретация знаний

  • Иначе говоря, это выявление сущностных взаимосвязей и формальное их обозначение, а также нахождение и сопоставление конкретного места, контекста с исследуемыми знаниями в действующем мире

• Синтезирование знаний в последовательные модели, представления, концепции или просто алгоритмы действий

  • Также к этому относится формирование на основе знаний прототипов продуктов, проектов, механизмов и прочих вещей нуждающихся в структурах и структурировании

  • Здесь же может быть налажен процесс проверки, тестирования знаний необходимый для их корректировки, демаркации или в случае неудачи исключения из разряда объективных

• Использование знаний для изменения окружающей действительности

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

Разнородная информация под одним куполом

Наверх

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

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

Если говорить проще, то вот о чём я хочу сказать. Мир не является черно-белым. Поэтому, когда мы исследуем этот мир, то и в нашей голове не должны формироваться черно-белые представления. База знаний хоть и не является нашей цифровой копией, но всё же она вполне себе способна отражать уровень именно нашего развития и более того она даже сильно скоррелирована с ним. В общем, если у нас в голове всё чёрно-белое и в базе знаний все чёрно-белое, то у нас явно большие проблемы с "глазами" и с этим нужно точно что-то делать.

Работоспособный поиск информации

Наверх

Этот пункт я хотел бы обсудить подробнее. На мой взгляд, чем лучше налажен процесс поиска информации в базе знаний, тем лучше сама база знаний. Т.е. связь между проработанным поиском и качеством базы знаний прямая.

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

Далее я поговорю о некоторых идеях, которые могут помочь в улучшении поиска.

(Вам стоит, пожалуй, открыть содержание, чтобы понять дальнейшую структуру рассуждений. Habr, к сожалению, недостаточно отчётливо обозначает уровни заголовков.)

База знаний НЕ как интернет

Наверх

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

Интернет даже не смотря на свой быстрый глобальный рост, в локальных своих проявлениях кажется и не меняется вовсе. Я имею в виду то, что сами по себе материалы в интернете довольно статичны – статьи не исправляют, курсы не обновляют, видео не переснимают, книги не переписывают, авторов не меняют, всякую бесполезную дичь безвозвратно не выпиливают. Иначе говоря, у материалов, которые мы находим в интернете слабо развиты итеративность и версионность (хотя у систем, на которых держится интернет как раз-таки всё это наоборот возведено почти в абсолют – забавное противоречие).

Почему же я рассуждаю про интернет, когда речь ведется про базу знаний? Да, всё просто. Часто люди превращают свою базу знаний в небольшой такой локальный интернет. Как следствие у базы знаний появляются болячки интернета, которые я озвучил выше.

Как побороть эти болячки будет далее.

Релевантная информация

Наверх

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

• В базе знаний должна содержаться крайне релевантная информация

  • Этого можно достичь только за счёт тщательно подобранных материалов (из которых добывались и структурировались знания)

    • Сами по себе источники должны быть:

      • с глубоко продуманной структурой

      • с высоким качеством информации

      • с крепкими фундаментальными основаниями

      • с обилием долгоиграющих выводов и фактов

      • с проверяемой информацией (хотя бы на уровне источников)

  • За счёт высококачественной информации и за счёт, подробной работы в прошлом с этой самой информацией, мы пытаемся добиться синергетического эффекта

    • Иначе говоря, мы пытаемся умножить качество материала, на качество нашей обработки, чтобы получить плодотворный результат, который в будущем собираемся как-то использовать

  • База знаний подразумевает работу со знанием (логично, да?). Вопрос. Собственное мнение, предположение, гипотеза являются знанием? Мой ответ – нет.

    • Об этом я ещё поговорю в другой части текста

    • Если кратко, то одно дело строить свою базу на основе работы с какими-то валидными и обоснованным источниками, пусть хоть и сквозь призму своего восприятия, а другое строить цифровую копию своего мозга

      • Последнее просто по умолчанию обрекает на невозможность выбраться из пленения собственных заблуждений. Иначе говоря, дублировать свой мозг является неплодородной идей или скорее даже антиплодородной, т.е. напрямую вредящей

Протаптывание путей

Наверх

• В первую очередь процесс нашего поиска должен завязываться на протаптывании путей

  • Это значит, что у нас должны быть какие-то базовые способы поиска информации

    • Например, у меня базовый способ поиска информации происходит через кагориальную заметку. Так я в ней последовательно просматриваю иерархии, мета-заметки, проекты и источники по выбранной теме

    • Бывают и другие механизмы. Например, можно устроить свою базу как связанную цепочку "причины, факты, источники -> преобразование -> следствия, выводы". В таком случае базовый механизм поиска будет сводиться к скольжению по этой цепочке

    • Если база знаний устроена в виде проектов, то тут базовый механизм может реализовываться через поиск по входным данным (условиям) и/или по полученным результатам

Протоптанность это не только налаженный базовый процесс поиска.

• Протоптанность также выражается в ясном понимании того как происходит добыча знаний на всех этапах

  • Метафорично выражаясь, база знаний должна быть лишена чудес

  • Когда есть понимание того какие этапы проходит знание в процессе своего рождения, можно довольно ясно представить, что реально найти, а что будет пустой тратой времени

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

      • Это можно обобщить как то, что если у нас по умолчанию мешанина из тем, плохо работает фильтрация обрабатываемых материалов и при этом нет никаких толковых формальных разделений, то мы вероятно не сможем протоптать нужные дорожки и как следствие найти то, что нам нужно

    • Если есть довольно ясное понимание этапов обработки, то можно делать довольно точные предсказания того, что может быть в базе, а чего нет без прибегания к формальному поиску

      • Я говорю "предсказания" потому что наша память неидеальна

Цели меняются, а база все равно работает

Наверх

Эту мысль я хотел бы раскрыть с двух сторон:

• Работу с базой знаний можно отложить на любой срок без какого-либо ущерба

• Стабильная база знаний лучше, чем продуктивная

Откладывание на любой срок

Наверх

База знаний должна быть устроена так, чтобы при наличии сколь угодно долгого перерыва к ней можно было вернуться абсолютно безболезненно. Это значит по сути две вещи:

1. База знаний должна быть устроена достаточно прозрачно и ясно

   • Не должно быть путаницы в том, что за что отвечает и какая кнопка что делает

   • Должно быть понимание того, что за чем следует

   • Все алгоритмы работы с информацией каким-либо образом должны быть формально закреплены

     • например, за счёт визуального оформления самих заметок

     • за счёт справочных страниц

     • за счёт метаданных, шаблонов, автоматизации, заранее оформленных структур и ссылок

2. Должны иметься хорошо наработанные привычки

   • Должны быть отработаны на автоматизме самые частые действия

     • Создание служебных (источники, MOC и пр.) и обычных заметок

     • Создание проектов (если таковой механизм есть)

     • Навигирование по заметкам

     • Иные базовые практики, которые обусловлены спецификой базы знаний и индивидуальными особенностями её пользователя

   • Утрируя, это по сути значит, что нужно довольно долго поработать с базой знаний, ничего в ней структурно не меняя, и, делая большинство вещей неизменяемым, одинаковым образом

Стабильность важнее продуктивности

Наверх

Стабильности мы будем достигать за счёт:

• Наличия тестового репозитория, на котором будут отрабатываться новые механики

• Минимизирования количества изменений в пользовательском интерфейсе и в рабочем процессе

Тестовый репозиторий

Наверх

Чем сложнее и навороченнее база знаний и при этом чем меньше понимания того как всё работает под капотом, тем выше шанс, что малейшее какое-то случайное изменение может разрушить рабочий процесс (нередок случай, что даже целиком).

Если хочется что-то внедрить новое, то стоит это обязательно делать через тестовый репозиторий. Так в нём стоит:

• Подробно прорабатывать внедряемую механику

• Смотреть как всё работает в совокупности

  • Тестировать на конфликтные ситуации

  • Проверять на дублирование с имеющимися механиками

  • Имитировать основной рабочий процесс

• Анализировать и давать общую оценку. Так, например, могут быть сделаны следующие выводы:

  • Возможно новая механика может что-то сломать, усложнить, запутать и потому её не стоит внедрять

  • Возможно наоборот механика окажется более разумной и оптимальной и тогда стоит уже начать предметно думать о её внедрении в основную базу

Делать эксперименты или сразу в лоб менять наработанные механики в основной базе знаний дело опасное – велик риск того, что будут внесены какие-то непродуктивные изменения, которые потом будет трудновато откатить назад. Тестовый репозиторий – это ограничивающее условие, которое создаст полезное сопротивление структурным изменениям.

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

Сегодня и завтра без изменений

Наверх

Изменения в механиках, в интерфейсе, в оформлении, в структуре рабочего процесса негативно влияют на наработку интуиции.

Я говорю про ту интуицию, которая отвечает за результативность самого инструмента, а не про ту, которая помогает осваивать что-то новое в нашем быстро меняющемся мире.

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

Лирическое отступление про изменения в системах.

Я клоню к тому, что

• В базе не нужно таскать кнопки, хоткеи и прочее подобное туда-сюда

• Не нужно заниматься вечным перекладыванием всего и вся

• Не нужно пилить себе триллионы возможностей в том, чтобы сделать одно и то же действие разными способами

  • Тут, я думаю, немного прояснит эту мысль аналогия с молотком. У него как у инструмента есть всего одно место за которое нужно держаться и это никак не умаляет его эффективность

  • Чем меньше лишних действий, практик, методов, тем меньше суеты, тем меньше лишних сущностей, тем быстрее и лучше развивается интуитивность

  • Это относится к самой базе знаний как структуре, но не к процессу обучения и исследования

• Не нужно плодить мириады непротестированных рабочих процессов

Кратко говоря, рабочий процесс в базе знаний сегодня и завтра должен быть в среднем одинаковым.

Не следовать за модой

Наверх

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

Одно дело, когда мы пробуем и тестируем что-то новое, чтобы почерпнуть какой-то полезный опыт. А другое, когда мы постоянно насилуем наш инструмент улучшениями, ради того, чтобы поймать неуловимую, ультимативную, доступную только верховным богам продуктивность.

Достаточное пространство

Наверх

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

• Пространство для изменений базы должно быть небольшим

• Пространство для работы в базе должно быть максимально возможным

Пространство для изменений базы

Наверх

Я хотел бы сделать аналогию с разработкой игр. Так в играх есть движок и есть "всё остальное". Движок довольно жестко запрограммирован: в нём строго регламентированы механики и различные взаимодействия объектов; прописан механизм отображения самих объектов; в нем жестко зафиксированы все процессы взаимодействия различной информации между собой. "Всё остальное" же строится на основании комбинации возможностей движка. Но не нужно преуменьшать "все остальное", ибо как раз-таки оно и создает целые миры, которыми мы восхищаемся, не говоря уже о том, что кто-то в них даже живёт свои жизни. Движок хоть и выступает формообразующим элементом, но и также выступает по отношению "всего остального" как нечто служебное. При этом сломайся движок и тут же рухнут все прекрасные миры. В общем есть довольно жесткая взаимосвязь.

С базой знаний все сущностно также – есть "движок", который состоит из набора каких-то устоявшихся практик и есть всё остальное. "Движок" обеспечивает нам возможность генерировать знания. Сломайся "движок" и генерация также исчезнет.

В общем говоря, саму базу знаний стоит менять крайне медленно и очень аккуратно, ибо от неё сильно зависит то на сколько мы стабильно и эффективно можем добывать знания.

Перейдем теперь в пространство, в котором мы добываем знания.

Пространство для работы

Наверх

К характеристикам такового пространства, пожалуй, относится нескованность в использовании иллюстраций, схем, графиков, ментальных карт, канвасов, каких-то хитроумных разметок текста, методов связывания знаний и отображении этих связей. Думаю к этому же относятся возможности в налаживании разнообразных интеграций с какими-то прочими ценными ресурсами и сервисами.

Когда инструмент намеренно ограничен какими-то жесткими рамками, то с одной стороны это, конечно, хорошо. Ничего не отвлекает – одна сплошная концентрация. К тому же и сам инструмент под нашим воздействием или воздействием разработчиков становится со временем острее, точнее, совершеннее в плане выполняемых функций. Но с другой стороны, жесткие рамки могут мешать решению каких-то задач, которые требуют комплексного подхода. Знания, наверное, очень трудно или скорее даже невозможно построить лишь только за счёт одних текстов или одних иллюстраций, или одних схем. Мне кажется, что для того, чтобы добиться какой-то продуктивности в добывании знаний, нужно использовать всевозможные методы и способы это знание запечатлеть и формализовать. Более того, желательно, чтобы все эти способы сконцентрированно реализовывались в одном пространстве – дабы не тратились силы на лишние переключения и последующее недолгоживущее интегрирование.

Из вышенаписанного можно понять, что пространство в котором мы добываем знания, должно быть максимально широким. Это в том числе значит, что можно прибегать к каким-то регулярным изменениям. Однако, стоит заметить, что только таким изменениям, которые могут быть поддержаны самой системой, т.е. нашей базой знаний.

Рассуждения на основе базы знаний

Наверх

Закончу я, пожалуй, на самом понятном маркере того, что база знаний у нас хороша. (Закончу на маркерах, а не в целом, так что крепитесь, хах.)

Если мы способны в нашей предметной области составить грамотное, последовательное рассуждение на основе материалов базы знаний, то мы явно добились весьма высокого уровня как владения базой, так и в целом в управлении знаниями.

Этот маркер является крайне важным по той причине, что он как бы намекает на рефлексивную мысль "Я веду базу знаний вероятно не для того, чтобы ею кичиться и не для того, чтобы в полной мере реализовать ошибку коллекционера. Наверное, у меня есть какие-то более благородные и продуктивные цели. Правда ведь?".

Если говорить более конкретно, то я думаю, что рассуждение в предметной области должно содержать следующее:

• Основное

  • Конкретные термины из предметной области

  • Отсылки к первоисточникам

    • Или иначе в более общем смысле – отсылки к валидным и обоснованным данным, а не к собственному стихийно полученному опыту

  • Ясный и последовательный ход мысли

    • Т.е. не должно быть каких-то слабосвязанных, близких к случайным рассуждений

    • Если знания объективные, то у них должны быть довольно точно очерчены границы применения

• Опциональное

  • Открытые вопросы и обозначенные белые пятна

  • Описание и обоснование порядка на основе которого были получены знания

    • Это может быть хронологический порядок

    • Порядок основанный на цепочках по типу

      • проблема -> решение

      • гипотеза -> проверка, эксперимент -> анализ результатов

  • Описание процесса разбора наличествующих противоречий и несостыковок

Почему не получается?

Наверх

Теперь поговорим о том почему или скорее по каким причинам может что-то не получаться в ведении базы знаний.

Слишком много о себе думаю

Наверх

У людей есть просто супер огромная проблема с переоценкой значимости своих мыслей. Причём зачастую люди не понимают, что их мысли являются чем-то эфемерным, недолгоиграющим, сильно зависящим от их культуры, воспитания и невоспроизводимого личного опыта.

Если ваша база знаний, в большинстве своём, состоит из ваших же мыслей и идей, то можете прямо сейчас её безвозвратно удалить. Пользы из неё вы не сможете вынести никакой. Может разве, что у вас с натугом получится написать книжку художественного толка, но и то она будет предельно низкого качества.

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

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

Не учусь и не меняюсь

Наверх

Так уж получается, что многие значительные вещи в жизни достигаются за счёт длительного и упорного труда, который регулярно смазывается, в том числе, интенсивным обучением и внедрением новых практик и привычек.

База знаний крайне тяжелый как в построении, так и в поддержании интеллектуальный продукт. Поэтому, если у вас что-то не получается вести или вы не чувствуете заметной отдачи, то вероятно вам просто не хватает знаний/понимания/опыта в ведении базы. Чтобы всё это компенсировать, придётся поучиться и хочешь не хочешь, но поменять в своей голове определенные убеждения, установки, алгоритмы действий, а также добавить полезные или наоборот искоренить вредные какие-то привычки.

Имею технический долг

Наверх

База знаний может плохо работать, если в ней регулярно формируется или хуже того прогрессирует технический долг. Так, например, это могут быть

• Недописанные или в целом плохо проработанные шаблоны

  • К этому также можно отнести перекручивание шаблонов по логике

  • Большое количество шаблонов тоже проблема, так как это может сделать систему более запутанной, а на нас таки вообще навесить лишнюю ответственность (ибо какой смысл делать шаблоны и их не использовать?)

• Недоделанный базовый функционал

  • Особенно хотел бы отметить ситуации, когда какой-то рабочий процесс не продуман до конца, но всё равно используется как формообразующий

• Отсутствующая или необоснованная автоматизация

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

  • Количественно необоснованная автоматизация. В базе знаний происходит так много разных автоматизированных процессов, что

    • мы порой не можем понять что из-за чего происходит

    • мы тратим очень много времени на отладку в случае проблем

    • мы порой не можем исправить проблемы, потому что просто забыли какую автоматизацию и где прикрутили

    • мы постоянно сомневаемся в каждом следующем шаге, потому что постоянно забываем, что нужно сделать, чтобы сработала нужная автоматизация

  • (Качественно) необоснованная автоматизация. Эта проблема появляется тогда, когда мы не даём себе отчёт, что какие-то определенные вещи мы должны сделать самостоятельно, вручную, ибо от этого зависит, например, наши процессы запоминания или в целом осознания и понимания

    • Этот пункт уже трудно назвать в чистом виде техническим долгом, скорее это просто неверно приложенная автоматизация

• Не внедрение практик, которые действительно будут полезными, но которые требуют каких-то заметных манипуляций с базой знаний

  • Это очень коварный технический долг, так как он может очень сильно ударить по базе знаний. Так есть риск, что мы будем копить с каждым днем ощущение неполноценности и нереализованного потенциала, который в итоге приведет, что и новую практику мы не внедрим, и базой перестанем пользоваться (ибо зачем добавлять себе ещё больше работы, которую позже все равно придется исправлять?)

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

    • В общем к трудностям нужно быть готовым – они в любом случае возникнут по мере развития и их придется решать

• Недоделанные структуры

  • Наверное, это самая частая, проблема

  • Люди не хотят прописывать заранее все структурные элементы, не хотят прорабатывать досконально рабочий процесс. Они всё держат в голове. Голова пухнет, а база знаний в это время хиреет

  • Думаю, что этот пункт как раз является чистым проявлением технического долга – ты что-то не делаешь важное, игнорируешь и довольствуешься тем, что и так сойдет, а оно потом через какое-то время стреляет тебе в спину

Не разделяю процессы

Наверх

(Теперь точно подходим к концу, хех.)

Из текста ранее можно было уловить мысль о том, что процесс добычи и использования знаний сам себе является разделенным на отдельные процессы. Это разделение довольно абстрактное. Чтобы понять как на практике вы разделяете процессы, стоит озадачить себя следующими вопросами:

• Где и как я обрабатываю источники?

• Что я делаю или собираюсь делать с полученными знаниями?

Уровень расплывчатости ответов на эти вопросы напрямую связан с тем на сколько у вас смешаны процессы и на сколько по сути у вас неэффективна база знаний. Ещё раз напомню, что база знаний – это набор практик. Практики – это конкретные действия, которые вполне себе конкретно описываются конкретными словами. Если у вас не находится подходящих слов для того, чтобы вменяемо описать что вы делаете в базе знаний, то вам явно стоит рассматривать это как маркер того, что у вас не всё в порядке именно на уровне разделения процессов. Эта проблема, к сожалению, может брать своим началом довольно много других проблем:

• Возможно вы плохо продумали структуру базы

• Возможно вы банально знаете мало практик обработки информации

• Возможно вам не хватает техничности в формальном разделении процессов

• Возможно у вас просто нет нужды в базе знаний и потому строите её постольку-поскольку

• Возможно вы внедрили так много всего, что у вас всё это не выстраивается в общую картину

Вместо итога

Наверх

Ухх... Порой я сам своей занудности удивляюсь. Поэтому пора закругляться, ибо и так уже много всего написал.

Дальше будет лирическое отступление про Linux, если вы вдруг пропустили отсылку к нему в части "Сегодня и завтра без изменений".

В целом, у меня на этом всё.

Лирическое отступление

Наверх

Вернуться обратно

На самом деле мысль о нежелательности визуальных и структурных изменений у меня в целом родилась задолго до начала ведения базы знаний. Это было связано с операционными системами. В частности, в Windows меня всегда раздражало то, что за меня решали какие панели мне использовать, какие кнопки нажимать и где, какие элементы в контекстных меню отображать и прочее. Хуже того, всё это с течением времени постоянно куда-то перемещалось, что также вызвало у меня глубокое неудовлетворение.

При переходе на Linux ситуация заметно улучшилась. Однако всё-равно во всех популярных DE регулярно меняется пользовательский интерфейс, что вроде как является признаком развития, но по факту лишь заставляет регулярно приспосабливаться к новому, но далеко необязательно нужному и полезному. Это также вызывает раздражение.

Идеальным решением для меня оказался переход на tiling-managers. На столько идеальным, что у меня в моём окружении нет ничего, чем я не пользуюсь. Меня в нем ничего не раздражает, у меня никогда не отваливается и не лагает интерфейс (по крайней мере из-за самого менеджера), в нем никогда не происходит изменений, которые были бы против моих желаний (вообще говоря, в нем вообще никаких извне навязанных изменений не происходит или по крайней мере тех, которые я бы смог неожиданно для себя обнаружить). Более того, у меня налажен чётко только тот функционал, который мне необходим в действительности. Я уж совсем молчу о том, что я понимаю как работают все автоматизации и все хоткеи и о том, что есть чувство абсолютной предсказуемости работы системы.

Кстати, также у меня стоит одно оформление для всех приложений, которое меня ни капельки не раздражает. Такое единообразие придает непрерывный, монолитный и, что ещё важнее персонализированный опыт использования всей системы. В прочих системах даже такого добиться почти невозможно.

Короче я все пытаюсь свести к тому, что, в каком-то смысле, Linux и tiling-managers выжгли на моей подкорке важную мысль: всякая система, которой я пользуюсь, должна быть подчинена именно мне, а не кому-то другому. Поэтому, когда какой-то сложный, а тем более интеллектуальный продукт, которым я очень часто пользуюсь не дает мне инструментов глубокой, персональной настройки, то меня аж корёжить начинает.