Как построить управление корпоративными знаниями по ИТ-продукту

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

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

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

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

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

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

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

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

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

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

• среда для совместной работы (коллабораций) над документированием;

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

• инструмент синтеза новых знаний на основе ранее разработанных решений;

• информационно-методическое обеспечение процесса обучения сотрудников компании знаниям о разработанных решениях, продуктах, сервисах и т. д.

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

• площадка для фиксации и совместного использования результатов проектирования решений;

• база знаний по корпоративным паттернам (шаблонам) проектирования, моделям данных, характеристикам модулей разрабатываемых решений;

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

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

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

• информационно-методическое обеспечение процессов разработки и актуализации пользовательской документации на ПО.

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

• источник сведений для подготовки технико-коммерческих предложений, заявок для тендеров, описаний продуктов и т. п.;

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

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

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

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

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

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

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

   2. как работает продукт (взаимодействие модулей).

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

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

   2. в описании функций и алгоритмов каждого модуля есть указания на используемые модели данных.

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

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

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

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

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

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

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

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

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

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

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

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

1. Инициация

   1. Контракты

      1. Проект 1

         1. Продукт / Сборка 1

            1. Релиз 1

               1. Контракт 1

               2. Контракт / Доп. соглашение ...

            2. Релиз …

         2. Продукт / Сборка …

      2. Проект ...

   2. Тендеры

      1. Проект 1 

         1. Технико-коммерческие предложения

         2. Продукты / Сборки 

      2. Проект ...

   3. Переписка

      1. Заказчик 1

         1. Проект 1

         2. Проект …

      2. Заказчик ...

   4. Протоколы

      1. Внутренние совещания

         1. Проект / Продукт 1

            1. Спринт / Дата 1

            2. Спринт / Дата …

         2. Проект / Продукт ... 

      2. Внешние переговоры

         1. Контрагент / Проект 1

            1. Проект / Контрагент 1

               1. Дата 1

               2. Дата …

            2. Проект / Контрагент …

         2. Контрагент / Проект ...

2. Постановка

   1. Бизнес-требования

      1. Проект / Продукт 1

         1. Релиз 1

         2. Релиз …

      2. Проект / Продукт ...

   2. Бизнес-модели

      1. Проект 1

         1. Диаграммы бизнес-процессов

         2. Исходники диаграмм бизнес-процессов

      2. Проект ...

   3. Инфологические модели

      1. Проект 1

         1. Диаграммы “сущность-связь”

         2. Исходники диаграмм “сущность-связь”

      2. Проект ...

   4. Функциональные требования

      1. Продукт / Сборка 1

         1. Релиз 1

         2. Релиз …

      2. Продукт / Сборка ...

   5. Product Backlogs

      1. Продукт 1

         1. Релиз 1

            1. Sprint Backlog 1

            2. Sprint Backlog …

         2. Релиз …

      2. Продукт …

3.  Реализация

   1. Архитектура

      1. Продукт / Сборка 1

         1. Релиз 1

            1. Принципиальная схема 

            2. Модули

            3. Программные интерфейсы

         2. Релиз …

      2. Продукт / Сборка ...

   2. Модули 

      1. Модуль 1

         1. Описание модуля 1

         2. Модели данных модуля 1

         3. Продукты / Сборки, включающие модуль 1 

            1. Продукт / Сборка 1

               1. Релиз 1

                  1. Функции и алгоритмы модуля 1 в продукте 1, релиз 1

                     1. В конфигурации модулей 1

                     2. В конфигурация модулей ... 

                  2. Техническая реализация модуля 1 в продукте 1, релиз 1

                     1. В конфигурации модулей 1

                     2. В конфигурации модулей …

               2. Релиз …

            2. Продукт / Сборка …

      2. Модуль … 

   3. Продукты / Сборки 

      1. Продукт / Сборка 1

         1. Модули 

            1. Модуль 1 (ссылка на соответствующий 3.2.1)

            2. Модуль ...

         2. Сценарии использования

         3. Release Note

      2. Продукт / Сборка ...

4. Тестирование

   1. Продукт / Сборка 1

      1. Релиз 1

         1. Тест-кейсы

      2. Релиз …

   2. Продукт / Сборка … 

5. Внедрение

   1. Продукт / Сборка 1

      1. Релиз 1

         1. Пользовательская документация

         2. Учебно-методическая документация

      2. Релиз …

   2. Продукт / Сборка … 

6. Развитие

   1. Продукт / Сборка 1

      1. Запросы на изменения

   2. Продукт / Сборка … 

7. Шаблоны документов

   1. Шаблоны страниц mediawiki

   2. Шаблоны технических заданий

   3. Шаблон сценария использования

   4. Шаблон тест-кейса

   5. Шаблон Sprint Backlog

   6. Шаблон Product Backlog

   7. Шаблон Release Note

   8. Шаблоны технико-коммерческих предложений

   9. Шаблоны протоколов

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

Эффекты от использования системы управления базой знаний

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

Сокращение недостатков методологии Agile:

• введение управления требованиями;

• планирование развития продуктов;

• использование проверенных опытом решений, паттернов, накопленных в базе знаний.

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

• роста качества постановочной документации (по критериям доступности, полноты, актуальности, целостности, консистентности, пертинентности);

• роста эмерджентности проектирования решений;

• модульности структуры документации в базе знаний.

Повышение качества процессов и управления процессами тестирования решений компании за счет:

• роста скорости поиска требований к продуктам и модулям;

• стандартизации и унификации порядка тестирования, в том числе с помощью сценариев;

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

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

Снижение трудоемкости разработки и актуализации технико-коммерческих материалов (корпоративные веб-сайты, Sales Kit, ТКП и т. д.).