Comments 7
Вы рисуете правильную схему, выстраивание по ней взаимодействие, все работает как единый организм, а потом принимают закон, отсекающий четверть вашего бизнеса, но дающий новые возможности - и вы встраиваете костыль.
Потом ещё один. И ещё. И пару заплаток.
От первоначальной стройной схемы остаются обрубки, ведущие в никуда.
А в это самое время кто-то, у кого просто автоматизирована работа отдельных участков, что-то выбросил и что-то добавил, и у него все работает.
Классический выбор "монолит против микросервисов"
Здравствуйте! Спасибо вам огромное за этот комментарий. Вы попали в самую суть вечного спора и главную боль любого архитектора: стройность против гибкости. И ваша аналогия с «монолитом против микросервисов» — идеальна.
Вы абсолютно правы. Если понимать мою идею «единого организма» как создание жёсткого, монолитного монстра, то вы на 100% правы: первый же серьёзный внешний удар (новый закон, уход поставщика, смена технологии) заставит нас городить «костыли», и вся красивая схема рассыплется. Это путь в никуда.
Но дьявол, как всегда, в деталях. Когда я говорю о «едином организме», я имею в виду не монолит, а скорее экосистему.
Представьте себе не единый механизм, а муравейник. У него есть общая, понятная всем цель и единые правила взаимодействия (феромоны — наш аналог ДРАКОН-схем). Но при этом каждый муравей (или группа муравьёв) — это автономный «микросервис». Он выполняет свою чёткую функцию: одни строят, другие ищут еду, третьи защищают.
Что происходит, когда меняется внешняя среда? Например, старый источник еды исчез, но появился новый.
В «монолите» нам пришлось бы остановить и перестроить весь муравейник.
В «экосистеме» же группа «добытчиков» просто переключается на новую задачу. Они получают новую, простую и понятную «ДРАКОН-схему»: «Теперь ходим за едой не налево, а направо». Остальной муравейник продолжает работать как ни в чём не бывало. Связи между ними не рвутся, потому что они изначально гибкие и построены на общих правилах.
Моя идея не в том, чтобы зацементировать бизнес в одной идеальной схеме. А в том, чтобы описать на едином, понятном всем языке взаимодействие между отдельными, гибкими частями. И когда приходит время перемен, мы не ломаем всю систему, а просто достаём схему конкретного «микросервиса» (например, «Процесс работы с поставщиком N»), быстро её перерисовываем и запускаем в работу.
Ваш комментарий невероятно ценен, потому что он заставил меня лучше сформулировать свою мысль. Проблема не в «единой схеме», а в том, как мы её понимаем: как жёсткий чертёж или как гибкую карту взаимодействия автономных частей. Спасибо вам
А сколько времени потребуется на внедрение ?
Например...
Я собрал проект на коленке тестовый(1 html страничка) тема сложная и не известная мне. Делел с помошью ии.
Пока собирал понял как часть работает.
ИИ уже больше на данный момент не может увеличивать объем странички. Она огромная.
Я делаю рефакторинг и разбиваю на компоненты. Приэтом появляются баги (рефакторинг с ии ужасная идея, лучше делать сразу правильно, но в начале не знаешь что такое правильно)
Но эти компоненты сами становятся огромными и я делаю структуру для не обработаной части первого html. Получается уже два набора компонентов. Одни в одном файле, вторые уже структурированные.
ИИ добавляет еще больше багов.
В итоге, страничку я первую собрал за 1 день, рефакторинг ее 2 недели.
Сейчас я следующий проект, есть еще одна страничка, я буду делать уже с учетом опыта, который получил. Думаю сокращу время до 1 недели.
К чему я это.
То что я описал, происходит на любых уровнях, не только в разработке. Этот кейс появляется, когда в начале результат который хочешь получить имеет очень большую неопределенность. Это какие то исследования, что то новое.
Какие инструменты есть в вашей системе, которые позволяют даже при высокой неопределенности, не уходить в рефакторинг, а позволять последовательно проводить анализ паралельно с синтезом полученных результатов ?
Здравствуйте! Спасибо вам огромное за такой глубокий и, самое главное, до боли знакомый каждому разработчику и аналитику комментарий. Ваша история про "коленочный проект" и последующий двухнедельный рефакторинг — это идеальная, просто хрестоматийная иллюстрация той самой проблемы, о которой я пытался рассказать в статье.
Вы абсолютно правы: эта беда — "сначала делаем, потом переделываем" — универсальна. Она возникает везде, где есть высокая неопределённость. Вы совершенно точно сформулировали главный вопрос: какие инструменты позволяют проводить анализ параллельно с синтезом, чтобы не увязнуть в бесконечном рефакторинге?
В связке, которую я предлагаю, за это отвечают все три компонента, но каждый на своём уровне.
1. ДРАКОН: "Прививка от рефакторинга" на уровне логики
Ваша проблема с ИИ, который "уже больше не может увеличивать объём странички", — это классический пример того, как сложность выходит из-под контроля. Вы интуитивно начали делать то, что ДРАКОН заставляет делать принудительно.
Принудительная декомпозиция: Правило "силуэт" в ДРАКОНе не дало бы вам создать одну огромную схему. Оно бы физически заставило вас сразу, на самом первом этапе, разбить большую задачу на маленькие, понятные куски (ваши "компоненты"). Вы бы не смогли нарисовать схему, которая не помещается на один экран.
Чёткие связи вместо "спагетти": ДРАКОН заставляет сразу продумывать, как эти "компоненты" будут общаться друг с другом. Вы бы не смогли просто накидать код, а потом думать, как его структурировать. Вы бы сначала нарисовали "скелет" взаимодействия, и только потом начали бы "наращивать мясо" на каждую кость.
То есть, ДРАКОН — это инструмент, который заставляет вас делать "правильно" с самого начала, даже когда вы ещё "не знаете, что такое правильно". Он не даёт неопределённости превратиться в хаос.
2. АСис: "Фундамент, который не надо перестраивать"
Представьте, что вы строите дом из LEGO.
Если у вас обычный набор, то каждая деталь уникальна. Вы построили стену, а потом решили сделать её шире — вам придётся всё разобрать и искать новые, подходящие детали. Это и есть ваш двухнедельный рефакторинг.
А теперь представьте, что у вас есть «волшебный» набор LEGO от АСис. В нём все кирпичики стандартные, 2х4. И все они умеют соединяться друг с другом без всяких хитрых переходников.
Вам не надо думать о деталях. Вы просто берёте готовые кирпичики и строите. Не нужно каждый раз изобретать новую деталь для новой задачи. Это и есть единая модель данных.
Всё подходит ко всему. Вы можете отломить кусок стены в одном месте и прилепить его в другом, и он идеально подойдёт. Связи между кирпичиками (компонентами) уже заложены в самой их природе.
То есть, АСис даёт вам такой набор «стройматериалов», с которым не нужно каждый раз всё перестраивать с нуля. Вы можете спокойно менять «комнаты» и достраивать «этажи», не боясь, что весь ваш «дом» развалится. Вы просто работаете с готовыми блоками, а не воюете с их несовместимостью.
3. ИИ: "Штурман, который видит рифы"
А Искусственный Интеллект в этой связке выступает в роли умного штурмана, который работает с уже структурированными данными.
Анализ "на лету": Получая данные из АСис в реальном времени, ИИ может сразу подсвечивать вам проблемы: "Смотри, вот этот компонент стал слишком сложным, его пора делить" или "Вот здесь у тебя намечается "узкое место", которое через неделю затормозит всю систему".
Помощь в синтезе: Он может не просто критиковать, а предлагать решения, основанные на анализе тысяч похожих ситуаций: "Судя по твоей ДРАКОН-схеме, вот этот новый компонент лучше всего построить вот по такому шаблону, который мы уже использовали в другом проекте".
Итог
Ваш вопрос — самый главный в современном управлении и разработке. И ответ, который предлагает моя система, таков:
ДРАКОН не даёт хаосу зародиться на уровне идеи.
АСис не даёт хаосу просочиться на уровень архитектуры.
ИИ помогает бороться с хаосом на уровне исполнения и эволюции.
Эта связка позволяет вам двигаться итерационно, постоянно анализируя и синтезируя, но при этом не проваливаясь в "долговую яму" рефакторинга. Вы строите систему из стандартных, предсказуемых блоков, и каждый новый блок делает систему не сложнее, а богаче.
Знаете, я тут перечитал наш с вами диалог и понял, что в своём первом ответе увлёкся объяснением "как", но совершенно упустил ваш самый главный и самый практический вопрос: "А сколько времени потребуется на внедрение?".
Это моё упущение, и вопрос настолько важный, что заслуживает отдельного, прямого ответа.
Ключевая идея здесь — вы не останавливаете завод на год, чтобы всё перестроить. Вы начинаете с самого больного места и получаете результат здесь и сейчас. Это эволюция, а не революция.
1. ДРАКОН: от пары дней до нескольких месяцев
Здесь всё зависит от масштаба задачи.
Простой процесс с одним человеком: Описать его можно буквально за 1-2 дня.
Сложный процесс отдела: Если нужно опросить несколько человек и учесть много деталей, это займёт 1-2 недели.
Сквозной процесс всей компании: Описание "основного бизнес-процесса" — это уже серьёзная работа на 2-3 месяца, а то и больше.
И здесь важно понимать, как идёт сама работа. По моему опыту, эффективная сессия с одним человеком или группой над схемой — это 60-90 минут. Потом у всех начинается "плавление мозгов", и продуктивность падает до нуля. Нужен перерыв. Пытаться выжать больше за один присест — контрпродуктивно.
2. АСис: начинать можно почти с колёс
Внедрение этой системы — не классический долгий проект.
Старт "в режиме творчества": Вам не нужно заранее строить шаблоны процессов. Можно зарегистрировать пользователей в облаке и начать работать в тот же день: ставить задачи, планировать результаты, общаться в мессенджере.
Параллельное создание процессов: Уже внутри работающей системы вы можете создать проект "Построение типовых процессов" и постепенно, без остановки основной деятельности, описывать и автоматизировать свои схемы.
То есть, формальное "внедрение" как таковое отсутствует. Вы начинаете пользоваться системой сразу, а порядок наводите постепенно.
3. ИИ: эффект гораздо быстрее, чем принято думать
Современные ИИ-модели не требуют полугодовой "раскачки" на идеально чистых данных.
Первые подсказки — почти сразу: Как только в системе появляются первые структурированные задачи и данные (из ДРАКОНа и АСис), ИИ уже может начать находить простые зависимости и подсвечивать аномалии. Это вопрос нескольких недель, а не месяцев.
Значимый эффект — 1-3 месяца: Чтобы ИИ начал давать действительно ценные советы по оптимизации и прогнозированию, ему нужно накопить определённый объём данных. Но речь идёт скорее о 1-3 месяцах активной работы системы, а не о полугоде.
А есть какие нибудь примеры посмотреть как это выглядит ?
Вы про холократию писали. Есть ли что то похожее на это ?
https://github.com/holacracyone/Holacracy-Constitution-5.0-RUSSIAN
Здравствуйте! Спасибо за очень точный и глубокий вопрос. Вы уловили самую суть: и ДРАКОН-схемы, и Конституция Холакратии — это попытки формализовать «правила игры» и сделать их понятными для всех.
Проще один раз увидеть, чем сто раз услышать. Вот пример схемы, которую я буквально за 15 минут набросал для процесса «Обработка заказа из интернет-магазина».
Давайте посмотрим, что эта схема нам даёт, и почему это так похоже на Конституцию Холакратии.
Это — Закон процесса. Как и в Конституции, здесь нет места для интерпретаций. Каждый шаг и каждое решение чётко прописаны. Менеджер не может «забыть» проверить наличие (блок 9) или не записать инцидент в CRM (блок 19). Он просто следует по «рельсам».
Это — общий язык для всех. Эту схему одинаково поймёт и менеджер по продажам, и кладовщик, и директор. Она устраняет «испорченный телефон» между отделами. Когда вы говорите «обработать заказ», все участники видят перед глазами одну и ту же картинку.
Это — инструмент для поиска проблем. В отличие от сплошного текста Конституции, визуальная схема мгновенно подсвечивает «узкие места». Сразу видно, где процесс может «провиснуть» (например, в блоке 10, где мы ждём ответа поставщика) или где мы рискуем потерять клиента (блок 17).
Это — основа для Холакратии. Вы абсолютно правы. Холакратия не может существовать в хаосе. Ей нужен фундамент из чётких правил. ДРАКОН-схемы и есть этот фундамент. Они описывают «как» мы работаем, а холакратические круги уже решают «что» и «зачем» делать, опираясь на эти понятные всем алгоритмы.
Так что да, вы попали в самую точку. ДРАКОН-схема — это и есть визуальная, работающая Конституция для каждого отдельного бизнес-процесса в вашей компании.
Почему ваш бизнес хромает: история одного IT-ортопеда