May 20th, 2007

Превед

(no subject)

Попытка очень простыми словами сформулировать (мое представление о том), что говорит Левенчук в своих постах и разговорах про онтологию администрирования, софт для issue tracking'а и т.п.

Есть какие-то люди. Они работают вместе, что-то совместно делают. При этом они каким-то образом договариваются, кто что делает, какую информацию и результаты труда кто кому передает, и как делать правильно, а как лучше не делать. Договариваются обычно спонтанно и каждый с каждым. По мере роста количества людей и сложности деятельности, такие договоренности перестают работать - начинают теряться целые куски деятельности, другие наоборот дублируются, никто не знает, как делать правильно, а как неправильно, люди теряют информацию и отдают друг другу недоделанные результаты. Получается неэффективная деятельность.
Тут приходит администратор, и говорит остальным, как они должны работать, чтобы их работа была более эффективной.
Проблема:
1. У администратора нет языка, на котором он мог бы это сказать, и остальные не только могли бы его понять, но и обсудить с ним сказанное.
2. Ему некуда это сказать - нет такого места, где все естественным образом ожидали бы услышать сказанное.

Решение:
Построить систему (программный продукт) для учета деятельности, передачи между людьми информации о деятельности и результатов их деятельности. Вот тут совсем не получились простые слова. Еще раз: построить систему, в которой люди будут хранить свои дела, передавать их и их результаты друг другу, описывать их, учитывать их и управлять ими. А дальше вместо высказываний администратора в их традиционном понимании (на естественном языке или в виде какой-то модельки, в письме или на стенке) дать администратору возможность высказываться прямо в этой системе. Точнее, сама система должна стать высказыванием администратора. Формочки для ввода и поля в них, виды дел и правила работы с ними, вся бизнес-логика - все это говорит людям нечто об их работе. Пусть это нечто и будет языком, на котором администратор говорит людям, как они будут работать, языком и инструментарием для обсуждения с людьми в организации организации их деятельности в этой организации. :)
Традиционный процесс предполагает, что администратор пишет тексты (на каком-то языке), доносит эти тексты до работающих в организации людей, люди начинают работать в соответствии с этими текстами, затем аналитик вынимает из этих текстов сущности и правила, которые программист кладет в программный продукт. Здесь процесс несколько укорачивается: администратор кладет в программный продукт сущности и правила, люди начинают работать в этом программном продукте. Все.
Для того, чтобы администратор мог высказываться о том, кто что делает, и как делать правильно, ему нужна:
1. Онтология администрирования
2. Стандартные онтологии: финансы, HR, маркетинг и продажи, логистика и т.п.
3. Онтология предметной области
Т.е., ему нужно уметь говорить как об абстрактных понятиях, таких как дело, задача, проект или поручение, так и о понятиях из финансов (здесь есть примеры хороших онтологий, например, у ребят, делающих Финград), рекрутинга или продаж, но также и о понятиях из своей предметной области. Последнее означает, что администратор должен иметь возможность сам создавать онтологию прямо в системе - т.е., создавать язык, на котором он высказывается.

Пока все. Просьба ко всем - сказать, что непонятно, к ailev и vvagr - сказать, что не так.