Создание цифровых юридических продуктов: от идеи до запуска

Юристы становятся создателями полезных сервисов и делятся опытом с коллегами

Создание цифровых юридических продуктов: от идеи до запуска

11 октября участники программы повышения квалификации «LegalTech-директор»® прослушали лекцию руководителя LegalTech-направления «СберЛигал», CTO и руководителя проекта «СберЮрист» Дарьи Николаевой. В 2018 г. она оказалась в числе первых участников этой программы, уже успела создать свой LegalTech-продукт и вот теперь пришла поделиться опытом.

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

Клиент регистрируется в личном кабинете. Затем отвечает на вопросы анкеты и после оплаты получает готовый документ и алгоритм действий. Если жизненная ситуация оказалась нетипичной, он может обратиться за помощью к юристам. К слову о пользе конструкторов документов: юристы тоже используют конструктор, только его расширенную версию – со значительно большим перечнем вопросов в опросном листе.

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

Как зафиксировать идею?

«Ни одна идея не сработает так, как вы ожидаете, когда она столкнется с реальностью» –свое выступление Дарья Николаева начала со слов первого гендиректора Netflix Марка Рэндольфа. Она подтвердила, что так всегда случается и иначе быть не может. Тем не менее без фиксации идеи совсем ничего не получится.

Вот что понадобится перенести из головы на материальный носитель:

  • бизнес-требования – бизнес-цели, которые позволит достичь разработанное ПО;
  • моделирование бизнес-процесса – описание бизнес-процессов, которые нужно автоматизировать с помощью разработанного ПО (BPMN, ARIS, VISIO);
  • функциональные требования – описание сервисов и функций, которые должна выполнять система;
  • пользовательские требования – простое и понятное описание работы системы;
  • системные требования – детализированное описание свойств и методов работы всех компонентов системы;
  • архитектура ПО – «скелет» системы, ее инфраструктурное описание;
  • проектирование ПО – описание на уровне кода работы каждого из модулей.

Конечно, чтобы так зафиксировать идею и уж тем более воплотить ее в жизнь, кроме юриста понадобится целая команда специалистов. Дарья Николаева рассказала, без кого точно невозможно обойтись при разработке сложного LegalTech-продукта.

Команда разработки

1. Юрист (analyst, methodologist, algorithm specialist).

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

«Должен ли юрист программировать?» – этот вопрос не раз звучал на лекциях. По мнению управляющего партнера юридической компании TAXADVISOR Дмитрия Костальгина, программирование помогает ставить задачи перед разработчиками и их контролировать, оценивать бюджет и платить исполнителям за работу приемлемые суммы. Своим мнением поделился и директор ООО «ЛигалТех», эксперт по LegalTech-инновациям в юридическом бизнесе Александр Бороухин: умение программировать помогает освоить необходимые для проектирования системы компетенции и решать локальные задачи автоматизации самостоятельно. Однако это умение не является ни обязательным, ни достаточным для создания техзадания. А основатель и научный руководитель программы «LegalTech-директор», внешний консультант по LegalTech-инновациям для юридических департаментов Александр Трифонов считает, что юрист – это методолог, без которого программисты не справятся. Его мнение о том, что должен уметь руководитель LegalTech-направления, я передала в материале «Как стать LegalTech-директором?».

2. TeamLead – бывший инженер разработки с системным, аналитическим, стратегическим мышлением.

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

3. Backend, frontend, full stack developer – инженер-программист.

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

4. Quality assurance specialist – специалист, который ищет ошибки (баги) в создаваемом продукте путем сопоставления требований заказчика и того, что реально получилось.

  • Пишет тест-планы и тест-кейсы;
  • участвует в приемочных испытаниях;
  • дает рекомендации по исправлению ошибок или устраняет их сам;
  • обеспечивает непрерывность тестирования разработанного ПО.

5. DevOps-инженер – бывший системный администратор, который знает, что делают разработчики.

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

