Управление знаниями. Основные понятия предлагаемой концепции.

(С) 2003, Кабанов Алексей (БТР)
mailto: leshenka@mailru.com

/

Цель данной статьи: дать представление о пожеланиях автора к рабочему пространству коллективных разработок программных продуктов (и, если более широко – вообще коллективных и индивидуальных разработок всевозможных продуктов, проектов, проведения исследований и т.п.)

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

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

Рабочее пространство коллективных разработок (Common Development Workspace – CDWS) представляет собой программную среду, позволяющую наиболее эффективно организовать процесс коллективных разработок, посредством непрерывного совершенствования коллективного представления различных продуктов и проектов, организованных в рамках CDWS, (в том числе и самой системы CDWS!), в произвольных формах представления объектов знаний. Например, текстовых обсуждений, диаграмм, эскизов, схем, сценариев, алгоритмов, исходных кодов, таблиц и отношений баз данных, исполняемых модулей, библиотек и т.д.

Рассмотрим более подробно, что собой представляет CDWS.

 

 

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

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

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

При накоплении достаточно большого количества информации мы сталкиваемся с необходимостью группировать обсуждения, и даже отдельные сообщения в обсуждениях, по темам или, точнее, рубрикам. Предполагается, что любое сообщение можно включить в несколько различных рубрик. Это можно сделать, просто добавив в список релевантных рубрик выбранное сообщение. Другой способ предполагает творческий подход, путем цитирования и редактирования сообщения в совокупности с другими в обзоре или дайджесте – резюмируя обсуждения и не забывая указывать, какие сообщения были учтены в резюме. Обзоры, таким образом, являются особой разновидностью рубрик. Следует особо подчеркнуть, что динамический порядок организации рубрикатора приводит к необходимости очень гибкого управления его составом. Разумеется, для этого применяется все тот же способ обсуждений. То есть, состав рубрик и их иерархия являются предметом обсуждений в обычном порядке. Как при этом не потерять контроль над ситуацией? Для этого и существует распределение участников на группы и проекты. Но это лишь часть более общего решения проблемы управления. Попробуем составить полное представление.

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

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

Итак, сначала мы вводим рейтинг каждого объекта в системе (участника, группы, проекта, сообщения, обсуждения, рубрики и т.д.) для любого другого объекта в любых парных соответствиях. Рейтинг является сложносоставным и гибким инструментом. Он состоит из двух основных элементов – уровня популярности и уровня релевантности (для тех, кому этот термин незнаком, поясню на пальцах: релевантность – это степень соответствия ответа вопросу). Каждая часть, в свою очередь, может иметь отношение ко многим категориям CDWS. Любой участник может изменять свою точку зрения к популярности и релевантности других участников, как в целом, так и в рамках групп, проектов, тем, обсуждений и даже отдельных сообщений. Такое построение рейтинговой системы позволяет организовать гибкую систему фильтров для сокращения информации в рамках обсуждений, отсекая часть сообщений при визуализации. При этом, лидеры мнений (а они могут быть как в рамках групп, так и свои для каждого участника) имеют больший вес в фильтрах и могут влиять на то, какие сообщения стоит отображать. Что же касается проектов, то в них ситуация более жесткая. Руководители проектов и ответственные участники в рамках своих задач просто обязаны непосредственно влиять на рейтинги сообщений в обсуждениях, которыми назначены управлять.

Разумеется, задача ручного назначения рейтингов слишком трудоемка. Поэтому необходимо подумать о том, как наибольшую часть рутинных вопросов уточнения огромного количества предпочтений автоматизировать. Здесь можно предложить множество идей, практически, это тема отдельного разговора. Множество идей вполне банальны, такие как повышение рейтинга сообщения, если оно высказано участником с высоким рейтингом или повышение рейтинга участника, если его сообщение было процитировано или использовано в более глубоких уровнях проекта (об уровнях поговорим чуть ниже). Уже само предложение и обсуждение идей по управлению рейтингом должно быть веткой отдельного обсуждения и целой рубрикой в CDWS. Ну, и разумеется, кроме автоматических механизмов необходимо иметь широкий спектр автоматизированных. Например, если участник хочет, он должен иметь возможность пометить какое-то сообщение, как нерелевантное (флейм) и это приведет к некоторому снижению индекса релевантности автора сообщения как по данной теме, данному обсуждению, так и в целом по отношению к рецензенту, группам, в которые он входит и даже итогового индекса, на величину, пропорциональную индексу релевантности рецензента в соответствующих группах.

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

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

