И (или)

Ещё один способ очистить текст — писать только «или» вместо «и/или» или «и (или)». Союз «и» добавляют, потому что пытаются показать, что правило работает и в случае, когда срабатывают все условия одновременно, и в случае, когда срабатывает только одно.

Но в этом случае союз «и» — излишнее уточнение. Если допускается «или», значит это автоматически нестрогая дизъюнкция. То есть тогда предполагается, что могут применяться как все условия одновременно, так и только некоторые и даже одно из них. Без дополнительного «и» мысль не теряется.

При запущенной паранойе можно писать, например: «нарушение возникает, если произошло хотя бы одно из следующих событий». Но чаще всего даже из контекста предложения понятно, что могут применяться и одно, и все условия.

Если нужна строгая дизъюнкция, так и пишите «либо… либо…». В остальных случаях — только «или».

#НастоящийЛигалДизайн

(далее — 2024)

Навигационный пост

О Симплоере и этом канале

Это канал компании Симплоер (подробнее о компании). Здесь рассказываем про настоящий лигал-дизайн, лигал-тех и юридическую эффективность.

У нас есть чат, где можно поднять темы для обсуждения или просто пофлудить на тему нашего канала — Simplawyer Talks. Там время от времени разгораются огненные обсуждения, присоединяйтесь.

🔎 Хэштеги для поиска по каналу

#НастоящийЛигалДизайн — приёмы, типичные ошибки в дизайне документов, советы по разработке документов и внедрению лигал-дизайна.

#SimplawyerLegalOps — всё о лигал-опс и лучших практиках по эффективности, советы и готовые решения по улучшению процессов.

#SimplawyerTrends — мысли о том, в каком направлении развиваются юрдепартаменты и юридическая профессия в целом, а также интересные исследования и статистика.

📖 Книга Симплоера

В 2023 издали целую книгу о лигал-дизайне и юридической эффективности — почитать о книге и заказать.

📑 Бесплатные материалы, которые помогут улучшить работу с документами

Памятка по вёрстке, орфографии и типографике для документов — распечатать и повесить над рабочим столом

Мини-статья о хранении файлов — как организовать файлы, чтобы всей команде их было удобно и быстро искать

🧠 Управление знаниями

Статья об управлении знаниями — о том, как создать базу знаний для юридической команды и сделать так, чтобы сотрудники реально пользовались базой знаний, а юристы её регулярно обновляли

Запись вебинара об управлении знаниями — о методологии управления знаниями, разработке структуры базы знаний и изменении культуры команды

🤖 Искусственный интеллект для юрдепартамента

Пост и запись выступления об AI — для тех, кто хочет научиться правильно применять новый классный инструмент и разбираться в теме чуть глубже, чем «AI заменит юристов!!1!»

📃 SimpleNDA — унифицированное соглашение о конфиденциальности для всего рынка (бесплатное)

Узнать больше о SimpleNDA и скачать документ — на сайте проекта

Разбор кейса SimpleNDA

🎥 Длинное, но полезное видео о лигал-опс

Запись митапа о лигал-опс — для тех, кто только начал погружение в юридическую эффективность. Поможет понять, в каком направлении лучше двигаться.

💬 Задать вопрос и заказать лигал-дизайн

Чтобы задать вопросы напрямую или заказать лигал-дизайн, пишите на smart@simplawyer.com

Юзкейсы для AI

Доступный для всех AI — одна из самых горячих тем прошлого года. Надеемся, что в этом году к разговорам ещё прибавится активное внедрение.

Для внедрения нужны понятные юзкейсы. Сегодня о том, с чего можно начать использование AI:

📌 документы — первый драфт внутреннего документа, первый подход к структуре;
📌 переписывать на человеческий язык уже написанные материалы — консультации, FAQ, инструкции, отдельные формулировки в договорах;
📌 быстро узнавать, какое регулирование в сложных договорах, — задавать AI вопросы в формате: какой порядок оплаты, какой будет штраф, если мы просрочим оплату, где найти положения о случаях дефолта и т. д. AI неплохо делает семантический анализ и в разы быстрее человека анализирует длинные документы;
📌 делать списки обязательств компании по договору — обязательство, срок исполнения, ответственность;
📌 переводить на другой язык договоры;
📌 брейнштормить идеи контраргументов в переговорах, рисков и т. п.

Список юзкейсов, который у вас получится, точно не конечный. В будущем сами пользователи точнее поймут, как работает AI, и найдут ещё больше юзкейсов. Ещё AI быстро «учится» и сейчас разработчики почти каждый месяц выкатывают новые фичи.

3 вещи, о которых нужно помнить:

📍 и у AI, и у человека есть ограничения и сильные стороны. Например, AI иногда галлюцинирует (т. е. правдоподобно пишет всякий бред), но при этом он неплохо умеет простым языком писать сложные вещи без потери смысла (в отличие от многих юристов). Человек лучше AI оценивает контекст ситуации, но он не такой внимательный, как AI, — обязательно пропустит пару запятых и опечаток, когда будет сам вычитывать документ;
📍 AI не заменяет целый процесс, а решает только одну из небольших задач, составляющих этот процесс. Например, AI пока что хуже человека справится с разработкой адекватного финального договора, но он сильно поможет, когда нужно сделать первый драфт или переписать конкретную формулировку;
📍 не во всех случаях можно ожидать от AI полноценных решений. Часто AI даёт не готовый результат, а вдохновение на результат.

Если вы уже используете AI, пишите в комментах, для каких задач применяете его, какие успехи (и провалы).

#SimplawyerLegalOps

Разделяйте операционку и изменения

Одни и те же люди не могут хорошо делать и стандартную работу (в бизнес-терминологии Run), и заниматься изменениями этой работы (Change).

Причины простые:

📌 у операционки и инноваций совершенно разные задачи и разная мотивация. Линейный юрист, например, в первую очередь думает о том, как согласовать договор в срок. Подразделение инноваций думает о том, как сделать так, чтобы договоры не согласовывались в принципе;
📌 для инноваций нужен другой набор навыков и способность мыслить по-другому;
📌 проекты по изменениям всегда ресурсоёмкие — чтобы что-то сдвинуть с места, не хватит часа в день по остаточному принципу.

Поэтому в хороших командах эти функции чётко разделяются.

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

#SimplawyerLegalOps

Исключение

Когда формулируете исключение из общего правила, не нужно писать в одном предложении длинное «за исключением случаев предоставления…». Не нужно также писать исключение в скобках (и тем самым понижать вес фразы) или хуже того — в сносках.

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

Чтобы выделить исключение в общем тексте, мы всегда сначала формулируем общее правило. Затем в соседнем предложении описываем исключение. Предложение так и начинаем — со слова «исключение»:

Контрагент может приостановить выполнение работ, если выявит некачественные Исходные данные.  Исключение — работы нельзя приостановить, если эти Исходные данные собирал Контрагент

#НастоящийЛигалДизайн

Главная фича любого софта

У Association of Corporate Counsel вышел очередной отчёт о покупке и внедрении софта в юрдепартаментах. Самая интересная часть отчёта — внедрение. Есть два важных результата, на которые точно нужно обратить внимание:

📌 большинство юрдепартаментов при выборе софта в первую очередь смотрят на список фич, а во вторую — на цену. При этом качество интерфейса вообще не вошло в топ. То есть либо на интерфейс вообще не обращают внимание, либо это делают единицы (статистическая погрешность);

📌 одна из основных проблем при внедрении — у софта плохой интерфейс. Им сложно пользоваться, долго изучать, люди постоянно ошибаются.

Авторы отчёта не анализируют связь между этими двумя результатами. Но мы думаем, что она прямая — большая часть проблем при внедрении возникает из-за плохого интерфейса.

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

Мы лично слышали истории, когда пользователи осознанно не заходили в софт по полгода, потому что он страшно выглядит и непонятно как работает.

Качество интерфейса — это критично. Хороший интерфейс понятен пользователям без долгого обучения и многостраничных инструкций. (Любой софт требует обучения — вопрос в том, как быстро и легко можно научиться.)

Разумеется, функционал тоже критически важен. Но не стоит слишком сильно очаровываться только им. Об этом уже писали:

– как понять, какие фичи точно нужны
– о приоритизации фич

#SimplawyerLegalOps

Как писать нормальные консультации

Юристы пишут консультации как попало. На это есть 2 причины. Первая — не знают, как лучше писать: какую структуру использовать, насколько подробно отвечать на вопрос, как перевести с юридического на человеческий и т. д. Вторая — трусость. Чаще всего и то, и другое одновременно.

Бизнес приходит на консультацию не ради юридического ликбеза. От юристов ожидают конкретную инструкцию. Поэтому ответ на вопрос «можем ли мы…?» не должен начинаться со слов «в соответствии с…». Хороший ответ начинается со слов «да» или «нет». Всё остальное — логику регулирования, подробное обоснование, пересказ судебных решений — писать, только если пользователь точно не решит свою задачу без дополнительного контекста. В большинстве случаев эти подробности никого не интересуют.

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

Каждую консультацию нужно оценивать по трём критериям:

📌 полезность — информацию сразу можно использовать для решения задачи (например, скопировать ответ и отправить контрагенту) или планировать действия;
📌 ясность — всё однозначно понятно с первого раза;
📌 краткость — суть донесена лаконично и без лишних деталей (если на это не было специального запроса).

Консультация качественная, если все три критерия соблюдены.

Хорошо написанные отдельные консультации — это точно не предел. Продвинутые юрдепартаменты не только учат юристов хорошо писать, но и в целом стандартизируют структуру ответов и язык и формализуют эти правила. О стандартизации консультаций недавно писали.

#SimplawyerLegalOps

Юридического языка не существует

Одно из самых популярных сопротивлений — тезис «документы нужно писать юридическим языком». В связи с этим ещё раз заявляем. Юридического языка не существует.

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

Есть понятие «юридическая терминология», но это конкретные термины, которые приняты на рынке или в законодательстве. Например, «цессия», «независимая гарантия». К юридической терминологии нужно относиться строго и сохранять её во всех документах.

Есть ещё понятие «деловой стиль». Но это относится к строгости языка — однозначность, стилистически нейтральная лексика и слова без эмоциональной окраски. Деловой стиль — это именно тот стиль, который ожидается от хорошего документа.

В остальном язык юридического документа ничем не ограничен. Главное — написать так, чтобы с документом было удобно работать, а пользователи однозначно и быстро понимали, что от них хотят.

В общем, юридической терминологии и строгому деловому стилю — да. Клише и канцеляриту — нет.

#НастоящийЛигалДизайн

Не как, а что

Часто видим на рынке такой подход к оптимизации: спросить у пользователей, как они видят решение проблемы, положить это в основу ТЗ — и пилить эти хотелки в точнейшем соответствии. В реальности такой подход редко способен дать лучшее решение.

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

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

Эту тему давно поняли в касдеве и продуктовом дизайне. Там у пользователей спрашивают не про конкретные решения (нравится ли вам решение или как бы вы поступили), а про пользовательский опыт — как люди решают свою задачу, почему именно так, какая у них конечная цель, какие возникают трудности и т. д.

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

И, кстати, эффективность такого решения эти команды оценивают не по критериям «нравится/не нравится пользователям» или «привычно/непривычно», а исходя из того, решена ли эта проблема.

#SimplawyerLegalOps

Как прийти к параллельному согласованию

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

Уже давно все перешли на сэды, ERP и т. п., но сам процесс по-прежнему выстроен так, что один согласующий приступает к проверке только после того, как документ закончит смотреть другой.

Последовательное согласование:

❌ долгое — очередь согласования чаще всего ничем не оправдана, но пока одно подразделение ждёт другое, подписание необоснованно затягивается. В итоге иногда начинают работать без договора;

❌ дорогое — больше ресурсов (чаще всего юристов) уходит на сбор всех комментариев и правок из ворда, имейлов и сэда в финальный файл. (И, конечно, упущенная выгода от поздно подписанного договора.)

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

Двигаться к параллельному согласованию нужно и на уровне документов, и на уровне процессов:

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