6. Cyber Security Officer – телохранитель цифрового продукта.

  • Понимает все процессы создания продукта;
  • взаимодействует с командой разработки и специалистами инфраструктуры для обеспечения безопасности продукта;
  • создает инфраструктуру, которая обеспечивает безопасность персональных данных и режим коммерческой тайны;
  • контролирует процесс закупки и работоспособности средств защиты информации;
  • участвует в тестировании продукта на предмет наличия уязвимостей.

7. Маркетолог – человек, без которого о продукте никто не узнает.

  • Исследует рынок, целевую аудиторию и изучает конкурентов;
  • знает больше всех слов из трех букв: SEO, SMM, SPA, SPL, SPO, GTM и т.д.;
  • формирует ценовую политику и маркетинговую стратегию;
  • создает систему продаж, определяет каналы;
  • ставит задачи копирайтеру, дизайнеру, seo- и smm-специалистам, менеджерам по продажам;
  • систематизирует и оптимизирует кампании.

Этапы создания LegalTech-продукта

Для команды разработки:

  • аналитика;
  • дизайн;
  • проектирование;
  • разработка;
  • тестирование;
  • эксплуатация (техподдержка);
  • развитие (доработка).

Для продуктовой команды:

  • описание бизнес-процесса;
  • составление карты взаимодействия потребителя с продуктом (customer journey map);
  • подготовка бизнес-требований, требований к ПО;
  • описание use cases, атрибутов;
  • подготовка нормативной документации;
  • адаптация юридических документов для автоматизированных сервисов и процессов;
  • приемка результата работ/ UAT-тестирование;
  • маркетинговая кампания, CEO, SMM.

Особого внимания заслуживает вопрос технической поддержки разработанного сервиса и его дальнейшей эксплуатации. «Разработчики могут создать для вас сервис так, что в будущем вы не сможете отказаться от их услуг. Зашьют что-нибудь в код – этакую изюминку разработки. И если вы не обладаете определенными техническими знаниями и навыками, вы как заказчик это не увидите. А когда у вас что-то будет ломаться, вам никто это не починит, кроме вашего разработчика, – предупредила Дарья Николаева. – Чтобы избежать таких проблем, можно в процесс приемки ввести независимого эксперта. Или можно еще на этапе разработки продукта привлечь технического консультанта, который будет отслеживать, как пишется ваш код. Попросите его задать параметры программирования и включить их в техзадание. При приемке он проверит, все ли выполнено». Кроме того, нужно решить, за кем будет закреплена техподдержка. Можно передать эту функцию разработчику или после получения кода нанять команду технической поддержки.

Непростительные ошибки при создании LegalTech-продукта

По словам директора ООО «ЛигалТех» Александра Бороухина, до внедрения любого LegalTech-продукта нужно будет ответить на несколько вопросов.

  • Знаете ли вы, как работают сотрудники вашего подразделения, смежники, филиалы, ДЗО?
  • Уверены ли вы, что ваше видение решения единственно правильное?
  • Не сломает ли ваше решение процессы смежников?
  • Не сможет ли продукт решить и другие проблемы?

Александр Бороухин перечислил распространенные ошибки, которые встречаются при создании LegalTech-решений.

  • «Поручим всё разработчикам». Если вам захочется однажды вот так же махнуть рукой на многоступенчатый творческий процесс, задайте себе вопрос: так почему тогда вы не просите автомеханика из сервиса выбрать вам автомобиль?
  • «Поручим это всё кому-то одному». То есть найдем не загруженного работой «гика» и не сформируем команду из сотрудников разных подразделений.
  • «Не спросим смежников». А значит, не подумаем об Enterprise Architecture (пусть ее пока и нет), не учтем возможность интеграции и мнение бухгалтера, финансистов и технарей, проигнорируем внешние ограничения.
  • «Не погрузим в процесс руководство». Следовательно, не сможем эффективно решать внутренние конфликты и не обеспечим результативное внедрение. Вот вам пример, основанный на реальных событиях: чтобы автоматизировать отдельные процессы в подразделении компании, нужно было получить о них исчерпывающую информацию. Но продолжительный разговор с сотрудником, ответственным за эти процессы, результатов не дал. Только после вмешательства его руководителя в ситуации удалось разобраться: человек боялся, что после автоматизации он лишится работы, а потому не горел желанием выстраивать конструктивный диалог.

Советы по разработке LegalTech-продукта

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

2. Предложить оценить готовое решение вместо того, чтобы задавать вопросы на этапе разработки продукта, – путь к провалу проекта. И не забывайте оценивать контекст и важность полученной информации.

3. Обеспечивайте поступательное и результативное движение процесса (как это сделать – можно прочитать в материале «Аgile-подход в работе юристов»).

4. Документируйте результаты.

5. Начинайте с простого. Закон Голла гласит: работающая сложная система обязательно произошла от работающей простой. Сложная система, разработанная с нуля, никогда не работает, и ее невозможно исправить так, чтобы она заработала. Нужно начать заново, с простой работающей системы.

6. Решите, покупать ли готовый продукт или разрабатывать собственный.

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

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

7. И помните: пользователям должно быть удобно, иначе они начнут саботировать использование продукта. «Попробуйте сделать систему такой же увлекательной, как соцсети», – предложил докладчик. И правда, уж туда силой нас никто не тянет.

8. Отнеситесь внимательно к документации LegalTech-проекта. Причем не имеет значения, покупаете ли вы готовый продукт или разрабатываете собственный.

Тут важно избежать двух ошибок.

  • «А давайте просто перешлем свои регламенты». Имейте в виду, что регламенты не всегда отражают реальную картину и обычно непонятны. К тому же внедрение ПО должно привести к изменению регламентов.
  • «Давайте просто опишем интерфейс». Нельзя с этого начинать и уж тем более этим ограничиваться. Как и Дарья Николаева, Александр Бороухин акцентировал внимание на этапах документирования проекта: обоснование потребности – предпроект – функциональные требования – техническое задание – материалы для обучения – документация на ПО (ИС) – проектные решения – технический проект.

9. Для общения с разработчиками лучше использовать диаграммы. Разработчики не всегда их понимают. Но еще меньше они понимают тексты, написанные юристами. Тем более тексты долго составлять и сложно править. Используйте mind maps и попробуйте сочетать диаграммы с текстом.

Берем пример с коллег

«А трудно это – пройти путь от идеи до запуска LegalTech-продукта? Допустим, я талантливый и амбициозный юрист. Вижу потребности рынка и хочу предложить ему свое LegalTech-решение. Что нужно, чтобы добиться успеха?» – с этим вопросом я обратилась к члену экспертной коллегии Фонда «Сколково» по LegalTech-стартапам Александру Трифонову.

«Создать стартап и стать единорогом – это сложно. В России единорогов я не встречал (единорогами называют компании-стартапы с рыночной стоимостью свыше 1 млрд долл.). Но успешные стартапы есть», – ответил Александр Трифонов и привел несколько примеров.

Антон Солдатов не был юристом, он программист. Но, понаблюдав за работой юристов, разглядел их потребности и создал Jeffit. Его коллега Максим Царёв рассказал участникам образовательного курса «LegalTech-директор»®, как с помощью их LegalTech-продукта «Сибур», «Балтийский лизинг» и «Объединенная металлургическая компания» объединяли все свои системы в единые экосистемы. Почитать об этом вы можете в материале «Технологии на службе у юристов».

Еще один удачный пример – сервис НДФЛка.ру, который помогает получить налоговый вычет. Его сооснователь Дмитрий Костальгин – налоговый консультант, управляющий партнер юридической компании TAXADVISOR. Однажды он понял: большинство людей знают, что им положен вычет, но никогда не пробовали его получить или, столкнувшись с трудностями, останавливались после первой же попытки. Поэтому гражданам предложили удобный онлайн-сервис для быстрого возврата налогов. Его пользователям удалось вернуть уже более 7 млрд руб. Компания стала партнером крупнейших организаций, в числе которых и Сбербанк.

В 2018 г. выпускники МГЮА основали компанию «Судоход». Этот сервис разработан для содействия юридическим департаментам, фирмам и отдельным юристам в решении судебно-технических вопросов.

В общем, успешных проектов накопилось достаточно. Есть с кого брать пример...


Читайте также: