156
1
0
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники
Назад

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

Время чтения 1 минута
Нет времени читать?
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники
156
1
0
Нет времени читать?
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники

Привет, вАЙТИ! Меня зовут Дмитрий Кочергов, я кандидат экономических наук и бизнес-аналитик. Сегодня хочу поделиться своим опытом организации и построения корпоративной базы знаний для продуктовой ИТ-разработки. В конце статьи подведу итоги внедрения такой системы.

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

Начнем с фундамента

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Комментарии0
Тоже интересно
Комментировать
Поделиться
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники