Взгляд на работу с требованиями с точки зрения дисциплины управления знаниями (knowledge managemant, KM) оказался очень любопытным, и объясняющим некоторые вещи. Я-то, так вышло, работал с методами KM, и даже был когда-то членом экспертного совета премии Most Admired Knowledge Enterprise Russia, так что с темой знаком. А вот для аналитиков и архитекторов, на удивление, эта тема малоизвестна. Хотя разговор про архитектуру систем всегда затрагивает вопросы управления знаниями, это у меня один из главный инсайтов с курса про микросервисную архитектуру. Закон Конвея и разделение по командам тоже про управление знаниями — какие знания аккумулировать в команде, а какие выдавать наружу.

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

Например, такая вещь, как модель SECI (или модель Nonaka-Takeuchi) объясняет, что для разных стадий работы со знаниями нужные разные методы. Модель вводит различение между неявными знаниями (tacit knowledge, существует только в головах или в навыках людей и часто даже не осознается) и явными, эксплицитными (explicit knowledge, существует в виде отчужденного артефакта: документа, описания, регламента, записей). Если бы все знания были эксплицитными, и задачи разработки требований бы не было, точнее, она была бы сугубо технической.

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

Потому что документация — это эксплицитное знание, и переход требует значительных усилий — экстернализации. Это то, чем часто занимается аналитик — экстернализирует неявные знания.

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

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

(Картинка из статьи Germán Scalzo и Guillermo Fariñas, лицензия CC BY 4.0)