Объектно-ориентированная охота на мамонта (записки делопроизводителя).
При написании статьи ни один мамонт не пострадал.
«Охота на мамонта» — одна из первых абстракций, созданных предками на стене в пещере.
Любуясь на шедевр, дальновидный вождь наверняка думал о там, как повысить эффективность охоты. Сам думал, потому что бизнес-аналитиков не было. Если бы были и пытались оптимизировать охоту, мы бы сейчас кормили морковкой мамонтов в зоопарке, а фраза «Россия – родина слонов» ни у кого не вызывала сомнений.
Как бы описал бизнес-аналитик охоту на мамонта, если бы мудрые предки его вовремя не съели?
Фраза из двух существительных, но описывает процесс, т.е. действие (просто, как «format c:»).
Бизнес-аналитик посмотрел бы на стену, поговорил с главным охотником, и…:
Есть входные данные (живой мамонт), есть бизнес-процедура с копьями и стрелами, есть мертвый мамонт.
Теперь поручим описать то же делопроизводителю:
1. Есть план добычи мамонта.
2. На основании плана создается документ «Заявка на охоту».
3. Вождь дает поручение.
4. Создается группы «Поиск».
5. Создается группа «Охотники».
6. Проводится мероприятие «Обработка».
7. Списание в архив.
У делопроизводителя лучше. Почему? Потому что бизнес-аналитик плохой.
Ругаем, снимаем премию, получаем:
Охота, это когда мамонта убили, потому что перед этим выследили, потому что так вождь сказал, а потом съели, а потом закопали, а в плане это было.
Лучше, но все равно плохо. Хвалим, даем премию, получаем:
На основании процесса «План» создаем связанный процесс «Мамонт».
Процесс может иметь статус
«На рассмотрении у вождя/Поиск/Охота/Использование/Утилизация».
Статус меняется бизнес-процедурами
«Послать/Найти/Убить/Съесть/Закопать».
Почему у делопроизводителя получилось сразу, а у бизнес-аналитка с трудом?
Потому что первый строит модель на основе объектов, а второй на основе процессов.
Потому что первый мыслит существительными, а второй глаголами.
Процесс – это действие, а значит это глагол (лингвисты вздрогнули), а описать модель, используя глаголы как основу, сложно. Проще и понятней использовать как основу существительные, т.е. объекты. У делопроизводителя нет функции «Искать», у него есть объект класса «Поиск», в котором скрыты методы поиска.
Сравним 2 знаменитые фразы:
«Ночь, улица, фонарь, аптека»
и
«Пришел, увидел, победил»
Первая с помощью 4 существительных достаточно убедительно переносит объективную реальность в область абстрактных моделей нашего сознания и даже добавляет эмоциональную окраску.
Если мы проектируем систему, то каркас модели готов, причем ночь описывается как отдельный объект, который влияет на состояние других объектов.
Фраза из трех глаголов с трудом, но тоже может быть описанием модели. Если поручить бизнес-аналитику описать самого себя, он создаст модель: «Пришел, увидел, описал». Увидел действия специалиста, соединил квадратики стрелочками, перевел объект из состояния А в состояние Б, и бизнес-процесс пошел. Куда пошел, зачем пошел из модели не следует. Куда надо, туда и пошел.
У нас, делопроизводителей, есть регламент (совокупность правил) и инструкция (последовательность действий). Регламент описывает жизненный цикл объектов и правила, которые этот жизненный цикл обеспечивают. Инструкция описывает, какие кнопочки в какой последовательности нажимать.
У регламента объектно-ориентированная природа в отличие от процедурно-ориентированной инструкции.
Я считаю сам принцип построения модели на основе бизнес-процессов порочным. Это все равно, что строить модель на основе инструкции пользователя, не читая регламента. Больше того, я критикую не методику, а образ мыслей (такое не прощают), когда в основе модели лежит процесс, меняющий свое состояние, а объектов либо вообще нет, либо они есть в качестве свойств процесса.
Недавно один профессионал в части построения систем с полной уверенностью заявил мне, что бухгалтерский счет не является документом.
В наш меркантильный век трудно себе представить человека, который не держал бы в руках счет. Насколько же глубоко в мозги должно засесть процессо-ориентированное мышление, чтобы основание для платежа с номером, датой, подписями не считать документом, а считать одной из отчетных форм процесса. Причем он не просто считает, он системы так проектирует и других учит. Ужас.
Пример с мамонтом – как-то сложно и не убедительно. Рассмотрим что-нибудь более понятное, например нашествие жука (bug tracking, англ. – перевел, как смог).
Можно каждый этап заявки рассматривать как смену состояния процесса. Есть процесс, который под воздействием бизнес-процедур обрастает новыми свойствами и меняет статус.
Можно каждый этап считать объектом, связанным с другими объектами либо отношением «хозяин-подчиненный» (owner-slave, англ. для солидности), либо отношением «основание-связанный» (ground-linked).
Начинается все с заявки.
Бизнес-аналитик: Заявка – это процесс.
Делопроизводитель: Заявка – это документ.
Пользователь: мне без разницы, лишь бы выполнили.
ДП: Заявка может иметь документ-основание: например входящее письмо, расписанное на исполнителя с резолюцией «Прошу извести жука и дать ответ заявителю». Это значит, что ответ заявителю будет на нее ссылаться.
Б-А: ну и что? Вот такой у нас процесс.
ДП: Процесс создан на основании документа, это нормально, а вот указать в ответе в качестве основания процесс, — как то странно.
Б-А: ничего странного: входящий – это процесс, заявка – это процесс и исходящий тоже процесс. Они друг друга порождают и друг с другом связаны.
Пользователь: входящий – это документ. Начальник так сказал. А процесс – это когда он им размахивал и кричал.
Б-А: ты не понимаешь. Входящий сканируют и присоединяют, статус процесса меняется, начальник должен наложить резолюцию…
ДП: резолюция тоже документ.
Б-А: сам-то понял, что сказал?
Заявку рассматривает руководитель проекта и расписывает на исполнителей.
ДП: резолюция достаточно сложный объект: она содержит текст, фамилии, сроки, срочность и пр. Кроме того, резолюций может быть несколько, и у каждой будет свой жизненный цикл. А документом я ее называю, потому что после сохранения она должна стать неизменяемой. Помнишь Управление записями в ISO-9001? Документ считается неизменяемым, не потому что его нельзя править (срок может быть перенесен), а потому что из него должна быть исключена любая нормализация. Он должен быть неизменяемым не на уровне пользовательского интерфейса, а на уровне базы данных, т.е. быть самодостаточным. Делопроизводство осуждает нормализацию: начальник может сменить должность, исполнитель фамилию, — в документе все должно остаться, как было. Document is normalization-free zone (англ. для убедительности).
Б-А: неизменяемость означает, что при изменении значения старое значение переводится в историю, а историю изменить нельзя.
Пользователь: неизменяемость, это когда я тыкаю, а оно не тыкается.
ДП: резолюция может отправляться по e-mail. Для документа это вполне привычно.
Б-А: у заявки есть связанная сущность «Резолюции». Отправляются ничуть не хуже.
Пользователь: У одного связанная сущность, у другого подчиненный документ. Мне-то что?
Исполнитель начинает работу по изведению жука.
Бизнес-аналитик: Работа – это процесс. Любого спроси.
Пользователь: Ты прав.
Делопроизводитель: в базу записывается не работа, а отчет о работе (начало, содержание, процент выполнения) – а это документ.
Пользователь: И ты прав. Все ваши отличия в терминах. Какая разница, каким словом назвать.
ДП: У древних мысль и слово обозначались одинаково: Логос. Помнишь документацию от Ивана: «Сначала была мысль…». Это означает, что если модель описана криво, то и система будет кривая. А у нас модели отличаются на уровне понимания (концептуальная несовместимость). Для меня «Работа (Задача)» — это документ в журнале «Работы». Она может быть связана с заявкой (журнал «Заявки»), а может со служебкой (журнал «Служебки»), а может быть инициативной и вообще ни с чем не связана.
Система управления организацией, — это совокупность взаимосвязанных журналов, образующих единое целое. Документы журнала могут копироваться в другие журнал и начинать там новую жизнь, не теряя при этом своих свойств, но приобретая в новой жизни новые свойства.
Есть биоценоз леса, есть книжный шкаф. Если срезать в лесу грибчагу и положить в шкаф, она не должна стать книгой о грибчаге.
Модель мира (неважно, большого или малого) может быть реализована только в документо-ориентированной базе данных.
Б-А: Какой-такой доко-бд-монго-дб? База должна быть реляционной и три раза нормализованной. Посмотри вокруг: большинство систем в мире создано нами.
ДП: Посмотри на эти системы. Тебя не удивляет, что после вашей оптимизации штат увеличивается, что по американской статистике безбумажные технологии увеличивают расход бумаги на 40%?
Пользователь: Мне хоть безбумажные объекты, хоть безбумажные процессы. Пока принтер не отнимут, я все равно все буду печатать.
Б-А: Слышал, что он сказал! Вот я и победил.
ДП: Победил, и успокойся.
Б-А: Нет не успокоюсь, нет не успокоюсь, нет не успокоюсь … ( Д.Хармс)
— Уважаемый! Жизнь – это движение. Ее нельзя описать декларативным языком.
— Жизнь – это взаимодействие объектов. Пока ученые не открыли микробов, лечение было неэффективным. Императивная часть модели должна быть вторичной.
— А пользователь является объектом модели?
— Конечно. Свойства задает администратор, методы прописаны в инструкции.
— Пользователя трудно отлаживать?
— Нет. Гораздо сложнее отлаживать программиста. Но главная беда – это бизнес-аналитик: он не поддается отладке.
— До свидания.
— Счастливо.
При написании статьи ни один мамонт не пострадал.
«Охота на мамонта» — одна из первых абстракций, созданных предками на стене в пещере.
Любуясь на шедевр, дальновидный вождь наверняка думал о там, как повысить эффективность охоты. Сам думал, потому что бизнес-аналитиков не было. Если бы были и пытались оптимизировать охоту, мы бы сейчас кормили морковкой мамонтов в зоопарке, а фраза «Россия – родина слонов» ни у кого не вызывала сомнений.
Как бы описал бизнес-аналитик охоту на мамонта, если бы мудрые предки его вовремя не съели?
Фраза из двух существительных, но описывает процесс, т.е. действие (просто, как «format c:»).
Бизнес-аналитик посмотрел бы на стену, поговорил с главным охотником, и…:
Есть входные данные (живой мамонт), есть бизнес-процедура с копьями и стрелами, есть мертвый мамонт.
Теперь поручим описать то же делопроизводителю:
1. Есть план добычи мамонта.
2. На основании плана создается документ «Заявка на охоту».
3. Вождь дает поручение.
4. Создается группы «Поиск».
5. Создается группа «Охотники».
6. Проводится мероприятие «Обработка».
7. Списание в архив.
У делопроизводителя лучше. Почему? Потому что бизнес-аналитик плохой.
Ругаем, снимаем премию, получаем:
Охота, это когда мамонта убили, потому что перед этим выследили, потому что так вождь сказал, а потом съели, а потом закопали, а в плане это было.
Лучше, но все равно плохо. Хвалим, даем премию, получаем:
На основании процесса «План» создаем связанный процесс «Мамонт».
Процесс может иметь статус
«На рассмотрении у вождя/Поиск/Охота/Использование/Утилизация».
Статус меняется бизнес-процедурами
«Послать/Найти/Убить/Съесть/Закопать».
Почему у делопроизводителя получилось сразу, а у бизнес-аналитка с трудом?
Потому что первый строит модель на основе объектов, а второй на основе процессов.
Потому что первый мыслит существительными, а второй глаголами.
Процесс – это действие, а значит это глагол (лингвисты вздрогнули), а описать модель, используя глаголы как основу, сложно. Проще и понятней использовать как основу существительные, т.е. объекты. У делопроизводителя нет функции «Искать», у него есть объект класса «Поиск», в котором скрыты методы поиска.
Сравним 2 знаменитые фразы:
«Ночь, улица, фонарь, аптека»
и
«Пришел, увидел, победил»
Первая с помощью 4 существительных достаточно убедительно переносит объективную реальность в область абстрактных моделей нашего сознания и даже добавляет эмоциональную окраску.
Если мы проектируем систему, то каркас модели готов, причем ночь описывается как отдельный объект, который влияет на состояние других объектов.
Фраза из трех глаголов с трудом, но тоже может быть описанием модели. Если поручить бизнес-аналитику описать самого себя, он создаст модель: «Пришел, увидел, описал». Увидел действия специалиста, соединил квадратики стрелочками, перевел объект из состояния А в состояние Б, и бизнес-процесс пошел. Куда пошел, зачем пошел из модели не следует. Куда надо, туда и пошел.
У нас, делопроизводителей, есть регламент (совокупность правил) и инструкция (последовательность действий). Регламент описывает жизненный цикл объектов и правила, которые этот жизненный цикл обеспечивают. Инструкция описывает, какие кнопочки в какой последовательности нажимать.
У регламента объектно-ориентированная природа в отличие от процедурно-ориентированной инструкции.
Я считаю сам принцип построения модели на основе бизнес-процессов порочным. Это все равно, что строить модель на основе инструкции пользователя, не читая регламента. Больше того, я критикую не методику, а образ мыслей (такое не прощают), когда в основе модели лежит процесс, меняющий свое состояние, а объектов либо вообще нет, либо они есть в качестве свойств процесса.
Недавно один профессионал в части построения систем с полной уверенностью заявил мне, что бухгалтерский счет не является документом.
В наш меркантильный век трудно себе представить человека, который не держал бы в руках счет. Насколько же глубоко в мозги должно засесть процессо-ориентированное мышление, чтобы основание для платежа с номером, датой, подписями не считать документом, а считать одной из отчетных форм процесса. Причем он не просто считает, он системы так проектирует и других учит. Ужас.
Пример с мамонтом – как-то сложно и не убедительно. Рассмотрим что-нибудь более понятное, например нашествие жука (bug tracking, англ. – перевел, как смог).
Можно каждый этап заявки рассматривать как смену состояния процесса. Есть процесс, который под воздействием бизнес-процедур обрастает новыми свойствами и меняет статус.
Можно каждый этап считать объектом, связанным с другими объектами либо отношением «хозяин-подчиненный» (owner-slave, англ. для солидности), либо отношением «основание-связанный» (ground-linked).
Начинается все с заявки.
Бизнес-аналитик: Заявка – это процесс.
Делопроизводитель: Заявка – это документ.
Пользователь: мне без разницы, лишь бы выполнили.
ДП: Заявка может иметь документ-основание: например входящее письмо, расписанное на исполнителя с резолюцией «Прошу извести жука и дать ответ заявителю». Это значит, что ответ заявителю будет на нее ссылаться.
Б-А: ну и что? Вот такой у нас процесс.
ДП: Процесс создан на основании документа, это нормально, а вот указать в ответе в качестве основания процесс, — как то странно.
Б-А: ничего странного: входящий – это процесс, заявка – это процесс и исходящий тоже процесс. Они друг друга порождают и друг с другом связаны.
Пользователь: входящий – это документ. Начальник так сказал. А процесс – это когда он им размахивал и кричал.
Б-А: ты не понимаешь. Входящий сканируют и присоединяют, статус процесса меняется, начальник должен наложить резолюцию…
ДП: резолюция тоже документ.
Б-А: сам-то понял, что сказал?
Заявку рассматривает руководитель проекта и расписывает на исполнителей.
ДП: резолюция достаточно сложный объект: она содержит текст, фамилии, сроки, срочность и пр. Кроме того, резолюций может быть несколько, и у каждой будет свой жизненный цикл. А документом я ее называю, потому что после сохранения она должна стать неизменяемой. Помнишь Управление записями в ISO-9001? Документ считается неизменяемым, не потому что его нельзя править (срок может быть перенесен), а потому что из него должна быть исключена любая нормализация. Он должен быть неизменяемым не на уровне пользовательского интерфейса, а на уровне базы данных, т.е. быть самодостаточным. Делопроизводство осуждает нормализацию: начальник может сменить должность, исполнитель фамилию, — в документе все должно остаться, как было. Document is normalization-free zone (англ. для убедительности).
Б-А: неизменяемость означает, что при изменении значения старое значение переводится в историю, а историю изменить нельзя.
Пользователь: неизменяемость, это когда я тыкаю, а оно не тыкается.
ДП: резолюция может отправляться по e-mail. Для документа это вполне привычно.
Б-А: у заявки есть связанная сущность «Резолюции». Отправляются ничуть не хуже.
Пользователь: У одного связанная сущность, у другого подчиненный документ. Мне-то что?
Исполнитель начинает работу по изведению жука.
Бизнес-аналитик: Работа – это процесс. Любого спроси.
Пользователь: Ты прав.
Делопроизводитель: в базу записывается не работа, а отчет о работе (начало, содержание, процент выполнения) – а это документ.
Пользователь: И ты прав. Все ваши отличия в терминах. Какая разница, каким словом назвать.
ДП: У древних мысль и слово обозначались одинаково: Логос. Помнишь документацию от Ивана: «Сначала была мысль…». Это означает, что если модель описана криво, то и система будет кривая. А у нас модели отличаются на уровне понимания (концептуальная несовместимость). Для меня «Работа (Задача)» — это документ в журнале «Работы». Она может быть связана с заявкой (журнал «Заявки»), а может со служебкой (журнал «Служебки»), а может быть инициативной и вообще ни с чем не связана.
Система управления организацией, — это совокупность взаимосвязанных журналов, образующих единое целое. Документы журнала могут копироваться в другие журнал и начинать там новую жизнь, не теряя при этом своих свойств, но приобретая в новой жизни новые свойства.
Есть биоценоз леса, есть книжный шкаф. Если срезать в лесу грибчагу и положить в шкаф, она не должна стать книгой о грибчаге.
Модель мира (неважно, большого или малого) может быть реализована только в документо-ориентированной базе данных.
Б-А: Какой-такой доко-бд-монго-дб? База должна быть реляционной и три раза нормализованной. Посмотри вокруг: большинство систем в мире создано нами.
ДП: Посмотри на эти системы. Тебя не удивляет, что после вашей оптимизации штат увеличивается, что по американской статистике безбумажные технологии увеличивают расход бумаги на 40%?
Пользователь: Мне хоть безбумажные объекты, хоть безбумажные процессы. Пока принтер не отнимут, я все равно все буду печатать.
Б-А: Слышал, что он сказал! Вот я и победил.
ДП: Победил, и успокойся.
Б-А: Нет не успокоюсь, нет не успокоюсь, нет не успокоюсь … ( Д.Хармс)
— Уважаемый! Жизнь – это движение. Ее нельзя описать декларативным языком.
— Жизнь – это взаимодействие объектов. Пока ученые не открыли микробов, лечение было неэффективным. Императивная часть модели должна быть вторичной.
— А пользователь является объектом модели?
— Конечно. Свойства задает администратор, методы прописаны в инструкции.
— Пользователя трудно отлаживать?
— Нет. Гораздо сложнее отлаживать программиста. Но главная беда – это бизнес-аналитик: он не поддается отладке.
— До свидания.
— Счастливо.
