Привет. Меня зовут Сергей Колесников. И последние 32 года я, по сути, занимаюсь одним и тем же: охочусь на хаос. Я видел, как он прячется в стопках бумажных накладных, как мутирует в десятках несовместимых программ, как маскируется под умными словами в регламентах. Я видел его на складах, в рекламных агентствах, на заводах медтехники и в автосервисах. Имя этому хаосу — неэффективный бизнес-процесс.
Моя личная война с ним началась не в кабинете IT-директора, а на пыльном складе в перестроечные 90-е. Я был кладовщиком в компании ООО«Восточная Сибирь», и моей главной головной болью были отчеты. Представьте себе это: горы товара, стопки бумаг, карандаш и калькулятор. На один отчет для руководителя у меня уходило несколько дней мучений.
А потом случилось чудо. В один прекрасный день терпение у директора лопнуло, и он отправил меня учиться. В соседнем здании, в отделе программирования авторемонтного завода, стоял ОН — компьютер Intel 086 с программой SuperCalc 5, прапрадедушкой современного Excel.
И вот она — магия! То, на что уходили дни, теперь делалось за пару часов. Помню, как директор смотрел на ежедневные сводки и не верил своим глазам. Это был мой первый, самый чистый и незамутненный вкус автоматизации. Потом было обучение FoxPro, которое не пригодилось мне напрямую, но я впервые заглянул «под капот» этой магии и понял, как пишутся программы.
С тех пор я сменил много отраслей. Но куда бы я ни приходил, я везде сталкивался с одной и той же картиной: люди на местах делают одно, программы в компьютерах показывают другое, а руководство где-то наверху хочет третьего. И всё это живет в том самом «зоопарке систем», где CRM не дружит с бухгалтерией, а та знать не знает про складскую программу. Знакомо, не правда ли?
Каждый раз я смотрел на этих разрозненных, не желающих разговаривать друг с другом «бегемотов» и думал: «Да должен же быть способ заставить их работать вместе! Должен же быть один, простой и понятный всем язык!»
Эта статья — история моих поисков этого языка.
Болезнь и ее симптомы: ступор на заводе и «синдром непонятного ромбика»
Вы думаете, я пришел к этому через умные книги? Если бы. Мой путь начался не в тишине лекционного зала, а под гул станков Елатомского приборного завода. Серьезное производство, медицинская техника, всё по-взрослому. И вот там, посреди всего этого, я впервые столкнулся с ними. Со схемами.
На бумаге у нас был образцовый порядок — сертификат ISO 9001, пухлые папки с регламентами. Но я нутром чуял: что-то не так. Люди на местах кивали, но в глазах у них была пустота — идеально заученная инструкция, за которой не стояло ни грамма понимания. Однажды я решил сам разобраться в одной из ключевых BPMN-схем. Распечатал этот огромный лист и просто уставился на него. Это был даже не лабиринт, который хотя бы обещает выход. Это был просто визуальный шум, гениально спроектированный, чтобы запутать.
Эта мысль осталась со мной надолго, но настоящий диагноз болезни я поставил позже. Судьба свела меня с Юрием Максимовым — крепким предпринимателем, построившим свою сеть строительных магазинов «Молоток» на собственном горбу и чутье. Перед нами стояла амбициозная задача: оптимизировать всю бизнес-структуру компании для создания собственного IT-продукта. И снова, как старый призрак, возникла необходимость описать процессы.
Казалось бы, теперь-то, с моим новым опытом, все получится. Я сел рисовать эти стройные, логичные, правильные BPMN-схемы. А Юрий смотрел. Вежливо, умнó, но с абсолютно отстраненным взглядом. В конце он тяжело вздохнул и сказал фразу, которая меня просто припечатала к стулу: «Слушай, я верю, что ты умный парень и всё это — очень умные штуки. Но я не смогу объяснить это своим ребятам. И, если честно, я и сам через пять минут забуду, что значит вон тот ромбик с крестиком».
Провал. Полный. И этот случай с обезоруживающим «я не понимаю» заставил меня копнуть глубже. Это была уже не просто догадка. Это стала какая-то одержимость. Я должен был понять, что не так с этим монстром под названием BPMN.
И оказалось, я был не одинок в своих подозрениях. Я наткнулся на работы австрийского ученого Яна Мендлинга, который научно доказал то, что я почувствовал на своей шкуре. Вы только вдумайтесь: в BPMN больше сотни (!) уникальных элементов. Сотни! Причем для одной и той же задачи часто можно использовать три-четыре разных значка. Система сама провоцирует тебя на ошибку.
Но настоящий удар под дых я получил, когда докопался до фундамента — до когнитивной психологии. До работ Нельсона Коуэна. И знаете что? Оказывается, наша рабочая память, та часть мозга, которой мы думаем «прямо сейчас», может одновременно удерживать в фокусе всего четыре, ну максимум пять, элементов.
Четыре!
А BPMN подсовывает нам сотню. Он заставляет нас жонглировать десятками связей и правил одновременно. Это биологически невозможно для нашего мозга. Это идеальный тренажер для его поломки. И вот тогда я окончательно понял: делать сложно — легко. А вот делать сложное — простым... вот в этом и есть настоящий гений, которого в BPMN попросту не оказалось.
Лекарство из космоса: открытие языка ДРАКОН
После провала у Юрия я ушел из его кабинета, одержимый одной мыслью: найти альтернативу. Я начал лихорадочно искать, перерыл, кажется, всё. Мне нужен был инструмент, который помогает, а не унижает своей сложностью.
И вот однажды я наткнулся на него. На ДРАКОН.
Когда я открыл книги Паронджанова, у меня было ощущение, будто кто-то включил свет в темной комнате. Оказалось, кто-то уже десятилетия назад задался теми же самыми вопросами, которые мучили меня. И создал не просто очередной язык, а целый инструмент для «прокачки» человеческого ума.
Его философия была простой до гениальности. Он не пытался заставить мозг работать по правилам машины. Он заставил машину работать по правилам мозга. ДРАКОН говорил не текстом, а картинками. Он не заставлял тебя запоминать — он просто показывал.
И тут я узнал его историю. У меня просто мурашки по коже пошли. Это был не просто какой-то язык. Это был клей, который сцепил воедино титанический проект — космический корабль «Буран». Вы только вдумайтесь: четыре сотни (!) разных научных институтов и конструкторских бюро. И все они смогли договориться и запустить в космос сложнейший автоматический корабль в истории. Не приказами, а с помощью общего, понятного всем языка.
И тут меня пронзило. Если этот язык смог усадить за один стол академиков и инженеров, чтобы запустить «Буран»... неужели он не сможет усадить за один стол директора магазина и его кладовщика?
Я больше не чувствовал себя провалившимся аналитиком. Я чувствовал себя человеком, который несет гениальное решение. Я пришел к Юрию снова. Он склонился над листом. Прошла минута молчания, но это была уже совсем другая тишина — сосредоточенная. А потом он поднял на меня глаза и — впервые за всё время — улыбнулся.
«Так, — сказал он. — Вот это понятно. Вот это я могу взять и завтра показать своему кладовщику. И он поймет».
И я получил то самое, выстраданное подтверждение: инструмент, созданный для космоса, идеально ложится на земные проблемы. Потому что и там, и здесь самое сложное — это заставить людей понять друг друга.
ДРАКОН в окопах: как это работало на самом деле
Но теория — это одно. А как всё это выглядело в реальной жизни? Четыре года я работал бизнес-аналитиком в компании «СТО Фильтр», и у нас была одна вещь, которая держала весь этот сложный механизм вместе. Мы в шутку называли ее «пирамидой» — гигантская, живая карта всего предприятия, полностью описанная на языке ДРАКОН.
И это была не просто картинка на стене. Это был наш главный рабочий инструмент. У кого-то из руководителей рождалась идея? Отлично. Мы открывали нашу «карту», смотрели, как процесс выглядит сейчас, а потом я садился и рядом рисовал новую ДРАКОН-схему: «А вот как это будет работать, если мы сделаем по-новому». Все всё видели. Сразу. И только после этого мы проверяли идею на практике.
Иногда это приводило к поразительным результатам. Однажды мы с начальником отдела 1С решили втайне от руководства автоматизировать один сложный процесс. Я быстро набросал логику на ДРАКОНе, и программист за месяц сделал рабочий прототип, а за два — полноценную программу. Помню шок генерального директора на презентации. Он повернулся к своей команде и спросил: «Как так вышло, что вы пилите похожую задачу уже год, а эти двое за пару месяцев выдали готовый продукт?» Ответ был прост — в ясной ДРАКОН-схеме, которая сэкономила десятки часов споров.
Но скорость — только половина дела. Вторая, и может, даже более важная часть — это ясность. Особенно ярко я это понял на одном совещании в Иркутске. Мы собрали всех руководителей СТО, обклеили стену схемами нашего основного бизнес-процесса и я задал один вопрос: «Ребята, мы так работаем?» И тут началось! Оказалось, несколько управляющих понимали спущенные им сверху регламенты совершенно по-своему. ДРАКОН, как беспристрастный судья, заставил всех говорить на одном языке. Читая текст, люди понимают его по-разному. Глядя на ДРАКОН-схему — одинаково.
Этот инструмент ломал барьеры не только между отделами, но и между «технарями» и «гуманитариями». Позже мы с начальницей отдела продаж, которая в программировании не понимала от слова «совсем», с нуля нарисовали схему будущей CRM-системы. И меня поразило, как быстро она «въехала» в логику и начала сама предлагать решения. Радость была не от того, что мы создали сложную систему вместе с человеком, далеким от алгоритмов.
Именно в этот момент я до конца понял всю мощь этого подхода. ДРАКОН стал нашим универсальным языком. Он заменил и громоздкий BPMN для бизнес-аналитиков, и сложный UML для программистов. Он просто убил «испорченный телефон» как явление.
ДРАКОН против всех: битва на бумаге
Хорошо, историй было много, но давайте на минуту отложим эмоции. Почему я так «вцепился» в ДРАКОН, когда в мире существуют общепризнанные гиганты — BPMN и UML? Чтобы не быть голословным, я хочу просто поставить их рядом. Я свел их ключевые различия в одну таблицу.
Посмотрите, тут не нужно быть экспертом, чтобы увидеть, в чем пропасть между ними.
Критерий |
ДРАКОН |
BPMN |
UML |
|---|---|---|---|
Основная цель |
Универсальный язык для описания любой деятельности с приоритетом на наглядность. |
Стандарт для моделирования бизнес-процессов. |
Язык для проектирования объектно-ориентированных систем. |
Целевая аудитория |
Все: от менеджера до программиста. "Человечий" язык. |
В первую очередь – бизнес-аналитики. |
Прежде всего – программисты и архитекторы ПО. |
Сложность |
Минимальная. Мало элементов, строгие правила. |
Высокая. Более 100 элементов, провоцирует ошибки. |
Высокая. Множество диаграмм, требует спецподготовки. |
Читаемость |
Высокая. Создан для легкого восприятия мозгом. |
Низкая. Легко создать запутанную и перегруженную схему. |
Низкая для не-программистов. Слишком абстрактный. |
Универсальность |
Высокая. Один язык для бизнес-процесса, ТЗ и алгоритма. |
Низкая. Только для бизнес-процессов. |
Средняя. Только для IT-систем. |
"Сквозное описание" |
Да. Один язык от идеи до кода. Минимизирует "испорченный телефон". |
Нет. Нужен перевод в UML или ТЗ для программистов. |
Нет. Нужен перевод в BPMN для бизнеса. |
Проблема ведь не в том, что BPMN или UML плохие. Нет. Проблема в том, что они, как и десятки других инструментов, построили в бизнесе настоящую Вавилонскую башню.
У аналитиков свой язык. У программистов — свой. У менеджеров — третий.
И на каждом этаже этой башни, при каждой передаче смысла, он искажается, теряется, умирает.
И вот тут я понял главный фокус ДРАКОНа. Он не был просто «еще одним языком». Он был универсальным переводчиком. Тем самым инструментом, который мог говорить со всеми. Он был сквозным. От идеи в голове директора до строчки кода.
Битва за будущее, которую я проиграл
И вот тут-то и начинается самое интересное. Вооружившись всем этим пониманием, я попытался совершить революцию в одной, отдельно взятой компании. У меня в голове уже была цельная картина будущего. Я представлял себе, как искусственный интеллект сканирует весь бизнес и сам строит ДРАКОН-схемы «как есть». А дальше — один клик, и эта схема разворачивается в живую модель предприятия на единой платформе, вроде той самой «АСис» Олега Захарчука. Это была мечта. Мечта об убийстве «зоопарка систем» и «Вавилонской башни языков» одним ударом.
И тогда я пошел ва-банк. Я познакомился с тем самым Олегом Захарчуком и получил от него шикарное предложение на внедрение его платформы у нас, в «СТО Фильтр».
Это была моя главная битва. Мы собирали совещания, я доказывал, показывал... Но генеральный директор был убежден, что ему нужен Битрикс24. В самые ответственные моменты он просто покидал совещания, перекладывая решение на топ-менеджеров, которые, конечно же, не хотели брать на себя ответственность. Стена.
В итоге из всей этой битвы я вынес для себя две незыблемые истины.
Истина первая: Единственно верный путь передачи знаний в компании выглядит так: бизнес процесс → понятная всем ДРАКОН-схема → эта же схема как четкое ТЗ для программистов → реализация в коде. Всё. Точка. Любой другой путь — это «испорченный телефон» и потеря денег.
Истина вторая: Системы, построенные на единой метамодели, как «АСис», опережают свое время. Они позволяют управлять не набором программ, а целой экосистемой как единым организмом, не плодя бесконечный «зоопарк».
Я пытался объединить эти два подхода. И проиграл. В компанию пришел новый IT-архитектор, который, не вникнув, с порога отверг и ДРАКОН, и «АСис». Генеральный директор меня не поддержал. Мне пришлось уйти.
Прошло уже пять лет. А компания... компания до сих пор с большим энтузиазмом строит свой собственный, очень дорогой и очень «инновационный» зоопарк.
Проигранное сражение, но не война: новое оружие
Я ушел из той компании, проиграв сражение. Но не войну. И вот, совсем недавно, когда я уже второй год вожусь с тренировкой нейросетей, меня как током ударило. Я понял, каким будет следующий ход в этой войне. Я понял, каким будет наше новое, главное оружие.
Представьте себе...
Искусственный интеллект, как неутомимый стажер, сканирует весь бизнес: документы, переписку, регламенты. И на выходе выдает чистую, понятную ДРАКОН-схему «как есть».
А дальше... дальше начинается магия. Директор, который в жизни не написал ни строчки кода, садится и, как в компьютерной игре, начинает двигать блоки, создавая схему «как надо». Он может просто сказать: «А что, если мы вот здесь добавим проверку склада?» — и ИИ тут же перестраивает схему, показывает узкие места, просчитывает стоимость, ресурсы, риски. И вот она, рождается — «схема-решение». Утвержденная, просчитанная, готовая к внедрению.
И я понял, что это и есть та самая недостающая деталь в моих прошлых битвах. Главной задачей становится не научить программиста понимать бизнес, а дать самому бизнесу штурвал в руки.
Говорят, наш мир становится слишком сложным для человеческого мозга. Мой опыт кричит об обратном. Проблема не в нашем мозге. Проблема в наших убогих инструментах.
Будущее не за тем, чтобы заменить человека машиной. А за тем, чтобы дать ему такие инструменты, которые превратят его ограниченный, но гениальный мозг в суперкомпьютер. И эта битва, я уверен, будет выиграна.
Вместо заключения, или Несколько вопросов, которые у вас наверняка остались
Наверное, после всей этой истории у вас в голове роится куча вопросов. Я попробую угадать самые главные.
Что за зверь этот ДРАКОН, и почему он лучше обычных квадратиков и ромбиков?
Если коротко, то в нем, в отличие от «свободного творчества», есть строгие, почти военные правила. Они не дают сбиться с пути, исключают двусмысленность и заставляют тебя видеть всю логику целиком.Откуда такое официальное название — ДРАКОН? Не слишком ли грозно?
На самом деле, это аббревиатура, и расшифровывается она очень мирно: Дружелюбный Русский Алгоритмический Язык, Который Обеспечивает Наглядность. Ключевое слово здесь — «дружелюбный». Но у меня есть и своя, личная расшифровка. Если копнуть в древнерусскую буквицу, где у каждого символа был свой глубокий образ, то ДРАКОН — это не злой Змей Горыныч, а последовательность смыслов: Добро, Речь (как энергия), Азъ (я, как творец), Како (объединение), Он (некая божественная структура) и Наше (то, что нам дано предками). Получается, это язык, который помогает человеку-творцу через добрую речь объединять и структурировать наше общее знание. По-моему, это гораздо глубже отражает его суть.А где деньги? Сколько всё это экономит?
Отвечу без лукавства: по моему опыту, от 40% до 60% времени на разработку и отладку. В «СТО Фильтр», например, мы ужали создание техзаданий с месяца до одной недели.Работает ли это в маленьких компаниях?
Еще как работает. Даже в команде из десяти человек это окупается за пару-тройку месяцев, потому что самые дорогие ошибки — это ошибки в понимании. ДРАКОН их убивает.
И вот, подытоживая… Я за свои 32 года в этом деле понял одну простую вещь: лучшие решения всегда рождаются в диалоге. Эта статья — мое приглашение к нему.
Мне до сих пор чертовски интересны проекты, связанные с описанием по-настоящему сложных, запутанных бизнес-процессов. Или с интеграцией того самого «зоопарка систем». Или, что сейчас увлекает меня больше всего, — с внедрением ИИ в существующие процессы.
Если у вас в голове крутятся похожие задачи, если вы тоже чувствуете, что «так дальше жить нельзя», или если у вас просто есть вопросы — напишите мне.
Давайте поговорим.
Сергей Колесников
Тот самый бизнес-аналитик, который все еще верит, что можно починить всё.
Почта: sergrodna@yandex.by
Дополнительная информация на Хабре по языку Дракон:
https://habr.com/ru/articles/541478/
https://habr.com/ru/articles/345320/
Комментарии (22)
avshkol
24.08.2025 06:43В статье не хватает примера: описания процесса на bpmn, uml и драконе с разбором того, чем первые два хуже, а третий лучше.
SergiiKol Автор
24.08.2025 06:43Здравствуйте! Спасибо, что ткнули пальцем в больное место, это очень по делу. Мысль про наглядное сравнение — просто отличная, и, если честно, я сам об этом думал.
Когда я писал эту свою «исповедь», я намеренно не стал делать из неё технический справочник. Мне хотелось не столько доказать что-то «на бумаге», сколько поделиться своей личной войной с этим хаосом, своей одержимостью. Показать, как я сам, на своей шкуре, почувствовал разницу между мёртвой схемой и живым инструментом.
Поэтому и рассказ получился больше про людей, про совещания, про этот вечный «испорченный телефон», а не про ромбики и стрелочки. Я не ставил себе задачи сделать полноценный сравнительный анализ.
Но вы абсолютно правы: без примера, где можно было бы просто положить рядом три картинки и сказать: «Смотрите, вот тут — визуальный шум, а вот тут — понятно даже кладовщику», — мои слова остаются просто словами.
Так что спасибо вам за этот пинок. Прямо сейчас обещать не буду, но мысль очень правильная, и она у меня в голове теперь точно засядет. Возможно, это будет тема для отдельного, более «зубастого» разговора.
VladimirFarshatov
24.08.2025 06:43И UML и Дракон это всё одно и то же развитие Р-технологий Глушкова, ещё есть названия "Графит-Флокс", поинтересуйтесь с каких оно времен.. :)
SergiiKol Автор
24.08.2025 06:43Здравствуйте, Владимир! Вот за это — отдельное человеческое спасибо!
Вы абсолютно правы. Я в статье скорее махал флагом и делился своей болью, а вы взяли и подвели под это дело серьёзную базу. Честно говоря, я до таких глубин, как «Графит-Флокс», в своих раскопках не добирался, и это очень круто, что вы об этом напомнили.
Получается, что все мы, кто сегодня пытается бороться с хаосом с помощью картинок, на самом деле просто продолжаем дело тех гениев из 60-х. А ДРАКОН, по сути, — это их идеи, которые кто-то наконец-то догадался объяснить нормальным, человеческим языком. Чтобы не только академики понимали, а любой из нас мог взять и нарисовать.
В общем, вы очень круто дополнили мой рассказ. Одно дело — моя личная «война», и совсем другое — когда ты понимаешь, что у этой войны есть такая мощная предыстория. Спасибо, что поделились
VladimirFarshatov
24.08.2025 06:43Не переживайте, Вы не одиноки. Глушкова в свое время, ЦК КПСС тоже послал далеко и без хлеба, когда он предложил автоматизировать ГосПлан СССР. Не всем выгодна автоматизация.
К примеру, мои жалкие попытки на ИПП Советская Сибирь в Нск, в 90-е. Оказывается, учет бумаги на компе - это волюнтаризм и вредительство, ибо в каждом цеху(!) у каждого начальника смены(!) есть своя "неучтенка", которая лежит всё в том же цеху и на которой они периодически левачили, а периодически пускали в производство, когда отдел снабжения лопухался .. этакий "переменный лично-общественный запасец".. не всем оно выгодно на заводах.
SergiiKol Автор
24.08.2025 06:43Здравствуйте! Спасибо вам огромное за этот комментарий. Вы попали в самую точку и рассказали историю, которая до боли знакома. Ваш пример про «неучтёнку» на «Советской Сибири» — это идеальная иллюстрация того, о чём я пытался сказать.
Вы абсолютно правы. Моя битва в «СТО Фильтр» — это лишь бледная тень тех сражений, которые пришлось бы вести на любом советском предприятии. И я на 100% уверен, что я бы проиграл, даже не начав. Просто потому, что там и задачи такой не стояло — сделать всё прозрачным.
Ваша история про «переменный лично-общественный запасец» — это гениально. Это и есть тот самый «чёрный ящик», который и пытаются уничтожить любые системы учёта и автоматизации. И именно за право на существование этого «чёрного ящика» борются те, кому невыгодна прозрачность.
И вы совершенно справедливо вспомнили Глушкова. Его трагедия с ОГАС — это та же самая история, но в масштабах всей страны. Он предложил сделать всю экономику СССР прозрачной, как стекло, а в ответ получил отказ от тех, кто терял власть и контроль в этой новой системе. Министр финансов Гарбузов, похоронивший проект, по сути, защищал право каждого цеха на свою «неучтёнку».
Так что да, вы правы. Я не одинок в своём поражении. И дело тут не в ДРАКОНе, не в BPMN и не в «АСис». А в том, что любая попытка навести порядок всегда натыкается на яростное сопротивление тех, кто научился ловить рыбу в мутной воде.
Спасибо вам ещё раз за этот очень глубокий и точный комментарий. Вы помогли посмотреть на мою локальную проблему в совершенно ином, историческом масштабе.
alexhu
24.08.2025 06:43У реализации дракона есть несколько мелких недостатков - нет приемлемой ide, нет отладки по коду (только в своей голове) - а код может быть ну очень большой и много переходов, И это дополнительная работа которую многие считают лишней, поскольку отнимает время и не даёт генерировать код, а те ide что выдают код не позволяют производить отладку. IDE дракон крайне сырые.
А так конечно удобно, постоянно пользуюсь Dragon, для понимания чего я там напридумал и уже забыл.
Rsa97
24.08.2025 06:43Первые блок-схемы были представлены ещё в 1921 году Френком и Лилиан Гилбрет в работе "Process Charts: First Steps in Finding the One Best Way to do Work" и активно применялись в XX веке. Дракон всего лишь вводит некоторые дополнительные правила и ограничения на составление блок-схем, являясь, таким образом, не самостоятельным языком, а всего лишь стайлгайдом.
SergiiKol Автор
24.08.2025 06:43Здравствуйте! Спасибо, что копнули так глубоко в историю. Про Гилбретов — это очень к месту, вы правы, они вообще-то всё это и затеяли, пытаясь найти тот самый «единственно верный способ» сделать работу.
Но вот в чем, по-моему, главная штука. То, что делали Гилбреты — это был, по сути, репортаж с поля боя. Они смотрели, как люди работают, и пытались зарисовать это, чтобы найти узкие места. Это была карта местности. Очень полезная, но всё-таки просто карта. На ней можно было рисовать что угодно и как угодно, лишь бы было понятно самому.
А ДРАКОН — это не карта. Это устав.
Разница тут вот в чём. Когда у тебя на руках просто карта, два разных бойца могут проложить по ней два совершенно разных маршрута. И каждый будет по-своему прав. В бизнесе это выглядит так: два аналитика рисуют схему одного и того же процесса, и получаются две разные картинки. Вроде об одном и том же, но выглядят по-разному. И тут начинается хаос.
ДРАКОН же говорит: «Маршрут может быть только один. Шаг влево, шаг вправо — запрещено. Никаких перекрёстков, никаких "а я вот так линию проведу"». Он вводит почти армейские правила не для того, чтобы замучить, а для того, чтобы убрать саму возможность понять что-то не так. Чтобы у директора, кладовщика и программиста в голове была одна и та же картинка, пиксель в пиксель.
Поэтому для меня ДРАКОН — это не просто «стиль для блок-схем». Это попытка превратить туманную карту в чёткий, однозначный приказ. Чтобы он был понятен всем и не допускал толкований.
Спасибо вам, что дали повод об этом поговорить! Это помогает лучше сформулировать, за что мы тут на самом деле воюем.:)
Rsa97
24.08.2025 06:43ДРАКОН же говорит: «Маршрут может быть только один.
Так это и есть стайлгайд. Когда вы пишете, например, программу, то оформить один и тот же код можно по разному. Отступы пробелами или табуляцией, открывающие скобки на той же строке или на следующей, строка в 80 символов, 132 или вообще без ограничений, переменные в стиле snake_case или camelCase и многое другое.
Вот для того, чтобы все, занимающиеся проектом, оформляли всё одинаково и всем было проще читать этот код и принимают единый стиль оформления внутри проекта. Так же и дракон, который сам не является языком (попробуйте написать что-то на чистом драконе, не используя какой-либо язык, как программирования, так и естественный), всего лишь задаёт единые правила для оформления блок-схем. То есть, он является стайлгайдом для блок-схем.
В остальном, хотя правила оформления на драконе и достаточно жёсткие и схема с этими правилами читается лучше, чем без них, но он всё равно не является панацеей. Его недостатки - общие недостатки для всех блок-схем. Это и необходимость специального редактора и нечитаемого без него формата хранения, и существенно больший размер листа, чем при текстовой записи алгоритма, и практически невозможное наглядное отслеживание изменений между версиями.SergiiKol Автор
24.08.2025 06:43Здравствуйте! Спасибо, что продолжаете диалог, это очень ценно. Вы привели отличную аналогию со стайлгайдами в программировании (snake_case, отступы и т.д.), и она как раз помогает идеально вскрыть разницу.
Вы абсолютно правы: стайлгайд наводит порядок в форме, но не меняет суть. Код, написанный с табами или пробелами, остаётся функционально тем же самым кодом. Он просто выглядит по-разному.
А теперь давайте посмотрим на ДРАКОН. Его правила влияют не на «красоту» или «стиль», а на саму логическую структуру алгоритма.
Требование рисовать схему строго сверху вниз по одной оси («шампур») — это не вопрос стиля. Это запрет на произвольное управление временем, который заставляет выстраивать все события в единую, однозначную последовательность.
Правило «силуэт» (когда схема должна вписываться в определённый контур) — это не про эстетику. Это когнитивный хак, который заставляет дробить сложную задачу на простые, легко усваиваемые куски, потому что мозг не может удержать в фокусе слишком много информации сразу.
Запрет на перекрещивающиеся линии — это не перфекционизм. Это принудительная борьба со спагетти-логикой, которая заставляет аналитика находить более чистое и простое решение.
То есть, ДРАКОН — это не просто набор правил «как рисовать». Это набор правил, заставляющий думать определённым образом. Он меняет не то, как схема выглядит, а то, как мы приходим к самому решению, которое в ней заложено. Он вмешивается в суть, а не в форму.
А что касается недостатков, которые вы перечислили (редактор, размер, отслеживание версий) — тут я с вами на 100% согласен. Это огромная боль и главный тормоз. И это как раз доказывает, что ДРАКОН — не просто «картинка». Если бы это был просто стайлгайд, его можно было бы реализовать простым плагином-линтером к любому редактору. Но поскольку он меняет саму суть алгоритма, он требует своего, особого инструментария, которого, увы, пока нет в должном виде.
Спасибо вам ещё раз за этот глубокий диалог. Он помогает отточить формулировки и лучше понять друг друга.
Rsa97
24.08.2025 06:43Сильно сомневаюсь, что дракон заставляет думать как-то по особому. По крайней мере, на вашем же примере со схемой на драконе есть не самый хороший перескок из ветки в ветку, что, ЕМНИП, правилами дракона запрещается.
Ну а по поводу линтера - да, дракон можно реализовать как линтер к любому редактору блок-схем. По крайней мере, я никаких препятствий к этому не нахожу.SergiiKol Автор
24.08.2025 06:43Спасибо за ваш отличный комментарий, вы абсолютно правы.
Возможно с моей стороны это кусок схемы я выложил как легкую провокацию.
Вы этот момент заметили и оказались совершенно правы!С точки зрения канонических, "академических" правил языка ДРАКОН — да, это нарушение.
Правила гласят, что каждая ветка, выходящая из иконы "Выбор" (в вашем случае это "кто встретил клиента" (149)), должна быть полностью изолированной. Слияние боковых веток друг с другом не допускается. Каждая ветка должна либо вернуться на основной "шампур", либо завершиться.
Однако, и это самое важное, цель ДРАКОНа — не слепое следование правилам, а достижение максимальной ясности и читаемости.
В вашем конкретном случае это "нарушение" сделано очень аккуратно и, на мой взгляд, оправдано здравым смыслом:
Нет "спагетти": Линии не пересекаются, схема не превращается в запутанный клубок.
Сохраняется логика: Поток по-прежнему идет сверху вниз, и понятно, что после встречи клиента (механиком или ст. мастером) следует один и тот же следующий шаг — проверка, новый ли это клиент.
Устраняется дублирование: Мы избежали необходимости рисовать один и тот же блок дважды, что сделало бы схему более громоздкой.
Вывод: схема — это хороший пример инженерного компромисса. Я осознанно пошёл на небольшое формальное отступление от правил ради повышения компактности и, возможно, даже читаемости схемы. Для внутренней работы команды это абсолютно приемлемый и понятный вариант.
В общем я вам благодарен за вашу внимательность, сейчас я бы решил это немного по другому и не нарушал правил.
abcdsash
24.08.2025 06:43автор не сказал ничего на ДРАКОНьем, но налил целое озеро воды с притягиваем за уши исторических фактов.
SergiiKol Автор
24.08.2025 06:43Здравствуйте! Спасибо за прямой и честный отзыв.
Вы правы, я не стал делать из статьи технический учебник. Но одну реальную схему из своей практики в «СТО Фильтр» я всё-таки показал. Она там не для обучения, а как «вещдок», подтверждающий мою историю.
Эта статья — исповедь аналитика, а не мануал по ДРАКОНу. Я писал её для тех, кто, как и я, устал от хаоса и «испорченного телефона», чтобы они узнали в этой истории себя. Поэтому в ней так много личных переживаний.
Возможно, для технического специалиста, который ждал подробного разбора, в ней действительно много «воды». Но для менеджеров и аналитиков важна не сама схема, а результат, который она дает: ясность и взаимопонимание.
Тем не менее, ваш комментарий очень по делу. Видимо, теперь пора готовить материал с «мясным» разбором нотаций. Спасибо, что подтолкнули к этому.
abcdsash
24.08.2025 06:43Нет! речь не об учебнике или мануале... но условный "Hello, world!" показать можно было бы... ну, например, процесс перехода улицы на светофоре... легко же нарисовать BPMN вариант и в этом самом "драконе" и сравнить... нет?
И это не было бы ни мануалом, ни учебником. Тут аудитория в целом не глупая сидит и уловила бы что и как. И ясность и понимание было бы продемонстрировано ) А так, без конкретик статья выглядит просто как поток рекламы.
SergiiKol Автор
24.08.2025 06:43И снова спасибо за продолжение диалога. Вы абсолютно правы, и ваш пример про «переход улицы» — идеальный. Он бы действительно не превратил статью в мануал, а стал бы той самой наглядной «вишенкой на торте», которая бы моментально показала разницу подходов.
Я согласен с вами на 100%. Показать рядом две схемы — запутанную BPMN и чистую, как слеза, ДРАКОН-схему для одной и той же простой задачи — было бы лучшим аргументом, сильнее всех моих рассказов про «Буран» и «зоопарки систем».
И, если честно, ваш комментарий заставил меня пожалеть, что я так не сделал. Моя логика была в том, чтобы сначала поделиться «болью», а потом уже переходить к «лекарству». Но вы справедливо заметили, что аудитория здесь достаточно опытная, чтобы оценить практический пример, и он бы не помешал, а только усилил бы повествование.
Считайте, что вы меня убедили. Это было моё упущение.
Спасибо вам огромное за эту дискуссию. Она получилась очень полезной и показала, где статью можно было сделать лучше. Для меня это очень ценно.
VladimirFarshatov
24.08.2025 06:43Спасибо за статью, полностью согласен с тем, что ИДЕ ДРАКОН - сырые и малопригодные для серъезной работы, особенно в сравнении с проприетарщиной, хотя бы PHP-strom от JetBrain, да и vscode туда же. Обучал в свое время сына программированию, делал переходник ДРАКОН-Ардуино, зашло вполне. Ребенку было 11-12лет.
Tyuli
24.08.2025 06:43Автор, Вы не учли матчасть для любого бизнес-аналитика, в частности:
1) принцип ITIL "Отталкивайтесь от текущей ситуации" (Start where you are), то есть начиная работать в новой компании нужно понять подготовку, уровень и зрелость команды, понять планы в том числе по автоматизации, масштаб, какую внедрять нотацию если с нуля или стоит ли менять имеющуюся нотацию если она уже внедрена (что надо обосновать);
2) до начала моделирования разработать соглашение о моделировании. Тут может быть "облегченный BPMN" или вообще что-то ранее не существующее.Приходить с Драконом (или чем бы то ни было) в компанию и менять все на Дракон, потому что где-то он сработал, прямо скажем, очень оригинальное решение. У Дракона должны быть очень хорошие задокументированные (не на Хабре) показатели, идеально, внедрение в аналогичном бизнесе, на похожих процессах.
SergiiKol Автор
24.08.2025 06:43Здравствуйте! Спасибо, что так въедливо комментируете, это очень помогает. Вы всё правильно пишете, если рассуждать по книжкам и методичкам. Но моя история была немного про другое.
Я не врывался в «СТО Фильтр» с криками «Всем строиться, теперь живём по ДРАКОНу!». Всё было гораздо прозаичнее. Нас с партнёром (довольно известным 1С-ником) позвали чинить их старую, самописную программу. И именно он предложил ДРАКОН как способ распутать этот клубок.
А дальше случилась магия. Пока основная команда программистов год билась над одной сложной задачей, я просто из интереса сел с одним «левым» 1С-ником, который согласился работать по моим схемам.
И мы вдвоём, втихаря, за два месяца сделали то, что команда из пяти человек не смогла осилить за год.
Вот в этот момент директору стало всё равно, как называется наша нотация — ITIL, BPMN или хоть «палки-кружочки». Он просто увидел, что два партизана сделали для бизнеса больше, чем целая регулярная армия.
Мне до сих пор неизвестно, по каким «правильным» методичкам работала та команда. Но после нашего успеха все мои ДРАКОН-схемы стали для них законом. Потому что они работали. И по ним очень быстро делались реальные вещи.
Так что это была не история про «внедрение». Это была история про маленькую, но очень наглую партизанскую вылазку, которая оказалась успешнее большого наступления. И уже после этой победы мой подход стал для компании главным.
blik13
Буран начали разрабатывать в 76 году, а ДРАКОН начали разрабатывать(не использовать) в 86 году. Буран слетал в 88 году. Вот есть сомнения что этот язык что то там ключевое сотворил.
SergiiKol Автор
Здравствуйте! Спасибо, что так внимательно вчитались в статью и задали вопрос по существу — это очень приятно и ценно. Вы подметили важный момент, давайте разберёмся в нём вместе.
Вы абсолютно правы в датах: работы над самим кораблём «Буран» начались в 1970-х, задолго до того, как язык ДРАКОН был формализован в 1986 году. Конечно, ДРАКОН не использовали для проектирования корпуса или двигателей. Его звёздный час настал на самом последнем и критически важном этапе.
Нервная система для «Бурана»
Представьте себе, что «Буран» — это невероятно сложный организм. Его «скелет» и «мышцы» (то есть планер, механика) действительно создавали много лет. Но для того, чтобы этот организм мог жить и действовать самостоятельно, ему нужна была «нервная система» — сложнейшее программное обеспечение. Именно оно должно было управлять всеми системами в полностью автоматическом режиме во время уникального полёта и посадки без пилота.
Вот для этой задачи — создания «мозга» корабля — и потребовался новый подход. Стандартные языки программирования того времени не подходили. Была нужна технология, которая позволила бы сотням программистов из разных институтов писать код абсолютно одинаково, без малейшего шанса на ошибку или разное толкование.
Доказательства и источники
Прямая связь с проектом: Разработка языка ДРАКОН велась в рамках космической программы «Буран» с 1986 года. Это подтверждают многочисленные источники, включая документальные фильмы Роскосмоса и публикации участников проекта.
Эволюция языков: ДРАКОН не появился на пустом месте. Он стал развитием и объединением специализированных языков, которые создавались именно для «Бурана», таких как ПРОЛ2 (для бортовых систем) и ДИПОЛЬ (для наземных испытаний). Его цель была — дать универсальный и наглядный инструмент, понятный и инженерам, и программистам.
Логика и цель создания: Сама философия ДРАКОНа — строгость, наглядность и защита от ошибок — идеально отвечала требованиям проекта. В космосе цена ошибки абсолютна. ДРАКОН был создан как инструмент для написания сверхнадёжного кода, где человеческий фактор сведен к минимуму.
Дальнейшее применение: Успех этого подхода был настолько очевиден, что после «Бурана» технологию на основе ДРАКОНа стали использовать в других важнейших космических проектах: «Морской старт», «Протон-М», «Фрегат» и других.
Возможно, моя метафора в статье про «клей, который сцепил весь проект» была слишком яркой и могла создать не совсем верное впечатление. Спасибо вам, что вы это подметили. Речь шла именно о его ключевой, решающей роли в создании программной логики — той самой «нервной системы», которая и позволила «Бурану» совершить свой легендарный автоматический полёт.
Ещё раз большое спасибо за ваш вдумчивый комментарий! Мне очень ценно, когда читатели помогают сделать картину точнее и полнее.