Продолжаем рассматривать вопросы создания Базы Знаний в разработке ПО.      Можно ли функционировать команде разработки без Базы Знаний (БЗ)? На самом деле да, можно. Особенно если ПО (продукт, система, сервис) совсем маленькое или находится на начальном этапе разработки. Всегда можно заглянуть в исходный код и быстро разобраться в его работе.      С ростом сложности ПО и ростом численности команды, затраты времени на разбор вопросов будут прогрессивно расти. Это не означает, что будет невозможно разобраться. Всегда можно найти ответы, только на некоторые потребуется очень много времени. Данная ситуация будет усугубляться другими факторами. Например, если увольняется сотрудник, часть недокументированных знаний он «уносит» в своей голове. Для оставшихся потребуется время, чтобы разобраться в коде и набраться подобного опыта. При найме нового сотрудника уйдет больше времени на адаптацию. Другой пример это несогласованность в работе, один сотрудник может решать проблему, которую ранее уже решали до него. Он зря тратит свое время, когда можно взять имеющееся решение. Или одновременно два сотрудника работают над разными частями системы, которые потом будет трудно соединить/синхронизировать, потому что не было зафиксировано единого подхода по архитектуре и стандартам.      В результате все вопросы будут успешно разрешены, но это потребует дополнительных временных затрат. (Или не будут разрешены и организация перестанет существовать, как неэффективная на рынке разработки ПО…) Считаю, что удалось дать объяснение какую цель преследует ведение документации и создания БЗ - в конечном счете все сводится к уменьшению временных затрат. Переходим к вопросу границы БЗ - где тот предел описания, который теоретически возможен.

С одной стороны критерий границы БЗ определяется легко. Если информация относится к нашему ПО, то записываем и сохраним. Если вообще не имеет никакого отношения, тогда этой информации нет места в нашей БЗ. С другой стороны, следует любую информацию (даже полезную) пропускать через определенные фильтры. Например, у маркетологов есть информация о дистрибьюции нашего ПО до потребителей. Или другой пример, к БЗ можно отнести комментарии в исходном коде, или комментарии в таблицах и их колонках в БД. Очевидно, что пример 1 относится к Бизнес составляющей и в разработке ничем не поможет. А пример 2 показывает, что эту информации уместнее хранить рядом с исходным кодом, и не следует дублировать в нашей БЗ.Также следует обращать внимание не только на создание новых артефактов в БЗ. Нужно иногда проверять старую информацию на актуальность. Если старое описание процесса не соответствует действительности, или какая-то конфигурация уже не подходит, тогда ее следует удалить из БЗ. Или, как минимум, добавить особую пометку об устаревании или невостребованности.