SavePearlHarbor

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

—

от автора

admin

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

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

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

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

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

Собственно, такая задача возникла перед командой продуктовой разработки, в которой я участвовал в роли фулстек-аналитика. Мы занимались проектом системы управления складскими запасами (англ. 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, ТКП и т. д.).


ссылка на оригинал статьи https://habr.com/ru/articles/845982/

Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *