Вы наверняка слышали слово Jira. Разработчики его обожают или ненавидят, менеджеры требуют отчеты, а подрядчики в договорах пишут: «работа ведется в Jira».
Для большинства юристов Jira - это что-то вроде «доски с карточками для айтишников». Непонятно, зачем она нужна, как ее читать и главное - как это поможет мне выиграть спор или проверить подрядчика?.
Спойлер: поможет очень сильно. Причем именно там, где обычные акты и переписка бессильны.
В этой статье я объясню Jira так, как будто мы говорим о деле, а не о программировании.
1. Что такое Jira максимально простыми словами
Представьте себе юридическую канцелярию, где у каждого дела есть:
свой номер;
карточка с фабулой;
статус («принято», «на рассмотрении», «отказ», «удовлетворено»);
вся история движений по делу (кто, когда, что сделал, какой документ приложил);
переписка и резолюции.
Jira - это ровно такая же система, только для задач по разработке ПО.
Вместо «дела» там задача (issue).
Вместо юриста - разработчик или тестировщик.
Вместо резолюции - комментарий с решением.
Вместо процессуального срока - дедлайн.
И самое главное: в Jira остается полная, хронологически точная, с привязкой к людям и времени запись того, кто, когда, что сделал, а что - нет.
Для юриста Jira - это не инструмент разработки. Это инструмент фиксации фактов.
2. Почему юристу нельзя игнорировать Jira
Потому что в IT-спорах суд не принимает слова. Суд принимает документы и логи.
Типичная ситуация:
Заказчик: «Вы не сделали функцию поиска по договорам».
Разработчик: «Сделали. Вы просто не умеете пользоваться».
Суд разводит руками, назначает экспертизу (дорого, долго).
А если бы в договоре было условие «вся разработка ведется в Jira», то картина была бы другой.
Юрист заказчика открывает Jira и видит:
Задача «Поиск по договорам» создана 01.03.2025.
Статус задачи: «Closed» (закрыта) с пометкой «Won't Fix» (не будет исправляться).
Комментарий разработчика: «По ТЗ это не требуется, сделаем в следующей версии за доп. оплату».
Всё. Факт зафиксирован. Jira стала доказательством неисполнения обязательств.
3. Основные элементы Jira, которые нужно знать юристу (чтобы не пугать технических свидетелей)
Вы не обязаны работать в Jira. Но вы обязаны понимать, что там лежит, и уметь задать правильные вопросы эксперту или свидетелю.
3.1 Задача (Issue) - аналог судебного дела
Каждая задача имеет:
Уникальный номер (например, PROJ-123) - ссылаться на него в переписке и претензиях.
Заголовок - что нужно сделать («Реализовать фильтр по датам»).
Описание - подробно, как должно работать.
Тип задачи:
Bug - ошибка (что-то работает не так).
Task - задача (сделать новый функционал).
Story - история с точки зрения пользователя.
Epic - большая тема, объединяющая много задач.
Для юриста важно: если разработчик 6 месяцев не закрывал баги из списка, это основание для претензии о некачественной работе.
3.2 Статус (Status) - аналог процессуального положения
Статус показывает, на каком этапе находится задача.
Типичные статусы:
Open / To Do - задача создана, но никто не взял.
In Progress - разработчик работает.
In Review - код проверяют (аналог внутренней экспертизы).
Done / Closed - выполнено (сдано).
Reopened - задачу открыли заново (значит, сделали плохо).
Won't Fix - задача отклонена (ваш красный флаг).
Для юриста: статус Done не означает «работает как надо». Он означает «разработчик считает, что сделал». Разница - в предмете будущего спора.
3.3 Комментарии - аналог протокола совещания
Любой участник проекта может оставить комментарий в задаче.
И удалить его нельзя (можно скрыть, но в истории останется).
Для юриста это золотая жила:
разработчик написал «ждем данные от заказчика уже 2 недели» - значит, просрочка не его вина;
менеджер написал «заказчик утвердил изменения, делаем за дополнительные 200 тыс.» - это изменение договоренности;
технический директор написал «мы понимаем, что архитектура не выдержит, но начальство сказало делать» - доказательство заведомо ненадлежащего качества.
3.4 Спринт (Sprint) - короткий этап работ
Спринт - это отрезок времени (обычно 1- 4 недели), за который команда обещает сделать определенный набор задач.
Анализируя закрытые спринты, юрист может:
доказать неоднократный срыв сроков;
показать, что разработчик систематически не справляется с объемом;
выявить, что критические ошибки переносятся из спринта в спринт (а значит, не исправляются).
4. Как Jira помогает юристу в типовых IT-спорах
Спор 1: Подрядчик сдал работу, но она не работает
Вы привыкли: есть акт, есть ЭЦП. Значит, работа принята, спорить сложно. Но если в договоре написано «приемка осуществляется по факту закрытия задач в Jira», картина меняется.
Вы открываете Jira и видите:
Задача «Импорт данных из Excel» имеет статус Done.
В комментариях тестировщик пишет: «импортирует с ошибками, но проджект-менеджер сказал закрыть».
Всё. Акт не спасет разработчика. У вас есть прямое доказательство, что задача закрыта при ненадлежащем качестве.
Спор 2: Просрочка
В договоре: «сдача этапа - 30 апреля». Разработчик: «мы все сделали вовремя, заказчик просто не подписывает акт».
Открываем Jira:
Задача «Разработать модуль отчетов» имеет статус Done, но дата закрытия - 15 мая.
История переходов: задача была в статусе In Progress с 20 марта по 14 мая. Никаких комментариев о блокировках со стороны заказчика.
Доказательство просрочки на 15 дней готово.
Спор 3: Нецелевое расходование бюджета (актуально для крупных проектов)
В договоре - фиксированная цена за согласованный объем работ. Заказчик платит, а функционала не прибавляется.
В Jira видно:
Команда сделала 50 задач, из них 30 - правки по своим же ошибкам (косяки разработки).
Спринт за спринтом одни и те же баги всплывают снова.
Юрист предъявляет: «Вы оплачиваете не разработку, а бесконечное исправление своего некачественного кода. Это не наш риск».
Спор 4: Плагиат или кража кода (при расторжении договора)
Если по условиям договора заказчику передается доступ к Jira, то он получает:
историю коммитов (связки задач с кодом);
кто, когда и что менял;
описание архитектурных решений.
При споре об интеллектуальных правах Jira становится идеальной хронологией создания кода, которую невозможно подделать задним числом.
5. Как юристу выстроить работу с Jira (простая инструкция)
Шаг 1. Пропишите в договоре доступ к Jira
Образец условия:
«Исполнитель предоставляет Заказчику (и его уполномоченным представителям) доступ на чтение в систему Jira (или аналогичную) для контроля хода выполнения работ. Доступ предоставляется в течение 3 рабочих дней с начала работ.
В случае спора данные из Jira имеют приоритет над иными формами отчетности».
Шаг 2. Назначьте ответственного от заказчика
Не надо, чтобы юрист сам заходил в Jira (если не хочет). Пусть это будет технический менеджер или проджект.
Но юрист должен получать от него два документа:
выгрузку задач со статусами (можно в Excel);
скриншоты или логи по спорным моментам (особенно комментарии, где признается косяк).
Шаг 3. При любой претензии требуйте ссылки на задачи
Не принимайте фразу «мы это сделали». Требуйте: «покажите задачу в Jira со статусом Done и ссылкой на коммит».
Шаг 4. При судебном споре - включайте Jira в предмет экспертизы
Эксперт-компьютерщик (как мы в ЛЦИ) может:
проанализировать историю изменений в Jira;
сопоставить даты задач с реальными действиями в коде;
выявить признаки задним числом проставленных статусов (если система это позволяет).
6. Чего Jira НЕ МОЖЕТ (и что не надо от нее требовать)
Давайте без магии. Jira - это не истина в последней инстанции, а хороший журнал фактов.
Она не заменяет экспертизу:
статус «Done» не означает, что задача реализована качественно (это проверяет экспертиза, а не Jira);
удалить историю почти нельзя, но можно скрыть - поэтому нужен полный доступ, а не API-выгрузка, которую контролирует разработчик;
если никто в команде не заполняет комментарии, то Jira будет бесполезна - но это проблема культуры подрядчика, которую вы должны оценить до подписания договора.
7. Резюме для юриста (чтобы запомнить)
Jira для разработчика
Jira для юриста
Инструмент управления задачами
Инструмент фиксации фактов
Доска с карточками
Электронный протокол процесса разработки
Статусы для команды
Статусы = доказательство этапа выполнения
Комментарии для коллег
Комментарии = признания и доказательства намерений
История изменений
Хронология, которую сложно подделать
Если подрядчик говорит «мы работаем в Jira» — это не техническая деталь, а ваше процессуальное преимущество. Но только если доступ к Jira есть у вас, а не только у них.
Дорогие коллеги, не надо бояться Jira.
В нее не нужно самому заводить задачи, настраивать дашборды или разбираться в «скраме».
Достаточно:
Прописать доступ в договоре.
Раз в месяц получать выгрузку по задачам (или смотреть глазами).
При споре - идти не к эмоциям, а к Jira: кто, когда, что сделал и что написал.
А если понадобится судебная компьютерно-техническая экспертиза данных из Jira, исходных кодов или соответствия АИС техническому заданию - вы знаете, куда обратиться ;)