Далее, руководитель проекта должен следить за тем, чтобы участники, назначенные за проектирование (конструирование) приступили к выполнению следующего этапа проекта – подготовке спецификаций. Разумеется, этот этап порождает дополнительные обсуждения в слое «анализ», но при этом, новые сообщения от участников также попадают и в слой «проектирование». Особенность управления слоями заключается в том, что они также являются объектами CDWS и сообщениям назначаются рейтинги слоев. То есть, некоторое сообщение может иметь отношение сразу к нескольким слоям, но с разным уровнем релевантности.

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

Очевидно, чтобы не пугать разработчиков нижних слоев, предложения по изменениям не могут автоматически «метить красным» все обсуждения, которые порождены от редактируемых или рецензируемых. Для этого и вводятся дискретные утверждаемые сборки между этапами, и лишь, если ответственный за сборку (спецификаций ли, программного модуля ли, инструкции пользователя – чего угодно) подтвердит, что новое мнение имеет значение, да еще ответственный за распределение ресурсов по проекту руководитель согласится, что цена изменения соответствует его важности и срочности, то в планы разработчиков будут внесены корректировки, которые должны немедленно отразиться в примечаниям к заданиям. И вот здесь рождается еще одно понятие – варианты проекта. Руководитель может и согласиться с изменением, но не изменять задач, поставленных перед участниками, а выделить новый вариант и привлечь к нему дополнительные ресурсы. Ну и, разумеется, остается типичный механизм отложенных решений: «сделаем в следующей сборке», тем самым, хоть и поощряя двойную работу, но, тем не менее, сохраняя контроль над дискретной передачей ответственности по этапам проекта.

Дальше, участники ответственную разработку, организуют наполнение слоя «разработка», позволяя постоянно контролировать прогресс в ведении этапа реализации. Необходимо сделать несколько отступлений. Во-первых, слои проекта, как механизм управления проектом являются одной из обсуждаемых рубрик. В разных проектах могут быть применены разные методики, разное количество слоев. Это позволяет системе быть адаптивной и максимально отражать реальные процессы совершенствования методик в проектных организациях. Во-вторых, нужно отметить, что под разработкой понимаются как минимум две категории задач. Если речь идет о разработке программного обеспечения, то следует отметить, что в этом случае, слой «разработка» должен заканчиваться рабочими версиями модулей или компонент этого программного обеспечения. Во-второй категории, результатом является разработка документации, которая в свою очередь необходима и разработчикам ПО. То есть, если обобщить, то результатом этапа реализации должны быть логически завершенные сборки сообщений, представляющих собой либо модули объектов, либо параграфы и пункты документов, либо схемы, чертежи и диаграммы. Важно отметить, что каждая организация разработки ПО, в общем случае, имеет как проекты разработки ПО, так и проекты совершенствования методики разработок, методики продаж, методики управления персоналом и так далее. И предлагаемая система CDWS призвана охватить все эти проектные задачи в единой рабочей среде.

Остановимся пока в процессе демонстрации слоев, для демонстрации сказано достаточно, а теперь стоит перейти к вопросам безопасности данных, уровням компетентности и полномочий пользователей в системе. Существует много приемов и способов организации администрирования и следует отметить, что большую часть необходимой базы мы уже описали в рамках модерирования. Остается просто к рейтингу добавить жесткие иерархические уровни доступа и позволить назначать и изменять права любому участнику к любому сообщению, обсуждению, рубрике, проекту и т.д. Эти права уже оказываются гораздо проще рейтингов, так как здесь мы имеем совершенно линейную шкалу числовых рейтингов компетентности и совершенно банальное сравнение РК участника с РК сообщения. С точки зрения автоматизации речь идет лишь об автоматическом наследовании РК сообщения из РК обсуждения. Можно выявить еще одну интересную возможность относительно привлечения внимание автора сообщения в случае, если его РК вызывает вопрос в том, какой РК сообщения должен быть назначен. Для этого можно ввести понятие диапазона рейтингов компетентности, который может быть назначен обсуждению, рубрике, отдельному сообщению, группе или проекту, и разным диапазонам назначить разные правила. Например, если директор хочет сделать замечание для руководителя проекта относительно какого-нибудь обсуждения с низким уровнем РК, при помещении рецензии должен быть задан вопрос: «хотите ли вы сделать сообщение доступным для всех участников обсуждения, либо хотите ограничить доступ к нему только определенным компетентным участникам?»

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

Итак, мы рассмотрели достаточно большой спектр понятий и принципов автоматизации рабочей среды коллективного творчества. Что это – методика? Инструмент? Система? Пока трудно найти адекватные названия. Давайте обсудим?

Статья получена: Клерк.Ру

загрузка...