Введение
Я работаю юристом и люблю повторять — хочешь улучшить юридические процессы, посмотри, как свои процессы организуют в IT. В серии из двух статей я хочу поделиться опытом внедрения в работу юридического бюро методологий Scrum и Kanban:
В этой статье я расскажу:
— о нашей команде и ее проблемах,
— почему были выбраны эти методологии,
— этапы внедрения Scrum и Kanban,
— что получилось, и что не получилось в использовании Scrum и Kanban,
— факторы, повлиявшие на результаты внедрения Scrum и Kanban,
— в каком виде Scrum и Kanban используются сейчас.
Статья рассчитана на читателя, который знаком с теорией Scrum и Kanban, поэтому, если вы не знаете, что это такое, рекомендуется сначала ознакомиться с методологиями, например:
Наша команда и ее проблемы
На момент внедрения команда состояла из 5 юристов. Команда является частью адвокатского бюро и ведет отдельный проект — сопровождение текущей деятельности спортивной организации.
Выполняемая работа — подготовка писем, служебных записок, документальное оформление заседаний органов (бюллетени голосования, протоколы и т.п.), подготовка внутренних регламентов, подготовка аналитических заключений по вопросам международного и российского права и др.
Задачи можно разделить на плановые (глубина планирования год) и текущие. Текущую работу можно также разделить на выполняемую по шаблону и экспертную.
В отличие от других проектов, данный проект отличался:
— повышенными требованиями к качеству работы — один раз ошибся и ты ошибся, даже если эта ошибка — орфографическая,
— высокой глубиной планирования задач. Как правило, глубина планирования у юриста не превышает 1 месяца, в нашем случае большой объем задач (50% времени команды) был запланирован на год вперед.
— высокий объем поступающих текущих задач.
— длительность сроков согласования результатов работ плановых и экспертных задач.
В результате мы сталкивались со следующими проблемами:
— сложность распределения времени между текущими и плановыми задачами. Часто случался перекос времени в ту или иную сторону.
— не всегда был понятен статус переданных работ заказчику — результат еще находится на согласовании или про него забыли? Если заказчик забывал про выполнение задач, это воспринималось им как недоработка команды.
— сложность контроля за ходом выполнения задач. Таблицы в word для учета задач не отвечали потребностям. Из-за этого часто срывались сроки.
— следствием недостаточного администрирования была неравномерность распределения загрузки между участниками команды.
— следствием всех проблем — высокий стресс всей команды.
Почему Agile
Надо было что-то решать и мы случайно узнали про agile, когда искали методики управления проектами.
Нам сразу стало понятно, что юридическая работа — это уже agile. Юрист, как правило, понимает объем работы в процессе выполнения задач, изучения законодательства и судебной практики, получения дополнительных документов. Отношения внутри команды у нас уже были выстроены на основе открытости, безопасности, отсутствии строгой подчиненности, при лидерстве руководителя проекта. Вообще, юристу сложнее понять, как работает waterfall.
Неприятный момент: agile, как идеология, без конкретной методологии может легко превратиться в хаос. Когда мы узнали о Scrum и Kanban, стало понятно, что эти методологии смогут упорядочить нашу работу и повысить ее качество.
Внедрение
Вначале мы прошли обучение у Scrum-мастера. Уже на следующий день после обучения команда начала внедрять Scrum и Kanban в работу. Scrum был предназначен для плановой работы, Kanban — для текущей.
В качестве IT-решений мы использовали Jira и расширение Nova для отслеживания метрик текущей работы.
Шаг 1. Формирование бэклога на полгода вперёд для плановой работы
Данный этап проходил в рамках слепого мозгового штурма. Каждый участник сформировал свое видение всех задач по плановой работе, затем на собрании мы сформировали общий список. После этого руководитель группы сформировал спринты длительностью две неделе и разбросал задачи бэклога по спринтам. Решение было согласовано с командой. В последующем бэклог формировал руководитель и согласовывал с командой.
В целом, мы смогли выдержать темп работы. На этапе внедрения неудачными из 12 спринтов можно назвать только 2, каждый из которых был продлен на две недели из-за неожиданно поступивших крупных задач по текущей работе. В любом случае, темп работы по спринтам превышал темп работы без них.
Шаг 2. Ретроспектива
Еще до первого спринты мы провели ретро, чтобы понять, в какой ситуации мы находимся и какие проблемы есть. Ретроспективы мы проводили каждые две недели и они, пожалуй, дали самый большой эффект в повышении скорости работы, качества работы, планирования и т.п.
Каждый инцидент рассматривался командой и вырабатывались решения, что сделать, чтобы они больше не повторялись. В результате, если раньше замечания от клиента поступали раз в неделю, мы сократили их количество до, примерно, 1 раза каждые три месяца.
Например, у нас были проблемы с согласованием документов. Мы стали вести реестр, когда документы были направлены на согласование, и когда ожидаем на них ответ. Если срок срывался — напоминали. Если после напоминания в течение разумного срока (обычно неделя) не было движения — пытались решить проблемы через руководство заказчика. В результате мы стали не просто работать по принципу «отправил-забыл пока не ответит», а стали руководить процессом.
Сейчас мы сократили частоту ретроспектив и проводим их каждый квартал. В качестве компенсации мы стали разбирать инциденты вне ретроспектив, и проводить мероприятия, направленные на недопущение повторения таких же инцидентов в дальнейшем.
Шаг 3. Ежедневные митинги
Митинги помогли нам в распределение текущей работы, дав следующий эффект:
— Оперативное понимание мест, где возникают проблемы,
— Улучшили постановку приоритетов задачам,
— Равномерно распределили нагрузку,
— Способствовали повышению самодисциплины,
И как следствие:
— Снизили уровень стресса,
— Повысили объем выполняемых задач,
— Улучшили скорость выполнения «неприятных» задач.
Шаг 4. Приоритезация задач
Каждая задача по текущей работе имела свой приоритет:
— Нормальный. В этом случае задачи выполнялись в порядке их поступления с учетом сроков, отведенных для их выполнения.
— Высокий. Эти задачи выполнялись вперед задач с нормальным приоритетом.
— Самый высокий. Эти задачи должны были быть выполнены в день их поступления.
— Низкий. Эти задачи выполнялись, когда было время для их выполнения, но не позже предельных сроков.
Приоритеты обозначались непосредственно клиентом. По умолчанию все задачи поступали с нормальным приоритетом.
Шаг 5. Категорирование входящих поручений по текущей работе
Через несколько месяцев работы мы поняли, как можно категорировать задачи по текущей работе, чтобы можно было точнее определять сроки выполнения входящих поручений. Например, у нас были такие задачи, как:
— Проведение голосований комитета,
— Подготовка писем и служебных записок,
— Сложные задачи,
— Исправление ошибок.
и др.
Исходя из категории задачи и приоритета, обозначенного клиентом, определялись сроки выполнения задач, при этом, два дня закладывалось на согласование клиентом. Были написаны специальные правила определения сроков выполнения задач.
Например, на подготовку писем и служебных записок отводилось 5 дней, из которых 2 — согласование. Это не значит, что письмо писали 3 дня. Это значит, что задача поступала в очередь выполнения задач, и мы могли гарантировать клиенту, что, невзирая на любую другую работу, письмо будет отправлено клиенту на третий день. Если очереди в задачах не было, письмо могло быть отписано и через 15 минут после поступления задачи. Для исправления ошибок срок устанавливался 3 дня, из которых 2 — согласование с клиентом исправленного результата. И так далее.
Срок выполнения задач уменьшался, если клиент ставил сокращенные сроки.
Категорирование задач сейчас не используется командой. О причинах будет сказано ниже.
Результат
Из положительных моментов можно выделить:
1) Однозначно повысилась производительность труда. Теперь мы выполняли больше задач за единицу времени.
2) Повысилось качество работы: значительно снизилось количество любых ошибок.
3) Повысилось предсказуемость выполнения работы. Если в первый месяц использования системы в прогнозируемые срок было выполнено 15% задач, то постепенно мы повысили точность до 55%. Главная проблема для дальнейшего улучшения точности выполнения задач — более длительные сроки согласования результата работ клиентом, чем мы закладывали. Без учета согласования работы с клиентом в планируемые сроки выполнялось 85% задач.
4) Снизился уровень стресса у членов команды: прямое следствие снижения количества переработок и повышения предсказуемости работы.
Что не получилось или не понравилось:
1) Увеличение количества совещаний. На них стало уходить гораздо больше времени, поэтому пришлось себя ограничивать: проводить летучки в более сжатые сроки, уменьшить количество ретроспектив и т.д.
2) Мы не внедрили ревью в работу с клиентом. Мы так и не поняли, в каком виде мы можем его проводить. Все документы в ходе работы и так поступали клиенту для согласования, а показывать их повторно в конце спринта мы не видели смысла. В каком виде ревью может проводить юрист, для нас до сих пор загадка. Если в программировании можно демонстрировать готовый продукт, то в юриспруденции — только презентации. А презентации уже не рекомендует сама методология Scrum.
3) Необходимость высокого уровня самодисциплины. Почему это недостаток? Потому что вместо прямой работы нужно тратить много времени на соблюдение «ритуалов» Scrum. Каждая задача должна быть прокатегорирована, приоритезирована, поставлен конечный срок ее выполнения и т.д. Скажем прямо — это скучно. И если вы обнаружите, что клиент не требует от вас идеальной работы, и ему достаточно просто хорошей, появится желание отказаться от каких-то ритуалов. У нас так получилось с категориями задач: клиенту было достаточно, чтобы задачи выполнялись в сроки, которые он нам обозначил. Категорирование позволяло улучшить темпы работы, по сравнению с требованиями клиента, но поскольку клиенту хватало качества, которое мы выдавали без категорирования, от этого артефакта мы отказались.
4) Сложность масштабирования. Когда мы попытались перенести опыт команды на всю юридическую компанию, у нас ничего не получилось. Оказалось, что методологии хорошо работают, когда команда работает над одним проектом. Это бывает в двух случаях
i. Если команда сопровождает клиента с относительно небольшими типовыми задачами, где один юрист может легко заменить другого юриста.
ii. В крупных спорах, по которому работают сразу несколько юристов. Например, у нас в работе находился корпоративной спор между собственниками общего бизнеса, между которыми было сразу несколько судебных споров. Спор сопровождало сразу 4 юриста. Корпоративную войну мы сопровождали по методологии Scrum: исходя из дат судебных заседаний, формировали задачи в спринтах на две недели и распределяли их между участниками команды. Здесь методология оказалась эффективной.
Однако у нас было много небольших уникальных проектов, в которых команда состояла из одного человека. Другие сотрудники бюро, за редкими исключениями, не могли помочь коллеги с его проектом, поскольку были заняты своими небольшими проектами. Объединение таких людей в одну команду привело к тому, что положительный эффект от методологии был небольшим, а временные издержки на совещания и ведение карточек значительно выросли. Поэтому Scrum и Kanban сейчас используются в нашей компании только в изначальной команде. При этом некоторые из артефактов, например ретроспективы, канбан-доски были взяты на вооружение, но используются они только по необходимости.
Перспективы для использования Scrum и Kanban в юриспруденции
На мой взгляд, Scrum и Kanban имеют хорошие перспективы для их использования в юриспруденции. Основными препятствиями в их внедрении являются:
1. Юристы не знают о методологиях Scrum и Kanban. Юристам свойственна «коллективная слепота» и они редко смотрят на успешный опыт в других сферах. Однако в связи с распространением идеологии «Юридического дизайна» ситуация стала меняться и юристы стали чаще смотреть на положительный опыт в других отраслях. Популяризация методологий Scrum и Kanban может привести к ее более широкому применению.
2. Юристы не имеют менеджерского образования. Моя коллега проводила социологическое исследование, которое показало, что 9 из 10 руководителей юридических фирм не имеют какого-либо образования в сфере управления. Из-за этого руководители в юридических подразделениях и фирмах часто работают, как привыкли, не задумываясь над тем, как можно повысить эффективность администрирования.
3. Scrum и Kanban необходимо адаптировать под юридическую работу. Например, как я указал выше, Scrum предполагает ревью с клиентом, но как его проводить в юриспруденции — непонятно. Другой проблемой является вопрос о том, как и можно ли вообще использовать методологию, когда один юрист ведет несколько небольших, но все-таки полноценных независимых проектов. Можно ли в этом случае из юристов-одиночек сформировать реальную команду внутри подразделения? Необходимы практические наработки.
Выводы
Scrum и Kanban позволяют повысить качество и предсказуемость юридической работы, снизить уровень стресса и избавиться от хаоса в потоке задач. Одновременно методологии требуют высокой самодисциплины от команды и временных ресурсов на соблюдение ритуалов. Положительный эффект от внедрения методологии не гарантирован и во многом зависит от самого устройства команды и тех поручений, которые сотрудники ведут. Чем выше количество общих проектов и однотипных задач — тем выше положительный эффект. Чем выше самостоятельность юристов внутри команды — тем он ниже.
В любом случае, использование методологии требует от руководителя команды понимания всех проектов и задач, которые команда выполняет. Т.е. руководитель должен меньше выполнять юридическую работу и больше администрировать, но в целом эффективность команды должна вырасти.
У Scrum и Kanban имеется потенциал в юридической работе и, возможно, скоро мы будем наблюдать за тем, как методологии входят в работу юристов.
Больше по теме: http://t.me/tenrulelawyer
Отличная статья, спасибо. Отсутствие комментариев подтверждает мнение про коллективную слепоту)