Буквы в нумерации

На прошлой неделе народ слегка взбудоражила идея сквозной нумерации в пунктах формата «если-то» (см. комментарии). Были предложения вместо цифр использовать буквы.

По нашему опыту алфавит в нумерации — плохая идея (не только для формата «если-то», но и во всех других случаях):

❌ непонятно, все ли буквы нужно учитывать в нумерации, — у некоторых букв кириллицы (ё, й, ъ, ы, ь) неопределённый статус;

❌ буквы неудобно воспринимать при ранжированных ссылках (например, п. 1.2.3–1.2.10). Попробуйте быстро ответить, входит ли пункт s в список п. k–p;

❌ сложности при устном обсуждении документа — не все знают, как правильно произносить буквы английского алфавита. Например, пока одни правильно произносят букву e как [i:], другие думают, что речь идёт о пункте i (та, что [ai]). Отсюда начинаются классические лингвофокусы «эс, как доллар», «си, как «русская» эс». Это особенно неудобно при согласовании с иностранным контрагентом;

❌ не подходит, когда нужен длинный список (это нечастая ситуация, но она время от времени возникает в сложных документах). Буквы алфавита в какой-то момент кончаются. В английском алфавите их всего 26. В русском — 33 (или 32?) (или 30?).

P. S. Коллеги также предлагали использовать разные форматы нумерации на одном уровне. Например, «если 1, 2, 3, то а), б), в)». Мы так не делаем, потому что несколько разных стилей для одного и того же уровня порождает бардак.

Больше о подходах Симплоера к нумерации:

• четырёхуровневая нумерация
• висячая нумерация
• отступы в нумерации
• мелкая нумерация

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

Все знают, какие крутые мастер-классы у Симплоера. Но сегодня не об этом

Вчера был классный кейс — провели корпоративное обучение лигал-дизайну для команды, которая заказывает его в Симплоере уже во второй раз. С точки зрения эффективности обучения и внедрения лигал-дизайна это хороший подход, потому что:

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

Так что если вы вдруг пока ещё думаете, как использовать с толком оставшиеся бюджеты, то пишите на smart@simplawyer.com. Подробнее о программе и формате занятий читайте на сайте.

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

Предзаказ на книгу Симплоера

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

В этот раз книг должно хватить всем желающим. И заказать можно будет в любую точку мира.

Книгу издавали не абы где, а в Студии Лебедева. Это продвинутое издательство, а по дизайну вообще самое главное. Они уже выпустили тонны самых важных книг о дизайне, и теперь к ним присоединилась ещё одна.

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

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

Сделать предзаказ можно тут — https://store.artlebedev.ru/books/legal-design/

Например, пример

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

Так и пишите «[текст нормы]. Например: [текст примера]».

Чаще всего мы используем примеры в 2 случаях:

📌 чтобы объяснить норму или подставить переменные

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

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

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

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

Контрагентам такое не понравится

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

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

Это как если бы вам сказали, что айфон без клавиатуры — блестящая и прорывная идея, но клиентам будет непривычно, поэтому давайте ещё на экран добавим пластмассовые кнопки.

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

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

И (или)

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

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

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

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

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

(далее — 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