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

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

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

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

В чем польза системы управления базой знаний

Собственно, такая задача возникла перед командой продуктовой разработки, в которой я участвовал в роли фулстек-аналитика. Мы занимались проектом системы управления складскими запасами (англ. Warehouse Management System, WMS) с помощью радиочастотных технологий идентификации (англ. Radio Frequency IDentification, RFID). Решение строилось на расширенной трехзвенной модульной архитектуре с микросервисами и межсистемной интеграцией. Не раскрывая деталей, отмечу, что система объединила в числе прочего более 40 модулей, мобильное приложение, настольный клиент и веб-клиент, а также множество драйверов для подключения различных классов RFID-считывателей. Среди наших заказчиков были крупнейшие нефтегазодобывающие и сервисные компании страны с бюджетами порядка сотен миллионов рублей.

Стоит ли добавлять, что управление таким масштабным проектом, и особенно документирование жизненного цикла разработки, с учетом дефицита кадровых ресурсов само по себе стало серьезным вызовом? В этих целях я предложил разработать и развернуть систему управления базой знаний (СУБЗ) на opensource-движке MediaWiki — да, что-то вроде «корпоративной Википедии» для разработчиков. Хотя выбор платформы здесь не принципиален, подойдет любой инструмент для совместного создания, хранения, трассировки и версионирования проектных артефактов.

Мои аргументы — суть подхода и та польза, что приносит такая СУБЗ. В чем же они заключаются?

Для компании в целом это:

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

Для групп разработки продуктов и технического директората это:

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

Для группы выпуска/тестирования это:

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

Для коммерческой службы это:

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

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

Что дала развернутая СУБЗ нашему проекту

Прежде всего, она помогла понять:

Конечные зависимости модулей — связи «родитель — потомок»: 

• как сделать сборку из модулей без противоречий и избыточности;
• как работает продукт (взаимодействие модулей).

Откуда берутся данные: 

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

За что отвечает каждый модуль: 

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

Для каких бизнес-задач используется продукт (сборка) и как именно: 

• набор сценариев использования (use-cases).

Как должна вести себя система при тех или иных входных потоках: 

• набор сценариев тестирования (test-cases).

Текущий статус разработки по модулям и продуктам.

В чем специфика каждой сборки для конкретных проектов (заказчиков).

По каким протоколам и в каких форматах компоненты системы обмениваются данными.

Каковы аппаратные и программные требования к продуктам.

Как выглядит примерная структура двумерной базы знаний

Основной особенностью предложенного мной подхода к созданию СУБЗ стала структура ее контента — иерархия каталогов сопутствующей документации (артефактов). Для жизненного цикла разработки она была представлена в двух измерениях: стадии разработки и таксономии проектных документов, включая модульный принцип проектирования и разработки.