У меня для вас новости. Работа разработчика программного обеспечения по-прежнему тяжела. Впрочем, вы и сами это знаете, не так ли, дорогие читатели-разработчики?
Написание кода по-прежнему не самая сложная часть работы.
Вы уже догадались, о чем пойдет речь? Скажите это вслух.
Это кафкианский кошмар, где простые запросы превращаются в эпические саги, а тривиальные изменения требуют письменного обоснования, ревью кода, утверждения и благословения от того, кто уже не помнит, почему вообще существует это правило.
Это JIRA.
Добро пожаловать в джунгли
JIRA — неоспоримый чемпион по усложнению всего, чего только можно. Продаваемый как инструмент для совместной работы, прозрачности и поставки продукта, он обещает порядок и контроль.
Вместо этого, он надежно обеспечивает бюрократию и уныние.
Допустим, вы хотите зарегистрировать ошибку. Пока не исправить, просто зарегистрировать.
Вот как это выглядит:
- Выберите один из 37 различных типов формы. Это ошибка? Задача? Подзадача задачи, которая никогда не была должным образом определена? Никто не знает. Никто никогда не знал.
- Решите, к какой сфере она относится. Это оплаты или подписки? И то, и другое, значит, ни то, ни другое. Просто выберите что-то одно, а потом получайте нагоняй на летучке.
- Назначьте ее для спринта, которого еще не существует, или добавьте в текущий спринт в последний день и получите флаг «scope creep» («расползание рамок проекта»). Или просто выполните работу до начала спринта и «магическим образом» сделайте это в понедельник.
- Подождите, пока администратор JIRA (который неизбежно находится в другом часовом поясе) предоставит вам разрешения, которые вы должны были иметь ранее.
- Угодив в ловушку в правиле рабочего процесса, которого никто не понимает и за которое никто не чувствует себя ответственным, отчаянно пытайтесь заставить кого-нибудь (кого угодно) взять на себя ответственность за это.
Это похоже на государственную бюрократию, только без самого государства. Есть самоорганизующаяся команда, делающая вид, что существует какой-то центр контроля.
Система, которой никто не хотел
Не 3DO, нет. Это JIRA (тема этой статьи). Поскольку JIRA часто продают как инструмент для Agile-команд, можно подумать, что он будет сносным. Но это не так.
Он излучает энергию водопада настолько, что кажется, будто можно промокнуть.
Он навязывает бессмысленную управленческую нагрузку, называя это статусами, шлюзами, согласованиями, и внедряет структуры отчетности, которые вы не могли даже представить. Управленческая игра становится такой же трудоемкой, как и написание кода, но без того облегчения, которое приходит, когда вы решили проблему.
Хотя, кажется, я понял. Дело в том, что JIRA не помогает создавать программное обеспечение. Она помогает менеджерам генерировать отчеты о разработке ПО и отчитываться перед начальством.
Разработка ПО и составление отчетов — две совершенно разные вещи.
Современная разработка
Вот в чем абсурдность разработки в 2026 году.
Мы живем в мире, где разработчики могут:
- создавать шаблонный код за секунды;
- мгновенно запускать среды;
- автоматически генерировать тесты и документацию;
- поставлять продукт быстрее, чем когда-либо.
И все же, перемещение задачи из статуса «В работе» в статус «Готово» по-прежнему требует:
- множества согласований;
- комментария с объяснением, почему то, что вы отметили как завершенное, действительно завершено.
Мы можем автоматизировать работу, но не сам рабочий процесс.
Прогресс быстр. Разрешения медленны.
Личная хроника отчаяния
Для любого, кто работает с JIRA, американские горки эмоций выглядят примерно так:
Неделя 1
«Ладно, вроде полезная штука».
Неделя 2
«Почему мне нужно три согласования, чтобы обновить поле?»
Неделя 3
«Почему бэклог — это кладбище забытых идей?»
Неделя 4
«Почему простое исправление ошибки теперь требует шести шагов?»
Неделя 5
«Кто-нибудь вообще закрывал задачи?»
Неделя 6
«Я ненавижу это больше, чем свой собственный код».
В конце концов, вы уже не понимаете, чем занимаетесь — разработкой ПО или обработкой задач, причем в течение всего рабочего дня. Правда? Вы и разработчик на полную ставку, и обработчик задач на полную ставку, как и все мы.
Реальный результат
Скажу прямо. Система JIRA настолько плоха, что заставляет людей кардинально менять карьеру.
Интересно, почему так много инженеров «внезапно» переходят в консалтинг, DevRel или становятся инди-разработчиками? Дело не только в желании сбежать от ужасной кодовой базы или корпоративного бреда.
Дело в желании сбежать от JIRA и тех токсичных процессов, которые она создает.
Разработчики ПО любят создавать что-то. Они хотят писать код, тестировать его, поставлять и двигаться дальше. Никаких церемоний, связанных со статусом статусов. Никакого экзистенциального ужаса, вызываемого выпадающими меню. Это мечта, которую блокирует JIRA. Эта мечта просто неосуществима, когда вся система настроена таким образом, чтобы вы не смогли выполнить работу в срок.
Заключение
Неудивительно, что JIRA захватила мир. Владельцы продуктов и технические менеджеры ее обожают, ведь она помогает им достигать их целей. Поэтому все остальные вынуждены использовать JIRA.
Меня только удивляет, что они вроде как должны помогать разработчикам, но на практике не делают ничего подобного.
Просто вспомните проблемы, которые создает JIRA, когда вам будут говорит, что нет бюджета на инструмент, который экономит время и силы разработчика. Потому что бюджет на перетаскивание задач слева направо находится всегда.
Читайте также:
- 5 признаков того, что вы тратите свой потенциал разработчика впустую
- Один за всех и все за одного: 8 принципов командной разработки
- Куча советов по программированию, которые я дал бы себе сам после 15 лет опыта
Читайте нас в Telegram, VK и Дзен
Перевод статьи The Secret Developer: The Necessary Evil of Modern Software Development