📌 пересмотреть весь договорный процесс;

📌 постепенно мигрировать весь процесс согласования на одну платформу — где можно и вносить правки в режиме совместного редактирования, и обсуждать, и ставить согласования.

#SimplawyerLegalOps

Когда нужно делать приложения

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

Объясняют это обычно так:

– к этим условиям при исполнении договора обращаются чаще (или наоборот реже);
– эти условия обязательно должны прочитать — в отдельном документе на них точно обратят внимание (или наоборот, раз никто не читает, то и нечего это писать в договоре);
– собственные менеджеры как всегда что-то не найдут, забудут и т. д.

Это плохой подход. Во-первых, это делает структуру документа непоследовательной — непонятно, почему одна часть регулирования заслужила место в договоре, а другая нет. Во-вторых, это ещё одно усложнение для читателя.

У Симплоера есть чёткие правила, как определять, нужно ли выносить информацию в отдельный документ. В приложения выносим:

📌 таблицы, списки, перечисления (например, прайс-лист, список товаров, список предметов залога и т. п.) — т. е. информация, которая подаётся в ином формате, чем остальной договор, занимает много места, не является самостоятельным регулированием в чистом виде;
📌 в редких случаях — формы документов. Об подходе к формам в приложениях писали.

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

#НастоящийЛигалДизайн

Не существует магических формулировок

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

Не существует никаких магических формулировок. А аргументы «это где-то сработало» — попытка рационализировать инертность. Ни одна сложная формулировка не является инструментом управления рисками. На деле это неумение, нежелание или страх чётко и однозначно выразить и отстоять реальную позицию компании.

Если вы в вашей компании столкнулись с людьми, которые верят в магические формулировки (или хуже того, вы сами верите в них), то рекомендуем подумать вот о чём:

📌 что вероятнее: договор будет читать суд или госорган или через этот договор будет продираться контрагент (а потом править, потому что непонятно)?
📌 если формулировка когда-то попала в суд и помогла компании, то суд убедил порядок слов или всё-таки заложенный в неё юридический эффект?
📌 (если спор был о толковании договора) вы уверены, что держите в договоре хорошую формулировку, если она настолько хороша, что сторонам пришлось дойти до суда, чтобы выявить её значение (пусть даже в итоге суд решил в вашу пользу)?

По-прежнему единственный способ добиться желаемого юридического эффекта — максимально точно описать в договоре ровно то, чего вы хотите добиться. И не выдумывать запутанные многокилометровые формулировки.

P. S. про тех, кто считает, что умение написать сложный текст — главная суперспособность юриста, уже писали.

#НастоящийЛигалДизайн

Интервью о внутренних документах

Нас жутко бесит, когда компании делают километры сложных и непонятно что регулирующих внутренних документов, которые никто не читает (и логично, что не исполняет). Всё регулируется не чёткими правилами, а какими-то внутренними обычаями, которые люди успели пересказать друг другу. На это жалуются буквально все, в том числе и юристы. В нормальных компаниях такого быть не должно.

В мартовском номере «Трудовых споров» вышло интервью с управляющим партнёром Симплоера Антоном Вашкевичем. Поговорили об очевидных и неочевидных положительных эффектах от нормальных документов — как они помогают бизнесу внутри и снаружи.

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

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

#НастоящийЛигалДизайн

Об обосновании привлечения выделенной профессиональной команды для оптимизации работы

#SimplawyerLegalOps

Даже законы можно писать по-человечески

Во всех странах юристов ругают за законы, в которых не разобраться без пояснительной бригады (и чаще всего абсолютно заслуженно). Но вот вам пример более продвинутой юридической техники — британский Companies Act 2006.

Кроме сравнительно лаконичных и человекочитаемых формулировок, авторы используют хороший приём — разбивать на буллиты предложения с параллельными идеями. Не все предложения можно уместить в 15–20 слов, не потеряв смысл. Поэтому сложную идею лучше разделять на слои и объяснять поэтапно.

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

Пишите в комментах, какие вы видели примеры хорошо написанных законов.

#НастоящийЛигалДизайн